RAG 知识库为什么容易失败：从检索质量到评估缺位

检索增强生成的想法很朴素:在把问题交给大模型之前，先从企业自己的文档库里检索出相关片段，拼进提示词，让模型基于这些材料作答。相比重新训练或微调一个模型，这条路几乎不需要动模型权重，数据更新只需重新入库，还能给答案附上出处。对企业而言，它承诺的是三件事——减少凭空捏造、让回答可追溯、免去为每篇文档打标注的重活。正因为门槛看起来低，过去两年几乎每家有一定文档积累的公司都启动过类似项目:把员工手册、产品文档、历史工单、合同条款接进一个统一的问答入口，让新员工不必再翻遍旧文件，让客服不必再等资深同事回消息。中美两地的云厂商也顺势把 RAG 封装成开箱即用的托管服务，把向量数据库、embedding、检索与生成串成一条可点选的流水线，进一步压低了立项成本。问题在于，立项容易和跑进生产是两回事。真正稳定服务于业务、被员工日常使用、经得起边角问题考验的 RAG 系统，数量远少于当初的立项数；更多项目停在了演示效果不错、一上真实流量就露馅的阶段。承诺兑现不了，原因通常不在那个显眼的大模型，而在它前后那些不显眼的环节。把这些环节看清楚，是判断一个 RAG 项目值不值得投入、以及会在哪里翻车的前提。

澳大利亚一组研究者在研究、教育与生物医学三个领域各搭了一套 RAG 系统做工程复盘，归纳出七个失败点，其中至少四个都发生在检索环节。答案根本不在文档库里，系统却编出一个听起来合理的回复（FP1）；答案在库里，却没有排进返回给模型的前几名（FP2）；相关文档被检出了，却因为返回条目太多、超出上下文预算而被截断在外（FP3）；材料进了上下文，模型却被过多噪声淹没、没能抽取出那句正确答案（FP4）。这四类问题层层递进，任何一环出错，后面的生成都无从谈起。行业实践者的观察也指向同一处:当 RAG 出问题时，故障大多落在检索而非生成一侧。检索质量的地基是分块。把长文档切成片段供检索，是整条链路里最被低估的一步，却常常用一句固定长度切分草草带过。这种切法会把句子拦腰截断、把表格从中间劈开、把一段代码切成两半——检出的片段在字面上相关，拿到手里却无法使用。更隐蔽的是所谓语义相邻却事实无关:检索器返回了话题接近但内容对不上的文档，模型于是把这些碎片编织成一个貌似可信的错误答案。这类幻觉并非源于上下文缺失，而恰恰源于上下文本身就是干扰项。换句话说，检索器交上来的材料越多越杂，模型犯错的空间反而越大，盲目扩大召回往往是在给失败加码。

即便检索算法调到最优，它检出的也只是知识库里真实存在的东西。而企业知识库的真实状态，往往比立项时想象的糟糕得多。同一份政策存在三个版本，谁也说不清哪份现行；两年前的报价单和今年的混在一起；PDF 是扫描件，文字根本无法提取；财务口径的术语和业务口径互相矛盾。这些问题在人工使用时可以靠经验绕过——老员工凭直觉知道该信哪份文件、该忽略哪份——可一旦交给检索系统，它没有这种默会知识，只会忠实地把过时或矛盾的内容一并召回，再拼进上下文交给模型。检索越勤快，把陈年错误翻出来的概率越高。更棘手的是权限。多数企业 RAG 在检索时对用户身份、文档密级、访问策略一无所知，权限控制被放在应用层而非检索层。结果是检索引擎可能把某个员工本无权查看的薪酬表、并购文件或客户隐私一并召回，造成越权泄露；这类问题在处理个人健康信息或知识产权时会直接触发合规与监管风险。安全实践者给出的原则很直接:防止 AI 泄密最可靠的做法，是让系统从一开始就检索不到那些敏感内容，也就是把访问控制前移到检索这一层，而非事后在生成端加一道过滤。这意味着 RAG 落地的前置成本，常常是一次被拖延多年的数据治理——先把家底整理干净，检索才有意义。

许多 RAG 项目最深的问题是:没有人能说清它到底准不准。团队凭几个演示问题的表现就上线，而这几个问题恰恰是调试时反复看过、早已调通的样例；真实用户抛来的千奇百怪的提问，从没被系统性地测过。前述工程复盘给出的一条核心教训是，RAG 系统的验证只能在运行中进行，它的稳健性是逐步演化出来的，很难在设计之初就一次到位——因为系统上线后会持续遇到大量它从未见过的输入。要摆脱靠感觉判断，就得把评估拆成可度量的维度。RAGAS 这类框架的思路，是在没有人工标注标准答案的前提下，从几个方向自动打分:忠实度衡量答案是否真正建立在检出的上下文之上，还是掺入了无据的臆断；答案相关性衡量回复是否直接回应了问题，而非答非所问；上下文相关性与召回则衡量检出的材料是否精准、是否足以支撑作答。它的价值在于把评估变成可持续运行的循环，而非上线前的一次性检查。值得强调的是，这套指标把两种截然不同的失败区分了开来:一种是检索没找对，另一种是材料齐全但模型没用好。缺了这层度量，团队连问题出在哪一环都无从定位，只能在用户投诉里被动打补丁、越修越乱。评估是决定一个 RAG 系统能否持续改进的前提，而不是可有可无的收尾。

