面向生产级LLM应用的可观测性分层框架来了，还能直接用开源工具

AI系统可观测性的分层，图文解释：如果一个大语言模型应用要服务真实用户，只看它的输入和输出是不够调试的。比如说RAG管线，一次查询要经过嵌入、检索、上下文拼接和生成这几个步骤。每个操作都会增加延迟，还可能调用付费API，哪怕最终输出了一个看起来没问题的响应，过程中也可能已经出错了。追踪和跨度（spans）能提供可见性。

- 一次追踪（trace）记录一个请求的完整路径。追踪列从查询一直延伸到响应。
- 一个跨度（span）记录这次追踪里的单个操作。图中彩色方块就是跨度，每个跨度会记录：
> 查询跨度：输入、时间戳、会话标识符和请求元数据。
> 嵌入跨度：模型、输入大小、延迟、重试和速率限制错误。
> 检索跨度：检索到的片段、文档ID、相关性分数、过滤器、top-k值和延迟。很多RAG失败都出在这里。没有这些信息，就无法确认检索是不是选了错误的文档。
> 上下文跨度：从检索片段、指令和对话历史拼接出来的上下文。这一步能捕捉到被截断的文档、重复片段、缺失引用，还有超出token预算的提示词。
> 生成跨度：模型、token数量、首包响应时间、总延迟、结束原因、重试和估算成本。

有了这些细节，就能把错误响应定位到是检索、上下文拼接还是生成环节出了问题。实际用的时候，Opik已经为大语言模型应用实现了这套可观测性基础设施，而且是开源的。它可以跨大语言模型调用、检索步骤和工具执行来捕捉追踪和跨度，每个操作都会附带延迟、token使用情况和成本。

在Opik中，属于同一个请求的所有操作都带有相同的追踪ID。如果应用处理了1000个请求，就会生成1000条追踪，每条都包含自己的跨度。这让成本分析更有用。比起汇总开销，团队可以定位出是哪些模型调用、重试还是过大的提示词导致了成本过高。假以时日，检索分数、嵌入延迟或上下文大小的变化，在它们发展成更广泛的质量问题之前就能被发现。

话虽如此，可观测性只是我总结的构建生产级大语言模型系统需要学习的八个领域之一。我把这八个领域都写进了2026大语言模型工程路线图，每个领域都附带免费开源资源。请阅读下文。