大部分 RAG 系统的评测流程长这样:团队盖好,创始人问五个问题,答案看起来不错,出货。三个礼拜后客户开始抱怨答案有错,团队完全没法判断是哪一段管线坏掉。
认真做 RAG 评测不是选配。它决定了你出货的是「平均看起来能跑」的系统,还是「真实长尾问题不会烂」的系统。
这篇是实务 playbook:两条评测轴线、一份 golden dataset、真的能抓到 bug 的指标。
为什么「答案看起来不错」不够
RAG 至少有三种不同的失败模式,从外面看一模一样:
- 检索失败。 对的文档根本没进 top-K,模型靠自己的参数记忆乱答(经常错)。
- 检索成功,但生成没理它。 对的文档在 context 里,模型还是用自己原本的偏见回答。
- 检索成功、生成有用,但文档本身是错的 / 过时的。 这是内容问题,不是系统问题。
当创始人只是用眼睛看五个答案,他根本看不出来是哪一种模式在失败。每一种要修的东西都不一样。所以你必须分开评测检索跟生成。
先建 golden dataset
没这个其他都不重要。RAG 的 golden dataset 就是一串三元组:
{ question, ideal_answer, ideal_source_document_ids }
最小可用:30 题。甜蜜点:100-300 题。内容混搭:
- 简单题。 单文档、字面比对。(健全测试。)
- 中等。 多文档整合、需要改写。(真实使用主体。)
- 难题。 多跳推理、矛盾来源、时效相关。(暴露系统极限。)
- 超出范围。 你的 corpus 无法回答的题目。系统应该说「不知道」,不能瞎掰。
写这些很烦,也是整个项目 ROI 最高的工作。没 golden 集的团队就是蒙眼飞行。
从哪里来:真实用户 log、客服工单、现有 FAQ。如果还没用户,就坐在 corpus 前面自己写 30 题。
检索评测:对的文档回来了吗?
这部分最被低估。把每题只跑检索(不跑生成),检查理想来源 ID 有没有出现在 top-K。
三个指标:
- Recall@K。 K 笔结果里,对的文档有没有出现?如果 recall@5 = 60%,在 LLM 还没看到问题之前你就已经损失 40% 答案了。
- Precision@K。 K 笔里有几笔是相关的?precision 低 = LLM 在垃圾堆里找东西。
- MRR(Mean Reciprocal Rank)。 对的文档在第 1 位 = 1.0,第 2 位 = 0.5,第 5 位 = 0.2。抓「排多前面」。越接近 1.0 越好。
2026 年,在干净的 corpus 上 recall@10 低于 80% 代表检索要修了 —— 大概率是 chunk 大小、embedding 模型、或要加 hybrid search。
生成评测:给对的文档,答得对吗?
把生成独立出来:直接喂理想来源文档给模型(不是检索回来的),看输出。这告诉你 LLM 能不能用「绝对正确」的 context。
三轴要打分:
- 忠实度(Faithfulness)。 答案是不是只包含文档支持的主张?幻觉在这里是毁灭性的。用 LLM 当 judge:「给这些文档跟这个答案,每个事实主张是不是都在文档里?回 YES / NO 并说明理由。」
- 答案相关性。 答案有没有回答问题?「退费政策是什么?」答「我们有 30 天窗口」—— 相关。答「我们重视客户」—— 不相关。
- 完整度。 有没有涵盖理想答案的所有要点?用部分得分:把理想答案的关键主张抽出来,看模型答案命中几个。
一旦把检索跟生成分开,你就能定位 bug。检索坏了?修 chunking、reranking、query expansion。检索 OK 但生成烂?换更强模型或改 system prompt。
端到端指标
除了阶段性指标,还要追踪:
- 端到端准确率。 LLM judge 自动打或人工 review。你真正在意的数字。
- 幻觉率。 每 100 答有几个包含文档里没有的主张。目标 < 2%。
- 超出范围时的拒答率。 corpus 答不出来的问题,系统有没有说?应该 > 95%。
- 延迟 p50 / p95。 真实用户对延迟比对 5% 准确率提升敏感得多。
- 每次 query 成本。 对 unit economics 很关键。
已经帮你做好的工具
你不需要从零盖框架。2026 年现况:
- Ragas。 开源,事实标准。有 faithfulness、answer relevance、context precision/recall。pip install 指向你的数据就拿到分数。
- TruLens。 范围类似,更 dashboard 化。
- Promptfoo。 通用 LLM eval 工具但 RAG 支持很好。
- DeepEval。 pytest 风格的 LLM 输出断言,适合 CI。
- Langfuse / LangSmith。 tracing + eval 一条龙,如果你已经在用做 observability 顺便用。
真产品做法:Ragas 或 TruLens 跑批量评测,加上一份 30 题回归集,每次改 prompt 或换模型都跑一次。在用户抓到之前先抓到。
什么时候不适合投资评测
- MVP 之前。 还在搞清楚 RAG 是不是对的方法,评测过头了。先把第一版难看版本跑起来,再评测。
- 内部三人在用的工具。 直接问用户。
- corpus 每天变,你没时间更新 golden。 改追真实流量的聚合指标 —— 拒答率、引用来源、用户赞踩 —— 跳过静态 eval set。
真的能抓 regression 的 CI pattern
实务上这个流程有用:
- 把 30 题回归集存成版本控制里的 JSON 文件。
- 每次有意义的变动(新 chunking、新模型、新 prompt),跑一次回归集。
- 把它当 deploy gate:如果准确率掉 > 5% 或幻觉率上升 > 1%,挡下来查。
- 每季用真实用户投诉新增 10 题。
这个用 20% 的力气抓到 80% 的 regression。
下一步
- Ragas 论文跟文档。
- RAG vs Fine-tuning —— Microsoft research 文章。
- 查这些词:chunking 策略、hybrid search、reranking、LLM-as-judge calibration。