RAG 面试高频题:Word 和扫描版 PDF,AI 到底怎么读懂?

面试官问：

“用户传上来一份 Word 或者扫描版 PDF 合同，你的 RAG 系统打算怎么让大模型读懂里面的内容？”

这个问题看着平平无奇，真要落地，还是有很多坑的。

很多开发者对 RAG 的印象，还停留在”搞个向量库、存进去、查出来”那一步。

说白了，检索召回只是最表层的功夫。

真正让你裂开的，从来不是检索，而是文档本身。

格式乱七八糟、扫描糊成一团、表格歪七扭八，还有各种你想都想不到的脏数据——这些才是落地时的难点。

这也是 RAG 面试里的高频题。

它考的从来不是你背不背得熟流程图，而是面对真实业务文档时，你到底有没有完整的处理和落地经验。

整体处理流程

RAG 处理 Word 和 PDF，本质上是一条流水线。

一句话概括：解析优先、工具为王、别去重复造轮子。

整条链路长这样：

文档解析（抽文字、表格、图片）→ 复杂版式用多模态模型兜底 → 保留结构的语义切片 → 向量化入库 → 查询时多路召回加重排 → 组装上下文并附来源引用。

这一串里，最要命的环节是文档解析。

为啥？

因为解析质量直接决定了后面所有步骤的天花板。

你喂进去的文本本身就是一坨乱码，切片算法再花哨、模型再牛，召回出来的东西也不可能准。

而且 Word 和 PDF 在这一步踩的坑，完全不是一回事。

文档解析：最大的难点

Word 文档

说白了，Word 是个”懂事”的格式。

它内部自带结构化信息——标题层级、段落格式、表格标记，文件里都有对应标识，抽取起来相对轻松。

但别高兴太早，坑也不少：

• • 内嵌的图片、数学公式、文本框、修订痕迹、隐藏批注……这些要是解析时漏了，信息就丢了；
• • 提取姿势不对，又会带进来一堆噪声。

PDF 文件

PDF 跟 Word 完全是另一种生物。

它是版式驱动的格式，核心关注页面布局，而不是像 Word 一样天然保存标题层级、段落关系等语义结构。

这带来了几个经典翻车现场：

• • 双栏排版，最典型的坑。
• • 直接按行读，左右两栏内容交错成一锅粥，出来的文本完全没法看。
• • 表格处理也头大——跨页表格、不规则合并单元格，分分钟让行列结构错乱。
• • 扫描件更狠，本质上就是一组图片，压根没有文本层，想直接抽文字？门都没有。

那 Word 和 PDF 到底差在哪？

没有什么是一张表看不明白的：

面对这些挑战，主流做法很明确：别从零自建解析系统。

文档解析本身是个独立赛道，能把这块做透的团队，早被大厂收编了。

有数据安全要求的，通常会选择私有化部署文档解析方案，例如基于 OCR、版面分析、表格识别能力构建内部解析服务。

非敏感业务，直接调合合信息这种商业接口，中文合同、公章、跨页表格等场景通常具有较好的识别效果，适合非敏感业务快速接入。

常规解析搞不定时，怎么兜底？

先说结论：分桶。

说白了就是”看菜下饭”——普通文本页，老老实实走标准解析；

可一旦碰上复杂表格、糊成一团的扫描件、各种流程图，别硬啃，直接把这页拍成图，丢给多模态大模型。

那问题来了——丢过去就完事了？

当然不是。

得用提示词把它管住，逼它吐出标准 Markdown。

这么一搞，表格、公式、流程图全都能拿到精准的结构化描述，效果比纯 OCR 那套强太多。

GraphRAG 场景里还有额外红利：

这种结构化描述能直接拿去抽实体关系，比碎成渣的文本好用得多。

不过这里有个坑得提醒你——多模态模型可不是免费的午餐。

每页都调它，延迟和成本直接爆表，根本扛不住。

所以它从来不是主力，而是专门收拾烂摊子的兜底手段。

实际生产里没人全量调。

正确姿势是按复杂度分流：

绝大多数正常页走廉价通道，只把那少数异常的、复杂的页，送去吃多模态这顿”大餐”。

实际生产中通常不会全量调用多模态模型，而是根据文档复杂度进行分流，只处理少量异常和复杂页面。

把贵的能力用在刀刃上，这才叫真的香。

结构感知的切片策略

解析完，第二步是切片。

这里有个特别容易被忽视的认知偏差：切片不是越碎越好。

你要是粗暴按固定字数切，灾难就来了——一句话被拦腰斩断、一张表被劈成两半、一个逻辑单元被撕碎。

召回的内容缺头少尾，大模型自然答不对。

正确姿势是结构感知切片，记住三条：

• • 顺着标题层级和段落边界切；
• • 标题跟它管辖的内容绑在一起；
• • 表格尽量整块保留成 Markdown。

两种切法差别有多大，直接上对比：

实践里常用递归切片法，每块 400 到 800 Token，留约 20% 重叠区保连贯。

具体参数需要结合模型上下文窗口、文档类型和实际评测结果调整。

纯语义切片理论上更准，但计算成本高好几倍、效果提升却有限，非必要别上。

入库与检索

切片完，文本片段过 Embedding 模型转成向量，存进向量库。

查询阶段，千万别只走一条路。

用多路召回：

向量检索管语义相近，关键词检索管精确命中专业术语和编号。

两条路结果合并，丢给重排模型精排——这一步对最终准确率的影响，非常大。

上下文组装与引用

最后一步，给大模型组装上下文，并且回答里明确标出来源——答案出自哪个文件第几页。

这套来源引用机制，正是 RAG 比直接问大模型更靠谱的核心原因。

置信度兜底

线上环境还有一堆要兜底的情况：

扫描质量差导致 OCR 错字、表格抽取偶尔结构错乱。

所以，解析阶段必须加置信度评估：

识别结果不可靠，别硬塞入库，触发二次校验，必要时调多模态复核。

核心目标是在召回率和准确率之间找平衡点。

• • 召回太激进，噪声进来拉低质量；
• • 太保守，又可能漏关键信息。

所以，靠召回率、准确率这些指标反复调。

面试回答模板

面试时间紧的话，可以这么组织：

RAG 处理 Word 和 PDF，核心难点在解析，不在检索。

Word 自带结构，抽文字不费劲；可内嵌对象、修订痕迹这些暗坑，漏一个就丢信息。

PDF 是版式格式，压根不存语义——双栏、跨页表、扫描件，全是坑。

所以落地别自建，优先抱成熟工具的大腿；

真碰上搞不定的复杂页，多模态分桶兜底。

解析完按结构语义切片，标题表格保完整，再向量化入库。

检索多路召回配重排提准，输出附来源引用，全链路加置信度评估。

最后，按业务需求在召回率和准确率之间权衡——别贪多，也别太保守。

我把本文整理成了PDF，方便大家打印学习，链接放在这里：

https://pan.xunlei.com/s/VOxQGcLp2wvWGQuT63827THNA1?pwd=bnyd#