RAG 系统质量诊断实战：从"能答"到"答得准"的四个关键改造

很多团队做 RAG（检索增强生成）系统，第一反应是"换个更强的模型、换个更贵的向量数据库"，折腾一个月后发现效果还是不行。问题往往不在模型能力上，而是出在整条链路上：文档解析、分块策略、向量检索、重排序、上下文拼装，任何一个环节薄弱，最终答案都会跑偏。这篇文章不讲概念，直接给出一套可落地的诊断方法：先建评测集、量化三个核心指标，再针对不同病灶给出对应的改造方案，最后聊几个容易被忽视的工程细节。

一、先做"体检"：三个指标定位问题环节

RAG 系统答错，故障可能发生在任何环节。要定位问题，第一步是建评测集：从业务部门的历史数据里收集 300-500 条真实问题——客服工单、高频咨询、技术支持记录都行，前提是"知识库中一定存在可支撑答案的内容"。然后让现有系统逐条回答，人工判定结果属于"正确、部分正确、错误、拒答"四类中的哪一类。

有了评测集，重点看三个指标：

召回率（Recall）：拿一条测试问题，检查检索环节返回了哪些片段，正确答案对应的文档片段有没有被召回到。如果连片段都检不到，模型再聪明也答不对。这里建议分两类统计：一类是问法直接命中原文关键词的问题，一类是问法和原文说法差异很大的问题。后者召回率低，往往说明向量检索的语义理解能力不足，需要换 embedding 模型或引入混合检索。

排序质量（Ranking）：召回了一堆片段，但正确答案排在第 5 位之后，命中了却被后续环节丢掉。测试时看 Top-5 里正确片段的排位，如果正确答案经常出现在第 3 名以后，就要考虑加 rerank（重排序）环节，或调整向量索引的相似度计算方式。

噪声比例（Noise）：返回的 10 个片段里有 7 个是无关内容，即使正确答案在里面，模型也容易被带偏。这个问题通常出在索引粒度上：分块切得太碎，一个完整知识点被拦腰截断；或者知识库里混着大量模板化、无效内容，把有价值的文档稀释了。

这三个指标的优先级很明确：先解决召回，再解决排序，最后解决噪声。召回是地基，地基不牢，后面的优化都是空中楼阁。

二、病灶一：召回率低——混合检索与 embedding 升级

召回率低的典型表现是"换一种说法就查不到"。两个改造方向：

第一，引入混合检索（Hybrid Search）。纯向量检索对语义相近的表述很友好，但对精确关键词（型号、编号、人名、专有名词）不敏感；纯关键词检索（BM25）正好相反。混合检索就是把两者结合起来：同一查询同时跑向量检索和 BM25，结果合并去重后按相关度加权排序。主流向量数据库（Milvus、Weaviate、Qdrant）都内置了混合检索能力，实践效果通常是立竿见影的。

# 伪代码：混合检索示意vector_hits=vector_store.similarity_search(query,k=20)bm25_hits=bm25_index.search(query,k=20)merged=merge_and_rerank(vector_hits,bm25_hits)# 加权融合

第二，换更强的 embedding 模型。embedding 模型决定语义理解的粒度，是"问法不同也能查到"的关键。选择 embedding 模型时不要只看榜单分数，要用你自己的业务问题实测：把评测集里"问法差异大"的那批问题跑一遍，对比不同 embedding 模型的召回率。通用模型在垂直领域（法律、医疗、金融术语）往往表现一般，必要时微调或选用领域专用模型。

三、病灶二：排序不对——重排序（Rerank）环节

召回率上去了，但正确答案埋在长尾里，模型取不到——这是排序问题。RAG 架构里，"召回"和"排序"应该是两个独立环节：粗召回（向量+BM25，取 20-50 个候选，要求快）、精排序（reranker 模型对候选逐条打分，取 Top-3 到 Top-5 给模型）。

Reranker 与 embedding 的本质区别：embedding 把查询和文档分别编码成向量算余弦相似度，是"先压缩再比较"；reranker 则把查询和文档拼在一起做深度交叉编码，精度更高但速度慢。所以架构上必须分层——快召回、慢精排，各司其职。

fromFlagEmbeddingimportFlagReranker reranker=FlagReranker("BAAI/bge-reranker-base")query="合同违约金的计算标准是什么？"candidates=["片段A","片段B","片段C"]scores=reranker.compute_score([[query,c]forcincandidates])ranked=sorted(zip(candidates,scores),key=lambdax:-x[1])top3=[cforc,_inranked[:3]]

加了 rerank 之后，评测集上的"排序质量"指标应该明显改善。如果改善不明显，检查候选数量是否足够——粗召回只取 3 个，rerank 再准也没用，候选池至少要到 20 个以上。

