做 RAG 的人迟早会撞上同一堵墙：模型答得头头是道，但引用的原文根本不存在，或者把表格里的数字读串行。排查到最后，八成问题不在向量库，也不在 embedding 模型，而是最上游那一步——PDF 到底被解析成了什么鬼样子。我见过太多团队花两周调 rerank 策略，结果发现 chunk 里全是页眉页脚和断行的乱码。所以当我第一次看到pdf-inspector这个工具时，第一反应是：终于有人把"先看清楚 PDF 里到底有什么"这件事单独拎出来了。它不负责生成，不负责检索，只干一件事——把 PDF 的内部结构、文本层、图片、表格、字体信息摊开给你看，让你在写解析逻辑之前先知道自己在跟什么打交道。

1. 为什么 RAG 的瓶颈往往卡在 PDF 解析这一层

1.1 向量检索再好，也救不回被解析毁掉的原文

RAG 的链路是"解析 → 切分 → 向量化 → 检索 → 重排 → 生成"，很多人把注意力全押在后半段，觉得只要 embedding 够强、rerank 够准，答案质量自然上去。但这条链路有个残酷的特性：上游的信息损失是不可逆的。如果 PDF 解析阶段把两栏排版的文字按行交错读成一句话，或者把表格的单元格顺序打乱，那么后面无论用什么模型，拿到的都是一堆语义已经错乱的文本。向量化只是把错误忠实地编码进高维空间，检索只会精准地找回这些错误。

我做过一个对比实验，同一份 60 页的技术白皮书，用两种解析方式处理：一种是直接按文本流抽取，另一种是先分析版面再按区块抽取。切分参数、embedding 模型、检索策略全部一致，只换解析结果。最终问答准确率差了将近 30 个百分点。这个差距不是靠调 top-k 或者换 rerank 模型能补回来的。所以当你发现 RAG 效果怎么调都上不去时，先别怀疑检索层，回到最前面看看 PDF 被解析成了什么样。

1.2 pdf-inspector 到底在检查什么

pdf-inspector的定位很明确：它是一个 PDF 结构探查工具，不是解析器本身，而是解析器的"体检仪"。它帮你回答几个关键问题——这份 PDF 有没有文本层，还是纯扫描件？文本是按什么顺序排列的，阅读顺序和物理顺序是否一致？页面里有多少图片、多少矢量图形、多少隐藏的注释对象？字体是嵌入的还是系统回退的，有没有出现乱码的 CID 映射？表格是靠线条画的还是靠空格对齐的？

这些问题听起来琐碎，但每一个都直接决定你后面该用什么解析策略。比如一份 PDF 如果根本没有文本层，那你上多先进的版面分析模型都没用，得先走 OCR；如果文本层存在但阅读顺序错乱，那你要做的是重排而不是 OCR；如果表格是空格对齐的，那基于线条检测的表格识别会直接失效。pdf-inspector的价值就在于，它让你在动手写解析代码之前，先把这些坑摸清楚，而不是等 chunk 出来一堆垃圾再回头猜原因。

1.3 一个典型的翻车场景

说个我亲身踩过的坑。有批产品手册要入库，我图省事直接用了默认的文本抽取，跑完看着 chunk 数量正常，就上线了。结果用户问"某型号的额定电压是多少"，模型回答了一个完全不相干的数字。我去翻原始 chunk，发现那份 PDF 是双栏排版，抽取时把左栏最后一行和右栏第一行拼在了一起，而那个电压值恰好被拆到了两个 chunk 里，前半段在 A chunk，后半段在 B chunk。检索命中了 A，模型只看到半句话，就自己"脑补"了一个数字。

如果当时先用pdf-inspector看一眼，它会直接告诉我这份文档的文本块坐标是左右分栏的，阅读顺序需要按栏重排。五分钟的检查，能省掉后面几小时的排查。这就是为什么我说，做 RAG 的人应该把 PDF 结构检查变成流程里的固定动作，而不是出问题才想起来的事。

2. pdf-inspector 能帮你摸清 PDF 的哪些底细

2.1 文本层的有无与质量判定

第一件要确认的事，就是这份 PDF 到底有没有可用的文本层。有些 PDF 是扫描件直接封装，打开能选中文字，但选中的其实是 OCR 后叠加的隐藏层，质量参差不齐；有些则是纯图片，一个字都选不中。pdf-inspector会把每页的文本对象数量、字符总数、字体使用情况列出来，你一眼就能判断。

判断标准我一般这么定：如果某页字符数极少但图片面积占比很高，基本可以判定是扫描页，需要走 OCR；如果字符数正常但字体全是某种回退字体，说明原始字体没嵌入，可能出现字符映射错误，抽取出来的文字会有乱码。这里有个经验值，正常一页 A4 正文大概在 1500 到 3000 字符之间，如果某页只有几十个字符却有大图，别犹豫，那页就是图。

