你知道 RAG 系统可能在七个环节依次崩溃吗？检索层有『内容缺失』（知识库里根本没答案）、『错失首位』（正确结果在候选里排后面被截断）、『上下文整合失败』（关键信息被忽略）；生成层有『提取失败』（答案在眼前模型看不见）、『格式错误』、『特异性偏差』（答得对但太笼统）、『回答不完整』。本文案里用户查退款进度却收到通用说明，是典型的『内容缺失』和『错失首位』的叠 bug——订单实时状态根本不在知识库里，检索系统也没做工具调用分诊。

很多人以为 RAG 就是把文档扔进向量库、接个大模型就能智能问答。错了。真正的门槛在『80% 准确率陷阱』——首次搭建效果通常只到 60%-70%，70% 到 95% 的提升要靠逐环节的效果评估、切割策略调参、重排序模型选型、多路召回设计。从 10% 到 60% 靠工具，从 60% 到 95% 靠工程。本文作者给出的排查表，本质上就是为每一轮『从 70% 往 80% 爬』提供取证框架。

电商客服 Agent 日接三四千条消息，生产经验证明：把每条消息丢给大模型是『架构偷懒』。真实拆法是『四档漏斗』——规则匹配（毫秒级回复简单问题，如『今天发货吗』）→ 知识库检索（秒级回复常见问）→ 大模型生成（处理复杂语义）→ 人工转接。前端拦截掉七成高频简单问题，成本省一半、延迟降一个数量级、确定性数据不走模型、承诺类话术不上生成。

本文主张『先查日志再动手』，但吴恩达的 Prompt 工程派有一条不同路线——通过『分层 Prompt + 置信度评分』把意图识别准确率从 72% 拉到 89%，改提示词本身就能解决多数『答非所问』。两派的分歧在故障假设：Prompt 派假设『路由和检索都已经对，只是模型没理解』，排查派假设『哪都可能错，先还原现场』。实际生产中，亚马逊 REIC 方案用『检索增强分类 + 约束解码』把两派融合了，新增意图不用重训。

博睿数据的 Sage AI 故障诊断助手已经能根据告警自动拉取调用链、生成根因报告——『一句话诊断』不再是 demo。把这个模式移植到 AI 客服场景，技术上只差一步：把『用户问题→检索→生成』的每个 span 埋进 OpenTelemetry 链路，让系统在答非所问发生时自动比对『意图分类输出』『检索候选 Top-3』『注入模型的上下文片段』『模型回答』四者的差异。阿里云监控 2.0 已经在做这个方向。