RAG 答错时，先别怪模型：一次请求里有五个地方会出错

用户拿到一段语气笃定、格式漂亮的回答，背后可能只是检索拿错了 chunk。LLM 应用上线后，输入和输出不够用来 debug。一次请求里，embedding、retrieval、context assembly、generation 都可能加延迟、调付费 API、失败，最后还产出一个看起来有效的响应。

Avi Chawla 在 Daily Dose of Data Science 里把 RAG 请求拆成 trace 和 span。trace 记录一次请求从 query 到 response 的完整路径。span 记录路径里的单个操作，也就是图里那些彩色块。

下面这段视频把关系画出来了：左侧从 User Query 到 Final Response，右侧五个色块对应五类 span 的持续时间。

五类 span 各自要抓什么：

• Query span：输入、时间戳、session 标识、请求 metadata。
• Embedding span：模型、输入大小、延迟、重试、限流错误。
• Retrieval span：召回的 chunks、文档 ID、相关分数、过滤条件、top-k、延迟。很多 RAG 故障从这里开始。没有这些字段，就没有证据证明检索选错了文档。
• Context span：由召回 chunk、指令、对话历史组装出的上下文。它能抓截断文档、重复 chunk、缺失引用、超出 token budget 的 prompt。
• Generation span：模型、token 数、首 token 时间、总延迟、finish reason、重试、估算成本。

有了这些字段，一个坏回答可以追到 retrieval、context assembly 或 generation。有网友在回复里说，他见过的大多数坏答案来自 retrieval 拉错 chunk，模型只是背锅。另一位网友说，context span 抓截断文档最该先加，静默截断的 prompt 从外面看就像模型变笨。

Opik 把这套观测做成了开源实现。它由 Comet 构建，Apache-2.0 许可，完整平台可自托管。Opik 捕获 LLM 调用、检索步骤、工具执行，并把延迟、token 用量、成本挂在每个操作上。每个请求的所有操作共享同一个 Trace ID。应用处理 1000 个请求，就生成 1000 条 trace，每条 trace 包含自己的 span。

这让成本分析更有用。团队不用只看总支出，可以定位到具体模型调用、重试或超大的 prompt。时间拉长后，检索分数、embedding 延迟、上下文大小的变化会先暴露出来，再变成更广泛的质量问题。

上手方式很直接：

pip install opik
opik configure

from opik import track

@track
def my_function(input: str) -> str:
    return input

GitHub 仓库：https://github.com/comet-ml/opik

Avi Chawla 把 observability 放在 2026 LLM Engineering Roadmap 的八个领域里。原文链接：https://x.com/DailyDoseOfDS_/status/2115737924805460022