2.2 阅读顺序与版面结构

文本层存在不代表顺序对。多栏排版、侧边栏、脚注、页眉页脚，这些元素在 PDF 内部的存储顺序往往和人的阅读顺序不一致。pdf-inspector会输出每个文本块的坐标信息，你可以据此判断页面是单栏还是多栏，页眉页脚的位置是否固定。

我通常的做法是：先看文本块的 x 坐标分布，如果明显聚成两簇，那就是双栏；再看 y 坐标，顶部和底部如果有重复出现的小字块，那多半是页眉页脚，切分前要过滤掉。这些判断如果靠肉眼看 PDF 也能做，但一份几百页的文档你不可能一页页翻，pdf-inspector能批量给你统计出来，效率完全不是一个量级。

2.3 图片、表格与矢量图形的分布

RAG 知识库能不能存图片，这是热搜里经常出现的问题。答案是能，但前提是你得先知道 PDF 里哪些是图片、哪些是矢量绘制的表格。pdf-inspector会区分位图对象和矢量路径对象。位图就是真正的图片，可以抽出来单独做多模态处理；矢量路径往往是表格线、图表边框，这些不是图片，但承载了结构信息。

这个区分很关键。如果你把矢量表格当成普通文本流抽取，单元格内容会糊成一片；如果你把矢量图形误当成图片去跑 OCR，那是在浪费算力。先看清楚对象类型，再决定处理方式，这是省时间的关键。

2.4 字体与编码的隐患

字体问题是最隐蔽的坑。有些 PDF 用了自定义编码，文本层里存的是字形索引而不是 Unicode，直接抽取会得到一堆问号或者乱码。pdf-inspector会显示字体的编码方式和是否有 ToUnicode 映射表。如果没有映射表，那这份 PDF 的文本抽取基本没救，只能走 OCR。

我遇到过一份日文技术文档，文本层看着正常，但抽出来全是乱码。用pdf-inspector一查，字体是子集嵌入且没有 ToUnicode 表，字符编码是自定义的。这种情况下任何文本抽取库都无能为力，因为映射关系压根不存在于文件里。早点发现，就能早点切换到 OCR 方案，不至于在文本抽取上反复折腾。

3. 把检查结果转化成解析策略的实操思路

3.1 先分类，再决定走哪条解析路线

拿到pdf-inspector的报告后，我一般把 PDF 分成四类，每类对应不同的解析路线。这个分类动作应该在写任何解析代码之前完成，因为它决定了你整个 pipeline 的走向。

这个表格看着简单，但实际项目里最常见的错误就是拿一套逻辑套所有 PDF。混合型文档尤其坑人，前几页是原生文本，中间插了几页扫描的图表，如果你统一按文本抽取，那几页扫描页就会变成空白 chunk，检索时永远命中不了。

3.2 页眉页脚的批量识别与过滤

页眉页脚是 chunk 污染的重灾区。它们在每个页面重复出现，切分后会变成大量高度相似的 chunk，既浪费向量空间，又会在检索时抢占名额。pdf-inspector给出的坐标信息能帮你自动识别它们：如果某个文本块在超过 80% 的页面上都出现在相同的 y 坐标区间，且内容高度相似，那它基本就是页眉或页脚。

我的处理方式是在切分之前先做一轮过滤，把这些块从文本流里剔除。注意不要用简单的关键词匹配，因为页眉内容可能包含章节名，直接删会误伤正文。用坐标加频率双重判断更稳。这个步骤做完，chunk 的纯净度会有明显提升，检索的噪声也会少很多。

3.3 表格区域的单独处理

表格是 RAG 里最头疼的结构。pdf-inspector能告诉你表格是靠线条画的还是靠空格对齐的，这决定了你该用什么工具。有线条的表格可以用基于线条检测的方案，比如常见的表格识别库；靠空格对齐的表格则要靠文本坐标聚类来还原行列关系。

我的经验是，表格不要和正文混在一起切分。应该先把表格区域识别出来，单独抽成结构化数据，比如转成 Markdown 表格或者 JSON，再作为一个独立的知识单元入库。这样检索时，表格的完整性得以保留，模型拿到的也是结构清晰的数据，而不是一堆错位的单元格文本。对于跨页表格，还要做合并处理，否则一个表格被拆成两半，两边都不完整。

3.4 图片的抽取与多模态衔接

如果知识库需要支持图片问答，那图片抽取就是必须的。pdf-inspector能定位每张位图的位置和尺寸，你可以据此把图片抽出来，同时记录它在原文中的上下文位置。这样在检索时，图片可以和它周围的文字一起被召回，形成图文并茂的上下文。

