RAG检索优化四板斧一索引层小块检索、大块阅读一、先说结论检索是 RAG 的命脉很多人在 RAG 效果不好时第一反应是换 Embedding 模型、调 Prompt或者直接上 Rerank。这些手段都有用但它们大多是在后端做文章而真正决定 RAG 上限的其实是检索召回的内容本身。原因很简单LLM 只能根据送进上下文的材料来回答检索召回的内容就是整个系统的天花板。生成层做得再精致如果检索没把相关内容找回来模型再强也是巧妇难为无米之炊。反过来只要检索能稳定召回准确、相关的 chunk生成质量自然差不到哪里去。所以在 RAG 系统里检索优化是投入产出比最高的环节而索引层又是这一切的地基——知识怎么存直接决定了后面能不能被找到。二、核心矛盾一个 chunk 要同时干两件互相打架的事索引优化的本质是 Chunking 策略的延伸但它聚焦于一个更尖锐的矛盾检索用的粒度和 LLM 读的粒度天然是冲突的。一个 chunk 需要同时完成两个任务任务一检索时被找到。这要求向量语义尽量聚焦。把一整篇文章压成一个向量里面混合了太多不相关的语义用户问细节问题时这个笼统的向量很可能和问题向量距离很远根本检索不到。所以检索需要小粒度的 chunk每个 chunk 语义要纯粹。任务二被 LLM 读懂。这要求上下文完整。断章取义的几句话LLM 往往答不好。如果文档前一段定义了术语、后一段才是真正的解释只给模型后一段它可能根本看不明白。所以 LLM 需要大粒度的 chunk上下文要完整。这就是两难困境小 chunk 检索准但内容太碎大 chunk 内容完整但检索时语义被稀释。单纯把 chunk 切小检索会变准但 LLM 拿到的是碎片化信息回答质量反而下降单纯把 chunk 切大上下文是完整了但向量里混入太多语义检索精度又掉下去了。三、破局思路Small-to-Big小块检索、大块使用既然矛盾源于一个 chunk 要同时满足两个相反的需求那最直接的解法就是把这两个需求拆开用小块去做检索用大块去喂给 LLM。这就是 Small-to-Big 的核心思想——检索阶段用细粒度内容精确定位命中后再沿着指针把对应的大块内容交还给模型让精准召回和完整上下文各取所需、互不干扰。围绕这个思路业界落地了三种典型方案父子分块、摘要索引、多粒度分层索引。下面逐一拆解。四、方案一父子分块Parent-Child Chunking这是最直接、也最常被用作工程基线的方案。做法是把文档切成两个版本一份是细粒度的子 chunk比如 150 token 一个只给子 chunk 建向量索引一份是粗粒度的父 chunk比如 500 token 一个每个子 chunk 通过parent_id关联回对应的父 chunk。入库时只给子 chunk 建向量索引检索时用子 chunk 的向量来匹配因为粒度细、语义聚焦精度更高命中之后根据parent_id取出对应的父 chunk把父 chunk 塞给 LLM 阅读上下文自然完整。这样就做到了检索用小的、阅读用大的两全其美。这套逻辑在 LangChain 里有现成的封装ParentDocumentRetriever它会自动完成子块检索、父块返回的切换LlamaIndex 里的句子窗口检索Sentence Window Retriever也是同一思路的变体——检索命中一个句子后自动把这个句子前后若干句一起带出来相当于给命中结果补了一个上下文窗口。二者殊途同归都是在精确定位和完整上下文之间做调和。五、方案二摘要索引Summary Index摘要索引的思路稍有不同它不是切割文档而是用摘要替代原文去建索引。做法是让 LLM 为每一段内容生成一段摘要用摘要文本建立向量索引检索命中后再把对应的原始段落交给 LLM 阅读。为什么这样更准因为文档原文有时候表述很散同一个意思散落在多个句子里而摘要是对核心意思的提炼语义更聚焦在向量空间里和用户问题会更接近命中率自然更高。它本质上也是小块摘要检索、大块原文使用的变形。这个方案的优势在于弥补了原文表达散乱导致的检索偏差代价是入库时多了一道 LLM 生成摘要的步骤成本更高、也更慢。所以它更适合那些原文质量参差、表述不规范但对检索精度要求较高的场景。六、方案三多粒度分层索引这是更激进的方案不只建一层索引而是同时建立章节级、段落级、句子级三层索引。不同类型的问题适配不同粒度——什么是 RAG这种宽泛的概念性问题用章节级就够了退款申请需要几个工作日这种细节性问题用句子级更精准。系统根据问题类型自动选择合适的粒度去检索从而覆盖更多类型的用户需求。多粒度分层索引可以理解为把父子分块的二元粒度扩展成了更细的粒度谱系。它的召回覆盖面更广但代价是索引结构和检索路由都更复杂工程维护成本更高通常是在业务问题类型差异很大的情况下才值得投入。七、别忘了最基础的一环切分粒度与重叠窗口在引入各种高级索引结构之前其实还有一个更基础、也更容易被忽视的优化点——基础切分参数本身。切分策略大致可以分为三类固定长度切分按 token 数硬截断简单但可能切断语义、结构切分按标题、段落、句子等文档结构切保留自然语义单元、语义切分用 LLM 判断最佳切分点效果最好但成本高。实践中技术文档优先按小节或段落切问答类内容则常用 400600 token 配 5080 token 的重叠窗口是比较稳的经验起点。重叠窗口overlap的作用是避免关键信息恰好落在切分边界上被割裂通常设为 chunk size 的 10%20%。但要注意重叠过大也会带来存储成本和检索冗余需要配合去重一起做。这些基础参数调对了往往比一开始就上复杂索引结构收益更直接也是后面所有高级方案的起点。八、小结先让知识存得对后面才谈找得到回到这四板斧的第一层索引优化要解决的其实是同一个命题让存进去的知识既能被精准检索到又能被 LLM 完整读懂。父子分块、摘要索引、多粒度分层索引本质上都是 Small-to-Big 思想的三种落地形态区别只在于怎么从精准的小块回到完整的大块。不过也要清醒地认识到索引建得再好如果用户的提问方式本身和知识库的表述对不上检索依然会漏。这就引出下一板斧要解决的问题——查询层如何先问对问题再让知识库回答。下一板斧要解决的问题——查询层如何先问对问题再让知识库回答。