RAG 知识库分块与文档解析策略
校招考察频度：★ 高频（重点常考·大厂分水岭） 一句话速记：分块的本质不是机械“把文本切短”，而是切出“语义自包含的可回答单元”；递归字符切分是稳健工业基线，重叠窗口（Overlap 10%~20%）防止上下文腰斩；针对“检索精度与回答上下文”的天然矛盾，工业界最优解是父子块（Parent-Child）索引：小块向量匹配保召回，父级大块喂给 LLM 保忠实度。
在当今的大模型与 Agent 岗位面试中，RAG（检索增强生成）几乎是每位同学简历上都会出现的项目。很多初学者被问到分块时只会说“用 LangChain 默认 500 字符切分”，立刻暴露经验欠缺。
一、0 基础生动类比：图书切页与查字典模型
| RAG 分块环节 | 生活化比喻 | 现实面临的痛点 |
|---|---|---|
| 粗暴固定切分（Fixed） | 闭着眼睛每 500 个字拿剪刀剪一刀。 | 刚好把“但是以下情况除外：”剪在上一页，把具体免责条款剪在下一页，LLM 召回后直接给出与事实完全颠倒的致命回答！ |
| 滑动窗口（Overlap） | 剪书时，每页末尾与下一页开头重叠复印两句话。 | 保证相邻段落之间的语法与指代连续性，代价是产生轻微重复数据。 |
| 父子文档块（Parent-Child） | 字典的**“详细词条卡片（父块）”与“微型拼音索引标签（子块）”**。 | 用极小的子块（如 64 token）做精准的语义向量匹配；一旦命中，把完整的章节大卡片（如 1024 token）喂给 LLM，既准又全。 |
二、父子块索引架构（Parent-Child Retriever）
父子块（Parent-Child）索引与检索架构
为什么父子块能破解“语义分块悖论”？
- 语义分块悖论：块切得越小（如单句话 50 token），向量语义越纯粹，检索匹配精度极高；但当把这一句话送给 LLM 时，由于缺乏上下文的前因后果与逻辑推导，模型依然只能一本正经地胡说八道（产生幻觉）。
- 父子块两全其美：检索阶段用小块（解决向量被多主题稀释问题），推理生成阶段用大块（提供完整论证证据链）。
三、主流分块策略深度对比
| 策略模式 | 运作机制 | 适用场景与优缺点 |
|---|---|---|
| 固定字符大小 | 纯按字符或 Token 长度硬切，辅以 Overlap | 玩具级 Demo，容易破坏句子结构与词义。 |
| 递归字符分块 (Recursive) | 按分隔符优先级尝试：["\n\n", "\n", " ", ""] | 工业界通用默认方案。优先保留自然段落，段落过大再拆为单句，尽可能保全完整语义。 |
| 结构感知分块 (Markdown/HTML) | 解析 Markdown 的 #, ## 标题或 HTML 标签层级 | 适合技术文档、产品手册。能将上层各级标题自动拼接到子块头部作为上下文增强。 |
| 语义分块 (Semantic) | 计算相邻句子的向量余弦相似度，相似度急剧下跌处截断 | 适合论文、散文等无明显小标题的长文本，但计算开销大。 |
| 代码/表格感知分块 | 基于 AST 语法树切分函数与类；表格整表作为原子单元 | 代码与金融财报必备。严禁将一张完整的 Markdown/HTML 表格从中间横截切断！ |
四、文档解析的三大高频“深水坑”
- 表格结构损坏：
- 表格一旦被普通分块器切碎，表头与具体数值字段脱节，模型召回后完全不知道那一串数字代表什么含义。
- 解法：整表必须作为不可拆分的原子块；若表格超大，拆分时必须在每个子块中重复拷贝完整的表头与表元数据。
- 指代与代词断裂：
- 比如合同第 1 页定义：“本协议甲方指北京某某有限公司”；而在第 5 页切出的分块里只有：“甲方应在 3 日内付款……”。
- 解法：元数据注入（Metadata Injection），在每个分块的顶部强制追加包含“文档标题、核心实体定义”的面包屑描述文本。
- 扫描件与复杂多栏 PDF：
- 传统 PDF 提取库按物理从左到右读取，会把两栏排版的报纸直接串行混拼在一起。必须采用支持 Layout 布局感知的解析工具（如
MinerU、Marker或多模态 Vision 模型）。
- 传统 PDF 提取库按物理从左到右读取，会把两栏排版的报纸直接串行混拼在一起。必须采用支持 Layout 布局感知的解析工具（如
五、知识脉络关联网（Knowledge Highway）
- ⬅️ 底层原理支撑：为什么块大小不能无限膨胀？参见 大模型上下文窗口机制。
- ➡️ 后置管道对接：分块完成后如何做稠密向量检索与 Cross-Encoder 重排？参见 RAG 检索与重排序核心技术。
- 🔄 向量数据库选型：这些切出来的块应该存放在哪里？参见 向量数据库选型与 HNSW 索引。
六、校招高频面试追问
- 块大小（Chunk Size）和重叠度（Overlap）怎么调参？有黄金法则吗？
- 没有一劳永逸的固定数值，但有严谨的工程经验区间：
① FAQ / 问答对：100200 tokens；500 tokens（搭配 10%
② 常规企业知识库 / 规章制度：30020% 的 Overlap，即 5080 tokens）；
③ 硬性物理约束：Chunk 长度绝对不能超过你所选用 Embedding 模型的最大上下文长度（如 bge-large-zh 为 512 tokens，超出部分会被直接截断丢失）。最终必须基于你所在业务场景的真实召回评测集进行网格搜索调优。
- 没有一劳永逸的固定数值，但有严谨的工程经验区间：
- 什么是“丢失在中间”（Lost in the Middle）现象？分块如何缓解它？
- 论文《Lost in the Middle》指出：大模型对长上下文的头部（开头）和尾部（结尾）关注度最高，而对位于中间位置的信息敏感度急剧下降。
- 分块如果切得过大，关键信息若落在长块的中间，模型很容易视而不见。控制单块精炼度，并配合 Rerank 重排器将最相关的块调整到上下文的最前端或最末端，能有效解决该问题。