4.4RAG 评估与优化

先给直觉

RAG Demo 很容易做出“能回答”的效果。

但真正的问题是：

• 它找到了正确资料吗？
• 它有没有漏掉关键资料？
• 它有没有把无关资料塞给模型？
• 模型有没有根据资料回答？
• 引用是否真的支持结论？
• 资料不足时有没有承认不知道？

RAG 评估不是问“它有没有说话”，而是问“它说得是否有依据、可检查、可改进”。

RAG 评估的两层

RAG 至少要评估两层：

检索层：资料找得对不对
生成层：回答写得对不对

如果回答错了，原因可能在检索，也可能在生成。

例子：

用户问：

RAG 和微调有什么区别？

错误回答可能来自：

• 没检索到讲 RAG 和微调区别的片段。
• 检索到了，但排序太低，没有放进上下文。
• 放进上下文了，但模型误读。
• 模型回答正确，但引用错了。

不分层评估，就很难知道该改哪里。

构建测试问题集

评估前先建立问题集。

问题集要覆盖真实用户会问的问题，而不是只挑系统擅长的问题。

建议至少包含：

类型	示例	检查重点
直接事实	Token 是什么？	是否找对定义
概念解释	为什么模型会幻觉？	是否解释清楚
对比问题	RAG 和微调有什么区别？	是否找全差异
应用问题	什么时候需要向量检索？	是否能结合场景
边界问题	RAG 能彻底解决幻觉吗？	是否说明限制
资料不足	课程有没有讲某个未覆盖工具？	是否承认不知道
多跳问题	Agent 和工具调用有什么关系？	是否组合多个片段

问题集不用一开始很大，但必须有代表性。

检索评估

检索评估关注：

系统有没有把正确资料找回来？

召回

召回关注正确资料是否被找到。

如果正确片段没进入候选结果，后面模型再强也很难答对。

检查方式：

• 为每个测试问题标注理想参考片段。
• 看检索结果 Top-k 中是否包含这些片段。

排名

找到还不够，还要排名靠前。

如果正确资料排在第 20 位，而系统只取 Top-5，它等于没找到。

噪音

检索结果里无关片段太多，会干扰模型。

噪音常见来源：

• Chunk 太大。
• 关键词误匹配。
• Embedding 语义偏差。
• 元数据过滤不足。
• 重复文档太多。

回答评估

回答评估关注：

模型有没有基于资料给出正确、清楚、可验证的回答？

正确性

回答是否符合资料和事实。

完整性

是否遗漏关键点。

Groundedness

Groundedness 可以理解为“回答是否站在资料上”。

也就是：

• 结论是否能被检索资料支持。
• 是否加入了资料里没有的内容。
• 是否把推测写成事实。

引用准确率

引用是否：

• 真实存在。
• 指向正确片段。
• 支持对应结论。

引用不是装饰。引用不支持结论，比不引用更糟，因为它会给错误披上外套。

不确定性处理

资料不足时，模型是否承认不知道。

RAG 系统的可靠性，很大一部分体现在它什么时候愿意停下来。

常见失败类型

失败 1：检索不到

原因可能是：

• 问题表达和文档表达差异太大。
• Embedding 模型不适合。
• Chunk 切分不合理。
• 没有关键词检索补充。

失败 2：检索到但不相关

原因可能是：

• Top-k 太大。
• 文档重复。
• 元数据过滤不足。
• 相似但不支持答案的片段混入。

失败 3：检索正确但模型误读

原因可能是：

• Prompt 没要求只基于资料回答。
• 上下文太长。
• 资料之间有冲突。
• 模型能力不足。

失败 4：回答正确但引用错误

原因可能是：

• 引用生成没有绑定片段 ID。
• 模型自己编引用。
• 上下文组装时丢失来源。

失败 5：资料不足却强答

原因可能是：

• Prompt 没有停止规则。
• 模型倾向于补全。
• 系统没有检测低置信检索。

优化方法

优化 1：改问题理解

使用查询改写，让检索问题更明确。

例如把：

它和微调有什么区别？

改写成：

RAG 和微调有什么区别？

优化 2：改 Chunk

如果正确资料经常被切碎，就调整切分策略。

优化 3：加元数据过滤

按模块、文档类型、权限、时间过滤，减少无关资料。

优化 4：混合检索

结合向量检索和关键词检索。

优化 5：重排

对候选结果重新排序，提高上下文质量。

优化 6：改 Prompt

要求模型：

• 只根据资料回答。
• 引用来源。
• 资料不足时说明。
• 不把推测写成事实。

优化 7：模型升级或路由

如果资料正确但模型经常误读，可能需要更强模型或任务拆解。

成本与延迟优化

RAG 优化不只看准确性。

还要看：

• 检索耗时。
• 重排耗时。
• 输入 Token 数。
• 输出 Token 数。
• 模型调用成本。
• 缓存命中率。

优化方向：

• 缓存常见问题。
• 控制 Top-k。
• 合并重复片段。
• 对简单问题走轻量链路。
• 对高风险问题走强链路。
• 异步处理长任务。

评估记录模板

建议为每个问题记录：

字段	说明
question	用户问题
expected_sources	理想来源
retrieved_sources	实际检索来源
retrieval_score	检索评分
answer	模型回答
answer_score	回答评分
citation_score	引用评分
failure_type	失败类型
fix_suggestion	修复建议

没有记录，就没有优化。靠感觉调 RAG，很快会进入玄学园区。

案例：课程问答助手评估

问题：

RAG 能彻底解决幻觉吗？

理想来源：

• 04_rag_knowledge/01_why_rag/lesson.md
• 09_ai_safety_governance/01_hallucination/lesson.md

评估：

• 如果只检索到 RAG 定义，回答可能不完整。
• 如果检索到幻觉章节，回答会更可靠。
• 如果模型说“RAG 可以彻底解决幻觉”，就是边界错误。
• 如果引用了不相关的向量检索章节，引用质量有问题。

优化：

• 增加边界类问题测试。
• 强化 Prompt 中“说明限制”的要求。
• 调整检索，让幻觉相关章节进入候选。

常见误区

误区 1：回答看起来对，就不用评估

看起来对不够。要检查资料、引用和失败案例。

误区 2：只评估最终答案

必须分开评估检索和生成，否则不知道问题出在哪。

误区 3：测试问题越简单越好

简单问题只能证明系统会答简单问题。真实用户不会这么配合。

误区 4：RAG 优化就是调 Top-k

Top-k 只是一个参数。文档、切分、检索、重排、Prompt、模型都会影响效果。

误区 5：没有标准答案就不能评估

可以用参考资料、Rubric、人工评分和失败类型记录来评估。

动手练习

为课程问答助手设计 15 个测试问题。

要求包含：

• 3 个概念解释。
• 3 个对比问题。
• 3 个应用问题。
• 2 个边界问题。
• 2 个资料不足问题。
• 2 个多跳问题。

然后为每个问题标注：

• 理想来源。
• 可接受回答标准。
• 常见失败类型。