RAG分块策略

7993 字
40 分钟
RAG分块策略

RAG 的分块策略详解#

一、背景与重要性#

在 RAG(Retrieval-Augmented Generation,检索增强生成)系统中,文档分块质量直接决定问答系统能不能答准、答全、答得有依据

可以把 RAG 想象成一个开卷考试系统:

  1. 先把教材切成很多知识卡片。
  2. 用户提问时,系统先找出最相关的几张卡片。
  3. 大模型再根据这些卡片组织答案。

如果卡片切得不好,后面的检索、重排、Prompt、模型能力都会被拖累。

常见问题包括:

  • 上下文缺失:只召回了结论,没召回条件。
  • 事实性错误:模型拿到片面的证据后误判。
  • 拼接不连贯:多个块之间缺少过渡关系。
  • 错误引用:答案引用了不完整或不对应的原文。
  • 幻觉增加:检索内容不足,模型只能自己补。

最常见的误区是:按固定长度硬切文本。比如每 500 字切一块,前后重叠 100 字。这样实现简单,但容易把标题、段落、列表、表格、代码、问答、条件和结论切断。

高质量分块应该满足三个要求:

  • 贴合自然语义和文档结构边界。
  • 设置适度重叠,保证上下文连续。
  • 保留元数据,比如标题路径、来源位置、块类型。

结论:分块质量几乎决定了 RAG 系统的性能上限。分块不是把文章切短,而是把知识切成“用户提问时刚好能用”的最小完整单元。


二、为什么需要分块?#

1. 模型上下文窗口有限#

大模型不能无限制读取所有文档。即使模型上下文窗口很大,把整篇文档都塞进去也会带来成本、延迟和噪声问题。

因此,需要先把文档切成片段,再按用户问题检索相关片段。

2. 提升检索信噪比#

块太大:

  • 好处:上下文完整。
  • 问题:无关内容太多,关键信息被稀释。

块太小:

  • 好处:命中更精准。
  • 问题:上下文不足,模型不知道这句话的条件、范围和出处。

例如原文:

用户可在订单完成后 7 天内申请无理由退款。若商品已拆封且影响二次销售,则不支持无理由退款。超过 7 天后,仅支持质量问题申诉。

如果切得太小:

块 1:若商品已拆封且影响二次销售,则不支持无理由退款。

用户问“什么情况下不能退款”时,这个块能回答一部分,但不知道这是“订单完成后 7 天内”的规则,也不知道超过 7 天后的处理方式。

如果切得太大,把退款、发票、物流、会员规则都放在一起,检索结果又会混入大量无关信息。

3. 保障语义连续性#

很多知识不是单句成立的,而是由“条件 + 结论 + 例外 + 操作方式”共同构成。

例如:

员工连续旷工三日,公司有权解除劳动合同。因不可抗力或突发疾病导致无法到岗,并能提供有效证明的,不视为旷工。

如果只召回第一句,答案会偏严厉;如果只召回第二句,答案又缺少主规则。

理想目标:在“上下文完整性”和“信息密度”之间取得动态平衡。


三、分块策略详解#

1. 基础分块#

基础分块适合快速搭建 RAG 系统,也适合做 baseline。它们的优点是简单、稳定、成本低;缺点是对复杂结构的理解能力有限。


1.1 固定长度分块#

方法说明#

固定长度分块是最简单的方式:按固定字符数或 token 数直接切割文本。

例如:

chunk_size = 300
chunk_overlap = 50

意思是每块大约 300 字,相邻块之间保留 50 字重叠。

案例#

原文:

RAG 系统通常包括文档解析、文本分块、向量化、索引构建、召回、重排和答案生成几个步骤。文档分块的质量会直接影响召回效果。如果分块过大,检索结果里会混入太多无关信息;如果分块过小,模型又可能拿不到完整上下文。

假设每 45 字切一块,可能得到:

块 1:
RAG 系统通常包括文档解析、文本分块、向量化、索引构建、召回、
块 2:
重排和答案生成几个步骤。文档分块的质量会直接影响召回效果。
块 3:
如果分块过大,检索结果里会混入太多无关信息;如果分块过小,
块 4:
模型又可能拿不到完整上下文。

问题分析#

块 1 把“召回、重排和答案生成”拆开了。

块 3 把“如果分块过小”的后半句切掉了。

用户问“分块过小有什么问题”时,如果只召回块 3,模型看不到结论。

