企业知识库为什么答不准？RAG 效果评估的五个关键指标

我们在做企业知识库项目的头两年，最常听到的一句反馈是：「它有时候答得挺准，有时候答得离谱。」 追问「大概多少比例是准的」，回答往往是「感觉一半一半」。 「感觉」这个词，是企业 AI 项目最大的风险来源。

一个 RAG（检索增强生成）系统从提问到回答，至少要经过四个环节： 问题理解 → 文档检索 → 上下文组装 → 答案生成。任何一个环节出问题，最终表现都是「答不准」。 如果只看最终答案对错，你永远不知道该改哪一环。

一、为什么必须拆开评估

假设一个知识库的答案正确率是 65%。这个数字本身没有任何指导意义，因为下降的原因可能完全相反：

• 检索没找到：正确文档根本没进候选集，模型再强也答不出来。
• 检索找到了但排序靠后：正确片段被截断在上下文窗口之外。
• 检索和上下文都对，模型自己编了：这是生成环节的忠实度问题。
• 问题本身超出知识库范围：系统应该拒答，却硬着头皮回答了。

这四种情况的修复动作完全不同：第一种要改切分与索引，第二种要调重排，第三种要改提示词或换模型， 第四种要加拒答阈值。用同一个「正确率」指标去衡量，等于把四种病当成一种治。

二、五个必须测的指标

1. 召回率（Recall@K）

在标准答案所需的文档中，有多少被检索进了前 K 个候选。 这是整个链路的天花板——召回不到的内容，后面任何环节都救不回来。 工程上建议同时看 Recall@5 和 Recall@20，前者反映用户体验，后者反映重排空间。

2. 上下文精度（Context Precision）

进入上下文窗口的片段里，真正有用的占多少比例。 精度低意味着大量无关内容挤占窗口，既抬高成本，也容易诱导模型答偏。 常见病根是切片过大、元数据缺失、多版本文件未去重。

3. 忠实度（Faithfulness）

答案中的每个论断，是否都能在给出的上下文里找到依据。 这是最容易被忽略、也最容易造成事故的指标：答案读起来很专业，但内容是模型编的。 在金融、医疗、政务场景，忠实度不达标就不该上线。

4. 答案相关性（Answer Relevancy）

答案是否真正回应了提问。忠实但答非所问的情况很常见，尤其在多轮对话里—— 模型可能忠实复述了上一轮的上下文，却忽略了用户这一轮问的是什么。

5. 拒答准确率（Refusal Accuracy）

对知识库范围外的问题，系统是否正确拒答并引导人工。 这个指标直接决定用户信任：一个会说「我不知道」的系统，比一个永远自信的系统可靠得多。 实践中建议单独构建一批「应当拒答」的测试问题，占比不低于评测集的 15%。

三、评测集怎么建才不浪费时间

很多团队卡在这一步：想建一个几百条的高质量评测集，结果业务方没空标注，项目就搁置了。 我们的建议是先小后大，先窄后宽：

1. 第一周先做 50 条。从真实工单、客服记录、内部群聊里直接摘问题，保证是真人真问。
2. 每条标注「标准答案 + 依据文档段落」。只标答案不标依据，后面无法判断是检索问题还是生成问题。
3. 刻意留出 15% 的「不该答」问题。用来测拒答，这部分最容易被漏掉。
4. 把评测集纳入版本管理。每次改切片、改提示词、换模型都跑一遍，看指标是升还是降。
5. 每月从线上补充 20 条新问题。让评测集跟着真实使用一起进化。

我们的经验是：50 条标注良好的评测集，比 500 条随手标的有用得多。 关键不在数量，而在每条都能回答「错在哪一环」。

四、上线之后看什么

离线指标解决「能不能上线」，线上指标解决「上线后有没有变差」。我们通常会在控制台挂四类监控：

• 无引用回答占比：突然升高通常意味着检索侧出了问题，比如索引没更新。
• 用户追问率：同一会话内连续追问三次以上，往往说明第一次回答没解决问题。
• 点踩问题的聚类：按主题聚类，能快速定位是哪一批文档或哪类问题系统性失效。
• 人工转接率：在有人工兜底的场景里，这是最诚实的满意度指标。

五、一个常被忽略的前提

最后想说一句可能不太受欢迎的话：如果企业的文档本身质量很差，任何 RAG 方案都救不了。 我们接手过的失败项目里，相当一部分根因是知识库源文件本身存在大量过期版本、互相矛盾的制度、 扫描件识别错误。这类问题必须在数据准备阶段解决，而不是指望模型「理解个大概」。

所以我们的项目排期里，数据清洗与知识结构梳理通常占到总工期的 40%。 这个比例看起来不性感，但它决定了整个系统的效果上限。