11.3 日志、观测与故障排查

先给结论：RAG 上线后，最怕的不是出问题，而是出问题却不知道原因。日志、观测与故障排查的价值不是“可视化好看”，而是能把失败快速定位到数据、检索、重排、上下文或生成的具体环节。

很多团队上线后会遇到这些问题：

• 用户反馈“答错了”，但无法复现
• 线上延迟上升，却不知道瓶颈在哪
• 回答质量波动，无法判断是数据变化还是策略变化

这些问题的根因几乎都指向同一件事：

• 没有建立可观测的链路日志和指标体系

学这一节时，最值得先建立的判断

• 没有链路日志，就无法做归因
• 没有指标分桶，就无法看到结构性退化
• 没有故障定位流程，优化就只能靠猜

这一节会回答什么问题

• 如何做 RAG 的日志、观测和故障排查？
• 线上 RAG 系统应该监控哪些指标？
• 一次失败回答上线后，应该如何快速定位问题出在哪一层？

读完这一节后，你最好能更稳地判断：

• 日志应该记录到什么粒度才够用
• 线上指标应该怎么分层、怎么分桶
• 出现失败时，如何按链路顺序快速定位根因