更好的处理#

如果必须使用固定长度分块,至少要加重叠:

块 3:
如果分块过大,检索结果里会混入太多无关信息;如果分块过小,
块 4:
如果分块过小,模型又可能拿不到完整上下文。

适用场景#

  • 结构弱的纯文本。
  • 日志、 OCR 粗文本等没有明显标题结构的材料。
  • 快速验证 RAG 流程的 baseline。

参数建议#

中文文档:

  • chunk_size:300-800 字。
  • chunk_overlap:10%-20%。

记忆方法#

固定长度分块像用尺子切文章,快,但容易切断意思。


1.2 基于句子的分块#

方法说明#

先把文本切成句子,再把若干句合并成一个块。

它比固定长度分块更尊重语义,因为至少不会把一句完整的话从中间截断。

案例#

原文:

用户可以在订单完成后 7 天内申请退款。商品拆封后如影响二次销售,则不支持无理由退款。超过 7 天后,仅支持质量问题申诉。

第一步,分句:

句 1:用户可以在订单完成后 7 天内申请退款。
句 2:商品拆封后如影响二次销售,则不支持无理由退款。
句 3:超过 7 天后,仅支持质量问题申诉。

第二步,聚合成块:

块 1:
用户可以在订单完成后 7 天内申请退款。
商品拆封后如影响二次销售,则不支持无理由退款。
块 2:
超过 7 天后,仅支持质量问题申诉。

如果希望上下文更连续,可以做句子级重叠:

块 1:
用户可以在订单完成后 7 天内申请退款。
商品拆封后如影响二次销售,则不支持无理由退款。
块 2:
商品拆封后如影响二次销售,则不支持无理由退款。
超过 7 天后,仅支持质量问题申诉。

适用场景#

  • FAQ。
  • 新闻。
  • 法律法规。
  • 政策制度。
  • 短段落知识库。

注意事项#

中文分句不能直接照搬英文工具。比如 NLTK 对中文标点支持不好,容易把中文句子切错。

推荐:

  • HanLP。
  • Stanza。
  • 中文正则分句。
  • 自定义标点规则。

记忆方法#

句子分块的底线是:不要把一句完整的话切断。


1.3 递归字符分块#

方法说明#

递归字符分块会按照“从大到小”的边界依次尝试切分。

常见顺序:

标题 > 段落 > 换行 > 句子 > 空格 > 字符

如果按标题切后仍然太长,就继续按段落切;如果段落还太长,再按句子切。

案例#

原文:

## 退款规则
用户可以在订单完成后 7 天内申请退款。
商品拆封后如影响二次销售,则不支持无理由退款。
超过 7 天后,仅支持质量问题申诉。
## 发票规则
用户可以在订单完成后申请电子发票。电子发票开具后不可修改抬头。

第一步,先按标题切:

块 1:
标题路径:退款规则
用户可以在订单完成后 7 天内申请退款。
商品拆封后如影响二次销售,则不支持无理由退款。
超过 7 天后,仅支持质量问题申诉。
块 2:
标题路径:发票规则
用户可以在订单完成后申请电子发票。电子发票开具后不可修改抬头。

如果“退款规则”太长,再在标题内部按段落切:

块 1:
标题路径:退款规则
用户可以在订单完成后 7 天内申请退款。
块 2:
标题路径:退款规则
商品拆封后如影响二次销售,则不支持无理由退款。
超过 7 天后,仅支持质量问题申诉。

适用场景#

  • Markdown 文档。
  • 产品说明。
  • 技术手册。
  • 课程讲义。
  • 知识库文章。

优点#

  • 比固定长度更尊重结构。
  • 比纯语义分块成本低。
  • 大多数知识库可以直接使用。

缺点#

  • 对表格、代码、公式等复杂结构效果一般。
  • 依赖分隔符质量,文档格式混乱时效果会下降。

记忆方法#

递归分块像逐层拆盒子:先拆大盒子,太大了再拆里面的小盒子。


2. 结构感知分块#

结构感知分块的核心是:文档本身已经告诉你应该怎么切,不要无视它的结构。

标题、列表、表格、代码块、对话轮次,都是天然边界。


2.1 结构化文本分块#

方法说明#

对 Markdown、HTML、产品手册、技术文档等强结构文本,优先按标题层级切分,并把标题路径写入 metadata。

案例#

原文:

# 用户管理
## 批量导入
### 文件要求
- 支持 CSV 格式
- 文件大小不超过 20MB
- 单次最多导入 5000 行
### 字段要求
- 手机号必填
- 姓名选填
- 部门选填

切分结果:

块 1:
标题路径:用户管理 > 批量导入 > 文件要求
块类型:列表
内容:
支持 CSV 格式
文件大小不超过 20MB
单次最多导入 5000 行
块 2:
标题路径:用户管理 > 批量导入 > 字段要求
块类型:列表
内容:
手机号必填
姓名选填
部门选填

metadata 示例:

{
"source": "用户管理手册.md",
"title_path": "用户管理 > 批量导入 > 文件要求",
"chunk_type": "list",
"section_level": 3
}

为什么这样切#

用户问“批量导入文件最大多大”时,系统不仅能召回“文件大小不超过 20MB”,还能知道它属于“用户管理 > 批量导入 > 文件要求”。

这能减少歧义,也方便答案引用来源。

适用场景#

  • 技术文档。
  • 帮助中心。
  • 产品手册。
  • 白皮书。
  • Markdown / HTML 文档。

记忆方法#

结构化分块不是切文字,而是保留文档的骨架。


2.2 表格分块#

方法说明#

表格不能随便按字符切,因为表格的意义来自“表头 + 行 + 单元格关系”。

表格分块的原则:

  • 表头不能丢。
  • 行数据要带字段名。
  • 小表可以整表保留。
  • 大表可以按行或按业务分组切,但每块都要重复表头。

案例#

原文:

| 套餐 | 价格 | 适用人群 | 权益 |
| --- | --- | --- | --- |
| 基础版 | 99 元/月 | 个人用户 | 100 次调用 |
| 专业版 | 299 元/月 | 小团队 | 1000 次调用 |
| 企业版 | 定制报价 | 企业客户 | 私有化部署、专属支持 |

错误切法:

块 1:
基础版 | 99 元/月 | 个人用户 | 100 次调用
块 2:
企业版 | 定制报价 | 企业客户 | 私有化部署、专属支持

问题:模型可能不知道“私有化部署、专属支持”属于权益字段。

正确切法:

块 1:
标题路径:价格方案 > 套餐对比
块类型:表格
套餐:基础版
价格:99 元/月
适用人群:个人用户
权益:100 次调用
套餐:专业版
价格:299 元/月
适用人群:小团队
权益:1000 次调用
套餐:企业版
价格:定制报价
适用人群:企业客户
权益:私有化部署、专属支持

如果表格很大,可以按行切:

块 1:
标题路径:价格方案 > 套餐对比
套餐:企业版
价格:定制报价
适用人群:企业客户
权益:私有化部署、专属支持

适用场景#

  • 价格表。
  • 参数表。
  • 权限矩阵。
  • API 字段说明。
  • 竞品对比表。

记忆方法#

表格分块时,表头就是上下文。表头丢了,值就失去意义。


2.3 代码块分块#

方法说明#

代码块、JSON 示例、SQL、配置文件不能从中间切断。

代码分块的原则:

  • 一个完整函数尽量作为一个块。
  • 一个完整 API 示例尽量作为一个块。
  • 代码说明、参数说明、错误码说明要和代码上下文绑定。

案例#

原文:

## 创建订单接口
请求示例:
```json
{
"product_id": "P001",
"quantity": 2,
"address_id": "A123"
}
```
如果库存不足,接口返回 409,错误码为 OUT_OF_STOCK。

错误切法:

块 1:
{
"product_id": "P001",
块 2:
"quantity": 2,
"address_id": "A123"
}

正确切法:

块 1:
标题路径:订单接口 > 创建订单接口
块类型:api_example
请求示例:
{
"product_id": "P001",
"quantity": 2,
"address_id": "A123"
}
如果库存不足,接口返回 409,错误码为 OUT_OF_STOCK。

适用场景#

  • API 文档。
  • SDK 文档。
  • 配置说明。
  • SQL 查询示例。
  • YAML / JSON 配置。

记忆方法#

代码块不能切坏,示例和解释最好绑在一起。


2.4 对话式分块#

方法说明#

对话内容的意义往往来自上下几轮,而不是某一句话本身。

因此,对话式分块应该按:

  • 说话人。
  • 轮次。
  • 话题窗口。
  • 前后 1-2 轮重叠。

案例#

原文:

