文本分块策略对比
五种分块策略一览
| 策略 | 切割依据 | 效果 | 计算成本 | 适用场景 |
|---|---|---|---|---|
| 固定大小分块 | 固定 token 数量 | ⭐⭐ | 极低 | 快速原型、格式规范文档 |
| 按段落/章节分块 | 标题、换行符等自然边界 | ⭐⭐⭐ | 极低 | 结构清晰的文档 |
| 递归分块 | 多级分隔符，从大到小递归 | ⭐⭐⭐⭐ | 低 | 大多数通用场景 |
| 语义分块 | Embedding 相似度，话题变化处切割 | ⭐⭐⭐⭐⭐ | 高 | 格式混乱、高精度要求 |
| 滑动窗口分块 | 固定大小 + 相邻块有重叠部分 | ⭐⭐⭐ | 低 | 信息跨句子的连续性场景 |
详细对比
1. 固定大小分块（Fixed-size Chunking）
做法： 每隔固定数量的 token（如 512）强制切一刀，不考虑任何语义边界。
优点：
-
实现极简，几乎零成本
-
每个块大小均匀，便于管理
-
速度极快
缺点：
-
完全不理解内容，经常在句子中间切断
-
语义割裂严重，关键信息可能被切碎
-
块与块之间缺乏关联，上下文容易丢失
适用场景： 仅适合快速验证原型，生产环境不推荐单独使用。
2. 按段落/章节分块（Paragraph / Section Chunking）
做法： 根据文档的自然结构（标题、\n\n、章节符号等）进行切分。
优点：
-
尊重文档的原始逻辑结构
-
语义完整性较好
-
实现简单，无需额外计算
缺点：
-
高度依赖文档格式质量，格式混乱则效果很差
-
块大小极不均匀（有的段落几十字，有的几千字）
-
无法处理没有明显结构的文档（如纯文本、扫描件）
适用场景： 格式规范的文档，如技术手册、法律条文、带有标题层级的 Word/PDF。
3. 递归分块（Recursive Chunking）
做法： 预设分隔符优先级列表（如 ["\n\n", "\n", "。", " ", ""]），优先用高级别分隔符切，切出的块仍然过大则递归用下一级分隔符继续切，直到满足大小要求。
优点：
-
尽量在自然语义边界处切割，避免硬切
-
块大小可控，不会出现超大块
-
兼顾格式和内容，效果稳定
-
计算成本低，速度快
-
LangChain 等主流框架的默认推荐方案
缺点：
-
本质上仍依赖格式符号，不理解文本内容
-
无法识别同一段落内的话题切换
-
分隔符优先级需要根据语言/文档类型手动调整（中英文有差异）
适用场景： 绝大多数通用场景，是生产环境的首选基准方案。
4. 语义分块（Semantic Chunking）
做法： 先按句子粗切，然后用 Embedding 模型计算相邻句子之间的语义相似度，在相似度骤降（话题跳跃）的地方切割。
优点：
-
真正理解文本内容，在话题边界处切割
-
块的语义内聚性最强，检索精度最高
-
几乎不依赖文档格式，对格式混乱的文档也有效
-
能识别同一段落内的话题切换
缺点：
-
计算成本高：每个句子都需要计算 Embedding 向量
-
对大规模文档库处理速度慢
-
分块边界依赖相似度阈值，需要调参
-
实现复杂度较高
适用场景： 对检索精度要求高、文档格式不规范、或内容话题切换频繁的场景。
5. 滑动窗口分块（Sliding Window Chunking）
做法： 在固定大小分块的基础上，让相邻块之间有一段重叠内容（overlap）。例如 chunk_size=512，overlap=100，则相邻两块共享 100 个 token 的内容。
原文: [AAAAAABBBBBBCCCCCC]
无重叠: [AAAAAA] [BBBBBB] [CCCCCC]
有重叠: [AAAAAABB] [BBBBBBCC] [CCCCCCDD]
↑↑重叠↑↑优点：
-
避免关键信息恰好落在切割边界而丢失
-
保留跨块的上下文连续性
-
实现简单，成本低
缺点：
-
重叠部分造成冗余存储，增加索引大小
-
同一内容可能被检索多次，需要去重
-
块数量增多，检索效率略有下降
-
overlap 大小需要经验调参
适用场景： 常作为其他分块策略的补充手段配合使用，尤其适合信息跨句子分布的文档。
如何选择？
文档格式规范？
├── 是 → 按段落/章节分块 或 递归分块（推荐递归分块）
└── 否 → 语义分块（格式混乱时首选）
对精度要求极高？
├── 是 → 语义分块 或 递归分块 + Reranker
└── 否 → 递归分块（速度和效果的最佳平衡）
文档量极大、速度优先？
└── 递归分块 或 固定大小分块
关心块边界信息丢失？
└── 在任意策略基础上加上 overlap（滑动窗口思路）实践建议：
-
先用递归分块跑通整个 RAG 流程，作为基准
-
评估检索质量，如果召回不准再考虑升级到语义分块
-
几乎所有场景都建议加一定的 overlap（如 chunk_size 的 10%~20%）
-
可以结合父子分块：检索用小块（精准命中），送给 LLM 用大块（上下文完整）