测试一个“听起来对、实际上错”的 RAG 流水线

结论

一个「听起来对」的回答，可能错在检索，也可能错在生成。把两边揉进一个总分，你就会用一周去调不该调的那一层。

先把流水线拆开，再选指标。上下文精确率高、忠实度低：检索把对的段落拿回来了，生成器没用它们。上下文召回率低：缺的是索引或切分，不是提示词文采。

四件套，以及它们各自怪谁

Ragas、DeepEval 以及多数 2026 年的评测框架，都围绕同一组意图，名字略有出入：

没有标注答案时，这四项大多可以走「模型当裁判」。裁判模型会偏爱流畅、偏爱长、偏爱和自己相似的说法。所以裁判只能当回归报警，不能当唯一的发布标准。对外声称的质量，仍然要有一小份人工判过的题。

工具怎么配，而不是怎么站队

• Ragas：检索专项和数据集流水线。适合先回答「库本身行不行」。
• DeepEval：断言要和现有 pytest 放在一起、失败要挡住合并时用它。它另外提供按标准打分的 GEval，适合业务规则无法收成忠实度的场合。
• Arize Phoenix：要沿着一次请求的 trace 看出是哪一步掉下去的时候用它。指标报警之后，没有 trace 就只能猜。

三者经常一起用，而不是三选一。检索分用 Ragas 或 DeepEval 的同类指标；门禁用 pytest 断言；线上回放用 Phoenix 一类的追踪。LangSmith 等宿主内的追踪是同一角色的另一条实现，选型看你的调用已经落在哪套栈里。

黄金集决定上限

上面每个框架都吃题目。题目的质量封顶下游所有分数。五十条被业务方改过的问答，胜过五百条爬来的「问题—文档」对。

一份能用的题至少要有：用户原话、必须出现的事实、允许拒答的条件、不该被引用的易混文档。只存「标准答案」段落，测的是复述，不是检索。

建议把题分成三筐，比例可以按业务改，但三筐都要有：

1. 库里有、且唯一，测召回和忠实。
2. 库里有、但有近邻干扰，测精确率。
3. 库里没有，测拒答。没有这筐，系统会用流畅的编造拿高分。

每次改切分或嵌入，都重跑这三筐，不要只看总平均。总平均上升、拒答筐下降，是常见的假进步。

上线前的最小门禁

1. 检索指标和生成指标分列，禁止合并成一个「质量分」作为唯一门槛。
2. 黄金集有版本号，和索引版本一起记在同一次运行里。
3. 裁判模型的名字和温度写进报告。换裁判等于换尺子。
4. 抽 20 条低分样本看原文。指标不能解释的失败，比指标本身重要。

材料边界

指标定义综合 Ragas / DeepEval 在 2026 年的公开对比（包括 Atlan、Maxim 的工具综述）。本文不给出任何客户的线上分数。