5.2 文档分块策略
分块(Chunking)是将大文档切分为小片段的过程,是 RAG 系统的关键步骤。分块质量直接影响:
原则一:语义完整性
每个块应该是一个语义完整的单元,能够独立表达完整的含义。
原则二:大小适中
块不能太大(占用过多上下文空间),也不能太小(缺失必要上下文)。
原则三:信息自包含
块应该包含理解其内容所需的必要背景信息。
按固定的字符数或 Token 数切分。
参数:块大小(通常 500-2000 字符)、重叠大小(10-20%)
按自然分隔符(段落、句子、换行)切分。
常用分隔符:\n\n、\n、.、。
尝试按多级分隔符切分,自动适应文档结构。
典型分隔符序列:["\n\n", "\n", " ", ""]
基于语义相似度切分,保持语义单元完整。
实现方式:计算相邻句子的嵌入相似度,在相似度低谷处切分。
使用语言模型理解内容结构进行切分。
块大小选择
重叠设置
重叠可以防止信息被切断在边界处,典型设置为块大小的 10-20%。
元数据保留
为每个块附加元数据:
代码文档
按函数、类等逻辑结构切分,而非按行数。
表格数据
保持行完整性,必要时将表头附加到每个块。
对话记录
按对话轮次切分,保持问答对完整。
技术文档
尊重标题层级结构,将标题作为块的上下文前缀。
评估分块效果的方法:
5.2.8 实战案例:三种场景的分块对比
以下是三种典型场景的分块策略对比,展示如何根据内容特点选择合适的方法。
场景:用户问"这款手机支持5G吗?"需要从产品说明书中检索答案。
错误做法:
正确做法:
踩坑经验:规格表按固定字符数分块会把相关属性切断,导致模型无法完整回答。应按语义属性分块,每个块对应一个完整的产品特性。
场景:找出合同中的"不可抗力"免责条款。
错误做法:
正确做法:
踩坑经验:法律文本的完整性至关重要。曾因分块切断句子导致法律含义改变("不承担"变成"承担")。必须按条款结构分块,宁可块大一点也不能破坏语义完整性。
场景:开发者问"这个函数是怎么实现的?"
错误做法:
正确做法:
踩坑经验:代码按行数分块会切断函数逻辑,模型无法理解完整实现。应按 AST(抽象语法树)提取函数/类为单位,并附带调用关系元数据。