RAG 项目真正进入验收时，不能把「回答看起来不错」当作质量指标。更可靠的做法，是把问题拆成两个层面：检索有没有把应当出现的材料找出来，生成有没有忠实使用这些材料。Ragas 的指标体系给了一个实用拆法：context precision / context recall 盯检索，faithfulness 盯回答里的每一条主张是否能被检索上下文支持，answer 或 response relevancy 盯回答是否真正回应问题。这个拆法的价值不在某个开源框架本身，而在它让团队能判断失败发生在哪里。

对管理层而言，评估表至少要分成四列：问题、应检出的来源、实际检出的来源、最终回答是否忠实。没有这张表，团队只会在「换 embedding」「调 chunk」「换模型」之间来回试错；有了这张表，才知道是知识库里没有答案、检索没有召回、噪声挤掉了答案，还是模型拿到材料后仍然编造。RAG 的质量管理，首先是一套错误归因系统，而不是一个模型分数。

RAG 的工具链带有明显的地域烙印。围绕 OpenAI、Anthropic 与几大美国云厂商形成的英文生态，embedding 模型、评估框架与检索组件的成熟度最高，社区文档也最丰富；中国厂商则围绕自研模型与本地向量数据库另建了一套，数据不出境的诉求让不少企业根本无法直接采用美国的托管服务，只能在国产栈上重新踩一遍坑。工具差异之外，更实在的障碍是语言与合规。多语言检索并非把英文方案换套语料就能复用:有实验在特定跨语言语料上观察到，当查询语言与文档语言不一致时，检索性能相比同语言场景出现显著下降，检索器还会系统性地偏向与查询同语言的文档，把另一种语言里真正相关的材料排到后面。对身处中、英、马来语交织环境的新加坡与东南亚企业而言，这意味着一份夹杂多语的知识库天然更难被准确召回，员工用中文问、答案藏在英文文档里，恰恰是最容易漏检的情形。合规层面，新加坡的《个人数据保护法》、中国的数据出境规定以及各行业的数据驻留要求，都对知识库的存放位置、可召回范围与审计留痕提出硬约束。这些约束不是接一个模型就能化解的，它们决定了 RAG 架构从选型第一步就得把本地化纳入考量，而非上线后再补。

新加坡与 ASEAN 企业还要多看一层治理语境。AI Verify Foundation 与 IMDA 的生成式 AI 治理框架强调，可信环境需要从责任、数据、测试、安全、内容来源等多个维度同时推进；这意味着 RAG 不能被当成一个「接上文档就能问」的插件。它会读取企业文档、套用访问权限、生成可被员工或客户采纳的答案，因此它同时触碰数据治理、内容来源、信息安全和问责链条。

在多语环境里，这个问题更尖锐：同一份政策可能有英文原文、中文操作说明和本地语言摘要，检索系统若偏向查询语言，可能把真正权威的英文原文排在后面。合规上，个人数据、客户资料和跨境文档也不能等生成端再过滤；权限应该在检索层就生效。换句话说，RAG 项目的东南亚版本，不只是把知识库换成多语语料，而是要把身份、地域、文档密级和审计留痕一起放进检索设计。

把上面三层失败倒过来读，就是一份落地清单。第一，从评估开始，而不是从模型开始:在写第一行检索代码前，先攒一批真实业务问题和期望答案，建立忠实度、答案相关性、上下文召回这几个可度量的指标，让每次改动都有据可依，而非凭演示效果自我安慰。第二，把数据治理当成 RAG 的前置项目而非附属任务:清理版本冲突、处理扫描件、统一术语口径，并在入库时就把文档密级和访问控制作为元数据写进检索层，让权限成为检索的一部分，而不是事后在应用层补救。第三，不迷信默认分块:根据文档类型选择切分策略，保留表格、条款、代码的完整语义边界，必要时在片段里带上文件名与来源信息以帮助模型准确抽取。第四，承认 RAG 的稳健性是运行中长出来的:上线只是起点，持续用真实流量校准、监控检索命中率与失败分布，才是它区别于一次性采购的地方。最后一条判断更根本——先问这个场景是否真的需要 RAG。随着长上下文模型成本下降，一部分文档量有限、更新不频繁的场景，直接把材料塞进上下文窗口反而更简单可靠，省去了整条检索链路的维护。RAG 是解决大规模、高频更新知识的手段，而非所有问答需求的默认答案。选对场景，往往比反复调优参数更能决定一个项目的成败。