做 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 类型特征推荐解析路线原生文本单栏文本层完整坐标单簇分布直接文本抽取 规则清洗原生文本多栏文本层完整坐标多簇分布版面分析 按栏重排扫描件字符数极少图片占比高OCR 版面分析混合型部分页有文本层部分页是图分页判断分别处理这个表格看着简单但实际项目里最常见的错误就是拿一套逻辑套所有 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的报告就是判断依据。不要迷信 OCROCR 有识别错误率而且慢能用文本层就用文本层。但也不要迷信文本层质量差的文本层还不如 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扫一眼报告就知道大概该怎么处理了。这种直觉是靠一次次实际检查积累出来的没有捷径。