RAG 文档处理与 Chunk 工程

方向定位：聚焦 RAG 链路最上游的"文档→Chunk→向量"环节——决定 LLM 究竟能看到什么。包括 Chunk 切分的工程演进（三代方案、Recall 0.67→0.91 的实战路径）、五种 Chunking 策略选型、特殊元素专项处理（表格/列表/图片/跨页）、Overlap 量化实验、Chunk 元数据 6 字段设计、语义完整性 should_merge 检查、Semantic/Late/动态 Chunk 三个前沿方向。不研究检索阶段的优化（→ RAG 检索质量与排查）、不涉及服务化（→ RAG 服务化与企业级工程）、不讨论 RAG 整体动机（→ RAG 基础与评估体系）。当前版本：v0.2 首次构建：2026-05-15 最近更新：2026-05-19 文件名日期同步：2026-05-15 来源数：3 篇（04, 19, 23 部分）

方向定位

RAG 文档处理与 Chunk 工程研究的核心问题是："文档怎么切、表格怎么处理、Overlap 多少合适——决定 LLM 看到的是清晰段落还是信息残缺的碎片"。它的边界包括：

包含：Chunk 工程的根本地位（地基论）、五种 Chunking 策略选型、三代方案演进（V1→V3）、文档结构识别（多策略融合 + XGBoost 层级分类器）、超长章节递归细切、表格专项处理、列表前导句合并、Overlap 量化实验、Chunk 元数据 6 字段设计、语义完整性 should_merge、Semantic/Late/动态 Chunk 前沿方向、图片与跨页处理
不包含：RAG 为何需要切分的入门动机与向量库三元结构入门定义（→《RAG 基础与评估体系》概念 4）、Query 改写与 HyDE（→《RAG 检索质量与排查》）、Rerank 延迟优化（→ 同上）、QPS/限流/缓存（→《RAG 服务化与企业级工程》）、向量库选型与 ES 存储架构（→ 同上）
与相邻方向的区别：本方向只研究"入库阶段"，不研究"检索阶段"或"服务化阶段"

切分是 RAG 系统最被低估的地基——仅改变切分方式（不换 Embedding、不调检索），Recall@5 可从 0.67 提升到 0.91。先把地基打实，再去调上层。

知识图谱

地基论
- 切分 24 个点 vs 换 Embedding 4 个点
- chunk 切错了，所有上层优化都是地基不稳上加砖
- chunk_size 不是通用参数，必须和文档类型挂钩
五种 Chunking 策略
- 固定大小 + Overlap：兜底
- 语义边界切割：标题/段落/句子分级降级
- 标题层级切割：Markdown/HTML metadata 带路径
- 代码按函数切割：AST 解析
- 父子切割：小块定位 + 大块阅读
三代演进
- V1：固定 512+overlap 50，Recall 0.67
- V2：句子边界，Recall 0.74
- V3：语义感知（层级+表格+列表+智能overlap），Recall 0.91
V3 四大改进
- 文档结构识别（正则+样式+XGBoost）
- 超长章节递归细切
- 表格专项处理（小整保留/大切行复制表头）
- 列表项合并前导句
Chunk 元数据 6 字段
- section_path / is_key_clause / prev-next_chunk_id / chunk_type / page_range
Overlap 量化
- 0→100→300 token 召回率与存储增量
- 100 token 是性价比拐点
- 智能 overlap（句子边界）：0.89→0.91
语义完整性 should_merge
- 三种不该断开场景
- 错误截断 23%→4%
前沿三方向
- Semantic Chunking：相邻句子相似度
- Late Chunking：先编码全文再切
- 动态 Chunk Size：按语义密度调整
特殊元素
- 图片：流程图/数据图表/装饰图三策略
- 跨页段落：检测标题模式合并
- 代码：AST 按函数切
- 表格：Markdown 整保留

核心概念

概念 1：地基论——切分是 RAG 最被低估的地基

来自吴师兄 RAG 切分实战分享。

对比实验数据：

