RAG分块策略怎么选？从固定切分到late chunking的实战指南

你上传了一份文档，向RAG应用提问，却得到一个不完整的答案。你去翻原文，信息明明就在那里——为什么系统没找到？问题往往出在文档被切分的方式上。本文基于一篇90天AI挑战的Day 2笔记，结合Chroma的研究报告与ACL 2025论文，梳理RAG分块策略的选择逻辑与常见陷阱。

为什么分块决定了RAG能不能答对

原文给了一个典型例子。公司政策写道：「员工最多可结转五天未使用的年假。此选项仅在完成一年雇佣后方可使用。」用户问：「我可以结转未使用的假期吗？」如果系统只检索到第一句，就会回答「可以」，却漏掉「满一年」这个前提。模型拿到了相关段落，但没拿到解释这条政策所需的全部信息。

这就是分块策略要解决的核心问题：检索到的文本，要既能定位答案，又能支撑完整解释。

RAG（Retrieval-Augmented Generation，检索增强生成）是一种将信息检索与文本生成结合的系统架构：用户提问后，系统先从文档库中检索出与问题相关的文本片段，再把这些片段作为上下文交给大语言模型生成答案。检索质量直接决定了模型能看到什么证据，因此分块——即把原始文档切割成可检索的最小单元——是RAG pipeline中最靠前也最关键的决策之一。块切得好不好，后续的embedding、检索和生成都难以弥补。

小块与大块的两难

RAG系统把文档切成chunk（块），这些块就是检索的基本单位。小块更容易命中最具体的事实，但一个事实一旦脱离标题、定义或例外条款，含义可能就变了。大块保留了更多上下文，却也容易把无关信息带进结果。

还有一个容易被忽略的embedding问题：当一个块包含多个主题时，系统为它生成的单个向量必须同时代表所有主题，针对某个细节的提问就更难匹配上。原文提出的判断标准是：系统需要多少文本才能「找到」答案，又需要多少文本才能「解释」答案？这两个量不必相同。

Embedding（嵌入）是把一段文本映射为高维向量的过程，语义相近的文本在向量空间中距离更近，检索时通过计算向量相似度来匹配查询与文档块。由于标准做法是每个块生成一个向量，当块内混合多个主题时，这个向量只能是各主题语义的某种“平均”，针对单一细节的查询就难以精确命中。这也是块粒度需要权衡的根本原因之一：块越大，向量承载的语义越混杂，检索的区分度越低。

结构感知分块：有标题就用标题

政策、合同、技术手册通常自带信息归属线索。比如「正式员工」「合同员工」「试用期员工」这几个标题，会改变其下文本的解读方式。如果处理时把标题剥掉，一段话看起来就像适用于所有人。

结构感知分块（structure-aware chunking）利用标题和章节保留这层上下文，块可以携带类似「雇佣政策 → 正式员工 → 年假」的标题路径。这里有个细节值得注意：把路径存为metadata，并不会自动让它进入embedding。把路径写进被嵌入的文本，有助于检索匹配；把路径放进送给回答模型的上下文，有助于模型理解语义。两者发生在pipeline的不同环节，都有用，但不能互相替代。这也解释了文档解析为什么重要——解析阶段丢失的标题和表格关系，分块器无法凭空恢复。

递归切分：结构混乱时的稳妥起点

并非所有文档都有干净的章节。对于格式不统一的文本，递归切分（recursive splitting）是实用的起点：它先尝试段落这类较大的边界，不行再退到更小的单位。它运行简单，也不需要额外模型来判断每个切分点。

局限也很直接：段落换行不保证解释是完整的。一条规则可能在一段，它的例外在下一段。据Chroma的研究报告，配置得当的递归切分在其评测中表现具有竞争力——这提醒我们，在引入复杂方案前，应该先给简单基线一个公平的比较机会。

语义分块：主题变了但没有标题时

有些文档在主题之间切换却不加标记。语义分块（semantic chunking）用句子相似度等信号判断哪些段落该放在一起，避免把无关讨论塞进同一个块。但有陷阱：措辞相似不代表信息属于同一组。两个产品的描述可能几乎一样，限制条件却不同；政策例外也可能与它所修改的规则听起来毫不相似。

