收益：
- 能够识别模型退化的无声原因（数据漂移、概念漂移、上游错误）并建立三层（操作、输入、输出）监控
- 能够通过规则检查、LLM裁判和人工评估对LLM系统进行多层评估，并通过LLM裁判人工锚点进行校准
- 能够设计包含边缘和安全案例的评估集，并将每个捕获的错误转变为永久测试案例
一旦模型投入生产，您的工作还没有完成；您的工作还没有完成。真正的责任才刚刚开始。因为模型可能会在无人注意的情况下悄然崩溃。在本单元中，我们涵盖两个互补的学科：评估（系统地测量模型的质量）和监控（在生产中持续监控模型）。尤其是在 LLM 系统中，评估比经典 ML 更困难并且需要更多的关注。
为何生产模式正在悄然崩溃
错误崩溃，日志打印，警报响起。另一方面，机器学习模型可能会出错，但不会导致错误。退化的三个主要原因：
- 数据漂移：输入数据的分布随时间变化（新产品、不断变化的用户行为、季节性）。模型保持不变，但世界发生了变化。
- 概念漂移：投入产出关系发生变化。欺诈策略和垃圾邮件模式不断演变；昨天正确的事情今天将是错误的。
- 上游损坏：数据源改变格式，某个区域变得空闲；该模型默默地因损坏的输入而流口水。
追踪正在使这些无声的扭曲变得可听。
看什么：三层
良好的监控涵盖三个层面：
- 运营指标：延迟、错误率、请求量、资源使用情况。 “系统还正常吗？”
- 数据/输入指标：输入分布是否与训练中的分布相似？缺失值率是否增加了？有新类别到来吗？ “模型看到的是熟悉的数据吗？”
- 模型/输出指标：预测分布日志？信心分数下降了吗？如果可能的话，与真实情况相比，准确性是多少？ “这个模型还准确吗？”
第三层是最有价值但也是最困难的；因为真正的结果通常会延迟（几个月后才能清楚贷款是否会偿还）。
提示：如果实际结果有延迟，请先监控输入和预测分布。输入分布的变化是精度下降的早期迹象，并且可以在不等待实际结果的情况下发出警报。
评估法学硕士系统：特殊挑战
在经典 ML 中，“正确答案”很明确（0 类或 1 类）。另一方面，法学硕士的结果是开放式的：同一问题可能有许多正确答案，“正确性”并不适合单个数字。 LLM评估方法：
- 参考指标：将输出与理想答案进行比较。有限的;因为它可能认为正确的答案以不同的方式表达为“错误”。
- 基于规则的检查：输出的 JSON 是否有效？有禁止的词语吗？它包含所需的字段吗？便宜、可靠、紧凑。
- LLM-judge (LLM-as-judge)：不要让模型问“根据这个标准这个答案好吗？”它可以扩展，但裁判本身必须得到验证。
- 人工审核：黄金标准，但昂贵且缓慢。它被用在样品上。
在实践中，这些是一起使用的：对每个输出进行廉价的规则检查，对大样本进行法学硕士判断，对小而严格的样本进行人工评估。
弱方法/强方法
弱：“LLM-我问了裁判，我们92%的答案都很好。系统很棒。”
Güçlü：“我们首先对 100 份打印输出进行人工标记。我们对同样的 100 份打印输出进行了法学硕士法官的测试，并测量了人类与法官的一致性——85% 的一致性，可以接受。我们记录了法官系统性出错的地方（倾向于发现长答案不公平的好结果）并修正了他的提示。只有这样我们才相信法官的分数。”
区别在于：强方法是用真人主播来验证裁判，而不是盲目的。未经验证的法学硕士裁判给出了漂亮但虚假的信心。
注意：LLM-裁判也是模特；致幻、有偏见（偏爱长的/自信的答案）、可能不一致。在做出生产决策之前，使用人工标签校准裁判分数。
评价套装：精心设计
一个好的评估集代表了实际使用情况和困难情况的多样性。仅包含简单示例的评估会让您产生虚假的信心。确保将其放入 eval 集群中：
- 边缘情况：空输入、非常长的输入、不寻常的格式。
- 已知的困难情况：模型过去犯过错误的示例（作为回归测试）。
- 安全事件：提示注入尝试、恶意请求、侵犯隐私陷阱。
评估集群随着时间的推移而增长：您在生产中发现的每个新错误都会成为下一次评估的测试用例。
报警与干预
如果没有警报，监控仍然不完整。每个重要指标都应该有一个阈值和一个响应计划：“如果输入漂移超过 X，则通知工程师”，“如果错误率超过 Y，则自动回滚”。保持警报有意义——太多的错误警报会使团队变得不敏感，并让他们错过真正的警报。
三个迷你箱子
案例 1 - 预警。需求预测模型的真正准确性直到本周末才显现出来。该团队正在监控输入分布，并在周二看到了新产品类别的突然崛起——这是该模型从未见过的。他们没有等到准确率下降就更新了模型。输入监控节省了时间。
案例 2 - 未经验证的裁判。根据法学硕士评审员的评价，一支团队报告“我们的质量非常出色”。当顾客投诉增加时，引入了人工监控：裁判将自信但不正确的答案视为“好”。一旦裁判用人类标签进行校准，真实的质量就暴露出来了，而且要低得多。教训：在没有核实的情况下不要相信裁判。
案例 3 - 回归测试。迅速的改变解决了一个问题，同时又悄然破坏了另一个问题。但团队将过去的错误保留在评估桶中；当在该集群上测试新的更改时，损坏的情况立即被捕获并修复了更改。教训：每个修复的错误都应该成为永久的测试用例。
可复制模板
为该生产模型制定跟踪计划。涵盖三层：1）操作（延迟、错误率、体积）2）输入/数据（分布偏移、缺失值、新类别）3）模型/输出（预测分布、置信度、准确性（如果可能））模型：[描述]。实际结果需要多长时间才能到达：[持续时间]为每个指标添加阈值和干预建议。
为该 LLM 系统提出评估 (eval) 策略。任务：[描述]确定层：- 每个输出应运行哪些基于规则的检查？- LLM 仲裁员应评估什么标准以及应如何验证它们（人工锚点）？- 应在哪个样本中执行人工评估？列出我应放入评估集中的边缘和安全案例。
检查此LLM-裁判提示：- 评估标准是否明确或主观？- 是否容易出现长度/置信度偏差？- 如何用人工标签校准裁判？裁判提示：[提示]
为此监控警报编写响应操作手册。警报：[例如[超出输入漂移阈值]必须包含：初始控制步骤、可能原因、回滚标准、通知对象。
劣化原因表
失真
症状
早期发现的方法
数据漂移
输入分布变化
输入分布监控
概念转变
正义悄然降临
预测+实际对比
上游错误
字段变为空白/格式更改
模式验证+缺失率
模型不一致
产出分布变化
输出分布监控
常见错误
- 不建立监控。模型悄无声息地崩溃了，没有人看到它。
- 仅跟踪运营指标。系统已经启动，但预测可能是错误的。
- 使用LLM而不验证推荐人。它给人虚假的信心。
- 用简单的例子进行评估。它并不表明真正的困难。
- 不包括评估中过去的错误。同样的错误再次出现。
- 大声警报。团队变得麻木不仁，错过了真正的警报。
综上所述
模型可能不准确，但不会导致生产错误；因此评估和监控与开发同样重要。建立三层监控（运营、输入、输出）；如果实际结果延迟，请使用输入漂移作为早期警告。在LLM系统中，评估是开放式的；将规则检查、LLM 裁判员和人工评估结合使用，但一定要使用人工锚来验证 LLM 裁判员。使用边缘和安全案例丰富您的评估集群，并将每个捕获的错误转变为永久测试案例。
应用任务
为生产（或接近生产）模型编写一个三层监控计划，并为至少一个输入分布指标定义阈值+警报。如果您有一个 LLM 系统：用人类标记 30 个输出，在相同的输出上运行 LLM 裁判，并测量人类裁判的一致性；注意裁判的系统偏见。向您的评估集群添加至少 3 个边缘和 2 个安全案例。
清单
- [ ] 监控涵盖所有三个层（操作、输入、输出）。
- [ ] 如果实际结果延迟，我使用输入漂移作为早期警告。
- [ ] 我用人类标签校准了法学硕士仲裁员。
- [ ] Eval 集群包含边缘和安全案例。
- [ ] 我把我发现的每一个 bug 都变成了永久的测试用例。
- [ ] 每个重要指标都有一个阈值和响应计划。