在做 RAG 知识库的人，多半都遇到过这种情况：你上传了 PDF，系统没报错，切分数量却是 0。知乎很多人的第一反应是怪 embedding 模型、怪大模型、怪提示词，但看一圈社区最近的实战复盘，真正的罪魁往往在这些环节的上游——文档解析层。今天把这个坑一次性讲透：文档是怎么静默"死掉"的、出问题怎么分诊、每类文档又该交给哪个解析工具。
三种静默的"死法"
PDF 是页面描述格式，“有页面"不等于"有文字”。知识库里的文档通常死在三种方式上，而且都不报错。
第一种：解析器"根本没干活"。扫描件和拍照件里，很多页面只有图像、没有可提取的文本层，不少知识库工具的默认解析器读不了这些页面，一个字都提不出来，chunk 自然就是 0，整个过程还是静默的，你以为库建好了。可以先用低成本探针判断：用 PyMuPDF 之类的工具统计前几页的可提取字符数，如果五页合计只有几十个字符，或者大部分页面为空，就该果断走 OCR 路线。
第二种：字能提出来，但版面读乱了。不少解析器遇到带文本层的 PDF，只按坐标粗暴排序文本块，双栏页面可能读成"左栏第一行→右栏第一行→左栏第二行"，两段完整文字被交叉拼接。知乎这样的文本语法看似通顺、字数看着正常，语义却已经损坏，靠检查字数根本发现不了，所以"有文本层"也不等于能直接进 RAG。
第三种：字全认对，表格关系丢了。这一种对表格密集的文档杀伤最大——采购清单、资产台账、财报都是重灾区。OCR 把"价格""99"“数量”“2"都读出来了，每个字都对，但列头、行关系、合并单元格一丢，这些字就变成一堆互不相干的数字，你问"这个商品多少钱”，模型只能编。社区对此有个很准的总结：真正卡脖子的不是"字认没认对"的字符级归属，而是"这个数字属于哪一行哪一列哪一级表头"的字段级归属。所以评估指标也得换：别看 OCR 准确率，看下游可用率——解析结果能不能直接用于向量化、Chunking 和大模型推理。知乎
翻车之后，先分诊再调参
把所有问题都归结为"OCR 不准"，会导致参数越调越乱。知乎更稳妥的做法是把链路拆成可观测的阶段，每次只改一个参数并保存样本结果：
字符层错：识别文本对照原文，字错率高 → 先查扫描分辨率和页面旋转，再考虑换检测、识别模型；
字符对但结构错：字都对，双栏串了、表格散了 → 这是版面分析和表格重建的活，普通 OCR 管线解决不了；
解析对但检索不到：正确内容就在 Markdown 里，但正确页面进不了 Top K → 查分块（标题有没有进 chunk、表格有没有被拆开、重复页眉是不是占据相似度），再查 embedding 模型是否适配当前语言。
动手修之前，建议先准备三页"金样本页"：一页纯正文、一页复杂表格、一页双栏或公式。每次换模型、调阈值都比较这三页，比盯着一张"看起来识别得不错"的成功截图靠谱得多。
每类文档该交给哪个工具
B站有位 up 主用 6 个工具跑了 30 组真实实测，按文本准确、表格还原、图片处理、版式顺序、速度成本五个维度打分，把结论整理成一张决策树，测试集和评分脚本也都开源了（github.com/wyh020612/pdf-to-md-bench）。{{{CUSTOM_HTML_TAG_4}}}主干摘出来：
有文本层的正常 PDF → 直接文本层提取类工具就行，不必过 OCR；
Office 转出来的 PDF → MarkItDown，全场最快；
学术双栏、公式较多 → Docling，全能稳健；
表格密集的年报 → Marker，准，但在 Apple Silicon 上慢；
纯扫描、无文本层 → MinerU 流水线，这次纯扫描题 5/5 全过；
扫描件加想自己拼 OCR → PaddleOCR 组合：PP-OCRv6 负责检测识别，PP-StructureV3 负责版面和表格，最后拼出规范化 Markdown。
对最后一条，这位作者的评语很直白：扫描 + 想自己拼 OCR → PaddleOCR(组合拳,单跑别用)。哔哩哔哩它的优势是模块化——检测、识别、版面、表格都是可以单独替换和调参的组件；代价是链路要自己搭。如果只想"一条命令进、Markdown 出"，MinerU 或 PaddleOCR-VL 这类 VLM 路线更省心。
不过有两个提醒。一是这份测试集里 5 份 PDF 都有文本层（NASA 那份是 NTRS 自动 OCR 过的），真正无文本层的场景没有充分覆盖，作者自己也在视频里说明了，这类跑分表看方向就好，别迷信名次。二是跑分不等于实测：PaddleOCR-VL-1.6 和 MinerU2.5-Pro 在 OmniDocBench v1.6 上分别拿到 96.33 和 95.69 分，双双超过 GPT-4o 等闭源大模型，但真有人拿 5 个复杂 PDF 去测，手写漏行、印章读字、生僻字识别这些细节上照样见差距。哔哩哔哩
另外两个容易踩的坑
一个是版本。如果你是照着 2023、2024 年的教程学，注意不要照搬旧文章中的 2.x API：PaddleOCR 3.x 的流水线类、参数和结果对象已有变化。知乎生态漂移也存在：RapidOCR 这类第三方封装，有些版本的默认模型和默认参数与 PaddleOCR 并不一致，PP-OCRv5 之后两者的默认模型甚至也不相同。知乎结果对不上时先核对默认配置，再判断对错。
另一个是安全。扫描文档里经常有身份证号、合同、财务数据和内部印章，日志不要打印完整 OCR 文本，临时图片和 Markdown 要限定目录、设置生命周期，用远程解析服务的话，先确认文件会去哪里、保存多久、怎么删除。
十分钟自查清单
重建向量库之前，先把这四步做完，前后不超过十分钟：
探针：统计前几页可提取字符数，几页合计只有几十个字就走 OCR 路线；
抽样：纯正文、复杂表格、双栏或公式三页金样本，逐页对照原文人工核一遍；
对题：通过标准是"正确页面进入 Top K、答案能引用到正确段落"，不是"某一页看起来识别得不错"；
记录：把解析器版本、模型版本、关键参数写进任务版本，结果变了才能查。
值得继续盯的信号
百度 7 月开源了 HPD-Parsing：1B 级模型的解码步数最高压缩 18 倍，文档解析效率提升 3 倍。知乎VLM 解析路线正在从"能认"走向"认得快"，本地部署的成本结构会变，扫描量大的场景值得重新评估；
大模型直读文档是解析工具的真实竞争路线，社区已经开始出现对比实测，文档量小、单份价值高的场景，可以先比比 token 成本和部署成本哪边更划算；
端侧场景可以留意 PP-OCRv6，Tiny 档模型参数只有 1.5M。它在本地 M4 浏览器环境下单图端到端延迟能做到 97ms。哔哩哔哩浏览器内翻译、截图取字这类轻量玩法会越来越好用。
一句话收尾：知识库的质量上限，不取决于大模型多贵，而取决于文档真正进了多少库。重建向量库之前，先花十分钟把这三页探了。