张三:最近注册转化率下降了。
李四:我查了一下,主要卡在短信验证码。
王五:验证码失败率比上周高了 12%。
张三:那先切换备用通道。
李四:同时增加邮箱注册入口。
张三:这个方案优先级 P0。

按话题切:

块 1:
话题:注册转化率下降
张三:最近注册转化率下降了。
李四:我查了一下,主要卡在短信验证码。
王五:验证码失败率比上周高了 12%。
张三:那先切换备用通道。
李四:同时增加邮箱注册入口。
张三:这个方案优先级 P0。

如果对话很长,可以轮次重叠:

块 1:
张三:最近注册转化率下降了。
李四:我查了一下,主要卡在短信验证码。
王五:验证码失败率比上周高了 12%。
块 2:
王五:验证码失败率比上周高了 12%。
张三:那先切换备用通道。
李四:同时增加邮箱注册入口。
张三:这个方案优先级 P0。

适用场景#

  • 客服对话。
  • 销售沟通。
  • 用户访谈。
  • 会议纪要。
  • 语音转写记录。

检索优化#

对话内容召回后,建议做“邻接扩展”:

命中第 8 轮时,同时取第 6-10 轮。

记忆方法#

对话分块要保留前因后果,因为一句话经常要靠上下文才看得懂。


3. 语义与主题分块#

语义与主题分块不只看物理结构,而是判断内容的“意思”有没有发生变化。


3.1 语义分块#

方法说明#

语义分块会计算相邻句子或段落的语义相似度。当语义相似度明显下降时,说明可能发生了话题切换,可以在这里切分。

流程:

  1. 中文分句。
  2. 使用 embedding 模型编码句子。
  3. 计算相邻句子的相似度。
  4. 找到语义突变点。
  5. 结合最小和最大块长约束。

案例#

原文:

向量数据库负责存储文本向量,并根据相似度进行召回。常见的向量数据库包括 Milvus、FAISS 和 pgvector。选择向量数据库时,需要考虑数据规模、查询性能和运维成本。
重排模型用于对初步召回结果进行二次排序。它通常比向量召回更精细,但计算成本更高。常见做法是先召回 50 条,再重排出前 5 条。

语义判断:

前半部分主题:向量数据库
后半部分主题:重排模型
两段之间语义相似度下降,适合切分。

切分结果:

块 1:
主题:向量数据库
向量数据库负责存储文本向量,并根据相似度进行召回。
常见的向量数据库包括 Milvus、FAISS 和 pgvector。
选择向量数据库时,需要考虑数据规模、查询性能和运维成本。
块 2:
主题:重排模型
重排模型用于对初步召回结果进行二次排序。
它通常比向量召回更精细,但计算成本更高。
常见做法是先召回 50 条,再重排出前 5 条。

适用场景#

  • 论文。
  • 白皮书。
  • 技术论证文档。
  • 长篇课程材料。
  • 主题切换明显但标题不清晰的文章。

优点#

  • 块内语义更集中。
  • 适合高精度检索。
  • 能处理结构不明显但语义清晰的长文。

缺点#

  • 计算成本更高。
  • 对短文档收益有限。
  • 需要 embedding 模型质量较好。

记忆方法#

语义分块看的是“意思变没变”,不是“字数够没够”。


3.2 主题分块#

方法说明#

主题分块会先识别文档里的几个大主题,再按主题归类或切分。

它更像整理读书笔记:把散落在不同地方的同类观点放在一起。

案例#

原文内容比较散:

用户画像:核心用户是 25-35 岁的一线城市白领。
市场规模:在线教育市场仍保持增长,但增速放缓。
用户画像:这类用户愿意为效率工具付费。
竞争格局:头部平台占据主要流量,中小平台依赖垂直内容突围。
市场规模:职业教育和 AI 工具培训是增长较快的细分方向。
竞争格局:新进入者需要避开综合平台的正面竞争。

主题分块结果:

块 1:
主题:用户画像
核心用户是 25-35 岁的一线城市白领。
这类用户愿意为效率工具付费。
块 2:
主题:市场规模
在线教育市场仍保持增长,但增速放缓。
职业教育和 AI 工具培训是增长较快的细分方向。
块 3:
主题:竞争格局
头部平台占据主要流量,中小平台依赖垂直内容突围。
新进入者需要避开综合平台的正面竞争。

适用场景#

  • 行业报告。
  • 竞品分析。
  • 市场研究。
  • 长篇调研材料。
  • 多主题综述。

