分块
在RAG（检索增强生成）项目中，分块（Chunking）是连接原始文档与AI模型的核心桥梁，很多新手会疑惑"为什么非要分块？
什么是分块
分块就是把原始长文本拆成若干个小块，每个小块通常几百到上千字，包含相对完整的语义单元，比如一个段落、几个段落或一个小节。
通俗理解：把一本厚书拆成按章节划分的小册子，每本小册子保留完整章节内容，不用每次都抱整本书，方便查找和阅读。
为什么要分块
为什么需要分块?核心原因有三个:
1)模型处理能力有上限。大语言模型一次能吃进去的文本长度是有限制的，GPT-4 Turbo是128Ktokens，Claude 3是200K tokens。一本10万字的书直接塞进去，模型消化不了，得先切成小块。
2)检索需要精准定位。用户提问通常只关心局部内容，比如问"第三章的案例是什么"。把整本书向量化成一个大向量，检索时根本分不清哪段最相关。切成小块后，每个块都有自己的向量表示，检索时能快速找到最匹配的那几个块。
3)平衡上下文和计算效率 。小块既能保留足够的上下文让模型理解前后逻辑，又能让向量计算和存储更高效。一个500tokens的块比5000tokens 的块在相似度计算时快得多。
分块大小怎么定
实践中常用的chunk大小在200到500tokens之间作为起点 。对于长技术文档或学术报告，可以放宽到512到1024tokens。
- 同时建议设置10%到20%的重叠 ，让相邻块之间有交集，避免关键信息刚好卡在分界线上被截断。
- 也可以参考 OpenAI官方RAG分块默认值
元数据标注不能少，光切块不够，每个块还得带上身份信息:
- 1)来源信息:这个块属于原文档的哪一章、哪一节
- 2)位置信息:在原文档中的页码、段落编号
- 3)类型信息:是正文、标题、列表还是图表说明
这些元数据在检索时很关键。用户问"附录A的公式怎么推导"，检索系统能通过元数据直接定位到附录A的块，不会误匹配到正文里长得像的内容。
常用分块工具
- LangChain 的RecursiveCharacterTextSplitter 支持滑动窗口和语义拆分 ，是目前用得最多的。
- Hugging Face的Tokenizers 能按token数精确拆分，适合对token 限制敏感的场景。
- Llamalndex也有内置的分块器，支持按段落、句子等多种粒度切分。
追问
提问1:分块时设置重叠有什么好处?重叠比例一般设多少?
回答:**重叠是为了防止关键信息刚好卡在分界线上被截断。**比如一段话讲的是"方案的优点和缺点"，刚好在"优点"和"缺点"中间被切开了，前一个块只有优点，后一个块只有缺点，检索时可能漏掉完整的对比信息 。设置重叠后，边界附近的内容在两个块里都有，检索时更容易命中。重叠比例一般10%到20%，太大浪费存储和计算资源，太小起不到作用。
提问2:分块粒度对检索效果有什么影响?
回答:
- 粒度太细，每个块信息量太少，检索出来的块可能不足以回答问题，得召回很多块拼凑。
- 粒度太粗，块里混了多个话题，检索精度下降，模型容易被无关内容干扰。
- 实际项目中一般先用300到500tokens跑个基线，再根据检索召回率和答案质量调整。不同类型的文档最优粒度也不一样，技术文档可以粗一点，FAQ类的要细一点。
提问3:除了固定长度分块，还有什么更智能的分块方式?
回答:语义分块 是目前比较火的方向。不是机械地按字数切，而是用模型判断句子之间的语义相似度，相似度高的句子放一个块，相似度突然下降的地方就是分界点。
LangChain有个SemanticChunker 就是干这个的。还有基于文档结构 的分块，比如Markdown按标题切、PDF按段落切、代码按函数切，这种方式能保证每个块在结构上是完整的。