这里有个细节：图片的命名和存储要有规律，最好带上页码和序号，方便回溯。另外，图片如果包含文字，比如流程图里的标注，那还需要单独跑一次 OCR，把图内文字也提取出来作为补充。这一步很多人会漏掉，导致流程图类的内容检索不到。

4. 实测中那些文档不会告诉你的坑

4.1 文本层存在不等于文本可用

这是最反直觉的一点。很多人看到 PDF 能选中文字，就默认文本抽取没问题。但文本层可能是 OCR 后叠加的，质量很差，错字连篇；也可能是编码错乱的，抽出来是乱码。pdf-inspector能帮你识别这些情况，但前提是你得去看报告，而不是想当然。

我的做法是抽样验证：从报告里挑几页字符数正常的，实际抽一段文字出来肉眼看看，确认没有乱码、没有明显的 OCR 错误。这个动作花不了几分钟，但能避免后面大规模返工。尤其是批量入库的场景，一份文档的问题会乘以几百倍。

4.2 阅读顺序的重排没有万能公式

多栏排版的重排逻辑，网上教程大多给的是"按 x 坐标分栏，再按 y 坐标排序"。但实际文档千奇百怪，有的页面是两栏，有的页面是通栏标题加两栏正文，有的还有侧边栏注释。一套固定规则很难通吃。

我的建议是，先用pdf-inspector把文档的版面模式统计出来，看看有几种布局，再针对每种布局写规则。如果布局太复杂，那就考虑上版面分析模型，而不是硬写规则。规则适合处理格式统一的文档，格式一乱，规则的维护成本会急剧上升。

4.3 切分粒度要和解析质量匹配

解析质量差的时候，切分粒度要适当放大，给模型更多上下文去"猜"；解析质量好的时候，可以切细一点，提高检索精度。这个关系很多人没意识到，一味追求小 chunk，结果每个 chunk 都是残缺的句子，检索出来反而更糟。

我一般的做法是，解析质量高的文档用 500 到 800 字符的 chunk，带一定的重叠；解析质量一般的文档放大到 1000 到 1500 字符，靠上下文弥补噪声。这个参数没有标准答案，得结合你的文档特点和检索效果反复调。

4.4 别忽略 PDF 的版本和生成工具差异

同样是 PDF，用不同工具生成的内部结构差别很大。有的工具生成的 PDF 文本块顺序很规整，有的则乱七八糟。pdf-inspector的报告里通常能看到生成工具的信息，这个信息有用——如果你发现某类工具生成的 PDF 普遍有问题，可以在入库流程里针对性地加处理逻辑。

我在项目里就遇到过，某款办公软件导出的 PDF 表格全是矢量线条，而另一款导出的是位图。针对这两种情况，处理方式完全不同。提前知道来源，就能提前准备对应的解析方案，而不是等出了问题再临时救火。

5. 把 pdf-inspector 嵌进 RAG 流水线的具体做法

5.1 入库前的自动体检环节

我的建议是在 RAG 流水线的最前面加一个自动体检环节：文档进来先跑一遍pdf-inspector，生成一份结构报告，根据报告自动判断走哪条解析路线。这个环节可以做成一个独立的服务，输入是 PDF，输出是解析策略建议和风险提示。

具体实现上，可以设定一些阈值规则：字符密度低于某值判定为扫描页，文本块 x 坐标方差大于某值判定为多栏，字体无 ToUnicode 映射判定为编码风险。这些规则不需要很精确，只要能拦住大部分明显有问题的文档就行。剩下的边缘情况，人工介入处理。

5.2 解析结果的抽样校验

解析完不要直接入库，先抽样校验。从解析结果里随机抽若干 chunk，人工看看质量。如果发现乱码、断句、表格错位等问题，就回头调整解析策略。这个环节听起来费事，但比入库后发现效果差再返工要划算得多。

我通常会在校验环节重点看三类内容：含数字的 chunk（数字最容易出错）、表格附近的 chunk、以及跨页边界的 chunk。这三类是最容易出问题的地方，重点检查能覆盖大部分风险。

5.3 建立文档质量档案

长期做 RAG 的话，建议给每份入库文档建一个质量档案，记录它的解析难度、采用的处理方式、遇到的问题和解决方式。这样下次遇到类似文档，可以直接参考历史经验，不用从头摸索。pdf-inspector的报告可以作为档案的一部分存档。

这个档案的价值会随时间累积。做久了你会发现，文档质量问题其实就那么几类，有了档案，处理新文档的速度会越来越快，踩重复坑的概率也会越来越低。