不换 Embedding、不调检索策略，仅改变切分方式：Recall@5 从 0.67 → 0.91（+24 个百分点）
换最好的 Embedding 模型：Recall@5 从 0.67 → 0.71（+4 个百分点）

结论：先把地基打实，再调上层。很多团队在切分残缺的情况下反复调 Embedding，本质上是在错误的层级做优化。

切分不只是"设置一下 chunk_size"，它是一个需要分析文档特点、设计处理策略、用量化指标验证的工程模块。

chunk_size 不是通用参数：保险条款每句平均 40-50 字（通用文档 20-30 字），512 token 经常只有半个段落。改到 1024（关键条款 1536）后召回率提升 7 个百分点——必须和文档类型挂钩。

概念 2：粒度博弈——精度与完整度

切分的根本矛盾：

粒度	问题	后果
Chunk 太大	语义笼统、检索噪音高	超模型输入限制，主题分散
Chunk 太小	语义不完整、上下文丢失	LLM 无法理解碎片

没有全局最优解，只有针对文档类型的最优策略选择。500~1000 token 是起点，更关键的是按文档类型选对策略。

前置认知：为什么必须切分而不能"整篇存"，以及向量库三元结构（向量 / 原文 / metadata）的入门定义，已在《RAG 基础与评估体系》概念 4 给出。本方向直接基于"必须切"的前提，研究"怎么切"。

方法论与框架

框架 1：五种 Chunking 策略选型表

来自京东面试官（19 号笔记）和吴师兄实战（04 号笔记）综合：

策略	适用文档类型	优点	缺点
固定大小 + Overlap	纯文本、无明显结构	实现简单、chunk 大小可控	可能在语义中间截断
语义边界切割	段落分明的文章	语义完整，召回质量好	实现稍复杂，chunk 大小不均
标题层级切割	Markdown、HTML 文档	天然语义独立，带结构 metadata	依赖文档有清晰的标题结构
代码按函数切割	代码文件	保留代码逻辑完整性	需要 AST 解析，限定语言
父子切割	各类文档（追求高质量）	检索精准 + 上下文完整两全	存储量翻倍，索引构建复杂

工程实践优先级：快速起步用固定大小 + 重叠；有结构化文档就切换语义边界；对质量有明确要求时引入父子切割。

框架 2：三代切分方案演进路径

版本	方法	Recall@5	核心问题
V1	固定长度 512 token，overlap 50	0.67	句子中间截断，章节标题/结论句丢失
V2	句子级边界切分	0.74	不理解文档层级，表格/列表未特殊处理
V3	语义感知切分（层级+表格+列表+智能overlap）	0.91	-

框架 3：V3 四大核心改进

改进 1：文档结构识别（多策略融合）

策略 1：正则模式匹配中文文档三级标题体系（H1：第 X 章/条；H2：X.X/（一）；H3：（1）/a)）
策略 2：利用解析模块输出的样式信息（font_size, bold, indent_level）
策略 3：XGBoost 轻量级层级分类器——在 500 份标注数据上训练，特征为编号类型/字体大小/是否加粗/缩进/位置，层级识别准确率 94%（纯规则仅 77%，因 23% 文档编号不规范）
基本原则：同章节内容尽量放同一 chunk，跨章节绝不合并

改进 2：超长章节递归细切

普通章节 max_size = 1024，关键条款（责任/免责）= 1536
先按子小节边界切，没有子小节时按句子边界切

改进 3：表格专项处理

小表格（≤300 token）：整体不切
大表格：按行切分，每个 chunk 复制表头
效果：表格类问题正确率从 43% → 78%

改进 4：列表项合并前导句

问题："（1）核辐射"单独成 chunk 时，向量里没有"不在承保范围"的语义，LLM 会误判为承保
方案：识别列表结构，把前导句（如"以下情况不在承保范围"）合并到每个 chunk
效果：否定性查询召回率从 0.58 → 0.83

框架 4：Overlap 量化实验