注意事项#

主题分块可能改变原文顺序,因此不适合:

  • 合同。
  • 法规。
  • 操作流程。
  • API 文档。
  • 强依赖先后顺序的内容。

记忆方法#

主题分块像整理资料夹:相同主题放一起,但要小心打乱原文顺序。


4. 高级分块策略#

高级策略通常不是单纯“怎么切”,而是把“切分、索引、召回、上下文组装”一起设计。


4.1 小-大分块#

方法说明#

小-大分块的核心思想是:

  • 用小块做检索,因为小块更精准。
  • 用大块做回答,因为大块上下文更完整。

案例#

原文段落:

批量导入用户支持 CSV 文件。文件大小不得超过 20MB。单次最多导入 5000 行。字段必须包含手机号。导入后系统会自动校验手机号格式,错误数据可在失败列表中下载。

建立小块索引:

小块 1:批量导入用户支持 CSV 文件。
小块 2:文件大小不得超过 20MB。
小块 3:单次最多导入 5000 行。
小块 4:字段必须包含手机号。
小块 5:错误数据可在失败列表中下载。

同时保留大块:

大块 A:
批量导入用户支持 CSV 文件。文件大小不得超过 20MB。单次最多导入 5000 行。字段必须包含手机号。导入后系统会自动校验手机号格式,错误数据可在失败列表中下载。

用户问题:

导入失败的数据在哪里下载?

检索过程:

1. 小块 5 被命中。
2. 系统找到小块 5 所属的大块 A。
3. 最终把大块 A 提供给大模型。

这样既能精准命中“失败列表”,又能让模型知道这是“批量导入用户”的上下文。

适用场景#

  • 企业知识库。
  • 客服问答。
  • 政策问答。
  • 需要句级证据和段落解释的系统。

记忆方法#

小块负责找得准,大块负责答得全。


4.2 父子段分块#

方法说明#

父子段分块会显式维护父块和子块的映射关系。

常见设计:

  • 父块:段落、章节、完整规则。
  • 子块:句子、短段、具体条款。

检索时命中子块,回答时回到父块。

案例#

原文:

会员购买后 24 小时内,若未使用任何会员权益,可申请全额退款。若已使用专属优惠券、免费提现次数或专属客服权益,则不支持退款。连续包月会员可在下个扣费周期前取消续费。

父块:

父块 P1:
标题:会员退款规则
会员购买后 24 小时内,若未使用任何会员权益,可申请全额退款。
若已使用专属优惠券、免费提现次数或专属客服权益,则不支持退款。
连续包月会员可在下个扣费周期前取消续费。

子块:

子块 C1:
会员购买后 24 小时内,若未使用任何会员权益,可申请全额退款。
parent_id: P1
子块 C2:
若已使用专属优惠券、免费提现次数或专属客服权益,则不支持退款。
parent_id: P1
子块 C3:
连续包月会员可在下个扣费周期前取消续费。
parent_id: P1

用户问题:

用了优惠券还能退会员吗?

检索过程:

1. 命中子块 C2。
2. 通过 parent_id 找回父块 P1。
3. 用 P1 作为最终回答上下文。

与小-大分块的区别#

小-大分块更强调检索流程:

小块召回 > 大块回答

父子分块更强调数据建模:

父块和子块之间有明确映射关系

两者常常一起使用。

适用场景#

  • 制度文档。
  • 产品规则。
  • 课程知识库。
  • 帮助中心。
  • 需要来源回链的问答系统。

记忆方法#

子块像索引卡片,父块像原文段落;先用卡片找,再回原文读。


4.3 Agent-Based Chunking#

方法说明#

Agent-Based Chunking 是让 LLM 或小型 Agent 根据规则动态判断分块边界。

它适合处理复杂、混合、格式不稳定的文档。

常见规则:

  • 不在代码块中间切。
  • 不在表格中间切。
  • 不在公式中间切。
  • 保持标题链路完整。
  • 条件、结论、例外尽量放在一起。
  • 输出结构化 JSON,包含起止位置、标题路径、切分理由。

案例#

原文:

## 订单接口
下面是创建订单示例:
```json
{
"product_id": "P001",
"quantity": 2,
"address_id": "A123"
}
```
注意:不要在库存不足时重复提交订单。库存不足会返回 409。

普通分块可能把 JSON 切坏:

块 1:
{
"product_id": "P001",
块 2:
"quantity": 2,
"address_id": "A123"
}

