AI 评估管道：持续验证 vs 生产信任
很多 AI 团队到现在还在用一种“demo 数学”在运转。
一个 prompt 恰好成功一次。 客户点头。 截图发出去。 然后大家默默假设：下周、换一批输入、加上延迟压力、上下文更脏更乱时，系统也会同样表现。
不会的。
信号（The signal）
真正拉开差距的，往往是一些很无聊的东西：
像生产环境一样的评估流水线（evaluation pipelines）。
不是一次性的 benchmark。 不是某个“黄金 prompt”。 不是英雄式 demo。
而是一条流水线。
这意味着你评估的东西要尽可能接近真实：
- 代表性的任务（用户真的在做的工作）
- 代表性的输入（丑陋、不完整、现实世界那种）
- 代表性的约束（延迟、限流、上下文窗口、工具失败）
- 以及一个你每天都能跑的评分系统
如果你的 eval 不能按计划定时运行，那它就不算 eval。 它只是一个故事。
一条真实的 eval 流水线应该测什么
好的流水线不只是“答案对不对”。
对多数 agent 类产品来说，真正会伤到你的失败模式通常是：
1) 在变化输入下的可靠性 当出现以下情况时系统是否还能稳定：
- 用户换一种说法
- 上下文缺失
- 工具只返回部分数据
- 任务本身就有歧义
最危险的错误不是显眼的幻觉。 而是看起来很合理的错误。 那种“像对的”并且容易滑过去的。
2) 成果成本（cost-to-outcome） 做一个“聪明”的 agent 很容易。 做一个在预算内依然聪明的 agent 很难。
你的 eval 流水线应该能告诉你：
- 每个成功任务平均用多少 token
- 每个成功任务平均调用多少工具
- 输入越长、越乱时成本怎么变化
如果成本曲线不稳定，产品体验就会不稳定。
3) 信任建立时间（time-to-trust） 信任不是一种感觉。 信任是一种工作流。
你需要衡量系统是否：
- 展示证据
- 产出可审阅的结果（diff、引用、trace）
- 诚实暴露不确定性
- 让用户可以安全审批
如果 agent 有 80% 的时候是对的，但用户 100% 的时候都得费力核对，用户最终还是会停止使用。
怎么做（不需要一上来就造大山）
你不需要 1 万条样本。 你需要一个闭环。
先从 30–50 个任务开始，覆盖你最核心的用户工作流。 然后搭三层：
第一层：输入样本（fixtures） 保存：
- 原始输入
- 期望输出（如果能定义）
- 以及“可接受输出形态”（当无法定义唯一正确答案时）
对 agent 流程来说，“形态”可能意味着：
- 是否选择了正确的工具？
- 是否生成了正确的字段？
- 是否遵守了某些规则/政策？
第二层：全链路埋点（instrumentation） 记录：
- 模型版本 + prompt 版本
- 检索到的上下文
- 工具调用
- 中间产物（计划、草稿）
你记录这些不是为了“好奇”。 而是为了让你能在几分钟内定位回归（regression），而不是几天。
第三层：评分 + 发布门禁（scoring + gates） 定义：
- 通过/失败标准
- 分数体系
- 以及预算/延迟上限
然后把它变成不可谈判的制度：
- 不跑一次，不发布
- 不改 prompt，不跑一次
- 不改工具，不跑一次
这就是“prompt 调参”如何变成工程。
现实检验（Reality check）
如果你唯一的评估方式是 demo，你测到的只是氛围（vibes）。
demo 天生是为了说服人：
- 最好的输入
- 最干净的上下文
- 可控的时间
- 以及一个知道模型犹豫时该怎么救场的人类
而生产环境是为了混乱而生的。
demo 条件与真实条件之间的差距，就是信任死亡的地方。
所以有一个不太舒服的事实：
你真的不知道你的 agent 好不好，直到你能在 eval 流水线里反复地看到它失败——并且能稳定复现。
这不是悲观。 这是你如何把一个“能演示的东西”，变成“值得依赖的东西”。
先把流水线建起来。 然后让模型在这个框架里变好。