夜雨聆风文档切分（Chunking）：2026 年的新结论，和你过去的认知可能不太一样
Chunking 是 RAG 里看起来最简单、实际最容易被低估的环节。
说它简单——不就是把长文本切成小段吗？说它被低估——切的方式不同，检索效果可以差 30%-40%。
2026 年有几篇系统的研究结论很有意思，有些直接推翻了过去大家默认的做法。这篇不讲太多代码，重点说清楚各种策略的优劣、适用场景和取舍逻辑。
Chunking 的本质：不是"切"，是"怎么切了还能粘回去"
先想清楚一个问题：我们到底为什么要切文档？
因为 LLM 的上下文窗口有限，一次装不下整本书。
但切完的 chunk 最终还是要被重新"粘"回一个上下文窗口里的。所以 chunking 的核心矛盾是：
切得太细 → 检索精度高，但上下文容易断切得太粗 → 上下文完整，但容易混进无关信息
好的 chunking 策略，就是在精度和完整性之间找到平衡点。
六大策略一览
1. 固定长度切分
按固定 token 数或字符数无脑切。512 一刀就是一刀。
优点：简单，快，零计算成本缺点：大概率从句子中间切开，语义断裂严重适合：日志文件、CSV、短文本这类结构不重要、内容重复性高的场景
一句话评价：除了快，全是缺点。只适合做 baseline 和快速验证。
2. 递归切分
多级分隔符策略：先按段落切，段落太长按句子切，句子太长再按固定长度切。
这是 LangChain 里 RecursiveCharacterTextSplitter 的做法，也是 2026 年 IJAI 论文里综合表现最好的方案之一。它在不同编辑类内容上的检索准确率和生成质量都稳定领先。
适合：大部分通用场景，作为默认起点的安全选择
3. 句子级切分
按句子边界切，每个 chunk 包含若干完整句子。
2026 年 arXiv 上有一篇分析覆盖了 7 种策略，结论是：句子级切分在性能上等于语义切分，但计算成本低得多。 特别在上下文 5000 token 以内时，差距可以忽略不计。
适合：追求性价比的通用场景
4. 语义切分
用 Embedding 模型计算句子间的相似度，相似度低于阈值的地方就是边界。
优点：每个 chunk 语义完整，话题统一缺点：计算成本高，而且最近的研究表明——它并没有比句子级切分好多少
适合：内容主题变化频繁的文档（比如一本教材的不同章节）
5. 文档结构切分
按文档本身的标题层级来切。h1 一层、h2 一层，逐级向下。
优点：最自然、最不会破坏语义缺点：依赖文档本身有清晰的标题结构
适合：法律文书、技术手册、财报等结构化文档
6. 自适应切分
2026 年 LREC 会议上有一篇重要论文提出了这个框架。它不是一种固定的切分方法，而是先分析文档的特征（交叉引用密度、语义紧密度、结构完整性等），再动态选择最适合这个文档的策略。
结果：回答正确率从 62%-64% 提升到了 72%，回答问题数量增加了 30%。
适合：文档类型混杂的大型知识库
一张表看完优劣
| 通用默认方案 | |||
几个反直觉的结论（2026 年研究）
1. 重叠可能没用
过去大家都觉得 chunk 之间要留 10%-20% 的重叠，防止边界信息丢失。
但 2026 年 arXiv 那篇系统性分析发现：10%-20% 的重叠没有带来可测量的收益，但把索引体积撑大了 1.25 倍。
这个结论有争议，实操中可以这样理解：如果你的 chunking 策略本身已经比较合理（按句子或段落边界切），重叠确实帮不上什么忙。但如果你的切分比较粗糙（比如固定长度切），重叠还是能捞回一点边界信息的。
建议：如果你用递归或句子级切分，可以尝试把重叠降到 0-5%，观察召回率有没有变化。
2. 句子级切分 ≈ 语义切分
这是 2026 年另一个让人意外的结论。在 5000 token 以内，句子级切分和语义切分的检索性能几乎相同。
语义切分的计算成本高得多（需要跑一遍 Embedding 模型），所以从投入产出比来看，句子级切分通常更划算。
但有一个例外：如果文档的主题频繁跳跃（比如一本教科书，从"神经网络"突然跳到"历史背景"），语义切分更能抓住边界。
3. 存在一个"上下文悬崖"
研究还发现一个现象：当给 LLM 的上下文超过 2500 token 左右时，生成质量反而开始下降。
不是持平，是下降。他们管这个叫 Context Cliff。
原因可能是：太长的上下文中混入了更多噪声，模型分不清哪些信息重要、哪些是次要的。
建议：不一定要把所有检索到的内容全塞给模型。设定一个 2500 token 的上限，超出部分做重排序筛选，只把最相关的放进去。
4. 哪种 chunk 大小最好？取决于你的任务
没有万能的大小。最实在的做法：在你的数据上跑几组不同大小的对比实验，看哪个 recall 最高。
中文场景的特殊问题
中文切分和英文有本质区别，因为中文没有天然的空格分词。
几个实操要点：
分隔符优先级不同。英文递归切分的默认分隔符是 \n\n → \n → 空格。中文应该换成：
段落(\n\n) → 句子(。！？) → 逗号分号(，；) → 字符chunk 大小要缩水。中文一个字约 1-2 个 token，而英文一个单词约 1-2 个 token。同样 512 token 的限制，中文大概能容纳 250-350 个字。所以中文场景下 chunk_size 设在 250-350 比较安全。
分词工具可以辅助。在句子级切分前先用 jieba 或 HanLP 做分词，可以更准确地判断句子边界。
参考基线配置：
chunk_size: 250-300（字符数）overlap: 0-5%（如果用按句子切分）separators: ["\n\n", "\n", "。", "！", "？", "，", "；"]
进阶组合技巧
Parent-Child 检索（父文档检索）
这是 2026 年非常普及的技巧，思路很简单：
- 索引时
用小 chunk（比如 200 token）做检索，精度高 - 检索后
找到小 chunk 后，返回它所在的整个父段落（比如 2000 token）
这样既享受了小 chunk 的检索精度，又保证了大 chunk 的上下文完整性。效果比单纯用任何一种都好。
实现上也简单：索引时存两套 chunk，小 chunk 做检索，大 chunk 做生成，中间用 ID 关联。
Contextual Retrieval（上下文增强检索）
Anthropic 在 2026 年推广的做法：在对每个 chunk 做 Embedding 之前，先用 LLM 给 chunk 写一段简短的上下文描述，然后把描述和 chunk 一起编码。
比如一个 chunk 内容是"营收同比增长 15%"，加上上下文描述就是"2023 年财报中关于营收增长的部分：营收同比增长 15%"。
据公开数据，这个做法可以减少 67% 的检索失败。
代价是成本——每个 chunk 都需要一次 LLM 调用。
实操建议：从简单开始，用数据说话
如果你正在搭建一个新的 RAG 系统，建议的路径：
- 从递归切分或句子级切分起步
chunk_size 用 250-300（中文）或 300-500 token（英文），overlap 先设为 0 - 准备一组测试问答对
跑一遍 baseline 看 recall - 调整 chunk_size
分别试大中小三个尺寸，看 recall 变化 - 如果效果不满足，再上语义切分或 Parent-Child
- 最后考虑自适应切分
前提是你的文档类型足够杂，简单的策略满足不了
最关键的只有一条：不要凭感觉选，要拿数据说话。 适合别人的策略不一定适合你的文档。
总结
Chunking 没有银弹。2026 年的研究告诉你几件事：
简单策略（递归、句子级）在多数场景下够用了，别一上来就上复杂的 重叠大概率是浪费，可以砍掉试试 句子级 ≈ 语义切分，但便宜得多 上下文不是越多越好，2500 token 左右有个悬崖 中文场景注意分隔符和 chunk 大小缩水 Parent-Child 检索和 Contextual Retrieval 是门槛低、效果好的进阶技巧
下一篇预告：Embedding 模型选型——市面上几十个 Embedding 模型，怎么选、怎么测、怎么落地？
本文是「每天一个AI开发实战技巧」系列第4篇。你在实际项目中踩过什么 chunking 的坑？欢迎留言分享。
