在构建基于大语言模型（LLM）的检索增强生成（RAG）系统时，如何将文档切割成合适的“块”（Chunking）是至关重要的环节，但往往容易被忽视。错误的 Chunking策略 会导致即使是最强大的LLM也难以检索到正确的信息，进而产生不相关甚至荒谬的答案。本文将深入探讨几种主流的 Chunking策略，分析其优缺点以及适用场景，帮助你在RAG实践中选择最合适的方案，提升LLM的信息检索效果。

1. 固定窗口Chunking：简单高效，但可能割裂上下文

固定窗口 Chunking策略 就像一把“肉刀”，简单粗暴地将文本按照固定的长度（例如500个token或字符）进行切割，而不考虑句子或段落的完整性。这种方法的优点在于简单快捷，易于实现，尤其适用于大规模文本的预处理。

优点：

• 简单快速： 实现起来非常容易，对海量文本进行预处理非常有效。
• 可预测性： 你总是知道你的chunk的确切大小。因此，你总是知道文本字段的大小（无论是在数据库中还是在UI中）。

缺点：

• 上下文碎片化： 这是其最大的弱点。它可能会直接切断句子的中间（如果在字符级别上进行拆分，甚至会切断单词的中间），或关键信息，从而破坏其上下文。想象一下，一个食谱被分成了两部分：“加入两杯面粉，然后搅拌”和“直到面糊光滑。”——这不是很有帮助！
• 无视内容： 它不关心句子、段落、标题或任何语义结构。

适用场景：

当速度至关重要，并且你的文档结构相对简单，或者当你将其用作更复杂的 Chunking策略 之前的初步步骤时。

最佳实践：

通常最好在token级别而不是字符或单词级别进行 chunking。这是因为LLM使用token处理信息，并且它们的上下文窗口限制通常以token定义。通过token进行 chunking 直接与LLM“看到”和理解文本的方式一致，确保更一致的输入大小并更好地控制LLM将收到的实际内容。

尽管固定窗口 Chunking 速度快，但其最大的问题在于可能会割裂上下文，导致检索到的信息不完整或难以理解。例如，如果一篇关于“Transformer模型注意力机制”的文章被切割成“Transformer模型注意力”和“机制详解”，那么LLM可能无法完整理解注意力机制的概念。

2. 固定窗口+重叠Chunking：兼顾效率与上下文

固定窗口+重叠 Chunking策略 是对固定窗口 Chunking 的一种改进，通过引入重叠部分来缓解上下文碎片化的问题。可以将其想象成扫描书籍页面，但每次新的扫描都从前一次结束的几行之前开始，从而确保你不会错过句子的结尾或新句子的开头。

优点：

• 上下文保留： 重叠充当了一座桥梁，确保了跨chunk边界分割的信息不会完全丢失。
• 简单而智能： 仍然相对简单和快速，但比没有重叠有效得多。
• 良好的基线： 通常是RAG系统的良好起点。

缺点：

• 冗余： 重叠导致多次存储相同的信息，从而增加了矢量数据库的大小。
• 无关信息： 大的重叠或chunk大小可能会拉入太多无关的周围文本，从而稀释了焦点。

适用场景：

大多数通用RAG应用，尤其是具有连续散文或逻辑流程的文档。它通常是默认的选择，原因很好。

最佳实践：

试验chunk_size和chunk_overlap。一个常见的启发式方法是重叠chunk大小的10-15％。确保你的重叠足够大，以捕获句子或段落边界。

案例：

假设Alice的日记条目是“今天很棒。我吃了披萨。它很美味。我喜欢披萨。”，并且你的chunk大小是3个单词，重叠1个单词：

• Chunk 1: “今天 很棒。”
• Chunk 2: “很棒。 我 吃”
• Chunk 3: “我 吃 披萨。”

你明白了。重叠连接了想法。

这种 Chunking策略 在一定程度上缓解了上下文碎片化的问题，但同时也引入了冗余，增加了存储成本。最佳的重叠比例需要根据具体情况进行调整。例如，对于科技新闻，重叠比例可以设置得较低，而对于法律文件，则需要更高的重叠比例以确保信息完整性。

3. 递归Chunking：尊重文档结构的“外科医生”

