AGI 未来之门

主题

AI 评测驱动开发 ​

传统程序对同一输入通常给出相同输出，AI 系统却可能用不同措辞得到同样正确的答案，也可能流畅地犯错。因此测试不能只比较字符串；但“无法精确断言”也不等于只能靠感觉。评测驱动开发的目标，是把产品期望变成一组可重复运行的证据。

1. 从任务定义而不是模型分数开始 ​

先写清三件事：

  1. 用户想完成什么任务；
  2. 哪些失败绝对不能发生；
  3. 什么指标代表业务改善。

以客服草稿为例：任务不是“写一段好回复”，而是“基于当前政策生成可发送的草稿”。硬约束包括不编造退款资格、不泄露内部字段、不擅自承诺补偿；业务指标可能是采纳率、编辑距离和平均处理时长。

2. 建立有代表性的数据集 ​

2.1 样本结构 ​

json
{
  "id": "ticket-0042",
  "input": { "message": "扣了两次款怎么办", "plan": "pro" },
  "context": ["policy:duplicate-charge:v3"],
  "expected": {
    "intent": "duplicate_charge",
    "must_include": ["核对订单", "退款处理时限"],
    "must_not_include": ["保证当天到账"]
  },
  "slice": ["billing", "short-query", "high-risk"]
}

数据集应来自脱敏的真实流量，而不是全由开发者凭空编写。每条样本带切片标签，才能发现总体分上升但“高风险计费问题”退步。

2.2 至少覆盖四类样本 ​

  • 高频正常路径；
  • 长尾与模糊输入；
  • 对抗输入、越权请求和提示词注入；
  • 无答案、工具失败、超预算等系统边界。

初期几十条高质量样本胜过几千条含糊样本。线上出现一次重要失败，就把它清洗后加入回归集。

3. 分层评分，不追求一个万能分数 ​

3.1 确定性检查优先 ​

能用代码判断的不要交给另一个模型：JSON 是否可解析、字段是否齐全、链接是否属于允许域名、引用是否来自上下文、工具参数是否越权、总费用是否超限。

3.2 规则与参考答案 ​

分类任务可算准确率、精确率和召回率；信息抽取可按字段计算 F1；检索可用 Recall@K；代码任务应运行测试、类型检查和静态分析。

3.3 模型评分器 ​

语气、完整性、主张是否被证据支持等开放指标可用模型评分，但必须提供清晰量表：

text
事实忠实度：
4 = 所有关键主张均被给定证据直接支持
3 = 结论正确，有轻微无关扩展
2 = 至少一个次要主张缺少支持
1 = 核心结论缺少支持或与证据冲突
0 = 泄露信息、编造关键政策或未回答

对评分器做校准：抽样由两位人工独立评分，比较模型与人工的一致性；对不一致案例改量表或拆指标。评分模型本身升级时也要重新校准。

4. 区分组件评测与端到端评测 ​

text
输入 → 检索 → 规划 → 工具 → 生成 → 输出

端到端失败不告诉你哪一层坏了。需要分别测：

  • 查询改写是否保留意图；
  • 检索是否取回标注证据；
  • 工具选择与参数是否正确；
  • 给定正确证据后，模型是否生成正确回答；
  • 完整系统能否在预算内完成任务。

组件评测用于快速定位，端到端评测用于验证真实体验，两者不可互相替代。

5. 让每次改动都经过实验 ​

记录实验清单：代码提交、提示模板版本、模型与参数、知识库版本、数据集版本、每个切片的指标、延迟和成本。

推荐比较规则：

text
候选版本可以发布，当且仅当：
- 所有硬约束通过率 = 100%；
- 总体任务成功率不低于基线；
- 任一关键切片下降不超过阈值；
- P95 延迟与每成功任务成本在预算内；
- 人工抽检没有发现新的严重失败模式。

不要只报“平均分提高 2%”。如果变化小于评分噪声，就不能证明候选更好。可用成对比较：让评分器在同一输入上盲选 A/B，再对胜负和分歧做人工抽检。

6. CI 中的评测门禁 ​

小型稳定回归集放入每次提交的 CI；完整评测集在合并、模型切换或提示词发布前运行；昂贵的端到端 Agent 评测可按夜间任务运行。

yaml
steps:
  - run: npm test
  - run: npm run eval:smoke
  - run: npm run eval:safety
  - run: npm run eval:report

评测代码应能固定随机种子或保存原始输出，并设置并发与费用上限。失败报告必须显示具体样本、轨迹和评分理由，只有一个红色总分无法调试。

7. 线上观测补足离线盲区 ​

离线集永远落后于真实世界。线上关注：完成率、用户重新提问率、草稿采纳率、人工接管率、错误类别、工具失败率、延迟、成本与安全事件。把负反馈与轨迹关联，区分“模型答错”“检索没找到”“工具执行失败”和“产品交互让用户误解”。

灰度发布时只给小比例流量，预先写清回滚阈值。不要在发现指标下降后才临时决定什么算严重。

8. 避免评测系统自欺 ​

  • 不要用测试集持续调提示词而不保留隐藏集，否则会过拟合。
  • 不要只测试容易自动评分的任务，忽略真正影响用户的复杂场景。
  • 不要让生成答案和评分答案使用完全相同的错误假设。
  • 不要把“风格更像标准答案”误当成“事实更正确”。
  • 不要只评价最终文本；Agent 可能靠危险步骤碰巧得到正确答案。

成熟团队讨论的不是“哪个模型最好”，而是“在我们的任务、数据、约束和预算下，哪个系统版本有证据更好”。

先找工作，再找工具。

AGI 未来之门