LLM监测:超越延迟,错误和代币的测量

LLM监测应从模型调用状态开始:延迟,错误,请求量,代币和输出质量. 这对于聊天功能,检索管道或API包装来说是合理的默认. 一旦相同的应用程序能够计划,调用工具,等待批准,稍后恢复,或宣布任务完成, 两本账本回答不同的问题. 第一个问题是, 模型服务是否正常运行? 第二问题是, 代理是否取得了有用的进展并产生了预期的结果? run id ;不要把一张绿色的延迟图变成说工作是健康的. 开始使用默认的LLM监控层 一个有用的第一台仪表板不需要几十个面板. 它需要足够的证据来分离供应商故障,应用程序故障,成本漂移和输出质量漂移. 信号 问题,答案 实际的首次警报 它不能证明的 请求错误率 模特通话失败了吗? 按供应商和模型分为窗口的价格 成功的调用是否提升了任务 p50/p95延迟 反应时间下降了吗? 进行类似操作和模型的比较 慢跑是否最终提供 输入/输出代币 背景或一代人增长了吗? 从特定任务的基线上变化 额外的代币是否有用 吞吐量 货物变化了吗? 每分钟的请求加上同步时间 没有错过计划的运行 质量评分 样本输出是否符合规范? 版本评估器加载人气校准 一个文件,门票或部署是否存在 痕迹覆盖 运营商可以重建执行吗? 运行时间的遗漏或不完整的痕迹 预期结果是否存在 这一基线与当前的搜索意图相匹配. 朗夫斯描述了延迟,吞吐量和错误率的监控,并为执行路径进行了测量,并为输出质量进行了评估. 斯普朗克和迪纳特雷斯将集扩展到资源,安全,成本,反和应用信号. 这些是LLM应用程序的有用观点;仅仅因为存在代理层,就不应该丢弃它们. OpenTelemetry的GenAI语义公约使得在仪器本身中可见的分离. 开发规格定义了 gen ai.client.token.usage 和 gen ai.client.operation.duration ,然后分开工作流和代理仪器,如 gen ai.invoke agent.duration ,推断调用数量和工具调用数量. 开发在这里很重要: 按你实施的版本,并预计名称会发生变化. 清洁的实现是采用 run id , operation , provider , model 和时刻标签的模型调用账本. 总结它为服务级别的警报,但保留返回单个运行的路径. 一个没有运行标识符的代币尖是一个账单;一个与停滞的运行挂的代币尖是一个事件线索. 当应用程序成为代理时添加任务健康账本 在时间的推移下,一个支持LLM的功能跨越了运营界限. 它可能会打电话给数据库,写一份报告,打开抽取请求,等待一个人,或者按时醒来. 在这种情况下,成功的模型反应只是中间事件. 开放AI代理商SDK说明了这些事件可以变得多么丰富. 它内置的追踪记录代数,功能工具调用,交付,护卫,和代理运行. 这是有价值的调试证据. 同样的文档还指出,生成和功能范围可能包含敏感的输入和输出,这就是让内容捕获成为明确的选择而不是监测的先决条件的原因. 一个任务健康账本可能比痕迹小. 每次运行,记录: expected outcome :一个预言,如 report exists and parses ,而不是句子完成任务; 具有验证版本的 outcome verified : true , false 或 unavailable ; progress delta :在声明的窗口中,具体任务的计数或消化变化; waiting on :一个命名的依赖性,例如 human approval ,或 null ; last heartbeat at 和 last progress at ,因为活动和进展是不同的时钟; declared complete :运行时间报告的情况; collector freshness :这些事实在最后一次观察时. 这本书故意不重复每一个提示,完成或跨度. 它存储了必要的最小证据,以决定运行是否有效,等待,卡住,无法到达或完成. 在政策允许的情况下,可继续进行调查. 重要的建模选择是三状态证据. 如果收藏者无法检查交付品,请记录 outcome verified: "unavailable" . 不要将缺失的证据转换为 true ,并且不要仅仅因为其信号缺失而称未知的运行失败. 复制距离6次 附带装置包含6个合成跑步. 在请求错误至少为20%,p95延迟超过5000ms,或代币使用超过20,000时,LLM本书警告. 任务健康账本检查了明确的等待,宣布完成与确定性结果以及进展新鲜性. 运行 Node.js 20 或更新版本的审计: 结果是: 这种分歧是结果,而不是任何一个账本的缺陷. 供应商错误运行需要模型服务调查,尽管代理仍然在取得进展. 慢跑完成了经过验证的结果,所以这是一个性能问题,而不是缺失工作事件. 在LLM监控器上,批准等待和错误成功运行看起来是正常的,因为他们的呼叫是快速的,便宜的,成功的. 只有任务合同揭示了需要注意的东西. 这些数字是反示例,而不是基准. 六个合成记录不能确定通用警报门. 取代截止时间的基线,并用与实际工作相关的证据取代 progress delta . 将任务合同变成警报 开始一个高价值的工作流程. 在添加另一个仪表板之前,请写其完成预示. 一项研究工作可能需要一个Markdown文件,至少有两个可访问的来源,以及一个有效的方案证据账本. 一个编码工作可能需要一个清洁补丁加上一个命名的测试命令. 支持代理可能需要创建票或记录升级. 然后以保持意义的顺序评估信号: 1. 如果跑步时间或收藏器过时,标记跑步不可及或不确定. 2. 如果 waiting on 是明确的,则将依赖线路转换,而不是重新启动运行. 3. 如果运行时间宣布完成, 评估结果预测. 4. 如果运行是活跃的,但 progress delta 在窗口之外保持零,请标记它着. 5. 如果没有任何应用,有用的进展是新鲜的, 这项命令阻止了三次噪音干预. 一个合法批准的等待不是一个局. 一个从零出发的命令并不自动完成任务. 如果相关的文物从来没有改变, 警示下一步安全行动,不仅仅是症状. 提供商错误警报向应用程序所有者提供模型,操作,错误类别和跟踪链接. 审批等待是可以决定的人, 一个失败结果警报指向失败的预言. 再试循环建议暂停或调查;它不应该允许不可逆转的修复. 保持连接有用,没有收集一切 在两个账本上使用一个不透明的 run id . 不要把客户的文本,秘密,绝对路径或工具的有效载荷放在该标识符中. 有用的相关性记录可以包含: 如果数据风险不同,则保持保留和访问规则的不同. 总结延迟和代币 histograms可能需要更长的保留比提示承载跨度. 结果证据往往可能是消化,计数,状态代码或方案结果,而不是文物本身. 当运营商钻进一个痕迹时,请显示其新鲜度和采样界限,以免误认为缺失是证据. 自动评估也有一定的局限性. 对于文件,HTTP状态,数据库行,测试和结构化字段,确定性检查是最好的. 如果预期的结果是质性的,一个版本的评价者可以帮助,但它的分数是不确定性不是基础真理的证据. 根据人类检查进行校准并保持 unavailable 状态. 适合Sidewisp的地方 Sidewisp的产品方向是第二本书:关于现有代理运行时间的健康视图,有证据,新鲜性,问题优先级和明确的批准界限. 它不是为了取代运行时间,模型网关或原始追踪系统. 这就是指向,而不是出货监控索赔. Sidewisp 目前处于私密预览阶段。 公共网站和文章系统是现场,而生产代理健康收集,运行时间适配器和恢复执行通常没有运送. 如果这个模型调用与结果边界符合您需要解决的操作问题,请加入私人预览. 主要来源 开放Telemetry GenAI指标语义公约 为客户端,工作流程,代理和工具操作的开发状态指标名称. 开放AI代理SDK追踪指南 追踪事件类型,出口行为和敏感数据控制. 长:LLM可观测和监测是什么? 是延迟,吞吐量,错误,追踪和评估相同意图的基准.