5.4 和切分、向量化环节的衔接

解析策略确定后，切分和向量化环节也要相应调整。比如扫描件 OCR 出来的文本，噪声比原生文本大，切分时就要留更多重叠；表格转成 Markdown 后，切分时要保证表格不被拆散。这些衔接细节，如果不在解析阶段就规划好，后面会很难补救。

我的做法是把解析、切分、向量化当成一个整体来设计，而不是三个独立的步骤。解析阶段输出的元数据，比如版面类型、是否含表格、文本质量评分，都要传递给切分环节，作为切分参数的依据。这样整条链路才是连贯的，而不是各管各的。

6. 关于 PDF 解析与 RAG 的几个常见疑问

6.1 RAG 知识库到底能不能存图片

能，但要分清存的是什么。如果只是把图片抽出来存文件路径，检索时靠文字描述召回，那本质上还是文本检索。如果要支持以图搜图或者图片内容问答，那就需要多模态 embedding，把图片也编码进向量空间。pdf-inspector能帮你定位图片，但图片怎么用，取决于你的知识库设计。

我的建议是，先把图片抽出来，连同它的上下文文字一起存。检索时优先用文字召回，图片作为辅助信息展示。这样实现简单，效果也够用。等有明确的多模态需求了，再上多模态方案，不用一上来就搞复杂。

6.2 OCR 和文本抽取该怎么选

判断标准很简单：有可用文本层就用文本抽取，没有或者质量差就用 OCR。pdf-inspector的报告就是判断依据。不要迷信 OCR，OCR 有识别错误率，而且慢，能用文本层就用文本层。但也不要迷信文本层，质量差的文本层还不如 OCR。

实际操作中，混合型文档最常见，所以要支持分页判断，每页单独决定用哪种方式。这个逻辑写起来不复杂，但能显著提升整体解析质量。

6.3 表格识别为什么这么难

表格难在结构多样。有线表格、无线表格、合并单元格、跨页表格，每种都要不同的处理方式。而且表格里的内容往往是数字和关键信息，出错代价高。pdf-inspector能帮你判断表格类型，但识别本身还是要靠专门的表格识别工具。

我的经验是，表格识别不要追求全自动，关键表格人工校对一下更稳妥。尤其是财务、技术参数类的表格，一个数字错了，整个答案就废了。把表格单独抽出来，转成结构化格式，人工过一遍，再入库，这个投入是值得的。

6.4 解析质量对检索效果的影响有多大

非常大，而且是决定性的。我前面提到的 30 个百分点差距不是夸张。解析质量差，检索就是在垃圾里找垃圾，再好的模型也救不回来。所以如果你的 RAG 效果不理想，排查顺序应该是：先看解析质量，再看切分策略，再看 embedding 和检索，最后才看生成模型。

这个顺序很重要，因为越靠前的环节，影响越基础，修复成本也越低。很多人一上来就调生成模型的 prompt，那是本末倒置。先把上游的数据质量搞干净，后面的调优才有意义。

7. 我在实际项目里总结的几条硬经验

第一条，任何 PDF 入库前先跑一遍结构检查，这应该成为肌肉记忆。就像写代码前先看需求文档一样，做 RAG 前先看 PDF 结构报告。这个习惯能帮你避开大部分低级错误。

第二条，不要相信任何"一键解析"的工具。PDF 格式太复杂，没有哪个工具能通吃所有情况。pdf-inspector的价值就在于它不假装能解决所有问题，而是帮你把问题看清楚，让你自己决定怎么处理。这种定位反而更实用。

第三条，解析策略要跟着文档走，不要跟着工具走。先分析文档特点，再选工具，而不是手里有什么工具就硬套。工具是死的，文档是活的，搞反了顺序，效果肯定好不了。

第四条，留出人工校验的环节。全自动流水线很诱人，但 PDF 解析这种脏活，完全自动化往往意味着把错误也自动化了。关键文档、关键表格，人工过一遍，成本不高，但能避免大事故。

第五条，把解析质量当成一个可量化的指标来管理。比如统计乱码率、表格识别准确率、页眉页脚过滤率，定期看这些指标的变化。数据不会骗人，指标下降了，说明文档质量或者解析逻辑出了问题，能及早发现。

最后分享一个我常用的小技巧：拿一份你手头最复杂的 PDF，用pdf-inspector跑一遍，把报告从头到尾读一遍，对照着 PDF 原文看。这个过程能让你对 PDF 的内部结构建立直观认识，比看十篇教程都管用。等你对结构熟悉了，再遇到新的 PDF，扫一眼报告就知道大概该怎么处理了。这种直觉，是靠一次次实际检查积累出来的，没有捷径。