用户问:“本周哪天可以晚上开会?”助手回答“周三”,还附了一条引用。格式对,语气也自然,可那条引用说的是上个月。
给这个回答一个 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$;成立是因为计数逐层嵌套,不需要假设各阶段独立。随手乘几个在不同样本上算的平均分,没有同样的意义。
只在找到了证据的样本上评价生成,可以诊断生成能力,但要报告被排除的那些题。否则更差的检索器只留下最简单的题,生成分数反而可能更高。
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
- 把原始输入压成向量的那一半模型