文本分块（Chunking）详解：如何将长文档切分为语义完整的短片段

在构建基于大语言模型（LLM）的智能问答、知识库或检索增强生成（RAG）系统时，文本分块（Text Chunking） 是决定系统成败的关键预处理步骤。其核心目标是：将原始长文档（如PDF、网页、技术手册等）合理切割为若干语义完整、长度适中的短片段（Chunks），以便后续高效嵌入、精准检索与高质量生成。本文将从原理、策略、参数设置到实操案例，全面解析这一关键技术。

一、为什么必须进行文本分块？

1. 模型上下文窗口限制

所有大语言模型均有最大输入长度限制（即“上下文窗口”）。例如：

• GPT-3.5：约4,096 tokens（≈3,000汉字）
• Claude 3：最高支持200,000 tokens
• 国产主流模型：多为8K–32K tokens

若直接将一本10万字的产品手册喂给模型，不仅会因超限被截断，还会因信息过载导致注意力分散，生成质量下降。

2. 嵌入模型的输入约束

用于生成向量的嵌入模型（如BGE-M3、text-embedding-3-large）同样有长度上限（通常为512–8192 tokens）。超出部分会被强制截断，造成关键信息丢失。

3. 提升检索精度与效率

• 小而精的片段能更准确匹配用户查询。例如，问“如何重置密码”，应命中“账户管理”段落，而非整本用户指南。
• 过大块包含多主题，向量表示“语义稀释”；过小块割裂逻辑，导致检索碎片化。

实验表明：合理分块可使RAG系统的回答准确率提升40%以上。

哈耶普斯GEO系统-词条

二、什么是“语义完整的短片段”？

“语义完整”指每个文本块应构成一个独立、连贯、可理解的信息单元，而非机械截断的字符序列。判断标准包括：

• 逻辑闭环：如“问题→原因→解决方案”三要素齐全；
• 实体完整：人名、产品型号、地址、数据不被拆分（如“Model Y”不应切成“Mo”和“del Y”）；
• 上下文自洽：读者仅看该块即可理解其核心含义，无需依赖前后文。

典型语义单元示例：

• 产品手册中的“安装步骤”章节
• 技术文档中的“API调用示例”
• 新闻报道中的“事件经过”段落
• FAQ中的“一个问题+完整解答”

三、主流文本分块策略详解

1. 固定长度分块（Fixed-Size Chunking）

• 做法：按预设token数（如512）均匀切割，无视内容结构。
• 优点：实现简单、计算快。
• 缺点：极易切断句子或段落，破坏语义。
• 适用场景：日志文件、代码、结构化数据等机器生成文本。

# 示例：固定token分块
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese")
tokens = tokenizer.encode(long_text)
chunks = [tokens[i:i+512] for i in range(0, len(tokens), 512)]

2. 递归字符分块（Recursive Character Splitting）

• 做法：按优先级依次尝试分隔符（如 ["\n\n", "\n", "。", " ", ""]），确保先在段落、再在句子处分割。
• 优点：尊重自然语言结构，平衡效率与语义完整性。
• 缺点：对格式混乱文本效果有限。
• 推荐工具：LangChain 的 RecursiveCharacterTextSplitter

from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=100,
    separators=["\n\n", "\n", "。", "？", "！", " ", ""]
)
chunks = splitter.split_text(document)

3. 基于语义的分块（Semantic Chunking）

• 做法：
  1. 将文档拆为句子；
  2. 计算相邻句子的嵌入向量相似度；
  3. 当相似度低于阈值（如0.7），视为语义边界，进行分割。
• 优点：块内高度相关，跨主题干扰少。
• 缺点：计算成本高，需调参。
• 适用场景：学术论文、法律文书、多主题报告。

4. 结构感知分块（Structure-Aware Chunking）

• 做法：利用文档固有结构进行分割：
  • Markdown/HTML：按标题（#, ##）分块；
  • PDF：保留表格、图像描述，按章节拆分；
  • 代码：按函数、类定义分割。
• 优点：最大限度保留原始语义组织。
• 工具推荐：Unstructured、LlamaIndex 的 MarkdownHeaderTextSplitter

四、关键参数设置指南

1. 分块大小（Chunk Size）

• 通用建议：256–1024 tokens
  • 简单问答/FAQ：256–512 tokens（聚焦单一事实）
  • 技术文档/操作指南：512–1024 tokens（保留完整流程）
• 依据：嵌入模型最大长度 × 0.7（预留重叠与安全边际）

2. 块间重叠（Chunk Overlap）

• 作用：防止关键信息恰好位于边界被割裂。
• 推荐值：10%–20% 的 chunk size（如800 tokens → 重叠80–160 tokens）
• 示例：
  • 块1：第1–800字
  • 块2：第720–1520字（前80字与块1重叠）

3. 分隔符（Separators）

• 中文优先级建议：["\n\n", "\n", "。", "？", "！", "；", " ", ""]
• 避免使用英文标点（如.）处理中文文本。

五、实操案例：产品手册分块

假设有一份《智能空调用户手册》，内容包含：

• 产品简介
• 安装步骤（含图示说明）
• 功能说明（制冷/制热/静音模式）
• 故障排查表
• 售后服务信息

错误分块方式：
按每500字符切割 → “安装步骤”被切成三段，且一段混入“功能说明”。

正确分块方式：

1. 识别一级标题（如“## 安装步骤”）作为分块起点；
2. 对“故障排查”表格，整体作为一个块；
3. 设置 chunk_size=800, overlap=100；
4. 最终得到5个语义完整块，每块对应一个独立功能模块。

结果：当用户问“空调不制冷怎么办？”，系统精准召回“故障排查”块，而非混杂安装或售后信息。

哈耶普斯广告-Aichat

六、常见误区与优化建议

• 误区1：越大越好 → 导致噪声干扰，降低检索精度。
  建议：宁可稍小，确保语义聚焦。

• 误区2：完全依赖自动分块 → 忽略业务逻辑。
  建议：对核心文档（如产品参数、服务条款）人工校验分块边界。

• 误区3：忽略元数据 → 无法区分北京与上海的服务差异。
  建议：为每个块添加来源URL、地域标签、更新时间等元数据。

FAQ

Q1：如何确定最适合我项目的分块大小？
A：可通过A/B测试验证。例如，分别用512和1024 tokens分块，用相同问题集测试RAG回答准确率，选择得分更高者。一般原则：事实型内容用小块，论述型内容用大块。

Q2：PDF中的表格和图片如何处理？
A：使用专业解析库（如Unstructured）提取表格为Markdown或HTML格式，图像则通过多模态模型生成文字描述（如“图1：北京门店分布图”），再与文本一同分块。

Q3：分块后如何评估质量？
A：可采用以下方法：
① 人工抽查：随机抽取100个块，检查是否语义完整；
② 自动化测试：构造“问题-答案”对，验证能否从对应块中找到答案；
③ 使用ChunkViz等工具可视化分块边界，直观对比不同策略效果。