RAG面试通关指南：文档解析与Chunk切分，收藏这篇就够了！

基本上任何一个准备大模型面试的同学，几乎都能把“RAG流程”背得滚瓜烂熟：

「先把文档向量化 → 再召回 → 拼prompt → 最后生成回答。」

没错，流程对。

但当面试官追问一句：

“如果原始文档是PDF、PPT、扫描件或者图片怎么办？”

场面就开始尴尬了。

有的说：“那就OCR一下吧？”

有的沉默五秒：“我们好像没考虑过这种情况。”

其实，在真正的企业项目中，RAG最难的部分，根本不在检索，而在——“文档解析”与“Chunk切分”。

一、为什么RAG离不开文档解析？

文档解析，是RAG的第一环节。它的任务很简单：把原始文档变成“模型能读懂”的语料。

但这件事，往往被低估。你解析得好不好，直接决定了后续检索的上限。

举个例子：

在金融保险行业，很多公司都有成百上千份知识文档。它们混合了：

扫描版PDF；
内部PPT；
合同、报表、甚至视频转录文本。

这些文档结构复杂：多栏排版、表格嵌套、章节层级、图片说明……

如果解析不对，模型看到的世界就全乱了。

我们就遇到过这样的情况：一个PDF文件的左栏写“理赔流程”，右栏写“所需材料”。解析时顺序被拼在一起，结果模型以为：

“理赔流程 = 提交身份证复印件 + 合同复印件 + 医院诊断证明。”

这不就离谱了吗？

表格错位、标题丢失、章节打平，每一个错误都能让RAG的回答跑偏。

这就是为什么我常说：文档解析，是RAG的地基。你盖多高的楼，都要看地基打得稳不稳。

二、面试官会怎么问？

在RAG面试中，这部分常常会被问成一连串追问：

“在RAG里，文档解析的核心价值是什么？”

“不同格式文件你怎么统一解析？”

“OCR识别不准怎么办？”

“复杂表格、章节结构怎么保留？”

“解析质量要怎么量化？”

这些问题，其实都指向一个核心：你能不能把真实的业务文档变成有结构的知识。

三、项目中我们怎么做

在实战项目里，我们实现了一个多格式解析Pipeline：

格式识别与路由自动识别文件类型（PDF、Word、PPT、图片、HTML…），不同格式交给不同的子解析模块。
OCR识别 + 图像预处理对扫描件或图片型PDF，先增强图像，再OCR识别。表格、代码块这些结构用专门模型还原。
**布局分析（Layout Analysis）**对每页的文本块、表格、图片位置做检测，恢复段落层次和阅读顺序。
结构化输出把每一块内容（文本、表格、图片说明）和元信息（页码、标题层级、位置）统一输出成JSON格式。

最终得到的，不是散乱文本，而是一份“结构清晰、可追溯”的文档。这让后续的切分、向量化、检索都有了基础。

四、代码思路举例：PDF解析器主流程

pdf_parser = Pdf()text_boxes, tables = pdf_parser(    "financial_report.pdf",    from_page=0,    to_page=10,    zoomin=3)

内部流程大致是：

从PDF提取图像并OCR；
布局识别出文本块、表格、图片区域；
表格用Table Transformer模型结构化提取；
合并段落，保留层级；
输出为文本框列表和表格列表。

最后的输出像这样：

[  ("理赔流程：事故发生后尽快联系保险公司", {"page":1, "layout_type":"section", "title":"理赔流程"}),  ("申请人需提交以下材料：身份证复印件、保险合同复印件", {"page":1, "layout_type":"body"})]

——这，才是能喂给RAG的“干净语料”。

五、Chunk切分：从“句子碎片”到“可检索单元”

文档解析只是第一步， RAG真正能否跑得稳，还得看Chunk切分。

什么是Chunk？简单说，就是RAG检索的“最小语义单位”。

切得太短，语义断裂，模型上下文不全；切得太长，向量检索变得模糊，成本也高。

很多人用最朴素的策略：

“每500个字切一段。”

这当然能跑，但绝不优雅。

六、常见问题与解决思路

我们在实战中踩过无数坑，总结下来，Chunk切分的难点有三类：

1. 表格和图片被拆开

表格标题和表格内容分离；图片说明和图丢了。

解决：在解析阶段就标注 chunk_type（text / table / image），表格、图片统一视为不可拆分单元。

2. 段落断裂

一个完整句子被拆成两半。

解决：在切分时按Token计数，同时参考句子边界（句号、分号），超过阈值再切，保证语义完整。

3. 层级丢失

标题、小标题混在正文里。

解决：在解析阶段提取章节层级信息（如section_id），切分时保留为独立chunk，或附加到正文首部。

七、实战函数：naive_merge → advanced_merge

最开始我们用一个朴素函数 naive_merge()，按照Token计数控制chunk长度。

后来，为了支持表格、图片和跨页段落，我们升级成了 advanced_merge()：

def advanced_merge(sections, chunk_token_num=128):    for text, pos, ctype in sections:        if ctype in ("table", "image"):            # 不拆表格/图片            new_chunk(text)        elif same_paragraph(text):            add_chunk(text)        else:            # 超限则新开chunk            if current_tokens + tokens(text) > chunk_token_num:                new_chunk(text)            else:                add_chunk(text)

这段逻辑背后的思想很简单：