RAG 系统如何处理 PDF、Word、Markdown 等不同格式文档？
这道题考的是 RAG 系统中多格式文档的统一处理方案。面试官想看你能不能把"不同格式的文档怎么统一解析、怎么智能分块、选什么工具"这件事讲清楚。
我从四个方面来讲：文档处理的全流程链路、不同格式的解析策略、智能分块的黄金切割线、工具选型。
1. RAG文档处理的"厨房流水线"
文档从上传到入库，要经历 6 个关键环节，就像餐厅厨房的流水线：
文件上传 → 格式校验 → Layout解析 → 清洗去噪 → Chunking分块 → 元数据标注
每个环节都有特定职责，少了哪个都会出问题。
文件上传阶段，系统要识别文件类型（PDF/Word/Markdown），检查文件完整性，校验文件大小。
格式校验阶段，检查文件是否损坏、格式是否正确、编码是否合规。
Layout解析是最核心的环节，要把文档的视觉结构（标题层级、段落关系、表格位置、图片坐标）解析出来。PDF 和 Word 的 Layout 完全不同，这个环节决定了后面分块的质量。
清洗去噪阶段要去掉页眉页脚、水印、脚注、重复段落。
Chunking分块是技术活，决定了检索粒度。
元数据标注给每个 Chunk 打上来源章节、页码、标题等标签，方便后续溯源。
2. 不同文档格式的"切菜刀法"
不同文档格式有不同的"纹理"，需要不同的解析策略。
Markdown 最简单。它本身就是结构化文本，按标题层级（H1/H2/H3）切分就行。保持逻辑结构完整，每个 Chunk 都知道自己属于哪个章节。
Word 复杂一点。必须读取样式信息（标题1、标题2、正文），重建文档树，按标题层级切分。每个 Chunk 知道自己是第几章第几节，检索时能精准定位。
PDF 最麻烦。PDF 是"打印后的图像"，没有结构信息。多栏布局、表格合并单元格、页眉页脚干扰、扫描件模糊，全是坑。需要用 Layout 分析模型（比如 Docling）来识别这些元素的位置和关系。
代码文件 按函数、类、包切分。用递归字符切分器，按代码的语法结构来切，而不是按段落。
类比一下：Markdown 是切土豆丝（按纹理顺着切），Word 是切牛排（读懂肉的纹理再下刀），PDF 是切报纸（报纸排版乱，还可能有图片穿插），代码是切千层饼（按层次结构一层层拆）。
3. 智能分块的"黄金切割线"
分块大小是个技术活，太大太小都有问题。
太大了，Chunk 包含太多内容，检索时找不到精准焦点。比如"业务逻辑跨 Chunk"，一段完整的流程被切成两半，检索只能召回一半。
太小了，上下文丢失。专有名词被截断，"SSO单点登录"变成"SSO单点..."，检索时匹配不到。
混合分块是现在的最佳实践：先按语义把文档切成大块，再把大块切成小块。大块用于初筛，小块用于精排。
数据说话：混合分块让检索精度从 68% 提升到 89%，提升 31 个百分点。LLM 回答质量从 3.2 分提升到 4.6 分，提升 44%。
边界问题是 Chunking 的核心挑战。解决方案有两个：
- Overlap 重叠：相邻 Chunk 之间保留 15% 的重叠内容，确保上下文不断档
- Parent-Child 策略：大 Chunk 当爹，小 Chunk 当孩子。检索用小 Chunk，生成时回溯到大 Chunk 获取完整上下文
4. 工具选型的"十八般兵器"
主流工具有这么几个：
Docling（IBM 2024年8月发布）是现在的明星产品，GitHub 41k+ Star。它统一表示格式，表格识别、多栏布局、图表处理、OCR、公式识别全支持，而且无需 API 调用，本地运行。生产级 RAG 系统首选。
PyPDF2/pdfplumber 功能单一，只能处理 PDF，没有 OCR，没有 Layout 分析。适合简单场景快速验证。
AWS Textract 质量高，但需要 API 调用，$1.50/1000 页。预算充足、不想自己运维时用。
选型原则：生产环境选 Docling，本地化、无 API 成本、支持的格式全。简单场景用 pdfplumber，快速出结果。不差钱用 Textract，质量有保障。
面试怎么答
基础版（能过的回答）
RAG 系统处理多格式文档，核心是建立统一的处理流水线：文件上传后先做格式校验，然后根据不同格式采用不同的解析策略——Markdown 按标题层级切分，Word 读取样式信息重建文档树，PDF 用 Layout 分析模型处理多栏和表格。分块策略上，代码用递归字符切分，结构化文档用标题分块，通用文本用段落或固定长度。生产环境推荐 Docling，它能统一处理 PDF、Word、Markdown，输出标准化的文档结构。
加分版（让面试官眼前一亮）
在基础版基础上，加这些细节：
- Docling 统一方案：无论输入 PDF 还是 Word，输出都是标准化的 DoclingDocument 结构，这是多格式文档处理的核心思路
- 量化数据：混合分块检索精度提升 31%，LLM 回答质量提升 44%
- 降级处理：解析失败时，空文件拒绝入库、部分失败进入人工队列、乱码高时降级为纯文本 OCR
- 语义丢失场景：比如"SSO单点登录"被截断成"SSO单点"，导致专有名词匹配失败，这是 Chunk 边界的典型问题
一句话总结
RAG 多格式文档处理的核心是：统一流水线 + 按格式选刀法 + 混合分块保精度 + Docling 一把梭。