RAG 召回率与准确率怎么提升从查询改写到重排序码海寻道 · 大模型、智能体与 RAG 工程组件系列第 27 篇RAG 答错时不要直接把问题归因于大模型。先问两个问题相关资料有没有被召回召回后是否把最有用的片段排在前面前者主要影响召回率后者主要影响精确率和最终上下文质量。优化前应先建立一条可回放的检索链路保存原始问题、改写问题、权限过滤、各召回通道候选、Reranker 排名和最终上下文。否则一次参数调整后即使效果变好也很难知道究竟是哪一步贡献了收益。一、召回和准确率不是一回事假设标准答案需要 3 个 Chunk召回率关注这 3 个 Chunk 是否出现在候选结果中排名质量关注它们是否位于靠前位置最终答案准确率关注模型是否正确使用了这些 Chunk。召回不到 → 后面的步骤没有材料 排得太后 → 上下文预算可能放不下 资料正确但回答错 → Prompt 或生成环节有问题二、先建立可重复的评测集每条评测样本至少包含{question:北京出差的住宿上限是多少,relevant_chunk_ids:[doc-001:v3:0008],expected_answer:……,required_citations:[doc-001,page-6]}没有标注的评测集就无法判断一次调参到底提升了质量还是只是改变了结果。三、查询改写解决什么问题用户问题可能很短、含有代词或依赖上下文用户那上海呢系统需要结合历史对话改写成独立查询上海出差员工的住宿标准是多少改写时应保留用户意图不要加入未经证实的条件。建议记录原问题和改写问题便于排查改写是否引入偏差。四、查询扩展和多路召回对复杂问题可以生成多个检索角度原问题员工出差住酒店超标如何处理 查询 1住宿费用超出标准的处理流程 查询 2差旅报销超标审批规则 查询 3员工出差住宿费用补充说明多路查询能提高召回覆盖面但会增加 Embedding、搜索和去重成本。适合复杂问题不适合所有请求默认开启。五、Top K 应该怎样设置一个常见的两阶段策略向量库 Top 20 ↓ 过滤和去重 ↓ Reranker Top 5 ↓ 放入 Prompt向量库负责快速扩大候选范围Reranker 负责更精细地比较查询与候选文本的相关性。最终送入大模型的数量还要考虑 Token 预算和上下文冗余。六、Reranker 为什么有用Embedding 适合在大规模语料中快速找候选但它把问题和文档分别编码可能无法充分判断细粒度关系。Reranker 通常同时读取查询和候选文本再输出相关性分数。候选 A主题相似但没有回答具体条件 候选 B包含问题所需的数字和例外Reranker 可能把 B 排到 A 前面。代价是计算量更高因此一般只对 Top N 候选进行重排。七、如何避免重复和上下文污染按document_id、标题路径或相邻 Chunk 合并结果defdeduplicate(hits):seenset()output[]forhitinhits:key(hit[document_id],hit[chunk_id])ifkeynotinseen:seen.add(key)output.append(hit)returnoutput实际项目还应处理同一文档不同版本、相邻片段重复、表格行重复和多路查询重复。八、过滤条件会影响召回率过严的权限、版本或状态过滤可能把标准答案排除在外。排查时应同时记录未过滤候选数量权限过滤后数量版本过滤后数量Reranker 输入数量最终上下文数量。这样才能知道是“索引没有召回”还是“业务过滤后没有剩余结果”。九、使用阈值要谨慎相似度阈值可以过滤明显无关结果但分数受模型、距离指标、语料和查询长度影响。阈值必须使用验证集校准并按场景观察空结果率和误召回率。推荐保留两个策略有高质量结果 → 正常回答并引用 没有达到可信阈值 → 明确提示资料不足必要时转人工或追问不要为了让界面“总有答案”而把低相关片段强行交给大模型。十、提升效果的实验顺序固定 Embedding 与索引 ↓ 优化 Chunk 和元数据 ↓ 加入查询改写 ↓ 扩大候选 Top K ↓ 加入去重和 Reranker ↓ 尝试混合检索 ↓ 比较最终答案和成本一次只改一个主要变量保留实验配置和评测结果避免“感觉变好了”取代数据。建议把实验记录结构化保存experiment_id ├── embedding_model / chunk_policy ├── query_rewrite / top_k / rerank_n ├── filter_policy ├── RecallK / MRR / NDCG └── P95 延迟 / Token 成本 / 空结果率生产切换前还要做灰度流量和回滚准备不能只在离线数据集上确认效果。结语RAG 质量提升是一条完整链路先保证相关资料能被召回再通过查询改写、混合检索、去重和 Reranker 把有效片段排到前面最后评估大模型是否正确使用了上下文。下一篇将总结知识库最常见的失败模式并给出从上传、解析到回答的排查方法。参考资料Milvus 官方文档RerankingLlamaIndex 官方文档Query TransformationsLangChain 官方文档RetrieversLlamaIndex 官方文档Evaluation本文为“码海寻道”原创技术文章。召回参数和 Reranker 选择应基于目标领域评测集不宜直接复制通用阈值。
27.RAG召回率与准确率怎么提升从查询改写到重排序
RAG 召回率与准确率怎么提升从查询改写到重排序码海寻道 · 大模型、智能体与 RAG 工程组件系列第 27 篇RAG 答错时不要直接把问题归因于大模型。先问两个问题相关资料有没有被召回召回后是否把最有用的片段排在前面前者主要影响召回率后者主要影响精确率和最终上下文质量。优化前应先建立一条可回放的检索链路保存原始问题、改写问题、权限过滤、各召回通道候选、Reranker 排名和最终上下文。否则一次参数调整后即使效果变好也很难知道究竟是哪一步贡献了收益。一、召回和准确率不是一回事假设标准答案需要 3 个 Chunk召回率关注这 3 个 Chunk 是否出现在候选结果中排名质量关注它们是否位于靠前位置最终答案准确率关注模型是否正确使用了这些 Chunk。召回不到 → 后面的步骤没有材料 排得太后 → 上下文预算可能放不下 资料正确但回答错 → Prompt 或生成环节有问题二、先建立可重复的评测集每条评测样本至少包含{question:北京出差的住宿上限是多少,relevant_chunk_ids:[doc-001:v3:0008],expected_answer:……,required_citations:[doc-001,page-6]}没有标注的评测集就无法判断一次调参到底提升了质量还是只是改变了结果。三、查询改写解决什么问题用户问题可能很短、含有代词或依赖上下文用户那上海呢系统需要结合历史对话改写成独立查询上海出差员工的住宿标准是多少改写时应保留用户意图不要加入未经证实的条件。建议记录原问题和改写问题便于排查改写是否引入偏差。四、查询扩展和多路召回对复杂问题可以生成多个检索角度原问题员工出差住酒店超标如何处理 查询 1住宿费用超出标准的处理流程 查询 2差旅报销超标审批规则 查询 3员工出差住宿费用补充说明多路查询能提高召回覆盖面但会增加 Embedding、搜索和去重成本。适合复杂问题不适合所有请求默认开启。五、Top K 应该怎样设置一个常见的两阶段策略向量库 Top 20 ↓ 过滤和去重 ↓ Reranker Top 5 ↓ 放入 Prompt向量库负责快速扩大候选范围Reranker 负责更精细地比较查询与候选文本的相关性。最终送入大模型的数量还要考虑 Token 预算和上下文冗余。六、Reranker 为什么有用Embedding 适合在大规模语料中快速找候选但它把问题和文档分别编码可能无法充分判断细粒度关系。Reranker 通常同时读取查询和候选文本再输出相关性分数。候选 A主题相似但没有回答具体条件 候选 B包含问题所需的数字和例外Reranker 可能把 B 排到 A 前面。代价是计算量更高因此一般只对 Top N 候选进行重排。七、如何避免重复和上下文污染按document_id、标题路径或相邻 Chunk 合并结果defdeduplicate(hits):seenset()output[]forhitinhits:key(hit[document_id],hit[chunk_id])ifkeynotinseen:seen.add(key)output.append(hit)returnoutput实际项目还应处理同一文档不同版本、相邻片段重复、表格行重复和多路查询重复。八、过滤条件会影响召回率过严的权限、版本或状态过滤可能把标准答案排除在外。排查时应同时记录未过滤候选数量权限过滤后数量版本过滤后数量Reranker 输入数量最终上下文数量。这样才能知道是“索引没有召回”还是“业务过滤后没有剩余结果”。九、使用阈值要谨慎相似度阈值可以过滤明显无关结果但分数受模型、距离指标、语料和查询长度影响。阈值必须使用验证集校准并按场景观察空结果率和误召回率。推荐保留两个策略有高质量结果 → 正常回答并引用 没有达到可信阈值 → 明确提示资料不足必要时转人工或追问不要为了让界面“总有答案”而把低相关片段强行交给大模型。十、提升效果的实验顺序固定 Embedding 与索引 ↓ 优化 Chunk 和元数据 ↓ 加入查询改写 ↓ 扩大候选 Top K ↓ 加入去重和 Reranker ↓ 尝试混合检索 ↓ 比较最终答案和成本一次只改一个主要变量保留实验配置和评测结果避免“感觉变好了”取代数据。建议把实验记录结构化保存experiment_id ├── embedding_model / chunk_policy ├── query_rewrite / top_k / rerank_n ├── filter_policy ├── RecallK / MRR / NDCG └── P95 延迟 / Token 成本 / 空结果率生产切换前还要做灰度流量和回滚准备不能只在离线数据集上确认效果。结语RAG 质量提升是一条完整链路先保证相关资料能被召回再通过查询改写、混合检索、去重和 Reranker 把有效片段排到前面最后评估大模型是否正确使用了上下文。下一篇将总结知识库最常见的失败模式并给出从上传、解析到回答的排查方法。参考资料Milvus 官方文档RerankingLlamaIndex 官方文档Query TransformationsLangChain 官方文档RetrieversLlamaIndex 官方文档Evaluation本文为“码海寻道”原创技术文章。召回参数和 Reranker 选择应基于目标领域评测集不宜直接复制通用阈值。