把 AI 评估做成回归测试：从样例集到发布门禁

AI 应用最难维护的地方，是改一次提示词、模型、检索参数或工具描述后，很难知道系统是不是“整体变好了”。单看几个 demo 问题会让人产生错觉；更可靠的方式，是把评估做成持续回归测试。

OpenAI 的评估资料强调用 evals 衡量模型在特定任务上的表现，LangSmith 也把数据集、运行结果和评估器组织成应用评测流程。[eval-001][eval-002]

从 30 个真实样例开始

第一版评估集不用追求大而全，但要覆盖真实风险：

• 常见成功路径：用户问法清楚，知识库有答案。
• 边界问题：资料不足，系统应该承认不知道。
• 干扰问题：多个来源相似，要求引用正确。
• 对抗问题：用户要求跳过规则或输出不合规内容。
• 长上下文问题：答案需要跨多段材料组合。

评估集不是展示系统能力的样板间，而是暴露系统脆弱点的探针。

可以先用简单 JSON 管理：

{
  "id": "rag-missing-evidence-001",
  "input": "这篇博客有没有写过模型量化部署？",
  "expected_behavior": "如果没有证据，回答应说明未找到",
  "must_not_include": ["确定支持", "已经实现"]
}

评分器要分层

一个 AI 回答的质量可以拆成多层评分：

1. 格式评分：JSON 是否可解析，字段是否完整。
2. 任务评分：有没有回答用户问题。
3. 证据评分：结论是否有来源支持。
4. 安全评分：是否越权、泄露或执行高风险动作。
5. 回归评分：新版本是否比旧版本更差。

OpenAI 的结构化输出能力适合让模型或系统返回可验证字段，降低格式波动带来的测试噪声。[eval-003] LangSmith 的评估流程则适合记录运行、对比结果和定位失败样本。[eval-002]

发布门禁怎么设

不要把评估分数当成唯一真理。更实用的是设置发布门禁：

如果 critical 样例失败数 > 0：阻止发布
如果 边界问题误答率 上升：人工复核
如果 平均分下降但失败集中在低风险样例：允许灰度

综合这些资料可以推断：AI 评估最好进入 CI/CD，而不是停留在 notebook 里。它不会保证模型永不犯错，但能让每次变更都有可比较的证据。

参考资料

1. [eval-001] OpenAI Developers, “Evals”, https://developers.openai.com/api/docs/guides/evals
2. [eval-002] LangChain Docs, “Evaluation”, https://docs.langchain.com/langsmith/evaluation
3. [eval-003] OpenAI Developers, “Structured Outputs”, https://developers.openai.com/api/docs/guides/structured-outputs