用户问:“本周哪天可以晚上开会?”助手回答“周三”,还附了一条引用。格式对,语气也自然,可那条引用说的是上个月。

给这个回答一个 7 分,能知道下一步改什么吗?可能是旧记忆没过期,也可能是检索(retrieval)没找到新要求,或者模型拿到了两条信息却没分清时间。评估除了比较高低,还应该帮我们缩小问题范围。

下面沿用一个带检索和记忆的助手。先看如何定位失败,再看怎样比较改动。例子都是虚构的,不需要先读完统计学。

1. 顺着一次请求往回查

用户任务 → 可用数据与记忆 → 检索候选 → 上下文选择 → 模型回答 → 实际结果
              ↑                ↑             ↑             ↑            ↑
          信息是否存在      有没有找出来   是否正确保留    是否忠于依据   用户是否完成任务
看到的现象 先检查什么 能缩小到哪里
正确要求根本不在库里 写入记录、数据版本、权限 数据或记忆写入;调 prompt 没法补一条不存在的事实
正确要求在库里,但不在候选(candidate)中 精确检索与 ANN、过滤记录 表示、索引或过滤
候选里有,最终上下文里没有 截断、去重、重排、token 预算 上下文选择
上下文里有,回答仍用旧日期 时间消歧、引用支持、冲突处理 生成或证据解释
答案正确,但会议没有改成功 工具返回和最终日历状态 执行路径;不能只看模型说“已完成”

一个请求可能有多个问题。可以保存多种失败标签;若做漏斗统计,再另定义一个“最早失败阶段”,不要把两个口径混起来。

2. 不同问题,用不同的检查

这些方法不是从低级到高级的排名,也没有固定的成本顺序。一个 executor 可能很贵,一条人工检查可能很快。选法取决于要证明什么。

方法 适合回答 不能凭它断定
确定性规则 JSON 合法吗?引用 ID 存在吗?日期符合约束吗? 有引用就代表引用支持结论
参考答案或执行器 数学答案对不对?测试通过吗?日历状态真的变了吗? 测试没覆盖到的行为也正确
LLM judge 证据是否支持主张?遗漏了哪些要求? 模型自己的判断就是真值
人工审查 模糊案例怎样判?rubric 有没有漏掉重要标准? 单个人的看法必然一致、无偏
在线反馈与长期观察 用户是否完成任务?是否反复纠正? 一次短期点击就是长期价值

如果引用 ID 不存在,代码已经能给出明确失败,没必要再让 judge 猜。有引用但不支持结论,才需要语义检查。把这两步分开,还能查出 judge 是漏掉明显错误,还是确实遇到了有歧义的证据。

3. 一百个问题,怎么从 80% 变成 55%?

假设以下成功条件逐层包含:每一步只在通过上一步的样本里继续统计。

阶段 剩下多少题 相对上一步通过率
固定测试集 100 —
必要证据进入候选集 80 80%
必要证据保留在最终上下文 70 87.5%
关键主张均有支持 60 约 85.7%
同时完整回答了问题 55 约 91.7%

端到端成功率是 $55/100$,不是最后一行的 $55/60$。这个漏斗中,$0.8\times(70/80)\times(60/70)\times(55/60)=0.55$;成立是因为计数逐层嵌套,不需要假设各阶段独立。随手乘几个在不同样本上算的平均分,没有同样的意义。

动画 逐层嵌套的漏斗:100 → 55

这张图需要启用 JavaScript。

只在找到了证据的样本上评价生成,可以诊断生成能力,但要报告被排除的那些题。否则更差的检索器只留下最简单的题,生成分数反而可能更高。

4. Judge 应该看到什么,交出什么?

先把一个宽泛问题拆开:“这句关键主张有没有证据支持?”和“回答有没有覆盖所有要求?”分别判断。一个回答可以有依据却不完整,也可以表面完整但编了细节。

给 judge 的输入保留用户问题、实际提供给模型的证据、候选回答、评分规则,以及必要的时间与版本。输出保留判断、对应片段和不确定原因,而不是只要一个数。

{
  "example_id": "demo-017",
  "claim": "Wednesday evening is allowed this week",
  "support": "insufficient",
  "evidence_ids": ["memory-old"],
  "reason": "The cited record applies to last month, not this week",
  "needs_review": true
}

这是输出格式示意,不是事实证明。代码可以核对 evidence_ids 和摘录是否存在,却不能仅凭字符串存在就确认逻辑支持。人工抽查仍要看主张、证据与日期是否对应。

参考答案适合给出需要覆盖的事实,不应无条件限制唯一措辞。允许 insufficient、tie 或双方都差,避免强迫评分器从两个坏答案里挑一个“好答案”。比较模型时交换 A/B 顺序,检查位置敏感性;先用人工样本校准(calibration),再批量使用。更详细的例子见 Judge 章节。

5. 改一个部件,怎样知道是不是它起作用?

想测重排,先冻结候选集;想测生成模型,先冻结上下文;想测端到端体验,再让完整系统一起跑。组件实验负责定位,完整实验负责检查交互和真实代价,两者都需要。

实验 改什么 暂时固定什么
检索实验 编码器(encoder)或检索策略 语料快照、query、标注、候选预算
重排实验 排序器或融合规则 输入候选、下游上下文预算
生成实验 prompt 或生成模型 输入证据、解码约定、评估标准
整体实验 完整方案 测试任务、允许的总预算、成功标准

把正确证据人工放进上下文,是一个有用的 oracle 诊断:如果这样仍答错,检索不是唯一问题。但它不是可上线的系统,也不是总体性能数字。类似地,替换一个部件后其他部分可能需要重新校准,固定部件实验不能替代最终端到端测试。

6. 最小的一轮评估怎么做?

先手工准备一小组覆盖不同失败的任务:普通查询、时间冲突、没有答案、越权内容、相关信息被截断,以及需要实际执行的任务。用于改规则的样本和最终留出样本分开,不宣称小集合能代表全部用户。

每次运行保存输入、系统版本、中间候选、上下文、输出、工具结果和失败原因。先跑确定性检查,再做语义判断,最后抽查分歧与边界案例。固定例子帮助发现回归,新的独立样本帮助发现原来没想到的问题。

看报告时,同时问三件事:整体完成了多少、哪一步最容易失败、修它的成本是什么。接着读指标稳健性,再决定一次涨分能支持多大的结论。

本页术语 4
检索 retrieval
从外部语料里找出相关内容
候选 candidate
召回阶段捞出来、等待精排挑选的内容
校准 calibration
模型给出的置信度是否等于真实正确率
编码器 encoder
把原始输入压成向量的那一半模型