Overlap	Recall@5	存储增加
0 token	0.81	基准
50 token	0.86	+5%
100 token	0.89	+10%
200 token	0.90	+20%
300 token	0.90	+30%

100 token 是性价比最优点：召回 +10%，存储仅 +10%，再往上收益递减
智能 overlap 优化：在 overlap 区域向后扫描到句子结尾再截断，避免 87% 的句子截断问题，召回 0.89 → 0.91

框架 5：Chunk 元数据 6 字段设计

字段	用途
`section_path`	答案溯源："根据第3条 > 3.2 责任免除 > (2)..."
`is_key_clause`	检索加权（关键条款 1.5x），关键词+标题判断，准确率 94%
`prev/next_chunk_id`	语义不完整时自动拉取相邻 chunk 补全上下文
`chunk_type`	text / table / list，用于差异化处理
`page_range`	来源页码，用于定位原文

元数据字段进一步在检索阶段如何用于过滤、加权和静默过滤排查，见《RAG 检索质量与排查》第 1 层文档处理排查与第 3 层检索召回排查；在企业级权限控制中如何承载租户/部门/密级，见《RAG 服务化与企业级工程》四种权限元数据模型。

框架 6：语义完整性 should_merge 检查

切分后对相邻 chunk 做一轮检查，三种"不该断开"的场景自动合并：

python

def should_merge(chunk1, chunk2):
    # 场景1：chunk1 以冒号结尾 → 后面大概率是列表
    if chunk1.strip().endswith((':', '：', ';', '；')):
        return True
    # 场景2：chunk2 是列表项编号开头
    if re.match(r'^[（(]\d+[）)]|^[①②③④⑤]|^[a-z]\.', chunk2.strip()):
        return True
    # 场景3：chunk2 以转折词开头（解决"核辐射事故"）
    if chunk2.strip().startswith(('但', '然而', '除外', '不包括')):
        return True
    return False

效果：语义边界处错误截断从 23% 降到 4%。这正是解决"核辐射事故"的关键——"本保险承保……"后面的"但以下情况除外"会被转折词检测到并自动合并。

框架 7：特殊元素处理策略

图片处理：

流程图/示意图：用多模态模型生成文本描述，描述作为 chunk 入库
数据图表：用 chart-to-text 模型提取结构化数据
纯装饰图片：直接跳过

跨页段落处理：

如果下一页开头不是新章节标题（未检测到标题模式），则与前一页末尾合并为同一段落

代码文件：以函数或类为单位切割（AST 解析），中间截断则参数定义和返回值分离，单独 chunk 毫无意义

表格：整块保留转 Markdown，不能按行截断——每一行依赖表头才有意义

框架 8：父子切割（Parent-Child Chunking）

核心思路：检索时用小块（精准定位），返回时用大块（上下文完整）
存储：小 chunk（约 200 token，向量检索）+ 大 chunk（约 1000 token，通过 ID 关联，供 LLM 阅读）
检索流程：小 chunk 命中 → 根据 ID 取出关联的大 chunk → 大 chunk 塞进 prompt
类比：用目录卡（小 chunk）定位章节，拿出来读的是完整那一章（大 chunk）
代价：存储量翻倍，索引构建更复杂

案例库

案例 1：保险文档 5000 份切分优化（吴师兄 RAG 切分实战）

场景规模：5000 份保险文档，平均 80 页/份
关键发现：换最好的 Embedding 模型仅 +4%（0.67→0.71），优化切分 +24%（0.67→0.91）
表格 badcase：表头丢失导致 LLM 正确率仅 43%，加表头复制后提升到 78%
列表 badcase：孤立列表项导致否定性查询召回率 0.58，合并前导句后 0.83
V2 分维度短板：表格类 0.51，文本类 0.82——直接指导 V3 优先解决表格
测试集成本：2 人 1 周标注 2000 QA 对，后续每次评估 10 分钟（评估方法论详见《RAG 基础与评估体系》框架 2）

案例 2：512 token 通用起点（阿里飞猪面试题）

