Opik LLM 可观察性：在绿色之前审核线程分数

Opik 可以告诉您有关多轮代理的大量信息，但可见的痕迹或高对话分数还不能作为健康判断。合理的默认设置是使用 Opik 进行跟踪和评估证据，然后在显示绿色之前需要四个附加事实：在一个线程标识下着陆的预期回合、该线程有资格评分、分数是在最新活动之后生成的，并且请求的结果存在于其目的地。 当分数缺失或看起来令人放心时，这种区别最为重要。 “无分数”可能意味着对话仍处于活动状态，采样规则将其排除，评分待定，或评分已停止。 0.94 的分数可能属于线程的先前版本。即使是新的 0.94 也可能与丢失的文件、未发送的消息或失败的更新共存。 本指南构建了一个无内容收据并重播了十个针对它的案例。在存储库提交时针对 Opik 2.2.12 进行了检查 c54a6a9 2026 年 7 月 29 日。它不需要提示、响应、凭据或客户标识符。 在判断分数之前先证明线索 Opik 将相关迹线与用户定义的 thread id 进行分组。它是 固定的对话文档 表示标识符在项目中必须是唯一的。这为操作员提供了一个重要的边界：对话不是仪表板中“任何看起来相关的行”。 在读取任何线程级评估器结果之前，记录： 预计接收痕迹的工作空间和项目； 预期线程 ID 的不透明哈希或非敏感表示； 针对预期轮次观察到的不同线程 ID； 最近的跟踪活动时间； 用于建立可见性的收集器或查询时间。 一个与预期 ID 匹配的观察到的 ID 通过身份门。零 ID 是一个遥测问题。一个预期对话的两个 ID 是碎片，即使两个片段都有各自有效的跨度。在不同的项目中重复使用相同的显示友好ID也是不同的证据范围。 当痕迹不存在时，不要一开始就责怪评估者。 Opik的 固定SDK配置指南 在 TypeScript SDK 和显式 client.flush() 和 flushAll() 控件中进行批处理的文档。完成的刷新是有用的交付证据，但它仍然不能证明收集器接受了批次或查询正在读取预期的项目。确认齐平边界后的可见性。 此顺序可防止常见的诊断错误： 将冷却和采样视为合格，而不是失败 线程级在线评估故意是异步的。 Opik 记录了最后一次活动后、线程评分之前默认的 15 分钟冷却时间。该值可以在工作区设置中或通过记录的自托管环境设置进行更改。相同 固定文档 解释说，延迟是为了让整个谈话顺利进行。 因此， now last activity at < configured cooldown 是 活跃 ，没有逾期。代理可能正在工作，等待合法用户轮流，或者只是在观察窗口内。当记录的策略为 15 分钟时，在第五分钟寻呼会产生一个事件。 采样创建了第二条无故障路径。 Opik 在线规则具有明确的采样率及其模型、提示、变量映射和分数定义。如果收据表明未选择线程，则正确的状态是 coverage excluded 。它不是 scoring overdue 。 对于选定的线程，在冷却后添加单独的评分宽限期。该宽限期是您的操作 SLO，而不是 Opik 保证： 在这段时间之间，保留判决 scoring pending 。在 overdue at 之后，检查规则日志、评估者凭据、模型可用性、速率限制和队列运行状况。这会创建一个干净的警报边界，而不会混淆合法活动与失败的评估器。 收据需要保留做出决定的政策。将实际配置的冷却时间、规则版本、采样决策、评估者姓名和宽限期与分类一起存储。如果冷却时间从 15 分钟变为 30 分钟，历史事件应该保持可解释性，而不是默默地获得新的含义。 可见的分数仍然可能是陈旧的 新活动改变了证据版本。 Opik的 对话线程文档 表示添加跟踪会保留现有的反馈分数，重新启动冷却时间，并在新的冷却时间后重新运行在线评估。保存对于连续性很有用，但它会产生暂时的绿色风险。 使用这个规则： 如果可见分数早于最新回合，则将其分类为 score stale ，无论其值如何。等待重新运行或显式评估最新的线程修订版。不要将旧分数平均为绿色并且不要将其擦除；保留它作为有关早期线程状态的证据。 新鲜度是必要的，但还不够。 Opik将在线评估输出存储为反馈分数，其线程规则可以对整个对话进行判断。这 固定规则文档 还描述了对话连贯性、用户挫败感和自定义指标，包括当所选模型支持工具调用时对执行路径的访问。 这些是评估结果。他们回答了度量中编码的问题。它们不会自动证明存在外部副作用或可交付成果。 假设支持代理在表示更新了票证后收到了高相关性和一致性分数。线程证据可以支持“对话是连贯的”，也许“出现了预期的工具调用”。只有票证系统可以证明预期的票证现在包含预期的有界找零。最终门必须使用非敏感相关键查询该目的地，并将结果与​​确定性接受规则进行比较。 这会产生三个不同的决定： 新分数低于阈值： quality alert ； 没有目的地收据的新可接受分数： outcome unverified ； 新的可接受分数加上匹配的目的地收据： verified 。 排序是经过深思熟虑的。目标收据并不会使糟糕的对话变得健康，良好的对话分数也不会产生目标结果。 重播十州审计 随附的 opik thread score audit.mjs 装置不包含对话内容。每个案例仅提供可见性、预期和观察到的身份、上次活动、采样选择、得分和得分时间以及布尔目的地收据。该示例策略使用记录的 900 秒默认冷却时间、本地选择的 300 秒评分宽限以及 0.7 的演示阈值。 状态优先级最容易应用为移动安全决策列表： 1. telemetry missing ：预期的迹线不可见。检查刷新、收集器、项目和查询的新鲜度。 2. thread fragmented ：观察到的 ID 与预期 ID 不相等。在判断之前修复传播。 3. active ：最新活动已进入冷却时间。别管它。 4. coverage excluded ：符合条件的线程未被采样。记录覆盖范围；不要翻页。 5. scoring pending ：所选线程符合条件，但在宽限内。保留未知并等待。 6. scoring overdue ：所选线程超出恩典，没有分数。检查评估器路径。 7. score stale ：得分时间早于最新活动。评估最新修订版。 8. quality alert ：新分数低于所选阈值。以有限的权限审查证据。 9. outcome unverified ：分数新鲜，可以接受，但没有目的地收据。验证真实结果。 10. verified ：身份、时机、得分、结果全部通过。保留收据。 从其目录运行工件： 固定重播返回十种不同的预期状态，如果任何情况意外更改，则退出非零。有两个案例值得比较： 第一个的分数为 0.94 ，但该分数早于最新跟踪。第二张有一张新的 0.91 ，但没有目的地收据。只有第三个拥有稳定的线程、完成了当前评估、可接受的分数和经过验证的输出。 通过从您的环境中将合成收据替换为内容最小化的导出来调整固定装置。如果您只需要相等，则哈希标识符。将提示文本、响应、工具负载、机密和绝对本地路径保留在运行状况流之外。根据您自己的评估器延迟和校准数据设置评分宽限和质量阈值；这两个值均未作为通用 Opik 默认值提供。 使用一种冷静的操作规则 对于 Opik LLM 可观测性，实际规则是： 在预期跟踪形成一个当前线程并且评分策略表明该线程合格之前，不要解释线程分数。在分数比上次活动更新并且请求的结果经过独立验证之前，请勿清除运行。 该规则保留了合法的等待，使采样可见，并防止丢失分数警报和陈旧分数绿色状态。它还保持边界诚实：Opik提供了有价值的跟踪和评估证据；您的目的地提供结果收据。 审计有其局限性。它不测试评估器校准、提示质量、语义正确性、提供程序完整性或实时 Opik 部署的可用性。与内容无关的状态机无法决定 0.7 是否是您的任务的正确阈值。根据确定性和人为标签校准法官，记录不确定性，并为后续决策保留人为审查路径。 Sidewisp 目前处于私密预览阶段。 其计划的健康层旨在将证据、新鲜度、等待状态和验证结果放入一个操作员视图中，但本文并不意味着 Opik 适配器或生产监控引擎今天已发货。 主要来源 Opik 对话和线程身份文档，固定到已审查的提交 Opik 在线评估规则，固定到已审查的提交 Opik SDK 配置和刷新控件，固定到已审查的提交