Note

RAG 如何选择切块大小与重叠长度？

讨论语义完整性、检索精度、上下文容量与索引成本的权衡。

在构建知识库时，文本切块策略至关重要。你会如何选择合适的切块大小和重叠长度？这背后有什么权衡？

文本切块（Chunking）是RAG流程中最关键且最需要经验的步骤之一，它直接影响检索的召回率和精确度，进而影响最终生成答案的质量。选择合适的切块大小（Chunk Size）和重叠长度（Overlap）需要在多个因素之间进行权衡。

如何选择合适的切块大小（Chunk Size）？

  1. 依据嵌入模型的能力： 嵌入模型有其输入的最大Token数限制。切块大小应小于这个限制。同时，很多嵌入模型在处理中等长度（如256-512个token）的文本时效果最好，过长或过短都可能导致语义表征质量下降。
  2. 依据数据的类型和结构：
    • 对于结构化的、段落分明的文档（如论文、报告），可以采用语义切块，即按段落、标题或句子来切分，这样能最大程度地保留语义完整性。
    • 对于非结构化的长文本，则更多地依赖固定长度切块。
    • 对于代码，应该按函数或类来切块，而不是简单地按行数。
  3. 依据预期的查询类型： 如果用户的问题通常很具体，需要精确定位到某一句话，那么较小的切块（如句子级别）可能更有效。如果用户的问题很宽泛，需要综合多个段落的信息，那么较大的切块会更好。

如何选择合适的重叠长度（Overlap）？

重叠长度的作用是防止语义信息在切块边界被硬生生地切断。例如，一个重要的概念可能在一句话的结尾被提出，而在下一句话的开头进行解释。如果没有重叠，这句话就会被分割到两个独立的块中，破坏其完整性。

  • 一个常见的经验法则是设置重叠长度为切块大小的10%-20%。例如，对于1024个token的切块，可以设置128或256个token的重叠。
  • 重叠并非越大越好，过大的重叠会增加数据冗余和存储成本。

背后的权衡（Trade-offs）：

  • 大块（Large Chunks） vs. 小块（Small Chunks）：

    • 大块的优点： 包含更丰富的上下文，有助于回答需要广泛背景知识的复杂问题。

    • 大块的缺点：

      1. 噪声增加： 可能会包含大量与用户查询不直接相关的信息，稀释了关键信息的“信噪比”。
      2. 检索精度下降： 嵌入向量代表的是整个大块的平均语义，可能无法精确匹配非常具体的问题。
      3. 成本更高： 送入LLM的上下文更长，API调用成本更高。
      4. “大海捞针”问题： 容易触发LLM的“Lost in the Middle”问题。

    • 小块的优点： 信息密度高，与具体问题的相关性强，检索更精确。

    • 小块的缺点：

      1. 上下文不足： 单个小块可能不包含回答问题所需的全部信息，需要检索并拼接多个小块才能形成完整答案。
      2. 语义割裂： 容易将原本连续的上下文信息切断。

总结：

切块策略没有唯一的“最佳”方案。实践中，通常会从一个合理的基线（如chunk_size=512, overlap=64）开始，然后通过评估检索质量，针对具体的文档类型和查询场景进行迭代优化。有时甚至会采用多尺度切块的策略，即同时索引不同大小的块，以应对不同粒度的查询。