最优参数：512 token，overlap 64 token

为什么是 512（三个维度）：

维度	过小（100 token）	512 token	过大（2000 token）
检索精度	切断完整语句，缺上下文	最优	主题分散，精度下降
语义完整性	模型理解不了	段落/句子级完整	包含多个主题
Token 预算	浪费窗口	5 个 chunk + prompt < 4000 token	挤压生成空间

关键认知：chunk 的单位是 token，不是字节。1MB 文本 ≈ 50 万字，那是整本书，不是 chunk。

递归切分实操：① 先按段落切；② 段落超过 512 token，再按句子切；③ 保证每个 chunk 是完整段落或完整句子，不从中间劈开。

案例 3："核辐射事故" badcase 全链路

现象：用户问"核辐射事故是否承保"，RAG 答"承保"——大错
根因：列表项"（1）核辐射"被单独成 chunk，向量里没有"不在承保范围"语义
V3 解法：
1. 列表识别：把前导句"以下情况不在承保范围"合并到每个列表项 chunk
2. should_merge 转折词检测："但以下情况除外"自动与前文合并
效果：否定性查询召回率 0.58 → 0.83，整体错误截断 23% → 4%

前沿方向

方向	原理	当前状态（2026-05）
Semantic Chunking	用 Embedding 算相邻句子相似度，突变点即切分点	单文档 30-40 秒 vs 规则 2-3 秒，生产环境时延不可接受
Late Chunking	先对全文编码获取完整上下文向量，再在向量层面切	jina-embeddings-v3 实测内存 8-10x，暂不可用
动态 Chunk Size	按语义密度（LLM 评分 0-10）动态调 size	A/B 测试中，多跳推理 +3-5%，但评分本身有推理成本

关键洞察

切分优化 +24% vs 换 Embedding +4%——这两个数字应该挂在所有 RAG 团队的墙上，决定了优化资源该往哪儿投
chunk_size 不是通用参数——必须分析具体文档类型的句长、段落结构。保险文档要 1024（关键条款 1536），FAQ 用 200~512 就够
特殊元素必须专项处理——表格丢表头、列表丢前导句、图片直接跳过都是会反复制造 badcase 的死结构问题，不解决调多少参数都没用
元数据是答案溯源的护城河——section_path 让 LLM 答完后能告诉用户"根据第 3 条 > 3.2 责任免除 > (2)"，这是企业级 RAG 与 demo 级的硬差距
Overlap 不是越多越好——100 token 是拐点，之后召回率几乎不动但存储一直涨。智能 overlap（句子边界）比无脑加 token 更有效
前沿方法不一定上得了生产——Semantic Chunking 时延 30-40 秒、Late Chunking 内存 8-10x，生产环境对工程化要求与论文 SOTA 是两回事
2 人 1 周标注 2000 QA 对是性价比极高的前置投入——后续每次评估只要 10 分钟，免去"感觉更好"的无效讨论

待探索问题

结构化数据库 + 非结构化文档混合 RAG：合同字段表 + 条款全文这种混合场景，切分策略怎么协调？
多语言文档的层级识别：XGBoost 层级分类器在中文 94%，英文/混排文档呢？
PDF 解析失败的兜底：解析静默跳过、表格识别错误这类上游问题怎么持续监控？
父子切割的存储成本平衡：质量要求极高时翻倍存储能否接受？哪些字段可以共享？
动态 chunk_size 的 LLM 评分成本：评分本身的推理成本会不会吃掉收益？

来源索引

#	来源	提炼日期	主要贡献章节
1	吴师兄 RAG 切分实战分享	2026-04-03	地基论、三代演进、V3 四大改进、Overlap 量化、元数据 6 字段、should_merge、特殊元素处理、前沿三方向
2	京东面试官：RAG 文档怎么切割（公众号）	2026-04-13	五种策略选型、父子切割
3	派聪明 RAG 真实面试题（阿里飞猪一面）	2026-04-13	512 token 起点、递归切分实操、token vs 字节

演进记录

