RAG 召回评估实战：用向量检索和重排序减少答非所问

很多 RAG 知识库问答效果不好，并不是大模型“不会回答”，而是检索阶段没有把正确资料拿出来。模型拿到的上下文不相关，再强的生成能力也只能编得更像。真正要提升 RAG 质量，第一步应该盯住召回质量，而不是只换更大的模型。

本文用企业知识库问答场景，拆解一条可落地的 RAG 检索链路：文档切分、向量化、Top-K 召回、混合检索、重排序、上下文拼接和离线评估。重点是建立“发现问题、定位原因、调参复测”的闭环。

摘要

RAG 的稳定性取决于检索质量。建议先构建测试问题集和标准来源文档，用 Recall@K、MRR、nDCG 等指标衡量召回，再按失败类型调整 chunk 大小、top_k、混合检索权重和重排序阈值。这样优化有证据，不靠感觉改参数。

适合人群

适合正在做 AI 知识库、客服机器人、企业文档问答、代码库问答或内部搜索增强的开发者。示例不绑定某个厂商，向量模型、向量库和大模型都可以替换。

目录

1. 为什么 RAG 会答非所问
2. 一条完整的检索链路
3. 文档切分和元数据设计
4. 向量召回、混合检索与重排序
5. 用指标评估召回质量
6. 常见失败样本和调优方向

一、为什么 RAG 会答非所问

RAG 常见问题通常出在这几类地方：

• 文档切分太粗，正确答案被埋在很长的段落里；
• 文档切分太碎，单个片段缺少上下文，语义不完整；
• 只做向量召回，关键词、编号、产品名等精确匹配效果差；
• Top-K 太小，正确资料没进入候选集；
• Top-K 太大，噪声上下文太多，模型被干扰；
• 没有离线评估集，每次调参都靠主观试问。

所以 RAG 优化要先把检索链路拆开看：问题有没有召回到正确文档？正确文档排在第几位？进入最终上下文的是不是最相关片段？

二、一条完整的检索链路

一个比较完整的 RAG 检索链路可以拆成 8 步：

1. 文档清洗：去掉页眉页脚、重复导航、无意义空行；
2. 文档切分：按标题、段落、句子或固定长度切成 chunk；
3. 向量化：把 chunk 转成 embedding，并保存向量和元数据；
4. 召回：根据用户问题做 Top-K 向量检索；
5. 混合检索：把关键词检索和向量检索结果融合；
6. 重排序：用 rerank 模型重新排列候选片段；
7. 上下文拼接：按相关性、来源和长度限制组织上下文；
8. 生成回答：让模型基于上下文回答，并保留引用来源。

不要把 RAG 当成“向量库查一下再问模型”。如果没有重排序和评估，很多问题会被隐藏在看起来还不错的 demo 里。

三、文档切分和元数据设计

文档切分不是越小越好。建议先按业务文档结构切分，再用固定长度做兜底：

def split_text(text: str, max_chars: int = 800, overlap: int = 120) -> list[str]:
    chunks = []
    start = 0
    while start 

每个 chunk 建议保存这些元数据：

• 文档 ID、标题、章节路径；
• 来源 URL 或文件路径；
• 页码、段落序号、更新时间；
• 业务标签，例如产品线、权限范围、语言版本。

元数据可以用于过滤，比如只检索某个产品线的文档，或优先返回最近更新的版本。

四、向量召回、混合检索与重排序

向量召回适合语义相近的问题，但对编号、函数名、错误码、版本号不一定敏感。因此生产里常见做法是混合检索：向量召回负责语义，关键词检索负责精确匹配，再把两路结果融合。

def hybrid_retrieve(question: str, top_k: int = 30) -> list[dict]:
    dense_hits = vector_search(question, top_k=top_k)
    keyword_hits = keyword_search(question, top_k=top_k)
    merged = reciprocal_rank_fusion([dense_hits, keyword_hits])
    return merged[:top_k]

重排序负责在候选集里做更细的相关性判断。常见策略是先召回较多候选，例如 30 到 50 条，再用 rerank 模型选出最相关的 5 到 8 条进入上下文。

def build_context(question: str) -> list[dict]:
    candidates = hybrid_retrieve(question, top_k=40)
    ranked = rerank(question, candidates)
    return [item for item in ranked if item["score"] >= 0.35][:8]

重排序阈值不要拍脑袋设。阈值太低，噪声进入上下文；阈值太高，可能没有足够资料回答。更可靠的方法是用测试集评估。

五、用指标评估召回质量

先准备一批测试问题，每个问题标注应该命中的来源文档。然后记录检索结果，计算几个基础指标：

• Recall@K：前 K 个结果里是否包含标准来源，衡量“有没有找回来”；
• MRR：第一个相关文档排名越靠前越好；
• nDCG@K：考虑相关性和排名位置，衡量整体排序质量；
• 失败样本分布：把没召回、排名靠后、相关性误判分开分析。

def recall_at_k(results: list[list[str]], ground_truth: list[set[str]], k: int) -> float:
    hit = 0
    for doc_ids, expected_ids in zip(results, ground_truth):
        if set(doc_ids[:k]) & expected_ids:
            hit += 1
    return hit / max(len(results), 1)

调参时不要只看单个问题，要看整体指标和失败样本。否则很容易为了修复一个问题，牺牲一批原本正常的问题。

六、常见失败样本和调优方向

1. 正确文档没有进入 Top-K

优先检查 chunk 大小、embedding 模型和 top_k。可以适当扩大 top_k，再用重排序过滤噪声。

2. 正确文档召回了，但排名很靠后

通常需要重排序模型，或者调整混合检索融合权重。关键词明显的问题，可以提高关键词检索权重。

3. 问题包含编号、错误码、配置项

纯向量召回可能不稳定。建议增加关键词检索、字段过滤或元数据约束，例如按产品线、版本号、模块名过滤。

4. 上下文太长，模型回答混乱

减少进入上下文的片段数量，或者按章节合并相邻片段。上下文不是越多越好，重点是相关、完整、可引用。

七、资料依据

本文写作时参考了官方文档中的工程概念：OpenAI Embeddings 文档、Milvus 检索与重排序相关文档、LangChain RAG 检索相关文档。本文示例为原创整理，参数和架构需要结合具体业务数据评估。

八、总结

RAG 优化不要从“换模型”开始，而要从“检索是否拿到正确资料”开始。先建立测试问题集和标准来源，用 Recall@K、MRR、nDCG 定量评估，再围绕 chunk、top_k、混合检索、重排序和上下文拼接逐步调优。有了评估闭环，RAG 才能从 demo 走向稳定的生产应用。