为什么同样是做 RAG,有的效果拔群,有的却差强人意?分块(Chunking)策略可能是那个被你忽略的关键环节。
AI中的分块是指将大型文档分割成称为“chunk”的较小片段。这些片段可以是段落、句子、词组或受token限制的片段,这使得模型能更轻松地仅搜索和检索所需内容。这种分块技术对于优化检索增强生成(RAG)的性能至关重要。
在RAG中,检索到正确的信息是关键,但当知识库非常庞大,可能包含数百万字或文档时,使用有效的RAG分块技术对于从这类大型数据集中高效检索相关信息,就变得至关重要了。举个例子,你有一个服务QPS达到千万级还要在30ms内返回结果,这时一定会搞一组本地缓存的集群。把你的数据按规则初始化到缓存里,就是对应的RAG的Chunk操作。
Chunk也是RAG ETL Pipeline中Transform环节的核心组件之一,可以比喻成我们切蛋糕,在切之前就已经想好要分几块了。让我看看“切蛋糕”有几种手法。

•核心思想:根据预定义的字符数或 token 数将文本分成统一的块。
•工作方式:例如,固定每块 500 tokens。引入 “重叠区”(Overlap)来缓解上下文断裂问题。
•优点:实现简单,处理速度快,不依赖复杂模型。
•缺点:可能破坏语义完整性(如拆分句子或段落),对结构差异大的文档适应性差。

•核心思想:根据文本的语义相似度而非物理结构进行分块,确保每个 Chunk 内部主题高度相关。
•工作方式:通常通过计算句子 Embedding 的余弦相似度,当相似度低于某个阈值时进行分割。
•优点:能创建逻辑上最连贯的 Chunk,对后续检索和生成质量提升显著。特别适用于处理主题跳跃较多的文档。
•缺点:计算成本高(需要调用 Embedding 模型),处理速度较慢。

•核心思想:一种更智能的组合式策略,按优先级顺序尝试多种分隔符进行递归分割。
•工作方式:例如,优先按段落分割,如果段落仍过大,再按句子分割,最后才按字符数强制分割。
•优点:尽可能保留高级别的语义结构(段落 > 句子 > ...),适应性强,能处理多种类型文档。
•缺点:实现稍复杂,性能开销高于纯固定大小分块。

•核心思想:利用文档本身的元数据和结构信息(如标题层级、表格、图片说明、PDF 页码等)进行智能分割。
•工作方式:例如,将一个一级标题下的所有内容(包括子标题和段落)作为一个大 Chunk,或者将每个表格单独作为一个 Chunk。
•优点:完美贴合特定类型文档(如法律合同、学术论文、报告)的逻辑结构,信息组织性强。
•缺点:依赖高质量的文档解析和结构识别,通用性相对较弱。

•核心思想:这是一种更前沿的动态策略,根据 Agent 将要执行的具体任务或目标来决定如何分块。
•工作方式:Agent 会先理解任务,然后自适应地从文档中提取和组织最相关的信息块。例如,任务是 “总结”,则可能提取关键论点;任务是 “回答特定问题”,则可能精准定位相关证据。
•优点:灵活性和针对性极高,能最大化任务效果。
•缺点:实现复杂,通常需要强大的规划和推理能力,目前还不普及。

•核心思想:将文本分割成完整的句子,确保每个 Chunk 都包含一个或多个完整的思想。
•工作方式:使用 NLP 工具(如 NLTK, SpaCy)识别句子边界,然后可以将几个连续的句子组合成一个 Chunk。
•优点:保证了基本的语义单元完整,避免了 “半句话” 的问题。
•缺点:句子长度差异仍可能导致 Chunk 大小不均;多个句子组合时,如何确定最佳组合仍需策略。

•核心思想:基于段落的分块,通过提示符截取,将整个文本划分成多个段落。这种方式同样适合结构清晰的文档。
•工作方式:例如,保险条款、法律、论文、AB实验报告等文档。
•优点:优点自然分段,语义完整。
•缺点:缺点自然是段落长度不一,可能超token限制。
除以上7种外,还有很多大神们总结的切块方法论,如按照token、按照层级,按照excel sheet页,按照pdf页码等。都是针对特定场景。下面我结合实战和中文的切块的方法论做一下总结。
现实中不存在一种“one-for-all” 的数据读取和分块方法,特别像是 PDF 和 Word 这类复杂格式的文档。比较流行的方案是实用DeepDoc(OCR、TSR、DLR),所以实际中应根据业务,制作不同的模板。那么评估Chunk的参数和指标有哪些呢? 指标就是Precision和Recall,详细看表格:
| 参数 | 参考值 | 作用 |
| chunk_size | 512-1024 | 1.切的越小chunks数越多,所以chunk_size跟你的top-k值有关。在 Recall 差不多的情況下,可以选Precision 高的,比较有效率。 2.如果是能力強的大模型,Precision 低一點,也没问题。 3.如果是能力弱的小模型,容易被噪声影响,Precision 太低不好,因此切块需要调小。 4.为什么默认值是512?与主流预训练语言模型的上下文窗口大小(如BERT的512)保持兼容。 |
| separator | /n | 分隔符 |
| overlap | 10%-15% | 通常重叠块长度在10%-20%之间 |
Chunk参数与指标,我设计了两套策略:512/10%和2500/25 (单位token)
| 通用策略(512/10%) | 最大上下文策略(2500/25) |
|---|---|
| chunk_size:512个token,约450多个汉字是相对中等的切块大小。这个大小足以容纳完整的剧组或段落。大多情况可以在“准确率”与“上下文完整性”之间取的平衡 | chunk_size:2500个token相当于2000多个汉字,属于非常大的文本块了。这个设定的背后逻辑是利用现在的大模型(GPT-5.1、gemini 3)的超大token。当任务是进行长篇文件的深度思考推理时,可以提供丰富的信息给到模型,从而获得较高的Precision。 |
| overlap:10%是比较中庸设定,是业界普遍的建议,能缓解边界切割问题。 | overlap:10个左右汉字,基本可以忽略了,超大文本块被切割的几率相对较小。 |
我的方法论:段落分块(Paragraph Chunking),句子分块(Semantic Chunking),递归分块(Recursive Chunking),语义分块(Semantic Chunking)。
现在的RAG框架基本都是基于段落或句子来分块,也都都支持(\n。;!?)的递归分块。那从运营用户角度出发,或者第一次切的时候,如何傻瓜式操作呢?RAGFlow交出了一份方案,看一下它的分块核心算法

如何开始?可以从512 tokens 搭配 10-15%的重叠率开始。
如何优化?调试参数,多使用递归分块和句子分块,语义分块还是不够优秀。
如何测评?上号 chunking_evaluation
有和方法论? 上号 CRUD-RAG论文指出对于创意生成和保持文章连贯性的任务,切分较大的块表现会更佳。我们在
RAGas实验也得到了相同的答案。
好了,以上是我们的实践总结,希望能帮到大家。