RAG 没你想的那么简单

过去一年，几乎每个要做 AI 产品的团队都听过 RAG（检索增强生成）。逻辑听起来无懈可击：大模型不知道你的私有数据？那就先检索出相关内容，塞进上下文，让它「看着资料答题」。

这套逻辑在 demo 里永远跑得很顺。但一旦上了真实场景，RAG 的翻车率远超预期——AI 答非所问、引用了错误段落、明明资料里有却找不到、找到了却不理解。

问题不在 RAG 这个技术本身，在于大多数人把它当成了「接个向量数据库就完事」的简单工程。RAG 是一个系统，系统里至少有四个环节（检索、排序、组装、生成），每个环节都有坑。今天讲三个我在实战中踩过、且最反直觉的坑。

反直觉一：召回率越高，回答可能越差

这是最违背直觉的一条。

多数人做 RAG 的第一反应是：检索要准，要多召回一些，宁可多不能少。于是把 top-k 从 5 调到 10，再调到 20，把相似度阈值从 0.8 降到 0.6。

结果呢？回答质量不升反降。

为什么？因为大模型不是数据库，它有「注意力分配」的问题。你塞进去 20 段内容，其中只有 3 段真正相关，模型要在 17 段噪声里找出那 3 段——这比只给它 5 段（其中 3 段相关）更难。噪声越多，模型越容易被无关内容带偏，甚至产生「被干扰后的幻觉」。

这就是 RAG 的信噪比困境：召回率和高信噪比是矛盾的。你为了不漏掉相关信息而多召回，却稀释了信号的浓度。

怎么解？核心思路是「分层检索」。

第一步粗召回，用宽泛的相似度多捞一些（top-k 设到 20-30）。第二步精排序，用一个更小的模型或交叉编码器对这 20 段重新打分，只保留最相关的 3-5 段塞给大模型。

这个「先广后精」的两步法，在工业界叫「retrieve-and-rerank」。它比单纯调 top-k 有效得多，因为它同时兼顾了召回率和信噪比。

更激进的做法是：在 rerank 之后，还做一步「相关性校验」——让一个小模型先判断每段内容和用户问题的相关性，把「看起来相关但实际无关」的段落过滤掉。这一步能砍掉 30% 的噪声，对最终回答质量的提升非常明显。

反直觉二：切块策略比模型选择更影响效果

第二个反直觉：很多人花大量时间纠结用哪个 embedding 模型，却几乎不花时间设计文档的切块策略。

但实战中，切块策略对 RAG 效果的影响，往往大于 embedding 模型的选择。

为什么？因为检索的本质是「语义匹配」，而语义的载体是文本块。如果你把一篇 10 页的报告按固定 500 字切成 20 块，很可能把一个完整的论证逻辑切成了两半——前半块有结论没论据，后半块有论据没结论。检索到任何一半，模型都无法完整理解。

我见过最惨的案例：一个法律 AI 产品，把合同按固定长度切块，结果「违约责任」这个条款被切成了两段，检索只命中了后半段（赔偿金额），模型回答时完全不知道触发条件是什么。用户问「什么情况下要赔」，AI 答了「赔多少」。

怎么切块才对？没有万能方案，但有三个原则：

第一，按语义边界切，不按字数切。 文档的标题、段落、列表项天然是语义边界。优先在这些边界处切，而不是机械地数到 500 字就切一刀。

第二，保留上下文重叠。 每一块保留前一块的最后一两句（overlap 50-100 字），避免边界信息丢失。这会增加存储成本，但换来的是检索准确率。

第三，给每块加「上下文摘要」。 这是最值钱的一步。不要只存原文块，还要存一个该块所属章节的摘要。检索时，模型能看到「这块内容属于第三章第二节：违约责任」，理解会准确得多。

这三步加起来，工作量不大，但效果提升远超换一个更强的 embedding 模型。很多人忽略它，是因为切块听起来太「土」了，不像换模型那么有技术含量。但 RAG 的现实就是——工程细节决定下限，模型能力决定上限，而下限才是大多数产品的瓶颈。

反直觉三：最该优化的不是检索，是「问题改写」

第三个坑，藏得最深。

RAG 系统的标准流程是：用户提问 → 检索 → 生成。多数人把优化精力放在中间的检索环节。但实战中我发现，效果提升最大的优化点，在流程的最前面——用户的问题本身。

什么意思？用户问的问题，往往不适合直接拿去检索。

举个例子。用户问「这个方案有什么风险」。你拿这句话去做向量检索，检索出来的大概率是文档里包含「风险」这个词的段落——但真正有价值的「风险分析」可能写在「注意事项」「潜在问题」「合规要求」等小节里，压根没出现「风险」两个字。

语义检索不是关键词匹配，但它也逃不脱「问题表述和文档表述不一致」的困境。用户用自己的话问，文档用专业的话写，两者之间的语义鸿沟，检索很难自动跨越。

解法是加一步「问题改写」——在检索之前，先让大模型把用户的问题改写成更适合检索的形式。具体做两件事：

第一，扩展同义表述。 把「风险」扩展成「风险、注意事项、潜在问题、合规要求、局限性」。这样检索能覆盖到用不同表述写的相关内容。

第二，补全隐含上下文。 用户问「这个方案」，但如果前面对话聊过具体的方案名，检索时应该用完整名称而不是代词。问题改写时要结合对话历史，把代词消解掉。

这一步在学术上叫「query rewriting」或「query expansion」，实现成本很低（就是多调一次模型），但效果立竿见影。我做过对比测试，加了问题改写后，检索命中率提升了 25% 左右——这个数字换什么 embedding 模型都做不到。

更深一步，还可以做「假设性回答」——让模型先根据问题生成一个假想答案，然后用这个假想答案去检索（而不是用问题本身）。逻辑是：答案的表述比问题更接近文档的表述。这个技巧叫 HyDE，在某些场景下效果惊人。

三个反直觉背后的共同规律

拆完三个坑，你会发现一个共同点：它们都不是「模型不够强」的问题，而是「系统设计没到位」的问题。

  • 召回率高反而更差，是因为没做 rerank——这是架构问题。
  • 切块比模型重要，是因为忽略了工程细节——这是认知问题。
  • 问题改写最该优化，是因为只盯着检索没看全链路——这是视角问题。

RAG 的本质不是「检索 + 生成」这么简单的加法，而是一个有多个环节、每个环节都可能成为瓶颈的链路系统。优化 RAG 的正确姿势，不是某个环节做到极致，而是找到当前瓶颈在哪一环，集中火力打它。

这和产品优化是一个道理——不抓主要矛盾，哪里都使劲，等于哪里都没使劲。

结语

RAG 是当前 AI 应用落地最主流的架构，但「主流」不等于「简单」。它看起来门槛低（接个向量库就能跑），实际上要做好，需要把检索、排序、切块、问题改写每个环节都打磨到位。

很多人对 RAG 的失望，不是因为 RAG 不行，是因为只做了最浅的一层就指望它出奇迹。这就像买了一辆好车却不做保养，然后怪车不好开。

AI 产品的竞争力，从来不在「用了什么架构」，而在「这个架构的每个环节，你比竞品做得细多少」。RAG 拼的不是模型选型，是工程深度。

行动建议：打开你的 RAG 系统，找 10 个「答得不好」的真实 case。别急着归因到模型，逐一排查：是检索没召回到？召回了但排序靠后？排前面了但切块丢了上下文？问题本身就没表述清楚？你会发现 8 成问题不在模型，在链路。定位到瓶颈环节，集中优化它，比换模型有效十倍。