向量检索善于找到语义接近内容，关键词检索更擅长产品编号、姓名和原文术语。混合检索应让两路独立召回，再用统一文档 ID 融合，而不是把两组结果直接拼接后交给模型。 本文用 Qdrant Hybrid Queries 的思路说明流程，未在你的索引、嵌入模型和语料上实测；稀疏向量生成、融合公式和索引字段应按实际版本文档配置。
本篇验收要点：同一查询分别产生稠密向量和稀疏表示，两路各取候选后再用融合查询或稳定的排名融合方法合并。 每个文档片段使用稳定 point_id 或 chunk_id，融合后先按该 ID 去重，再把保留的分数和来源传给生成模型。
开始前准备
- 带稳定 chunk_id 的语料
- 稠密向量和可用的稀疏/关键词表示
- 至少 30 条带相关文档标注的问题
- 可以输出两路候选和融合分数的调试接口
按顺序搭建
- 为每个片段保存 chunk_id、document_id、title、version 和正文；重新索引时同一业务片段的标识策略要稳定。
- 建立稠密向量索引和稀疏向量索引。用包含编号的查询检查关键词路，用同义表达检查向量路，先分别验证。
- 对同一问题从两路各取 Top-N 候选。保留原始排名和分数，不要把不同量纲的分数直接相加。
- 使用 Qdrant 支持的融合查询或 RRF 等排名融合，将结果按 chunk_id 去重；同文档相邻片段可在生成前再做聚合。
- 在固定测试集上比较向量单路、关键词单路和混合检索的 Recall@K，并人工检查新增命中是否真的相关。
可复制的最小示例
调试输出至少要保留两路排名和融合结果：
query: "A-17 控制器复位方法"
dense: [(c81, 0.78), (c12, 0.74)]
sparse: [(c12, 9.30), (c44, 7.10)]
fused: [c12, c81, c44]
dedup key: chunk_id
注意：9.30 与 0.78 不直接相加
怎样验收结果
验证标准是含精确编号和同义表达的测试问题都能在 Top-K 找到标注文档，融合结果没有重复 chunk_id，离线指标优于至少一个单路基线且人工抽查没有明显噪声激增。
- 分别查看 dense 与 sparse 候选
- 融合前保留原始排名
- 按稳定 chunk_id 去重
- 用固定标注集计算 Recall@K
常见失败与处理
- 关键词候选为空：检查稀疏向量生成和字段索引。
- 融合后重复：统一 point_id/chunk_id，不能按正文字符串临时去重。
- 混合结果更差：调整两路候选数和融合方式，并检查关键词路噪声。
读者下一步是从日志中挑 10 个向量检索漏掉的编号或术语问题，建立标注文档，再比较三种检索结果。
相关问答
混合检索一定优于向量检索吗？
不一定。语料和查询类型决定收益，必须用同一标注集比较。
可以把 BM25 分数和余弦分数直接相加吗？
两者量纲不同，未经校准直接相加通常不可靠；优先使用排名融合或平台支持的融合查询。
官方资料与适用边界
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/32457.html