Agent 分块输出:

[
{
"title_path": "订单接口",
"chunk_type": "api_example",
"content": "下面是创建订单示例:\n```json\n{\n \"product_id\": \"P001\",\n \"quantity\": 2,\n \"address_id\": \"A123\"\n}\n```\n注意:不要在库存不足时重复提交订单。库存不足会返回 409。",
"reason": "代码块需要保持完整,错误码说明依赖订单接口上下文。"
}
]

适用场景#

  • 代码、表格、公式、正文混合文档。
  • PDF 解析后结构混乱的文档。
  • 高价值知识库。
  • 金融、医疗、法律等高准确率场景。

注意事项#

Agent 分块成本较高,需要护栏:

  • 限制输出格式。
  • 设置最大块长。
  • 设置失败回退策略。
  • 对切分结果做自动校验。

记忆方法#

Agent 分块像请一个助教先读懂文档,再告诉你哪里该切。


5. 混合分块#

方法说明#

真实生产文档很少只有一种形态。一个知识库里可能同时有:

  • 标题。
  • 正文。
  • FAQ。
  • 表格。
  • 代码。
  • API 示例。
  • 客服对话。
  • 会议纪要。

因此,最稳健的方式通常是混合分块。

推荐流程#

1. 粗切:先按结构切,比如标题、段落、代码块、表格。
2. 细化:不同内容使用不同策略。
3. 索引:小块建索引,大块做上下文存储。
4. 检索:小块召回,父块聚合,局部上下文组装。

案例#

一篇产品手册包含:

标题:用户管理
正文:批量导入功能说明
表格:字段说明表
FAQ:导入失败怎么办
API:创建用户接口

混合分块结果:

块 1:
类型:正文
标题路径:用户管理 > 批量导入
内容:批量导入的功能说明。
策略:结构化分块 + 递归分块
块 2:
类型:表格
标题路径:用户管理 > 字段说明
内容:字段名、是否必填、说明。
策略:表格分块,保留表头。
块 3:
类型:FAQ
标题路径:用户管理 > 常见问题
Q:导入失败怎么办?
A:可在失败列表下载错误数据。
策略:一问一答作为一块。
块 4:
类型:API
标题路径:开放接口 > 创建用户
内容:请求参数、示例代码、错误码。
策略:接口级分块,代码块保持完整。

质量-成本档位#

档位策略适用场景
Fast结构分块 + 递归分块快速上线、资源有限、内部试点
Balanced结构分块 + 递归分块 + 异常块语义分块 + 小-大检索大多数生产环境
QualityBalanced + Agent 精修 + 强 rerank + 人工抽检高精度、高风险场景

记忆方法#

混合分块的核心是:见什么材料,用什么刀法。


四、不同内容类型的切分口诀#

1. 规则类文档#

规则类内容要把“条件、结论、例外”放在一起。

如果、若、当、除非、超过、仅支持、不支持

这些词出现时,不要轻易切断。

示例:

若商品已拆封且影响二次销售,则不支持无理由退款。

这里“若”是条件,“不支持退款”是结论,必须放在同一块。

2. FAQ#

FAQ 按“一问一答”切。

Q:会员到期后优惠券还能用吗?
A:已领取但未使用的优惠券仍可在有效期内使用。

问题和答案不能拆开。

3. 表格#

表格必须保留表头。

套餐:企业版
价格:定制报价
权益:私有化部署、专属支持

不要只保留:

企业版 | 定制报价 | 私有化部署、专属支持

4. API 文档#

API 文档按接口切。

一个接口的:

  • 功能说明。
  • 请求参数。
  • 请求示例。
  • 返回结果。
  • 错误码。

尽量绑定在同一上下文中。

5. 对话内容#

对话按话题窗口切。

不要按字数切,要保留:

  • 原因。
  • 讨论。
  • 结论。
  • 负责人。
  • 时间点。

6. 长篇报告#

长篇报告先按目录切,再按段落或语义切。

不要让两个大主题混在同一个块里。


五、Metadata 设计建议#

分块不是只保存 content,还要保存 metadata。

推荐字段:

{
"doc_id": "doc_001",
"source": "用户管理手册.md",
"title_path": "用户管理 > 批量导入 > 文件要求",
"chunk_id": "chunk_001",
"parent_id": "section_001",
"chunk_type": "list",
"start_offset": 1280,
"end_offset": 1680,
"created_at": "2026-08-17"
}

