RAG上线后，最让人头疼的往往不是“完全不能用”。它会答，语气也顺，但细看经不起追问：制度引用的是旧版本，产品参数没有出处，一个需要跨文档判断的问题，只抓住了其中一段。
这类问题很容易被归到“大模型不够强”。可在RAG里，模型只是最后开口的那一环。《数字化领航》AI应用专刊把RAG流程拆成三个阶段：知识索引构建、查询检索、生成增强。很多故障沿着这三段往回看，比直接换模型更快定位。
先翻索引库，别先调提示词
RAG要先把企业里的PDF、Word、日志、技术白皮书等资料处理一遍：解析、清洗、脱敏、切块，再用Embedding Model转成高维向量，存进向量数据库。听起来是工程前置工作，实际上它决定了后面能不能答对。
这一步做粗了，后面很难靠模型补回来。
PDF里的表格结构如果在解析时丢了，Word文档的标题层级如果被当成普通正文，日志里混进大量无意义字段，脱敏规则又把关键实体抹掉，检索阶段拿到的就不是可用知识，而是一些残缺片段。模型再会组织语言，也只能围着这些片段转。
分块更容易被低估。IBM在讨论RAG问题时提到，分块策略不当会导致低质量输出。块太碎，答案缺上下文；块太大，命中后又可能把冗余内容塞进上下文窗口，真正相关的信息反而被挤掉。
所以第一步应该抽样看索引库，而不是马上改prompt。看同一份文档切出来的块还能不能被人读懂，标题、表格、版本号、适用范围还在不在，向量数据库里存的文本是不是已经变成“碎片仓库”。
检索结果看着相关，未必能用
查询检索是RAG最容易“看起来正常”的地方。用户提问后，系统把问题转成向量，或者先提取关键信息，再到向量数据库里做近似语义检索，找出相近片段。
麻烦在于，语义相近不等于业务正确。
用户问某个产品的现行配置，系统可能找到了旧版白皮书；问权限审批流程，命中了另一个相似部门的制度；问题里有多个条件，检索只对上了其中一个。最后生成出来的答案很流畅，但从第一步取材时就偏了。
AWS对RAG的解释里强调，它的作用是让大语言模型在生成前引用训练数据之外的权威知识库，而不是重新训练模型。反过来看，如果检索拿到的不是权威、最新、相关的片段，后面再怎么生成，都缺少支撑。
排查时别只看最终答案，要看检索日志。用户问题被改写成了什么？向量数据库返回了哪些片段？这些片段来自哪份文档、哪个版本？它们是不是本来就应该被引用？很多RAG翻车，到这里已经能看到原因。
往上下文里多塞材料，不一定更准
有些团队发现答案不稳，第一反应是把更多检索结果塞给模型。这个办法偶尔有用，但也会带来新问题。
IBM列出的RAG问题里，包括上下文窗口限制、聚合运算能力不足、复杂关系理解缺陷。也就是说，RAG不是把资料堆给模型就结束。问题一旦涉及多个文档、多个条款、多个对象，模型可能遗漏、混淆，也可能只抓住最靠前、最醒目的片段。
这就是不少企业知识问答的典型表现：问单个事实还可以，问比较、汇总、判断，质量马上波动。
这时要看的不是某个单独参数，而是检索结果进入生成阶段前怎么组织。片段有没有排序依据？重复内容有没有清理？出处是否保留？模型是否被明确要求基于材料回答？如果用户的问题本来就复杂，系统是否需要先拆成几个子问题，再分别检索？
权限问题别等出事再补
RAG接的通常不是公开网页，而是企业内部知识库。
IBM提到，RAG实施过程可能带来数据泄露等安全隐患。NVIDIA也指出，RAG会从结构化和非结构化来源中检索相关信息，包括文本、图像和视频，并把回答建立在公司的专有数据之上。
这意味着它不能只按“问答插件”来管。一个用户本来无权查看某份资料，如果相关片段被检索出来、塞进上下文，再由模型整理成答案，风险已经发生了。
排查时要把权限链路也拉出来看：索引阶段有没有脱敏？向量数据库里的片段有没有权限标签？不同用户查询时，检索范围是否不同？答案能不能追溯到具体来源？这些事如果指望上线后靠人工审核兜底，通常太晚。
RAG出问题，先按链路查
Cloudflare、AWS、NVIDIA等厂商都把RAG描述为一种把外部数据源或组织知识库接入大语言模型的方法，用来生成更贴近特定领域、更新、更有依据的回答。它的吸引力也很直接：企业不必为了每批新知识都重新训练模型。
但RAG不是接上向量数据库就能稳定工作。文档处理、分块、Embedding、向量检索、上下文组织、权限控制，任何一处松了，最后都会体现在那句回答里。
一个更实际的排查顺序是：先看索引是否干净，再看检索是否真的命中正确材料，再看生成阶段有没有按材料作答，最后检查权限和脱敏。别一上来就换模型，也别只盯着提示词。
用户看到的是一句答案。可这句话靠不靠谱，通常在模型生成之前就已经决定了。
