如何在一周内搭起一个检索 evals 集。

如果你的 RAG 系统没有 evals 集,每一次 prompt 改动都是凭感觉的发布。好消息:你可以在一周内搭起一个有用的 evals 集。不是完美的——是 有用的。完美是让团队彻底没有任何 evals 的陷阱。

下面是我们在客户第一天只有 0–5 个 evals、需要在一周末达到 200 个时所用的配方。

形态

你需要三样东西:

1. 一份冻结的语料——系统真正用来检索的文档,在某个时间点的快照。
2. 200 个问题,是真实用户可能会问的,带有标准答案和引用。
3. 一组保留集——这 200 个里的 30 个,锁起来,绝不用来调任何东西。

保留集最重要,也最常被跳过。我们稍后回来谈它。

第 1–2 天:挖掘真实问题

跳过“用户会问什么?”的工作坊。它们产出的是没有任何真实用户问过的问题。去你的源头:

• 支持工单 里提到任何 RAG 覆盖话题的。
• 搜索日志,如果你有一个现成的搜索栏。
• Slack 频道,人们在内部问相同问题的地方。
• 当前 LLM 系统的聊天日志,如果你已经有一个在跑。

目标是 250 个原始问题。去重、规整措辞、丢掉显然超出范围的。最终落在约 200 个。

第 3 天:按难度与话题打标签

把每个问题分桶:

• 难度:trivial(答案在一段里)、medium(答案需综合 2–3 篇文档)、hard(需要理解某条流程或规则)。
• 话题领域——通常 5–15 个桶,取决于你的领域。
• 对抗性标记——专门触发已知失败模式的问题(超出范围、信息冲突、最近更新过的信息)。

你需要一份组合。一个 90% 都是 trivial 问题的套件会告诉你系统棒极了,然后你会因为 medium 和 hard 用例崩了而部署一次回归。

第 4 天:标准答案

每个问题你都需要:

• 预期答案——书面表达,1–3 句话,领域专家会给出的答案。
• 支撑段落——指向语料中 应当 被检索出来以回答该问题的部分的指针(文档 ID、行范围、chunk ID)。

这是慢的部分。预估每题约 3 分钟 = 200 题约 10 小时。两人并行,半周。请用领域专家。

值得。这是把“LLM 说了一句听上去合理的话”转变成“LLM 引用了正确的来源并给出了正确的答案”的部分。

第 5 天:基线 + 指标

用你 当前的 系统(没有就用占位)对可见的 170 个问题跑一遍。记录:

• Retrieval@k:top-k 检索出的 chunk 是否包含了预期支撑段落?
• 答案正确性:由一个 LLM 评审针对预期答案打分,带上保留参考。用约 30 个人工评分校准评审,确保不是橡皮图章。
• 引用精度:在返回的引用中,有多大比例真的支持了陈述?

你现在有了基线。今后每次 prompt 或检索改动都将以相对基线的差值出现。

“不准拿来调优”的集合

那 30 个保留问题的存在只为一个原因:抓住你自己。

每个搭起 evals 集的团队最终都会开始 针对 evals 集 调系统。改一版 prompt,跑 evals,分数上去,发布。三个月后,你套件内的分数是 95%,而用户满意度毫无变化,因为你一直在过拟合。

那 30 个保留问题 只 在每季度健康检查时运行。如果它们在套件其余部分进步的同时回归了,这就是过拟合的烟雾报警。它们是对“检查”的检查。

不要看。不要新增。不要用等价物替换。锁进保险柜。

这给你带来什么

• 一个可复现的信号,用来为 prompt 与检索改动卡门禁。
• 一个评估新 LLM 版本时可对照的基线。
• 一个站得住脚的回答,回复“你怎么知道你的 RAG 是好用的?”

一周内搭起 v1。每月迭代问题。每年换一次保留集。

你永远没有时间去搭一个完美的 evals 集。你完全有时间去搭一个有用的。