Opik开源LLM 应用可观测性基础设施(1,000)

AI 系统可观测性的分层，用图来说明：如果一个 LLM 应用正在服务真实用户，仅靠输入和输出是不足以调试它的。

设想一个 RAG 流水线，查询依次经过嵌入、检索、上下文组装和生成。每一步操作都会增加延迟，可能调用付费 API，并且可能在仍然产生看似正常的响应时失败。

Trace 和 Span 提供了可见性。

- Trace 记录一个请求的完整路径。Trace 列从查询延伸到响应。
- Span 记录该 Trace 中的一次操作。彩色方框就是 Span。

每个 Span 捕获：

> 查询 Span
输入、时间戳、会话标识符和请求元数据。

> 嵌入 Span
模型、输入大小、延迟、重试次数和速率限制错误。

> 检索 Span
检索到的文本块、文档 ID、相关性分数、过滤器、top-k 值和延迟。许多 RAG 故障源于此。没有这些字段，就无法证明检索选错了文档。

> 上下文 Span
由检索到的文本块、指令和对话历史组装而成的上下文。这可以捕获文档被截断、文本块重复、缺少引用以及提示词超出 token 预算等问题。

> 生成 Span
模型、token 数量、首 token 时间、总延迟、完成原因、重试次数和预估成本。

有了这些细节，现在可以将一个糟糕的响应追溯到检索、上下文组装或生成环节。

在实践中，Opik 已经为 LLM 应用实现了这种可观测性基础设施，并且是开源的。它捕获跨 LLM 调用、检索步骤和工具执行的 Trace 和 Span，并为每个操作附加延迟、token 用量和成本。

GitHub 仓库：（别忘了给它点个星 ⭐）

在 Opik 中，属于同一个请求的每个操作都带有相同的 Trace ID。如果应用处理 1,000 个请求，就会创建 1,000 个 Trace，每个 Trace 包含自己的 Span。

这让成本分析更有用。团队可以找出是哪些模型调用、重试或过大的提示词导致了开销，而不是只看总花费。

随着时间推移，检索分数、嵌入延迟或上下文大小的变化会在演变成更广泛的质量问题之前显现出来。

也就是说，可观测性只是我们为构建生产级 LLM 系统需要学习的八个领域之一。我们在《2026 LLM 工程路线图》中涵盖了全部八个领域，并为每个领域提供了免费和开源资源。

请在下方阅读。