四、病灶三：噪声大——分块策略与数据治理

噪声比例高，多半是索引建得糙。两个层面：

分块策略。分块粒度直接影响检索质量：切得太碎，一个完整知识点被腰斩，检索到的只是半截话；切得太粗，一个块里混着多个主题，检索命中但信息混杂。推荐做法是语义分块：以段落和标题为锚点，按语义完整性合并相邻内容，而不是粗暴地按固定字符数切。对表格、代码、合同条款这类特殊内容，要用专门的结构化解析，保留其格式信息，否则向量化后信息丢失严重。

数据治理。知识库里的脏数据会持续稀释检索质量：过期的制度文件、重复的模板内容、未清理的 OCR 乱码。上线前要做一轮清洗，建立"内容准入"标准；运行中要做质量监控，定期统计"检索零命中"的查询，反查是数据缺失还是索引故障。知识库是活的东西，不进则退。

五、上下文拼装：给模型"喂什么"决定答案质量

检索做对了，最后一步是拼 Prompt。这里有几个容易踩的坑：

第一，控制注入量。不是召回越多越好。Top-5 片段塞进去，如果中间夹着两个不相关片段，模型就会被带偏。实践经验：给模型的片段控制在 3-5 个，每个片段控制在 200-400 字，宁缺毋滥。

第二，明确指令约束。系统提示词要写清楚："仅根据提供的资料回答，资料中没有的信息明确说明不知道，不要臆造。"这是抑制幻觉最关键的一步。同时给片段编号，让模型回答时能标注依据，方便溯源。

第三，提供"拒绝路径"。资料不足以回答时，模型要有明确的行为约定——“回答：资料中未找到相关信息”，而不是强行编一个。评测集里"拒答"类目就是用来衡量这个行为的。

第四，结构化输出。业务系统通常需要模型输出 JSON（抽取合同要素、生成工单结构化描述），配合 response_format 强制 JSON 模式，并做好解析容错。

SYSTEM_PROMPT="""你是知识库问答助手。仅根据【资料片段】回答问题。 规则： 1. 只使用资料中的信息，不得添加资料之外的内容； 2. 2. 资料无法回答时，回复"资料中未找到相关信息"； 3. 3. 回答中标注引用片段编号，如（片段1）。"""context="\n\n".join(f"[片段{i}]{text}"fori,textinenumerate(top3,1))prompt=f"{SYSTEM_PROMPT}\n\n【资料片段】\n{context}\n\n【用户问题】{question}"

六、进阶：多路召回、知识图谱与智能路由

基础改造做完，正确率可能已经不错，但距离"答得准"还有最后一公里。进阶方向有三个：

多路召回。同一问题同时从文档库、数据库、知识图谱多个来源召回，再统一融合。典型场景：制度问答需要查文档，指标问答需要查业务数据，多路召回让 RAG 从"文档问答"升级为"系统问答"。

知识图谱补强。向量检索对"实体关系类"问题（“哪些产品属于 A 部门负责”）天然薄弱，知识图谱擅长这种结构化的多跳推理。架构上：实体和关系入库，查询时先做实体识别，用图谱补全关联信息，再和向量结果融合。成本不低，适合关系密集型业务。

查询改写与意图路由。"违约金怎么算"和"合同里违约条款是什么"应该走不同路径。入口加一个轻量意图分类，把查询改写（扩写、纠错、拆解）后再进检索链路，能显著提升复杂查询的命中率。这个环节在 2026 年的 RAG 工程里已经是标配——查询质量决定了检索质量的天花板。

七、评估与监控：让系统持续变好

最后是长期运营的问题。RAG 系统上线不是终点，效果会随着数据变化而漂移。三件事必须做：

1. 评测集固化：把 300-500 条问题固化为回归测试集，每次升级（换模型、改分块、调参数）全量跑一遍，用四分类正确率对比新旧版本，防止"修好 A 弄坏 B"。
2. 2. 线上监控：跟踪回答延迟、token 成本、检索命中率、用户反馈（赞/踩），异常波动及时告警。
3. 3. 反馈闭环：用户标记"答错了"的问题自动进入待优化池，定期人工标注后补进评测集——知识库和评测集都要持续生长。

结语

RAG 系统"答不准"，90% 的原因不在模型，而在链路：数据脏、分块糙、召回弱、排序乱、拼装差。与其盲目换模型，不如先建评测集、量化指标、定位病灶。召回用混合检索，排序加 rerank，噪声靠语义分块和数据治理，拼装靠精确的上下文控制——每一步都是可验证、可量化的工程优化。把这条链路打磨扎实，RAG 才能真正成为可靠的企业知识基础设施，而不是"演示很惊艳、落地没人用"的摆设。