递归 Chunking策略 类似于解剖一份复杂的科学论文。你会首先将其分解为章节，然后是小节，再是段落，最后是句子。递归 Chunking 的工作方式类似，基于一系列分隔符逐步分解文本。它也被称为分层 chunking 或基于文档的 chunking。

工作原理：

它尝试一系列分隔符（例如，[“\n\n”, “\n”, “.”, ” “]）。它首先按最重要的分隔符（如双换行符表示段落）进行拆分。如果一个chunk仍然太大，它会尝试下一个分隔符（单换行符表示句子），依此类推，直到chunk在chunk_size限制内或无法进一步拆分为止。

优点：

• 结构保留： 它尊重你文档的自然层次结构。这对于Markdown、LaTeX、HTML甚至代码文件等格式尤其强大，在这些格式中，特定的字符或标签定义了逻辑部分（例如，Markdown中用于标题的#，LaTeX中的\section{}，HTML中的\，或代码中的函数定义）。
• 适应性： 与固定方法不同，它会根据内容动态调整 chunking。
• 更好的上下文： 更可能产生与文档结构一致的连贯、自包含的chunk。

缺点：

• 不均匀的chunk： 因为它优先考虑结构，所以chunk的大小可能会有很大差异，可能会导致非常小、信息量较少的chunk。
• 复杂性： 尽管某些库为特定文档格式提供 chunking 器，但总的来说，它比固定大小的方法更难以设置和微调。
• 分隔符依赖： 它的有效性取决于你选择的分隔符的质量和相关性。

适用场景：

非常适合结构高度化的文档，例如研究论文、法律文件、代码、markdown文件或手册，其中章节和段落的断点具有意义。

最佳实践：

定义一个经过深思熟虑的分隔符列表，从最大的逻辑中断到较小的逻辑中断。最好与其他 chunking策略 结合使用，例如带有重叠的固定窗口 chunking 来拆分较大的chunk，或者语义 chunking 来合并较小的chunk（即将推出！）。

案例：

对于一份Markdown格式的文档，递归 Chunking 会首先按照标题（#）进行分割，然后再按照段落（空行）进行分割，最后按照句子（.）进行分割，最终生成结构化的chunk。

这种 Chunking策略 能够很好地保留文档的结构信息，但可能会导致chunk大小不均匀，需要与其他 Chunking策略 结合使用，以获得更好的效果。

4. 语义Chunking：以“意义”为导向的智能分割

语义 Chunking策略 不关注固定大小或分隔符，而是关注“意义”。它就像一个非常聪明的编辑，阅读你的文本，并识别主题发生变化或完整想法结束的自然中断。

工作原理：

它涉及嵌入文档中的每个句子。然后，它比较相邻句子的余弦相似度。当相似度低于某个相似度阈值时，它会标记一个“断点”，表明主题发生变化或一个完整的语义单元。具有高相似度的连续句子被分组到一个chunk中。

优点：

• 上下文连贯性： 生成语义高度连贯的chunk，这意味着每个chunk都涵盖一个单一的、相关的主题。
• 改进的检索： 当查询进入时，它更可能匹配包含该特定语义概念的所有相关信息的chunk。
• 优化的Chunk大小： chunk的大小自然地基于内容，而不是任意数字。

缺点：

• 计算成本： 嵌入你整个语料库中的每个句子可能很慢和/或很昂贵，尤其是对于大型数据集。
• 复杂性与调整： 需要更复杂的设置和仔细调整similarity_threshold。错误的阈值可能导致过度碎片化或过于大的chunk。
• 性能与成本： 研究表明，与语义 chunking 相关的计算成本并不总是能通过在所有用例中始终优于更简单方法的性能来证明是合理的。

适用场景：

当处理非常长、密集的文档，其中包含多个相互交织的主题，并且检索信息的精确性绝对关键时。想想多章节的书籍或详细的技术报告。

最佳实践：

从更简单的方法开始，只有当它们未能达到准确性目标时才考虑语义 chunking。彻底测试similarity_threshold值。

案例：

一篇文档讨论了“AI伦理”，然后过渡到“LLM架构”。语义 chunking 可能会为每个主题创建单独的chunk。

