RAG依然失败的五个原因：2026年了，问题不在向量库

「我们做了 RAG，但用户还是不用。」

这句话我在 2026 年听到的频率，和 2024 年几乎一样高。技术方案换了三轮（向量库换了、reranker 加了、GraphRAG 上了），采用率却没怎么动。

原因很简单：大部分 RAG 项目的瓶颈早已不在检索环节。下面是五个反复出现的真实失效原因。

一、知识库本身就是过期的

一个典型的内部助手项目，从 6000 篇文档里检索。做完 POC 效果惊人，上线三个月后大家开始抱怨”答得不对”。

查下来发现：这 6000 篇文档里，有 38% 已经被新版制度替代，但它们仍留在库里，且标题相似、内容相似。检索器准确地找到了错误的那份。

检索的准确率再高，也只是”准确地找到错的东西”。修这个问题不需要更聪明的模型，需要一套文档生命周期管理：谁负责、多久复审一次、新版本上线时旧版本如何标记失效。

多数团队在这件事上的投入是零，然后指望检索算法解决它。

二、同一个问题有三个答案

比文档过期更隐蔽的是并行冲突。规章制度 A 说审批要三天，流程文档 B 说五个工作日，某个部门手册说”视情况而定”——三份都是”有效”文档。

用户问”审批要多久”，RAG 给出的答案取决于检索到哪一篇。用户第一次得到”三天”，第二次得到”五个工作日”，从此不再相信系统。

解法不是让模型”综合判断”，而是在入库阶段就做权威性标注：每类问题指定唯一权威来源，冲突文档降权或标注”参考”。这是一项内容治理工作，无法靠算法完成。

三、没有权限模型，“安全”就没人敢推广

很多 RAG 系统在企业内部推广失败的真正原因，是安全和合规部门不同意开放。原因很实在：文档里混着薪资、客户合同、未公开财务数据，而检索系统对所有人一视同仁。

权限过滤必须发生在检索阶段，而不是生成后脱敏。常见做法是文档入库时打上访问标签，查询时先按用户身份过滤候选集，再做向量召回。这个改动不难，但需要和权限系统打通，很多项目卡在这一步就停滞了。

四、没有评测，就永远在猜

「效果不好」是最没用的反馈。到底哪里不好？是召回没找到，还是找到了但生成忽略了，还是找到了但答案是错的？

没有一套固定的评测集，团队每次优化都是盲改。可行做法是：从真实日志里抽取 100～200 个问题，人工标注”正确答案应来自哪份文档”和”期望答案要点”，每次改动跑一遍，看三项指标——召回命中率、答案要点覆盖率、无依据回答率。

这三项一起看，问题的位置一目了然。只有召回命中率低才需要动检索，其他情况动的是提示词或知识库。

五、用户不信任，因为系统不给自己留后路

最后一个原因最容易被忽略：用户不用的原因不是答案差，而是不知道什么时候该信。

好的 RAG 产品会给每个回答附上引用来源，点开能看到原文段落；找不到依据时会明确说”知识库中没有相关信息”，而不是硬编一段。这种”可验证性”比答案准确率更能建立信任。

反过来，一个从不说”我不知道”的系统，用户试两次就会放弃。

结语

RAG 的技术栈已经成熟到不是瓶颈了。剩下的问题全在知识治理、权限、评测和产品设计上——都是不那么性感、但决定成败的工作。

如果你的 RAG 项目正卡在”效果不好”，先别急着换向量库。花一天时间统计一下：库里有几成文档过期？有几个问题存在冲突答案？有多少用户查过但从未采用结果？

答案大概率就在这里。