背景：为什么部署 + 监控仍然不够
传统软件工程把"上线"当作终点：代码通过 CI/CD 发布，Prometheus 监控可用性与延迟，Sentry 捕获异常，On-Call 处理告警。但 AI 系统即使 HTTP 200、延迟正常、没有异常栈，也可能在内容层面严重失败。部署与监控只是必要条件，质量保证才是充分条件。
AI 系统特有的失效模式
1. 幻觉（Hallucination）
模型会生成看似合理但实际错误的内容。更严重的是，输出往往语法通顺、格式规范，传统日志与错误码无法发现。
- 客服机器人给出错误的退款政策。
- 代码助手生成不存在的 API 调用。
- 医疗助手给出错误的用药建议。
这些错误的共同特征是：接口层面成功，语义层面失败。
2. 工具误用（Tool Misuse）
Agent 与工具链的普及让模型可以调用外部 API、数据库、搜索引擎。错误包括：
- 选错工具（如用"发送邮件"代替"查询库存"）。
- 参数格式错误（JSON Schema 不匹配、必填字段缺失）。
- 对工具返回结果过度推断或忽略关键字段。
- 循环调用同一工具，陷入死循环。
工具错误不会总以异常形式暴露，很多时候只是"做了不对的事"。
3. 回归（Regression）
更换模型版本、调整 temperature、修改 system prompt、升级工具实现，都会让之前表现良好的输入突然变差：
- 新模型在数学推理上更强，但在长上下文忠实度上更差。
- 更便宜的模型把特定领域的术语理解错了。
- Prompt 压缩后，指令遵循能力下降。
没有持续评估， regression 只能等用户投诉才能发现。
4. 长尾输入（Long-Tail Inputs）
训练数据覆盖不到的真实世界输入：
- 多语言混杂、拼写错误、极端长度的上下文。
- 对抗性 prompt、越狱尝试、诱导性角色扮演。
- 边界条件（空结果、超大表格、时间敏感问题）。
平均指标往往掩盖长尾失败。一个系统在 90% 输入上得分 95%，在 10% 长尾上可能完全不可用。
5. 成本与延迟漂移
- Agent 在没有明确终止条件时无限循环，token 用量激增。
- 检索召回过多片段，超出上下文窗口，触发更昂贵的模型调用。
- 某类输入导致模型反复生成，ITL 抖动拖垮 P99。
这些不是传统意义上的"错误"，但会直接影响商业可行性。
从 SRE 到 EvalOps
传统 SRE 回答"系统是否在运行"，EvalOps 回答"系统是否在做对的事"。
| 维度 | 传统 SRE | EvalOps |
|---|---|---|
| 核心问题 | 服务是否可用 | 输出是否正确、安全、可用 |
| 关键信号 | Error rate、Latency、Throughput | Correctness、Factuality、Tool accuracy、Safety score |
| 变更触发 | 代码发布、配置变更 | 模型版本、Prompt、工具、检索索引 |
| 反馈对象 | 工程师、On-Call | 模型、Prompt 工程师、产品经理、安全团队 |
| 度量方式 | 聚合指标 | 样本级评分 + 聚合分布 + 回归对比 |
EvalOps 不是替代 SRE，而是把 SRE 的"可观测性"扩展到语义层：
- Traces 记录 Agent 思考链与工具调用链。
- Metrics 增加质量分数、幻觉率、工具正确率。
- Logs 增加 prompt、completion、retrieved chunks、judge reasoning。
- Error Budget 从"可用性预算"扩展到"质量预算"与"安全预算"。
Benchmark + Evaluation 在 AI Infra 中的位置
在整个 AI Infra 版图中，Benchmark + Evaluation 位于"应用层"与"运维层"的交汇点：
- 它向上承接产品需求（能力边界、成功标准）。
- 向下依赖可观测性（trace、metrics、logs）。
- 横向连接 LLMOps（实验、版本、部署）、Security（红队、安全评估）、RAG（检索评估）、Agent（步骤评估）。
- 最终输出反馈给 CI/CD、模型选择、Prompt 优化、 guardrails 与运维决策。
为什么现在必须做
- 模型迭代快：基础模型每月更新，没有回归评估无法安全升级。
- Prompt 成为代码：Prompt 版本需要像代码一样被测试、review、回滚。
- Agent 复杂度指数级上升：单步评估不够，需要多步骤、多工具、多轮对话的端到端评估。
- 成本敏感：大模型调用昂贵，必须用评估驱动性价比优化。
- 安全合规：欧盟 AI Act、行业监管要求对高风险 AI 系统进行系统性评估与记录。
小结
部署与监控只能证明系统"活着"，Benchmark + Evaluation 才能证明系统"可信"。下一章将从评估维度、数据集构建、LLM-as-judge、在线 / 离线评估等核心概念开始，建立一套可落地的 EvalOps 语言体系。