Eval 飞轮与持续集成

运营化分两个互补的组件:

1. 安全网:CI 里的 code-based 评估(防止旧问题复发) 基础是一份黄金数据集(golden dataset)——不是生产数据的随机抽样,而是专门构建的压力测试集,必须覆盖核心功能场景、error analysis 中发现的高难度边界案例,以及每一个你修复过的重大 bug 的回归测试。每次代码或 prompt 变更,CI 流水线都在这份黄金集上跑一遍系统,用快速、确定性的 code-based 评估器检查输出,任何一项不通过就阻断上线。关键认知:CI 通过只代表"没有重新引入已知失败",是稳定性的信号,不是整体质量的信号——这是两件事,不要混淆。

2. 发现引擎:生产环境里的 LLM-judge 与 guardrail 评估(找出未知的未知) CI 只能防住"已知的未知",生产环境才是发现"未知的未知"的地方。流程是:①完整记录交互全链路(用户输入、所有中间步骤和工具调用、最终输出);②对采样的 trace 异步运行已验证的评估器(很多 LLM judge 太慢/太贵不能实时跑);③结果进监控看板,并用之前算出的 judge 的 TPR/TNR 对生产端读数做统计校正,得到更接近真实的失败率估计。对于高影响的关键失败,可以用guardrail(一种同步评估器)在请求路径里实时拦截、脱敏或重新生成响应——多数 guardrail 是快速确定性检查(正则、关键词黑名单、schema 校验),因为必须把延迟开销降到最低,且必须有极低的误报率(拦截一个本来正确的回复,本身就是一个生产 bug)。LLM judge 也可以当 guardrail 用,但只有在延迟预算允许的情况下才行——这是一个直接的权衡:医疗建议这类高风险领域,漏放有害内容(假阴性)的代价可能高到值得用更慢更强的 judge 做实时拦截;创意写作类场景,误杀合法回复(假阳性)的代价可能反而更高。

3. 闭环:改进飞轮 生产监控发现新的/正在漂移的失败模式后,会触发新一轮 error analysis。例如:上线新功能后"地点歧义"类失败激增,人工复核发现模型把"West Berkeley"和不存在的"Berkeley West"搞混了。这个发现反哺开发的两个方向:①改进产品本身(如优化 prompt 处理方向性限定词);②改进评估资产本身——把这个具体案例加进 CI 黄金数据集,确保未来任何重新引入这个混淆的改动都会被自动抓到。监控→分析→改进→部署这个飞轮,是 AI 产品质量的引擎:它确保每一次被发现的失败,都会让系统永久性地变得更聪明、更健壮。