ACL 2025论文《Document Segmentation Matters for Retrieval-Augmented Generation》从这个问题切入，提出PIC方法，用文档摘要来指导句子分组。论文报告在其基准上取得提升——这给了我们考虑该方法的理由，但不意味着它在所有文档上都占优。

重叠（overlap）能救什么、救不了什么

块间重叠会在相邻块中重复部分文本。如果有用上下文正好落在边界附近，重叠能让两侧都保留它。但相隔数页的例外条款，靠重复几句话是找不回来的。

重叠过多会带来另一个问题：重复的搜索结果。如果检索返回五个块，其中三个内容几乎相同，模型实际获得的新证据远少于结果数量暗示的。重叠最有价值的用法，是保护邻近上下文，同时不让结果被重复内容填满。

Overlap（重叠）指相邻块之间保留一部分重复文本，常见做法是让后一块从前一块末尾往前回溯若干token或句子。它的作用是防止关键信息恰好被切在边界上而两边都不完整。但重叠会增大索引体积和存储成本，也可能导致检索结果高度重复。实践中通常设置10%–20%的重叠比例，并配合去重或多样性重排来抑制重复结果。重叠不是万能药，它只能保护邻近上下文，无法跨越长距离恢复分散各处的关联信息。

父文档检索：小 passage 搜，大 section 答

RAG设计在这里变得有趣：搜索和回答不必使用同样多的文本。父–子检索（parent–child retrieval）的流程是：先用小块做精确匹配，再定位匹配块所属的更大章节，最后把相关章节送给回答模型。

回到年假例子，小块可以帮系统定位「可结转五天」，而带回来的周边章节则能一并恢复「满一年」的资格条件。这把两件事分开了：找到正确位置，和提供足够上下文来解释它。当然需要设限——每次匹配都返回整章会浪费上下文预算，重叠的章节也应合并，避免模型重复收到同一段内容。

late chunking：块在检索前就丢了含义怎么办

看这句话：「它仅适用于常驻伦敦的员工。」「它」指什么？读上一段的人立刻知道，但孤立处理这句话的embedding模型信息不足。

late chunking针对的正是这个问题。常规做法是先切分、再分别嵌入每个块；late chunking则让兼容的embedding模型先处理一段更长的文本，再从已经「看过」周边上下文的token表示中，生成各块的向量。这样每个块的向量带有更多上下文。

但要注意两点：回答模型仍然需要实际的支撑文本，更好的embedding不会自动把上一段加进检索结果；late chunking也需要兼容的嵌入pipeline，简单地把长文档丢给标准embedding API并不等于实现了它。

Late chunking依赖长上下文embedding模型（如支持数千token输入的模型），其做法是先对整段长文本做一次前向编码，得到每个token的上下文相关表示，再按分块边界对这些token表示做池化（如平均池化）生成各块向量。这与“先切块、再分别编码”的常规流程相反，因此块向量天然携带了前后文信息。实现上需要模型和推理框架支持token级输出与自定义池化，而不是调用返回单个句向量的标准embedding接口。

怎么判断分块到底有没有帮上忙

检查检索结果里有没有答案只是起点。在政策例子里，找到「五天未使用年假」只是部分成功——资格条件缺失了。更严格的评估应该问：检索是否找到了全部所需证据？答案是否保留了条件和例外？有多少无关文本进入了模型？检索文本重复了多少？引用的段落是否支撑了完整答案？

Chroma的报告在token层面评估检索，同时衡量相关文本与多余、重复内容。这也说明，为什么一个包含答案的大块，仍然可能是低效的检索结果。另外，比较不同配置时要公平：五个短块和五个长块给模型的信息量完全不同，记录实际检索文本量才让对比有意义。

选择分块策略时该看什么

从文档包含的信息类型和用户会问的问题出发。标题清晰，结构感知切分就值得用；格式混乱，递归切分是合理基线；主题切换没有标记，可以考虑语义分块。重叠处理邻近边界，父–子检索找回周边解释，late chunking解决嵌入时的上下文丢失。这些方法解决的是不同问题，可以组合使用。

目标只有一个：保留足够的意义，让一个相关的检索结果，同时成为有用的证据。当你的RAG应用漏掉条件、给出不完整答案时，去看检索到的段落——模型收到的是完整解释，还是一句看起来像解释的话？