1. 项目背景
某团队的知识库问答系统上线后，运维在监控大屏上发现了几个诡异问题。每天下午 3 点左右，P99 延迟会从 2 秒突然飙升到 15 秒，持续约 20 分钟后自行恢复正常；某类"合同审批流程"问题的 token 消耗竟是"请假流程"问题的 5 倍，但业务上两类问题的复杂度差异并不大；更令运维不安的是，偶尔出现"回答是空字符串"的情况——接口返回 HTTP 200，响应体里却没有内容，用户以为是系统故障，客服电话被打爆。
团队在全链路 7 个环节中排查了两天仍无法定位根因——因为每个环节都是一个"黑盒"。开发者能看到的，只有请求入口和最终的响应体，中间经历了什么、卡在了哪里、花了多少钱，全是盲区。
RAG 系统排障之难，根源在于三层复杂性叠加：
第一，环节多且串行依赖。一次完整的 RAG 请求要经过鉴权→检索→重排→LLM 调用→答案合成→返回，任意环节的性能抖动都会传导到端到端延迟。传统做法是在每个环节加print打点，但日志散落在不同模块的 stdout 中，无法串联为一个完整的调用树——当 P99 飙高时，你无法回答"是检索慢了还是 LLM 慢了？是向量库响应慢还是网络延迟大？"。
第二，成本是"隐性"的。Embedding 接口、LLM 接口、Rerank 接口的计费模型各不相同——Embedding 按输入 token 计费、LLM 按 input+output token 计费、Rerank 按文档量计费。没有链路级别的 token 统计，就无法回答"这次查询花了多少钱，钱花在哪个模型上"。月末收到账单时，团队只能分摊，无法归因。</
