概述
它将请求与检索、模型调用、工具及最终结果连接起来。目标是调查真实行为，而不将生成的解释视为内部计算的可靠痕迹。
主要要点
- 连接指标、追踪和事件。
- 衡量任务成果和运行时间。
- 尽量减少并保护已记录的内容。
深入探讨
使用互补信号。指标显示延迟、错误率和资源使用等模式。追踪连接请求的各个阶段。日志描述事件，帮助解释失败或决策。稳定的请求和版本标识符使这些信号更实用。在可能的情况下添加任务级测量。技术上成功的模型调用仍可能返回未受支持的信息或未能完成请求操作。跟踪证据覆盖率、验证失败、升级和验证结果，同时关注传输健康状况。保护遥测中的敏感内容。记录每个提示和响应可以创建一个新的私有数据存储。收集诊断所需的最低要求，应用访问和保留控制，优先使用已涂黑或汇总的信息，满足相同需求。使警报可操作。识别所有者、相关阈值、诊断上下文和恢复程序。避免出现噪杂事件页面，这些事件从未导致决策。测试预期信号中是否出现故意诱发的故障，并让操作员追踪到受影响的释放。
04工作示例
将症状与依赖联系起来
想象用户报告回答缓慢，而模型生成时间保持不变。
请求追踪显示，索引更改后文档检索时间从100毫秒提升到2秒。
调查这种依赖性，并用新的痕迹确认恢复，而不是无证据地替换模型。
它显示了什么
发明的计时展示了连贯测量的价值。
现实世界的实施
通过检索和模型生成追踪答案，以识别慢阶段。
将验证错误与特定提示词或模型版本关联起来。
付诸实践
为什么这很重要
- 成本与预算. 多年来，架构决策决定着性能和运营成本。
- 更清晰的判决. 技术教育帮助团队选择正确的堆栈，而不仅仅是最新的堆栈。
- 质量控制. 更好的工程选择可以减少生产中的可靠性事故。
留意
- 优化一项基准测试可以隐藏更广泛的系统弱点。
- 基础设施和维护成本常常被低估。
- 随着系统变得更加复杂，安全性和可观察性差距可能会扩大。
后续步骤
- 在实施之前定义延迟、质量和成本目标。
- 在实际负载和数据条件下进行基准测试。
- 仪器监控错误、漂移和用户影响。
- 在扩展之前准备回滚和事件响应路径。
资料来源与延伸阅读
- OpenTelemetry可观测性信号
不断探索
常见问题
我应该记录每一个可观察提示吗？
不是自动的。确定诊断需求和隐私影响，然后使用适当的最小化、访问和保留控制措施。