离线评估与在线监控的区别

定义离线评估

轨迹组成

轨迹是代理在接收特定输入时应遵循的有序步骤列表。每个步骤包含：

- 触发代理的用户语句或系统事件

- 代理应产生的思维或推理（如果记录了推理链）

- 代理应调用的工具或API请求

- 预期的工具响应或环境反馈

- 应该显示给用户或下游系统的最终代理输出

当您收集轨迹时，通常从一小组代表性的用户故事开始，然后通过添加日志或需求文档中可以想象的边缘情况来扩展它们。

评分标准

离线评估使用评分标准比较代理的实际轨迹和黄金轨迹，评分标准可以包含多个独立的维度：

- 精确匹配 - 代理是否产生相同的工具调用和响应序列？

- 语义相似性 - 代理的输出是否在含义上等同，尽管措辞不同？

- 忠实度 - 代理的推理是否保持在提供的工具输出中？

- 任务成功 - 最终输出是否满足故事定义的成功标准？

每个维度的评分在0到1之间。离线评分通常是加权平均，但也可以将每个维度作为单独的门槛。

在CI中运行离线评估

由于轨迹集是静态的，评分标准是确定性的，因此可以在持续集成管道中运行评估。步骤通常：

- 检出代理代码和轨迹固定

- 安装所需的依赖项

- 执行代理对每个轨迹，捕获实际跟踪

- 应用评分标准并写入JSON报告

- 如果任何评分低于预定义阈值，则构建失败

这为您提供了快速的反馈，关于可以重现的回归。

定义在线监控

生产环境中的观察

在线监控不比较预先编写的脚本。相反，它从运行的代理流式传输实时信号，并寻找与已建立的基线的偏差。典型的信号包括：

- 用户语句长度或令牌计数的分布

- 每个工具调用的频率

- 外部API返回的错误率

- 代理循环中每个步骤的延迟

- 回退或重试行为的速率

- 最终输出的语义漂移（使用嵌入距离测量到最近的参考集）

由于生产流量是无限的，因此您会在时间窗口（例如，五分钟滑动窗口）中收集这些信号，并将其与历史分位数进行比较。

仪表点

为了获取所需的数据，您需要在代理的几个关键位置进行仪表：

- 在入口点 - 捕获原始用户请求和时间戳

- 在每个工具调用之前 - 记录预期的调用和参数

- 在每个工具响应之后 - 记录成功标志、错误代码和有效负载大小

- 在代理产生最终输出之后 - 记录输出文本和任何安全评分

- 在定期间隔 - 发出包含内存使用和CPU负载的心跳

这些日志被发送到可观察性后端（Prometheus、Loki或自定义时间序列），在那里您可以创建仪表板和警报。

示例警报规则

一个有用的规则是，当特定外部API的5xx错误返回的比例超过过去两周的99分位数，持续三个连续窗口时，触发警报。这可以捕获依赖项的突然降级，这种故障模式在离线集中没有被覆盖，因为它只出现在实际负载下。

仅依赖一个层的常见陷阱

- 仅使用离线评分发布 - 您可能会通过门槛，但仍然发布一个代理，它在罕见的用户措辞或仅在高并发下出现的工具行为下失败。

- 仅使用仪表板发布 - 您可能会在问题被合并并影响用户之后的几天才注意到问题，使回滚更加困难，增加用户影响。

- 比较生产环境中的数字跨不同时间段，当模型、提示或工具列表也发生了变化 - 观察到的漂移可能是由于故意升级而不是回归，导致虚假警报。

- 使用相同的阈值进行离线和在线信号 - 离线评分通常很严格（您期望几乎完美的匹配），而在线指标是嘈杂的；应用单一截止值可能会导致过多的假阳性或漏检。

- 忽略对轨迹集的版本控制 - 如果您更新黄金轨迹而不记录更改，可能会导致评分不一致。

在CI中构建回归门

以下是如何为使用语言模型、检索工具和票据创建API的客户支持代理结构回归门的具体示例。

步骤 | 工具或脚本 | 输出 | 频率

检出代码和固定 | git clone + git checkout | 清洁工作空间 | 每次管道运行一次

安装依赖项 | pip install -r requirements.txt | 隔离环境 | 每次管道运行一次

在每个轨迹上运行代理 | python run_agent.py --trajectories data/trajectories.jsonl | JSONL文件，包含实际跟踪 | 每次管道运行一次

应用评分标准 | python score_traces.py --rubric config/rubric.yaml | 每个维度和总体评分 | 每次管道运行一次

