介绍如何通过追踪与跨度为 RAG 流水线的每个操作提供结构化可见性，以支持调试、成本分析和质量监控。
AI translation, not an official translation. Refer to the original for technical details.
Adapted from @_avichawlaAI 系统中的可观测性分层，图解说明： 如果一个 LLM 应用正在为真实用户提供服务，仅靠其输入和输出是不足以进行调试的。 以一个 RAG 流水线为例，查询请求需要依次经过嵌入、检索、上下文组装和生成等环节。 每个操作都会增加延迟，可能调用付费 API，并且在仍然产出看似合法的响应的同时悄然失败。 追踪（Traces）和跨度（Spans）提供了可见性。 - 追踪记录一次请求的完整路径。追踪列从查询贯穿至响应。 - 跨度记录该追踪中的某一个操作。图中的彩色方块即为跨度。 每个跨度捕获以下信息： > 查询跨度 输入内容、时间戳、会话标识符以及请求元数据。 > 嵌入跨度 模型名称、输入大小、延迟、重试次数以及速率限制错误。 > 检索跨度 检索到的文本块、文档 ID、相关性评分、过滤条件、top-k 值以及延迟。许多 RAG 故障源于此处。若缺少这些字段，则无法留下检索选择了错误文档的证据。 > 上下文跨度 从检索到的文本块、指令和对话历史中组装而成的上下文。此跨度可捕获文档被截断、文本块重复、引用缺失以及提示词超出 token 预算等问题。 > 生成跨度 模型名称、token 数量、首个 token 的生成时间、总延迟、结束原因、重试次数以及预估成本。 有了这些详细信息，一个不佳的响应现在便可以被追溯至检索、上下文组装或生成环节。 在实际使用中，Opik 已经为 LLM 应用实现了这套可观测性基础设施，并且是开源的。 它能够捕获跨 LLM 调用、检索步骤和工具执行的追踪与跨度，并为每个操作附加延迟、token 用量和成本信息。 GitHub 仓库：https://t.co/vahjkkfJCt （别忘了给它加星 ⭐） 在 Opik 中，属于同一请求的每个操作都携带相同的追踪 ID。如果应用处理了 1,000 个请求，则会创建 1,000 条追踪，每条追踪都包含其自身的跨度。 这使得成本分析更加有价值。团队可以识别出造成消耗的具体模型调用、重试操作或过大的提示词，而不是仅仅查看汇总支出。 随着时间推移，检索评分、嵌入延迟或上下文大小的变化在演变为更大范围的质量问题之前便会变得可见。 话虽如此，可观测性只是构建生产级 LLM 系统需要学习的八个领域之一。 我在 2026 年 LLM 工程路线图中涵盖了全部八个领域，并为每个领域提供了免费的开源学习资源。 请在下方阅读。
