在此页面上
简短的回答
留意三种变化：用户提出什么要求、系统响应如何以及您如何对其工作进行评分。将这些信号分开。仅收集调查问题所需的数据。使用经过审查的失败来填补测试集中的空白。
拿走什么
- 用户请求的变化并不总是意味着模型变得更糟。
- 即使答案保持不变，新的评分规则也可能会改变分数。
- 在收集每条数据之前确定为什么需要它。
已检查来源 .研究综合和 Rubrex 建议。示例和本地实验均已标记；它们不是客户结果。
研究和文档涵盖的内容
ProxyDrift 是 2026 年 8 月的预印本，研究如何使用交互的结构化摘要来比较实时流量与测试集。这些摘要代表直接访问原始交互。 LangSmith 的文档描述了对实时运行进行评分以及向离线测试集添加示例。这些是不同的方法。两者都不能证明监控设置可以保护隐私或涵盖各种用户请求。
观察三种变化
输入漂移意味着请求已更改。用户可能会提出不同的任务、使用新的语言或发送更长的文档。结果漂移意味着结果发生了变化，例如更多的错误或更慢的答案。测量漂移意味着评分过程发生了变化。新的裁判、评分指南或抽样规则都可以改变数字。单独记录这些更改。
较高的失败率可能意味着传入的任务更加困难。这并不总是意味着模型较弱。如果较简单的请求与较困难的请求相平衡，则平均值不变也可能隐藏问题。比较对您的产品重要的组，例如语言或任务类型。显示每个分数背后的示例数量。
保留重点监控记录
Rubrex 建议从每个警报应支持的决策开始。要调查工具超时，您可能需要工具名称、时间、错误类型和软件版本。您可能不需要完整的用户消息。要检查答案是否正确，您可能需要源文档。同意谁可以访问该数据以及何时必须删除该数据。
标签和基于数字的表示（例如嵌入）可能仍然包含敏感信息。检查它们是否泄露私人详细信息或可以与某个人相关联。将实时用户数据排除在公开示例之外。在解释故障时使用虚构的示例或删除敏感细节。已转换的数据不会自动安全地共享。
示例：扫描文档导致新的故障
假设采购助理在新集成启动后开始接收扫描文档。模型没有改变，但系统现在很难提取文本。旧的测试集使用干净的数字文本。即使真正的用户看到更多的失败，它仍然会过去。
首先，使用您可以查看的示例确认提取失败的位置。将扫描文档添加到单独的测试组，并检查参考文本。然后测试提取步骤以及最终答案。即时更改可能无法修复丢失的源文本。在将新测试作为警告信号之前，先检查新测试是否发现了真正的问题。
给每个警报一个下一步
为每个警报指定一个所有者。解释为什么它的阈值很重要以及所有者应该首先检查什么。查看误报以及警报遗漏的事件。当真正的故障成为测试用例时，记录它来自哪里、应该发生什么以及包含它的测试集版本。比较新旧结果时，请注意流量和评分规则的变化。
- 记录应用程序、测试集、判断和采样版本。
- 比较每个任务组内以及整体的质量。
- 查看广泛的样本以及触发警报的案例。
- 检查原始数据和派生标签的访问和删除规则。
使仪表板在事件发生期间发挥作用
监控显示所选信号如何随时间变化。可观察性可帮助您将信号追溯到请求、系统设置或依赖项。评估检查结果是否满足用户的需求。 Rubrex 建议将这些记录与运行 ID 连接起来。根据产品商定的数据规则，仅保留调查所需的数据。
尝试从头到尾遵循一个警报。团队能否找到受影响的案例以及软件版本？有人可以将失败转变为其他工程师可以重新运行的测试吗？在每个趋势旁边显示样本计数、缺失结果、严重失败和分数定义。修复后，重新运行测试并检查结果是否有所改善。当仪表板可以帮助人们决定下一步做什么时，它很有用。
证据的局限性
交互的摘要可能会遗漏有用的细节。这不是隐私保证。根据产品的数据规则和真实的故障案例检查您的监控计划。引用的预印本描述了一种方法； Rubrex 尚未在本文中重现其部署或结果。
常见问题
仅凭日志就能判断答案是否正确吗？
通常不是。日志可以显示事件和错误。要确定答案是否正确，您还需要可信的源材料、人工审核或您检查过的评分方法。
流量变化时离线数据集是否应该变化？
首先检查更改是否在测试中留下了空白或更改了决策。更新测试集时保存新版本，以便早期结果仍然可以理解。
来源和进一步阅读
本简报背后的主要来源。来源的研究结果适用于其自身的研究条件； arXiv 上的出版物不建立同行评审。
- 通过代理表示的大规模 LLM 应用程序的隐私保护数据漂移检测和恢复 arXiv · 2026 · 预印本已审核： 摘要和出版记录.已访问 2026年9月25日.
- 朗史密斯评估 浪链 · 生活参考 · 维护文档已审核： 评测概述.已访问 2026年9月25日.