一个大模型应用最隐蔽的风险，是行为会在你没动它的时候悄悄变：模型供应商静默更新、你改了一版 prompt、换了个工具实现——任何一个都可能改变输出。如果没有评测集，第一次发现这种退化，往往已经是在生产、被用户或业务方发现的时候。
传统软件靠测试防回归，LLM 应用同样需要。区别在于评测的对象不是“函数返回值精确相等”，而是“行为是否符合期望”。
一、先有一个固定评测集
评测集是一组代表性输入 + 期望行为，覆盖：
- 正常主流程（happy path）；
- 已知的边界与坑（缺数据、超长上下文、权限不足）；
- 历史上真实出过问题的案例。
期望行为不一定是精确字符串，可以是断言：是否调用了正确的工具、是否在缺数据时报告不可用、是否没有编造具体数字。
const evalCases = [
{
input: "查一下不存在的订单 X999 的状态",
assert: (out) => out.saidUnavailable && !out.fabricated, // 缺数据要报告，不能编
},
{
input: "本月待处理工单有多少条",
assert: (out) => out.usedTool === "count_tickets", // 精确问题要走工具
},
];
二、每次变更自动跑
评测集要在每次 prompt / 工具 / 模型版本变化时自动运行，而不是靠人偶尔手动跑。放进 CI，作为门禁：评测通过率低于阈值（例如跌破 90% 就拦住变更）。
这样你能在合并前就知道“这次改动是改进还是回退”，而不是上线后靠线上反馈才发现。
改 prompt / 换模型 / 改工具
│
▼
CI 自动跑评测集
│
┌────┴────┐
通过率达标 低于阈值
│ │
合并 拦住 + 给出退化的用例
三、评测样本怎么攒
好的评测集不是一次写完，而是持续沉淀：
- 把线上真实的失败案例、边界情况脱敏后回流进评测集；
- 每修一个 bug，补一个对应的评测用例，防止它复发；
- 定期回顾误报/漏报，调整断言。
这和内容工具里“把真实草稿回流成回归用例”是同一个思路：让系统的检查项跟着真实问题长。
四、别把评测当一次性验收
评测集的价值在于长期防回归，不是上线前跑一次就完事。模型会更新、需求会变、prompt 会迭代——评测集是这中间唯一能持续告诉你“行为有没有偷偷变”的东西。
常见问答
Q：评测集从哪来？ A：把线上真实失败/边界案例脱敏沉淀进来，比凭空造用例更有价值。每个历史 bug 都该留一个用例。
Q：多久跑一次？ A：每次 prompt/工具/模型变更自动跑（放 CI），而不是手动。手动跑迟早会被跳过。
Q：期望值不确定怎么写断言？ A：断言“行为特征”而非精确文本——是否调对工具、是否缺数据时报告、是否没编造数字，都比逐字比对更稳。
固定评测集 + CI 门禁 + 样本持续回流，是 LLM 应用不“悄悄退化”的工程底线。这也是我们做生产级 AI Agent 系统时的评测与回归实践：让每次变更都有据可依，而不是靠上线后救火。想看看你的 Agent 缺不缺这道回归门禁，可以做一次生产就绪自检。