给 AI 问答做测试：先把错误分清楚

给知识库换了检索策略，测试分数从 80 变成 90，可以上线了吗？

先别急。这个分数到底在衡量什么？搜到了目标文档，答案写得像参考答案，还是用户真的得到了可以使用的结论？

同样一个问题，可能文档找对了、答案却用错了版本；也可能答案正确，引用却点不开。把它们压成一个总分，最需要修复的地方反而不容易看见。

一道测试题不应该只有一句问题

假设要验证“2.3 版本能否处理扫描件”。测试样本可以这样记录：

id: version-scanned-document-001
question: "2.3 自部署版支持扫描件吗？"
identity_fixture: reader-a
expected_behavior: answer
required_claims:
  - "结论仅适用于 2.3 自部署版"
required_evidence:
  - "release-note-2.3#scanned-document"
forbidden_claims:
  - "所有版本均支持"
  - "未有证据的速度或准确率承诺"

这里的编号和材料名称都是示例。实际测试还应固定知识快照、检索参数、提示词版本和模型标识，便于发现退步后复现问题。

如果把问题改成“这个版本支持吗”，而上下文没有版本号，预期行为就应该变成补问。测试不能要求模型在缺少条件时猜中一个标准答案。

把整条链拆开看

对每一道题，分别记录下面几件事：

环节	要检查什么	常见问题
权限与范围	候选材料是否属于当前身份和版本	召回了不应访问的资料
检索	必要证据是否出现在候选结果中	正确文档没有进入结果集
结论	答案是否满足问题条件	拿其他版本的能力作答
引用	来源是否支持对应结论、能否访问	引用相关，但证明不了结论
使用结果	用户是否完成了原本的任务	答案完整，实际操作仍走不通

前四项可以做较多自动化。最后一项往往需要真实用户反馈或业务系统中的结果，不能用“接口返回成功”直接代替。

小样本也能有代表性

起步时可以先准备 20 道题：8 道明确可答、4 道需要补问、4 道无依据、2 道资料冲突、2 道权限边界。

这只是一个便于执行的起始分配，不是行业标准。重点是让不同失败类型都出现，而不是凑够数量。

每道题还可以保留一两个自然的改写。“是否支持扫描件”和“扫描出来的 PDF 能用吗”表达不同，用户意图却可能接近。改写题应该和原题放在同一组，避免同一个事实被重复统计，导致分数虚高。

权限测试需要分身份运行。管理员能回答，并不能证明普通用户也能安全使用。

指标要写清分母

“引用准确率 95%”可能有几种解释：95% 的答案带了链接，95% 的链接能打开，或者95% 的引用真的支撑了结论。

如果需要定义一个简单的引用支持率，可以使用：

引用支持率 = 有充分引用支持的事实性结论数 / 需要引用支持的事实性结论总数

但还要另外检查必要事实有没有回答完整，否则模型少说几句就可能获得高分。类似地，“应该拒答却直接作答”和“应该回答却拒答”需要分别统计，避免靠一律拒答得到漂亮结果。

延迟也一样。记录从用户发出问题到最终可见答案的时间，并说明是否包含排队、检索、重排和工具调用。离线单请求耗时不能直接代表多人同时使用时的体验。

用模型评分，也要保留人工标尺

模型可以协助检查答案是否遗漏条件、引用是否对应、表达是否清楚。不过评分器本身也可能出错，或者偏爱更长、更像自己的答案。

可以先人工标注一小组明显正确、明显错误和边界案例，再检查自动评分是否与人工判断一致。对权限泄露、相反结论、虚构能力等关键错误，保留明确规则和人工复核。

每次只回答一个改动问题

如果同时换模型、提示词、切分策略和重排器，分数变化很难解释。

更容易推进的方式是：固定其余条件，只改一个主要变量；对同一批题比较结果；优先查看从正确变成错误的样本；必要时重复运行，区分偶然波动与稳定退步。

测试输出可以很简单：通过哪些题、退步哪些题、错误发生在哪一层、下一步改什么。等这些信息稳定以后，再扩展规模和统计方法。

一份评测报告真正有用的地方，是让下一次修改更有方向。它不应该只留下一个看起来不错的分数。

打赏