常见 metadata 用途:

  • title_path:让模型知道内容属于哪个章节。
  • chunk_type:区分正文、表格、代码、FAQ、对话。
  • parent_id:支持父子分块和上下文回溯。
  • start_offset / end_offset:支持原文定位和引用。
  • source:支持答案溯源。

没有 metadata 的分块,就像一张没有出处的纸条。它可能有用,但很难被信任。


六、评估与调优方法#

1. 固定其他变量,只调整分块#

评估分块效果时,不要同时改 embedding、rerank、Prompt 和模型。

建议先固定:

  • embedding 模型。
  • 向量库。
  • 检索 top_k。
  • rerank 策略。
  • Prompt。

然后只调整:

  • chunk_size
  • chunk_overlap
  • 分隔符。
  • 是否启用结构分块。
  • 是否启用父子分块。

2. 看三个指标#

Recall@k#

用户问题的正确证据是否出现在前 k 个检索结果里。

nDCG#

正确证据是否排在更靠前的位置。

Faithfulness#

最终答案是否忠实于检索到的原文。

3. 做人工抽检#

抽检时重点看:

  • 条件和结论有没有被拆开。
  • 标题路径是否正确。
  • 表格是否丢表头。
  • 代码块是否被切坏。
  • FAQ 是否把问题和答案拆开。
  • 对话是否缺前因后果。
  • 召回块是否过大或过小。

七、最终建议#

快速上线方案#

结构化分块 + 递归字符分块 + 10%-20% overlap

适合:

  • 初期验证。
  • 内部知识库。
  • 文档结构较清晰的场景。

生产推荐方案#

结构化分块 + 递归字符分块 + 表格/代码特殊处理 + 小-大检索 + metadata

适合:

  • 企业知识库。
  • 帮助中心。
  • 产品文档。
  • 课程知识库。

高精度方案#

生产推荐方案 + 语义分块 + Agent 精修 + 强 rerank + 人工评估集

适合:

  • 法律。
  • 医疗。
  • 金融。
  • 高价值企业知识库。
  • 对答案准确率要求极高的场景。

八、总表:每种分块方法怎么选#

方法核心做法适合场景最大风险记忆句
固定长度分块按字数或 token 硬切快速 baseline、弱结构文本切断语义用尺子切文章
句子分块先分句,再聚合FAQ、新闻、法规块可能过短不切断一句话
递归字符分块标题、段落、句子逐级切大多数知识库表格代码处理弱逐层拆盒子
结构化分块按标题、列表、表格等结构切Markdown、HTML、手册依赖原文结构质量保留文档骨架
表格分块保留表头,按整表或行切参数表、价格表、权限表表头丢失表头就是上下文
代码分块保持代码块完整API、SDK、配置文档代码被切坏示例和解释绑一起
对话式分块按话题和轮次切会议、客服、访谈缺前因后果按话题窗口切
语义分块按语义突变点切论文、白皮书、长文成本高看意思变没变
主题分块按主题归类市场报告、竞品分析打乱原文顺序同类观点放一起
小-大分块小块检索,大块回答高质量问答数据结构复杂小块找准,大块答全
父子分块子块命中,父块补上下文可追溯知识库parent 映射维护成本先找卡片,再读原文
Agent 分块LLM 判断边界复杂混合文档成本高、需护栏助教读懂后再切
混合分块不同内容用不同策略生产级 RAG实现复杂见什么材料,用什么刀法

九、一句话升华#

RAG 分块不是简单的文本预处理,而是在设计知识的颗粒度。

颗粒太小,答案会碎;颗粒太大,检索会糊;颗粒有结构,答案才稳定;颗粒可追溯,系统才可信。

真正好的分块策略,不是问“每块多少字”,而是问:

用户提问时,哪一段内容刚好足够回答这个问题,并且不会引入太多噪声?

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

RAG分块策略
https://www.shanfengpm.com/posts/2026-04-12-rag-chunking-strategy/
作者
山风
发布于
2026-04-12
许可协议
CC BY-NC-SA 4.0
本文首发于「山风blog」,作者:山风(余涛)。欢迎转发、分享本文链接, 但禁止任何形式的未授权转载、摘编、改写或商业使用
推荐文章RAG
Profile Image of the Author
山风
12年产品经验,持续记录产品思考、业务设计、数据分析和团队管理实践。
站点统计