检查阈值 | python gate_check.py --min-overall 0.92 --min-faithfulness 0.88 | 通过/失败状态 | 每次管道运行一次

发布报告 | curl -X POST -d @report.json https://metrics.example.com/ingest | 时间序列记录 | 每次管道运行一次

每个步骤都故意保持幂等，以便重新运行管道会产生相同的结果。如果任何步骤失败，管道将停止，合并请求将被阻止。

设置有意义的生产警报

有效的在线监控关注于快速变化的信号，而不是缓慢漂移的指标。

工具错误率

测量每个外部服务的失败工具调用与总工具调用的比率。突然的激增通常表明下游服务中断或代理未适应的服务合同更改。

循环重试计数

一些代理在收到模糊响应时会重试工具调用。跟踪每个用户请求的平均重试次数。增加可能意味着模型产生了更多不确定的输出，或者工具返回了模糊的错误。

输出嵌入漂移

计算每个最终代理输出的句子嵌入，并将其距离与上周稳定期的中位数嵌入进行比较。如果95分位数距离超过预设边界，则触发调查。

安全信号监控

如果您在代理输出上运行提示注入检测器或亵渎过滤器，请记录被标记的请求的分数。使用OWASP LLM提示注入防御备忘录（https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html）决定要监控哪些模式。被标记的请求的增加可能表明模型变得更容易受到越狱尝试。

所有这些警报都应路由到带有明确运行手册的值班轮换，该手册描述了如何回滚代理版本、如何热补丁工具包装器或如何为离线测试收集更多轨迹。

闭环：将监控结果转化为离线测试

拥有两个层的真正力量出现在您使用生产观察来改进测试套件时。

捕获新失败

当警报触发时，第一步是提取导致问题的确切请求-响应序列。大多数可观察性系统允许您下载包含：

- 原始用户语句

- 每个工具调用及其参数

- 每个工具响应

- 最终代理输出

将此跟踪保存为新的轨迹文件。

标记预期行为

与产品负责人或安全负责人合作，决定正确的行为应该是什么。如果失败是由于工具中的错误，则可能决定模拟修复后的工具响应。如果失败是由于模型的推理，则可能编写一个推理链，导致正确答案。

添加到离线集

将新轨迹放入版本控制的轨迹目录中。更新文档以注明来源（例如“从生产事件INC-2024-09-12-07添加”）。

如果需要调整评分标准

有时新的轨迹会揭示以前被忽略的维度。例如，您可能会发现代理有时会产生正确答案，但包含不必要的道歉短语，这会让用户感到烦躁。您可以将“简洁性”维度添加到评分标准中，并为其赋予权重。

重新运行门

再次运行CI管道。如果新的轨迹导致总体评分低于阈值，则意味着当前代码会在门前失败——这正是您想要在发布前捕获的。

重复此循环会创建一个反馈循环，其中生产环境教会测试套件应该测试什么，而测试套件则防止已知的回归到达用户。

什么不是

本讨论并不承诺离线评估会在发布前捕获每个可能的错误。它并不声称在线监控永远不会错过失败，或者两个层次一起提供100%的正确性保证。它并不声明使用这些方法会使代理无懈可击，或者可以跳过安全审查、红队演习或正式验证。它并不建议这些信号对于高风险领域的监管合规是足够的。它并不断言工作流程将消除对人类监督的需求，或者可以仅依赖自动评分来做出发布决定。它并不保证任何特定的阈值将适用于每个团队或每个模型架构。它并不断言上表是设置CI门的唯一方法，或者列出的警报规则是普遍最优的。

参考

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html

- https://docs.agents-squads.com/guides/config-files

常见问题

我们需要两个吗？

是的，如果代理触及任何用户或系统关心的东西。它们检测不同的故障类。

离线测试可以替代监控吗？

不，您的测试集无法包含您尚未想到的输入。

监控可以替代离线测试吗？

不，监控会告诉您在事实之后发生了什么变化；门槛会告诉您在发布前。

我们应该在生产中警告什么？

故障信号的变化率、工具错误率和异常循环或重试模式——不仅仅是数量。

我们如何使评分随时间保持可比性？

固定评分标准和轨迹，并在评分旁边记录模型、提示和工具的更改。

任一层是安全认证吗？

不，两者都是工程信号。安全审查是单独的练习。

参考

- NIST — AI风险管理框架

- Stanford CRFM — HELM（语言模型的整体评估）

尝试产品：AgentGrade

2026-09-20 · 仅主来源 · 无虚假流量指标 · 决策支持

相关文章

- 跨栈移动的代理评估标准

- 浏览完整的AI微SaaS主题矩阵 →