RAG 调优核心：文本切分决定 70% 的性能表现

分块（Chunking）是构建高效RAG（检索增强生成）系统的核心。从固定分块、递归分块到语义分块、结构化分块和延迟分块，每种方法都在优化上下文理解和准确性上扮演了关键角色。这些技术能大幅提升检索质量，减少“幻觉”（hallucination），并充分发挥你的RAG pipeline的潜力。

在我近一年构建可扩展AI系统的经验中，我发现RAG系统的成功大多取决于检索（retrieval）。你如何切分和存储文档——也就是分块（chunking）——往往是成功背后的隐形推手。

引言

RAG（Retrieval-Augmented Generation）pipeline的性能很大程度上取决于你如何切分文档（分块）。在这篇文章中，我会带你了解RAG的流程，重点讲讲分块在其中的位置，然后深入探讨固定分块、递归分块、语义分块、基于结构的分块和延迟分块这五种技术，包括它们的定义、权衡和伪代码，帮你选择适合自己场景的方法。

RAG工作流程（高层次概览）

标准流程如下：

1. 文档摄取与分块
   拿来大份文档（PDF、HTML、纯文本） → 切分成小块（chunk） → 计算embeddings → 存储到vector DB中。
2. 查询与检索
   用户输入查询 → 将查询转为embedding → 检索top-k最相似的块（通过cosine similarity）。
3. 增强与提示构建
   将检索到的块（加上metadata）注入到LLM的提示中，通常会用模板和过滤器。
4. 生成
   LLM基于检索到的上下文和模型先验知识生成答案。

因为生成器（generator）只能看到你喂给它的内容，检索质量直接决定了结果。如果分块不合理或无关紧要，哪怕最好的LLM也救不回来。这就是为什么很多人说RAG的成功70%靠检索，30%靠生成。

在深入探讨技术之前，先说说为什么好的分块不是可有可无的：

• Embedding和LLM模型有context window限制，你没法直接处理超大文档。
• 分块需要语义连贯。如果你在句子或概念中间切开，embedding会变得杂乱或误导。
• 如果分块太大，系统可能会漏掉细粒度的相关内容。
• 反过来，如果分块太小或重叠太多，你会存储冗余内容，浪费计算和存储资源。

接下来，我们来探索五种主流的分块技术，从最简单到最复杂。

1. 固定分块（Fixed Chunking）

按固定大小（按token、单词或字符）把文本切成等大的块，通常块之间会有重叠。

这是RAG项目的良好起点，适合文档结构未知或内容单一的场景（比如日志、纯文本）。

实现代码示例：

def fixed_chunk(text, max_tokens=512, overlap=50):
    tokens = tokenize(text)
    chunks = []
    i = 0
    while i < len(tokens):
        chunk = tokens[i : i + max_tokens]
        chunks.append(detokenize(chunk))
        i += (max_tokens - overlap)
    return chunks

2. 递归分块（Recursive Chunking）

先按高层边界（比如段落或章节）切分。如果某个块还是太大（超过限制），就递归地进一步切分（比如按句子），直到所有块都在限制范围内。

适合半结构化文档（有章节、段落），你想尽量保留语义边界，同时控制块大小。

它能尽量保留逻辑单元（段落），避免不自然的切分，生成适合内容变化的多种块大小。

递归分块示例（LangChain）：

from langchain.text_splitter import RecursiveCharacterTextSplitter

# 示例文本
text = """
输入文本占位符...
"""

# 定义递归分块器
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=200,           # 每个块的目标大小
    chunk_overlap=50,         # 块之间的重叠以保持上下文连贯
    separators=["\n\n", "\n", " ", ""]  # 递归切分的优先级
)

# 切分文本
chunks = text_splitter.split_text(text)

# 显示结果
for i, chunk inenumerate(chunks, 1):
    print(f"Chunk {i}:\n{chunk}\n{'-'*40}")

这能确保后续embedding和检索时，不会丢失边界处的关键上下文。

3. 语义分块（Semantic Chunking）

根据语义变化来切分文本。用embeddings（比如sentence embeddings）决定一个块的结束和下一个块的开始。如果相邻段落的相似度很高，就把它们放在一起；当相似度下降时，就切分。

适合需要高检索精度的场景（法律文本、科学文章、支持文档），但要注意embedding和相似度计算的成本，定义相似度阈值也需要仔细调整。

实现代码示例：

from sentence_transformers import SentenceTransformer, util

model = SentenceTransformer("all-MiniLM-L6-v2")

defsemantic_chunk(text, sentence_list, sim_threshold=0.7):
    embeddings = model.encode(sentence_list)
    chunks = []
    current = [sentence_list[0]]
    for i inrange(1, len(sentence_list)):
        sim = util.cos_sim(embeddings[i-1], embeddings[i]).item()
        if sim < sim_threshold:
            chunks.append(" ".join(current))
            current = [sentence_list[i]]
        else:
            current.append(sentence_list[i])
    chunks.append(" ".join(current))
    return chunks

4. 基于结构的分块（Structure-based Chunking）

利用文档的固有结构（比如标题、副标题、HTML标签、表格、列表项）作为自然的切分边界。
比如，每个章节或标题可以成为一个块（或者再递归切分）。
适合HTML页面、技术文档、类似Wikipedia的内容，或任何有语义标记的内容。

根据我的经验，这种策略效果最好，尤其是结合递归分块时。
但它需要解析和理解文档格式，如果章节太大，可能会超过token限制，可能需要结合递归切分。

实现提示：

• 用HTML/Markdown/PDF结构解析库。
• 以章节/等作为块的根。
• 如果某部分太大，就回退到递归切分。
• 对于表格/图片，要么单独作为一个块，要么总结其内容。

5. 延迟分块（Late Chunking / 动态/查询时分块）

定义
延迟分块是指推迟文档的切分，直到查询时才决定。不是提前把所有内容切好，而是存储更大的段落甚至整个文档。收到查询时，只对相关段落动态切分（或过滤）。这样做的目的是在embedding时保留完整上下文，只在必要时切分。

Weaviate将延迟分块描述为“颠倒传统的embedding和chunking顺序”。

• 先用长上下文模型对整个文档（或大段）做embedding。
• 然后池化并创建块的embeddings（基于token范围或边界线索）。

概念流程：

• 在索引中存储大段或整个文档。
• 查询时，检索1-2个最相关的段落。
• 在这些段落中，动态切分（比如语义或重叠）出匹配查询的部分。
• 过滤或排序这些块，喂给生成器。

这种方法就像编程中的late binding，推迟到有更多上下文时再决定。

适用场景：

• 大型文档集（技术报告、长篇内容），跨段落的上下文很重要。
• 文档内容经常变化的系统，避免重新切分节省时间。
• 高风险或精度敏感的RAG应用（法律、医疗、监管），误解代词或引用可能代价高昂。

听起来很高级，但它也有成本。
对整个文档（或大段）做embedding计算成本高，可能需要支持长token限制的模型。
查询时的计算成本和潜在延迟也会更高。

本文转载自​​PyTorch研习社​​，作者：AI研究生