v0.2（2026-05-19） — 与《RAG 基础与评估体系》理顺分工。删除原"概念 2 向量库三元结构与不能整篇存"（重复入门内容）和粒度博弈节中的相关重复，改为引用基础方向。元数据 6 字段下方加入对检索/服务化方向的引用提示。新增"相关链路"段，明确上游/下游/落地三条线。
v0.1（2026-05-15） — 首次构建，由 /route-knowledge 路由分析触发。聚合 RAG/04（切分实战）、RAG/19（五种策略）、RAG/23（切片大小）三个来源，初始化方向定位、知识图谱、核心概念（地基论/三元结构/粒度博弈）、方法论（五种策略/三代演进/V3 四大改进/Overlap/元数据/should_merge/特殊元素/父子切割）、案例库、前沿方向与关键洞察。

思维模型

认知方法论

学科模型

职场与成长

05-AI与Agent

00-基础学科

01-Agent核心

02-Harness工程

03-RAG系统

04-成本与效能

05-AI安全

06-战略与前沿

RAG 文档处理与 Chunk 工程

方向定位

知识图谱

核心概念

概念 1：地基论——切分是 RAG 最被低估的地基

概念 2：粒度博弈——精度与完整度

方法论与框架

框架 1：五种 Chunking 策略选型表

框架 2：三代切分方案演进路径

框架 3：V3 四大核心改进

框架 4：Overlap 量化实验

框架 5：Chunk 元数据 6 字段设计

框架 6：语义完整性 should_merge 检查

框架 7：特殊元素处理策略

框架 8：父子切割（Parent-Child Chunking）

案例库

案例 1：保险文档 5000 份切分优化（吴师兄 RAG 切分实战）

案例 2：512 token 通用起点（阿里飞猪面试题）

案例 3："核辐射事故" badcase 全链路

前沿方向

关键洞察

相关链路

待探索问题

来源索引

演进记录

认知方法论

学科模型

职场与成长

00-基础学科

01-Agent核心

02-Harness工程

03-RAG系统

04-成本与效能

05-AI安全

06-战略与前沿

RAG 文档处理与 Chunk 工程 ​

方向定位 ​

知识图谱 ​

核心概念 ​

概念 1：地基论——切分是 RAG 最被低估的地基 ​

概念 2：粒度博弈——精度与完整度 ​

方法论与框架 ​

框架 1：五种 Chunking 策略选型表 ​

框架 2：三代切分方案演进路径 ​

框架 3：V3 四大核心改进 ​

框架 4：Overlap 量化实验 ​

框架 5：Chunk 元数据 6 字段设计 ​

框架 6：语义完整性 should_merge 检查 ​

框架 7：特殊元素处理策略 ​

框架 8：父子切割（Parent-Child Chunking） ​

案例库 ​

案例 1：保险文档 5000 份切分优化（吴师兄 RAG 切分实战） ​

案例 2：512 token 通用起点（阿里飞猪面试题） ​

案例 3："核辐射事故" badcase 全链路 ​

前沿方向 ​

关键洞察 ​

相关链路 ​

待探索问题 ​

来源索引 ​

演进记录 ​

RAG 文档处理与 Chunk 工程

方向定位

知识图谱

核心概念

概念 1：地基论——切分是 RAG 最被低估的地基

概念 2：粒度博弈——精度与完整度

方法论与框架

框架 1：五种 Chunking 策略选型表

框架 2：三代切分方案演进路径

框架 3：V3 四大核心改进

框架 4：Overlap 量化实验

框架 5：Chunk 元数据 6 字段设计

框架 6：语义完整性 should_merge 检查

框架 7：特殊元素处理策略

框架 8：父子切割（Parent-Child Chunking）

案例库

案例 1：保险文档 5000 份切分优化（吴师兄 RAG 切分实战）

案例 2：512 token 通用起点（阿里飞猪面试题）

案例 3："核辐射事故" badcase 全链路

前沿方向

关键洞察

相关链路

待探索问题

来源索引

演进记录