对话系统评测实战：怎么证明 AI 应用「变好了」

改完提示词、换了模型，"感觉变好了"是最常见也最不可靠的决策依据。这篇讲三层评测体系、评测集怎么建、规则/裁判/人工三种判定怎么配合，以及五个最容易踩的坑。

一、为什么 AI 评测比传统测试难

改完提示词、换了模型、调了检索参数，然后呢？大多数 AI 项目的答案是「我自己试了几个问题，感觉变好了」。这种决策方式有两个问题：它无法证明（换个人试可能觉得更差）、它无法回归（下次改动可能悄悄弄坏之前好用的场景）。

• 输出开放：同一问题有多种合格答法，不能用等号断言
• 输入长尾：真实用户什么都问，构造集永远覆盖不全
• 「好」是多元的：准确、忠实（不编造）、有用、安全、语气得体——五个维度可能互相冲突
• 会随时间漂移：换了模型版本、供应商悄悄更新，行为可能变化

评测不是「跑个测试」，而是「建一套能持续给出判断的系统」。

二、三层评测体系：各管一段

三层的分工要清楚：单元级定位「哪个部件坏了」，端到端回答「整体达标没有」，线上回答「用户真的变好了吗」。只做端到端，出了问题找不到原因；只做单元级，局部全绿而整体体验倒退。

三、评测集怎么建：最容易被跳过的一步

• 来源：真实日志优先（脱敏后使用），其次才是专家构造——真实分布才有代表性
• 规模：50 到 200 条起步；关键词是覆盖——正常、边界、恶意三类都要有
• 分层打标：标上类型与难度（简单事实、多跳推理、模糊指令、越界请求），分数下降时能立刻看出是哪一类变差
• 标注规范先行：先写清「什么叫正确答案」再动手标；关键条目双人标注，抽查一致性
• 版本化：评测集进 git，每次改动有记录——改评测集和改代码一样需要评审

四、判定方法：三种武器配合使用

三种武器各有位置：规则先挡掉可枚举的，模型裁判处理主观维度，人工只留给争议与关键验收。用模型当裁判（LLM-as-judge）是当前主流，但必须处理三个问题：给评分标准与示例（不能让模型自由发挥）、防位置偏见（比较两个答案时交换顺序各评一次）、校验裁判本身（先与人工标注对齐一致率，再大规模使用）。

你是答案评审。请依据以下标准给回答打分（1-5 分）：
5 = 完全正确，且只依据给定资料，无编造
3 = 方向正确，但缺少关键细节或有轻微冗余
1 = 与资料矛盾，或编造了资料中不存在的信息

<资料>…</资料>
<问题>…</问题>
<回答>…</回答>

只输出 JSON：{"score": 1-5, "reason": "一句话依据"}

五、指标体系：一个总分没用

评测要能回答「哪里变好了、哪里变差了」，所以指标必须拆开：准确性（答案对不对）、忠实度（有没有超出给定资料编造）、有用性（是否真正解决问题）、安全性（有没有越界、泄露）、效率（时延与成本）。然后给每个指标设基线与阈值：新版本低于基线就不放行——这一步接上 CI/CD，评测就成了发布门禁。

六、在线评测：A/B 与灰度

离线评测告诉你「应该更好」，线上才告诉你「是不是真的好」：核心在线指标包括任务完成率、答案采纳率、追加追问率（下降通常说明一次答清）、人工转接率、投诉率；做法是小流量灰度（先 5%）按场景与用户分层观测。同时警惕指标作弊：只优化「点赞率」会诱导模型给出讨好式而非正确的回答——这也是要同时看任务完成率的原因。

七、五个常见坑

• 拿构造集当评测集：用自己造的例子验证自己写的提示词，等于开卷考自己出题
• 只看平均分：平均涨了，长尾类问题却整体劣化——必须看分层分布
• 用模型裁判却不校验它：裁判错了整套评测都失真
• 单指标优化：准确率涨 3 个点，延迟翻倍、成本翻三倍
• 上线不回归：模型版本或供应商更新后行为漂移，只能等用户投诉

八、落地路线：三周搭起评测体系

• 第 1 周 · 地基：从真实日志抽 50 条，脱敏、分层打标，跑通基线
• 第 2 周 · 指标与判定：定义 3 到 5 个核心指标，写规则脚本与裁判提示词，与人工抽样对齐一致率
• 第 3 周 · 门禁与灰度：评测接入 CI（低于阈值不放行），线上开 5% 灰度做 A/B
• 持续运行：每周把线上失败样本回流进评测集——评测集越用越大，系统才越改越稳

速查卡

写在最后

AI 应用的「变好」，不该靠感觉，而该靠证据：一套覆盖真实分布的评测集、一组拆得开的指标、一条接进流水线的门禁。做到这三点，「优化」就从玄学变成了工程——每次改动都能回答两个问题：比之前好了吗？哪些场景变得不好？