RAG分块策略
RAG 的分块策略详解
一、背景与重要性
在 RAG(Retrieval-Augmented Generation,检索增强生成)系统中,文档分块质量直接决定问答系统能不能答准、答全、答得有依据。
可以把 RAG 想象成一个开卷考试系统:
- 先把教材切成很多知识卡片。
- 用户提问时,系统先找出最相关的几张卡片。
- 大模型再根据这些卡片组织答案。
如果卡片切得不好,后面的检索、重排、Prompt、模型能力都会被拖累。
常见问题包括:
- 上下文缺失:只召回了结论,没召回条件。
- 事实性错误:模型拿到片面的证据后误判。
- 拼接不连贯:多个块之间缺少过渡关系。
- 错误引用:答案引用了不完整或不对应的原文。
- 幻觉增加:检索内容不足,模型只能自己补。
最常见的误区是:按固定长度硬切文本。比如每 500 字切一块,前后重叠 100 字。这样实现简单,但容易把标题、段落、列表、表格、代码、问答、条件和结论切断。
高质量分块应该满足三个要求:
- 贴合自然语义和文档结构边界。
- 设置适度重叠,保证上下文连续。
- 保留元数据,比如标题路径、来源位置、块类型。
结论:分块质量几乎决定了 RAG 系统的性能上限。分块不是把文章切短,而是把知识切成“用户提问时刚好能用”的最小完整单元。
二、为什么需要分块?
1. 模型上下文窗口有限
大模型不能无限制读取所有文档。即使模型上下文窗口很大,把整篇文档都塞进去也会带来成本、延迟和噪声问题。
因此,需要先把文档切成片段,再按用户问题检索相关片段。
2. 提升检索信噪比
块太大:
- 好处:上下文完整。
- 问题:无关内容太多,关键信息被稀释。
块太小:
- 好处:命中更精准。
- 问题:上下文不足,模型不知道这句话的条件、范围和出处。
例如原文:
用户可在订单完成后 7 天内申请无理由退款。若商品已拆封且影响二次销售,则不支持无理由退款。超过 7 天后,仅支持质量问题申诉。如果切得太小:
块 1:若商品已拆封且影响二次销售,则不支持无理由退款。用户问“什么情况下不能退款”时,这个块能回答一部分,但不知道这是“订单完成后 7 天内”的规则,也不知道超过 7 天后的处理方式。
如果切得太大,把退款、发票、物流、会员规则都放在一起,检索结果又会混入大量无关信息。
3. 保障语义连续性
很多知识不是单句成立的,而是由“条件 + 结论 + 例外 + 操作方式”共同构成。
例如:
员工连续旷工三日,公司有权解除劳动合同。因不可抗力或突发疾病导致无法到岗,并能提供有效证明的,不视为旷工。如果只召回第一句,答案会偏严厉;如果只召回第二句,答案又缺少主规则。
理想目标:在“上下文完整性”和“信息密度”之间取得动态平衡。
三、分块策略详解
1. 基础分块
基础分块适合快速搭建 RAG 系统,也适合做 baseline。它们的优点是简单、稳定、成本低;缺点是对复杂结构的理解能力有限。
1.1 固定长度分块
方法说明
固定长度分块是最简单的方式:按固定字符数或 token 数直接切割文本。
例如:
chunk_size = 300chunk_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 语义分块
方法说明
语义分块会计算相邻句子或段落的语义相似度。当语义相似度明显下降时,说明可能发生了话题切换,可以在这里切分。
流程:
- 中文分句。
- 使用 embedding 模型编码句子。
- 计算相邻句子的相似度。
- 找到语义突变点。
- 结合最小和最大块长约束。
案例
原文:
向量数据库负责存储文本向量,并根据相似度进行召回。常见的向量数据库包括 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 | 结构分块 + 递归分块 + 异常块语义分块 + 小-大检索 | 大多数生产环境 |
| Quality | Balanced + 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 分块不是简单的文本预处理,而是在设计知识的颗粒度。
颗粒太小,答案会碎;颗粒太大,检索会糊;颗粒有结构,答案才稳定;颗粒可追溯,系统才可信。
真正好的分块策略,不是问“每块多少字”,而是问:
用户提问时,哪一段内容刚好足够回答这个问题,并且不会引入太多噪声?
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!