语义 Chunking策略 能够生成语义连贯的chunk，提高检索的准确性，但同时也需要更高的计算成本，需要根据具体情况进行权衡。

5. 基于LLM的Chunking（Agentic Chunking）：让AI来做主

与其自己做所有的繁重工作，不如让LLM来帮忙？基于LLM的 Chunking策略 将 chunking 决策权委托给智能代理，通常是LLM本身。

工作原理：

你基本上是提示LLM充当“ chunking 代理”。它可能会分析文档，识别逻辑部分，总结它们，然后动态确定chunk边界、内容，甚至元数据。一些高级形式，如ChunkRAG，使用LLM不仅进行 chunking，还从chunk中过滤掉不相关的信息，以增强焦点。

优点：

• 最佳的上下文保留： 可以智能地识别和维护高度相关的上下文边界，远远超出基于规则的方法所能实现的。
• 动态和自适应： chunk是动态创建的，针对特定内容和潜在查询量身定制。
• 查询优化： 可以生成固有地更适合LLM检索的chunk，从而产生更准确的答案。
• 增强的事实一致性： 正如在ChunkRAG等方法中所见，LLM可以帮助过滤掉从检索到的chunk中的噪声和不相关的细节，从而提高准确性。

缺点：

• 高计算成本： 如果你认为语义 chunking 很昂贵，那么运行LLM进行 chunking 就更糟糕了。特别是考虑到你需要一个具有足够大的上下文窗口的LLM来容纳整个文档。
• 复杂性与调试： 更难设置、监控和调试。LLM进行 chunking 的“推理”并不总是透明的。
• 延迟： 可能会引入明显的延迟，使其不适合实时应用。
• Agentic漂移/幻觉： LLM代理有时可能会错误地解释内容或“幻觉”chunk边界，从而导致错误。

适用场景：

对于高度复杂、细致的文档，其中每个上下文位都至关重要，并且基于规则或语义方法无法满足要求。想想法律发现、深入的研究分析或敏感的医疗文档，在这些文档中，精确性至关重要，而速度则不太重要。也非常适合需要总结和动态内容生成的任务。

最佳实践：

仔细设计你的 chunking 代理的提示。实施强大的评估，即检查LLM生成的chunk是否存在于原始文本中。考虑到成本，只有在其他方法无法交付时才求助于agentic chunking。

案例：

例如，你可以提示LLM：“分析以下文档，识别关键论点，并将其分割成能够完整表达论点的chunk。” LLM会根据其对文档的理解，动态地生成chunk。

基于LLM的 Chunking策略 能够实现最佳的上下文保留，但同时也需要更高的计算成本和更复杂的设置，需要谨慎使用。

如何选择合适的Chunking策略？

没有一种万能的 Chunking策略 适用于所有场景。“最佳” Chunking策略 完全取决于你的特定数据、用例和RAG系统的要求。

• 从简单开始： 通常，一个经过良好调整的带有重叠的固定窗口策略可以让你获得90％的成功。不要从一开始就过度设计。

• 实验是关键： 测试不同的chunk_size、chunk_overlap和分隔符。使用每种策略评估你的检索性能（精确率、召回率）。

• 考虑你的数据：

  • 非结构化文本（博客、论坛）：带有重叠的固定窗口。
  • 结构化文档（手册、代码、法律文本）：递归 chunking。
  • 复杂、主题性的文档：语义 chunking（如果计算成本可以接受）。
  • 高度细致、关键信息：基于LLM的/Agentic chunking（如果延迟和成本允许）。

• 元数据是你的朋友： 无论你的 chunking策略 如何，都要用相关的元数据（例如，来源、章节标题、日期、作者）丰富你的chunk。这种额外的上下文可以显着提高检索准确性。

• 迭代和改进： Chunking 不是一个一劳永逸的步骤。随着你的数据的发展或你的RAG系统的需求发生变化，重新审视和改进你的 chunking策略。

总而言之，选择合适的 Chunking策略 是构建高效RAG系统的关键一步。通过深入理解各种 Chunking策略 的优缺点，并结合实际情况进行选择和调整，可以显著提升LLM的信息检索效果，最终提升RAG应用的整体性能。在RAG项目中，你发现哪些 Chunking策略 最有效？请在评论中分享你的见解！