一、背 景

在 RAG 系统中，即便采用性能卓越的 LLM 并反复打磨 Prompt，问答仍可能出现上下文缺失、事实性错误或拼接不连贯等问题。多数团队会频繁更换检索算法与 Embedding模型，但收益常常有限。真正的瓶颈，往往潜伏在数据入库之前的一个细节——文档分块（chunking）。不当的分块会破坏语义边界，拆散关键线索并与噪声纠缠，使被检索的片段呈现“顺序错乱、信息残缺”的面貌。在这样的输入下，再强大的模型也难以基于支离破碎的知识推理出完整、可靠的答案。某种意义上，分块质量几乎决定了RAG的性能上限——它决定知识是以连贯的上下文呈现，还是退化为无法拼合的碎片。

 

在实际场景中，最常见的错误是按固定长度生硬切割，忽略文档的结构与语义：定义与信息被切开、表头与数据分离、步骤说明被截断、代码与注释脱节，结果就是召回命中却无法支撑结论，甚至诱发幻觉与错误引用。相反，高质量的分块应尽量贴合自然边界（标题、段落、列表、表格、代码块等），以适度重叠保持上下文连续，并保留必要的来源与章节元数据，确保可追溯与重排可用。当分块尊重文档的叙事与结构时，检索的相关性与答案的事实一致性往往显著提升，远胜于一味更换向量模型或调参；换言之，想要真正改善 RAG 的稳健性与上限，首先要把“知识如何被切开并呈现给模型”这件事做好。

 

PS：本文主要是针对中文文档类型的嵌入进行实战。

二、什么是分块（Chunking）

分块是将大块文本分解成较小段落的过程，这使得文本数据更易于管理和处理。通过分块，我们能够更高效地进行内容嵌入（embedding），并显著提升从向量数据库中召回内容的相关性和准确性。

 

在实际操作中，分块的好处是多方面的。首先，它能够提高模型处理的效率，因为较小的文本段落更容易进行嵌入和检索。

 

其次，分块后的文本能够更精确地匹配用户查询，从而提供更相关的搜索结果。这对于需要高精度信息检索和内容生成的应用程序尤为重要。

 

通过优化内容的分块和嵌入策略，我们可以最大化LLM在各种应用场景中的性能。分块技术不仅提高了内容召回的准确性，还提升了整体系统的响应速度和用户体验。

 

因此，在构建和优化基于LLM的应用程序时，理解和应用分块技术是不可或缺的步骤。

 

分块过程中主要的两个概念：chunk_size块的大小，chunk_overlap重叠窗口。

 

三、为何要对内容做分块处理

• 模型上下文窗口限制：LLM无法一次处理超长文本。分块的目的在于将长文档切成模型可稳定处理的中等粒度片段，并尽量对齐自然语义边界（如标题、段落、句子、代码块），避免硬切导致关键信息被截断或语义漂移。即便使用长上下文模型，过长输入也会推高成本并稀释信息密度，合理分块仍是必需的前置约束。
•  
• 检索的信噪比：块过大时无关内容会稀释信号、降低相似度判别力；块过小时语境不足、容易“只命中词不命中义”。合适的块粒度可在召回与精度间取得更好平衡，既覆盖用户意图，又不引入多余噪声。在一定程度上提升检索相关性的同时又能保证结果稳定性。
•  
• 语义连续性：跨段落或跨章节的语义关系常在边界处被切断。通过设置适度的 chunk_overlap，可保留跨块线索、减少关键定义/条件被“切开”的风险。对于强结构文档，优先让边界贴合标题层级与句子断点；必要时在检索阶段做轻量邻近扩展，以提升答案的连贯性与可追溯性，同时避免重复内容挤占上下文预算。

 

总之理想的分块是在“上下文完整性”和“信息密度”之间取得动态平衡：chunk_size决定信息承载量，chunk_overlap 用于弥补边界断裂并维持语义连续。只要边界对齐语义、粒度贴合内容，检索与生成的质量就能提升。

 

四、分块策略详解

4.1 基础分块

基于固定长度分块

• 分块策略：按预设字符数 chunk_size 直接切分，不考虑文本结构。
• 优点：实现最简单、速度快、对任意文本通用。
• 缺点：容易破坏语义边界；块过大容易引入较多噪声，过小则会导致上下文不足。
• 适用场景：结构性弱的纯文本，或数据预处理初期的基线方案。

from langchain_text_splitters import CharacterTextSplitter

splitter = CharacterTextSplitter(
    separator="",        # 纯按长度切
    chunk_size=600,      # 依据实验与模型上限调整
    chunk_overlap=90,    # 15% 重叠
)
chunks = splitter.split_text(text)

• 参数建议（仅限中文语料建议）：
  • chunk_size：300–800 字优先尝试；若嵌入模型最佳输入为 512/1024 tokens，可折算为约 350/700 中文字符起步。
  • chunk_overlap：10%–20% 起步；超过 30% 通常导致索引体积与检索开销显著上升，对实际性能起负作用，最后的效果并不会得到明显提升。