Loop Engineering with Adaptive PDF Parsing: Start Cheap, Pay for a Heavier Parser Only When the Page Needs It

基于自适应 PDF 解析的循环工程：从低成本开始，仅在页面需要时才调用昂贵的解析器

Large Language Model Loop Engineering with Adaptive PDF Parsing: Start Cheap, Pay for a Heavier Parser Only When the Page Needs It Enterprise Document Intelligence [Vol.1 #10A] – The escalation cascade and the free, deterministic checks that flag a failed parse before you pay for a deeper one angela shi Jul 18, 2026 32 min read Share 大语言模型循环工程与自适应 PDF 解析：从低成本开始，仅在页面需要时才调用昂贵的解析器。企业文档智能 [第1卷 #10A] —— 升级级联机制与免费的确定性检查，在支付昂贵解析费用前识别解析失败。作者：Angela Shi，2026年7月18日，阅读时长32分钟。

Photo by Binyamin Mellish, via Pexels. The good parser is slow and expensive. The fast parser misses the table the answer lives in. Run the heavy one on every page of a 200-page report and you pay for 200 pages to rescue three. Run the cheap one everywhere and the single flattened table sinks the answer. Neither setting is right for the whole document, because the document is not uniform: most pages are plain text a fast parser handles fine, and a few carry the tables that need the expensive one. The page itself should decide how hard it gets parsed. 图片来源：Binyamin Mellish (Pexels)。优秀的解析器速度慢且昂贵，而快速解析器往往会漏掉包含答案的表格。如果对一份200页的报告每一页都运行重型解析器，你将为200页的费用买单，只为挽救其中3页的内容。如果到处都运行廉价解析器，那么一个扁平化的表格就可能导致答案丢失。这两种设置都不适用于整个文档，因为文档并非均匀分布：大多数页面是快速解析器可以轻松处理的纯文本，而少数页面则包含需要昂贵解析器处理的表格。页面本身应该决定它需要多大程度的解析。

This article is the first of two parts on adaptive parsing, in Part III of Enterprise Document Intelligence, a series that builds an enterprise RAG system from four bricks: document parsing, question parsing, retrieval, and generation. This part builds the escalation cascade and the cheap checks that decide when a parse is good enough; the second part, Loop engineering with adaptive parsing in action: parsing flat tables with Azure and figures with a vision LLM (link to come), walks the deeper parsers in action. 本文是关于自适应解析的两部分文章中的第一部分，属于“企业文档智能”系列第三部分。该系列通过四个模块构建企业级 RAG 系统：文档解析、问题解析、检索和生成。本部分构建了升级级联机制和用于判断解析是否合格的廉价检查；第二部分《自适应解析的循环工程实践：使用 Azure 解析扁平表格及使用视觉 LLM 解析图表》（链接待发布）将展示深度解析器的实际应用。

📓 The runnable companion runs the cheap checks yourself: you call pre_parse_signals on each page of the Attention paper, print the per-page flags (char_count, image_count, the flat-table fingerprint on line_df), and watch which pages route to a heavier parser before a single dollar is spent on one. On GitHub: doc-intel/notebooks-vol1. 📓 可运行的配套代码让你亲自执行这些廉价检查：你可以对《Attention》论文的每一页调用 pre_parse_signals，打印每页的标志（字符数、图像数、line_df 上的扁平表格指纹），并观察哪些页面在花费一分钱之前就被路由到了更高级的解析器。GitHub 地址：doc-intel/notebooks-vol1。

PyMuPDF parses a page in five milliseconds for free. A vision LLM on the same page can cost ten thousand times more and take ten seconds. When the question lives in plain prose, the cheap parser wins. When the answer hides inside a table, a figure, a scanned region, or a flattened layout, the cheap parser silently returns nothing useful and the LLM confidently answers the wrong question. Running the heaviest parser on every page is wasteful. Running the cheapest one everywhere is wrong. The trick is to start cheap and escalate only when something says the cheap parse missed the answer. PyMuPDF 解析一页文档仅需 5 毫秒且免费。而在同一页面上使用视觉 LLM 的成本可能是前者的万倍，且耗时 10 秒。当问题存在于纯文本中时，廉价解析器胜出。当答案隐藏在表格、图表、扫描区域或扁平化布局中时，廉价解析器会默默地返回无用信息，而 LLM 则会自信地回答错误的问题。对每一页都运行最重的解析器是浪费，到处都运行最廉价的解析器则是错误的。诀窍在于从廉价解析开始，仅在有迹象表明廉价解析漏掉答案时才进行升级。

That signal has to come from the pipeline itself: a chain of checks against the parse output, the question, and the LLM’s own footprint when it tries to use what came out. The way around this is a feedback loop the pipeline builds for itself. Start with the cheapest parser. Evaluate its output at every check of the pipeline. Escalate to a deeper parser only when at least one check flags the cheap parse as insufficient for the question. 该信号必须来自流水线本身：即针对解析输出、问题以及 LLM 在尝试使用解析结果时留下的痕迹进行一系列检查。解决此问题的途径是流水线为自己构建一个反馈循环。从最廉价的解析器开始，在流水线的每个检查点评估其输出。仅当至少有一个检查点标记廉价解析不足以回答问题时，才升级到更深层的解析器。

The evaluation is not one check at one place. It is a cascade: pre-parsing metadata routes most of the corpus before any extraction; parsing-time outputs flag flattened tables and opaque figures; retrieval scoring catches anchors that drift; generation flags what survived all of the above. Each check is cheaper than the next, more reliable than the next, and asks its own question: “did the parser produce enough to answer?”. 评估并非在单一位置进行一次检查，而是一个级联过程：预解析元数据在提取前路由大部分语料；解析时输出标记扁平表格和不透明图表；检索评分捕获偏移的锚点；生成阶段标记出所有上述环节的幸存者。每一项检查都比下一项更廉价、更可靠，并提出自己的问题：“解析器产生的内容足以回答问题吗？”

1. When cheap parsing isn’t enough. Adaptive parsing runs in two phases. Phase one is initialisation: pick a baseline parser per document, based on what the document is (native PDF, scan, Word export). In a platform context this fires at ingestion: every new document gets its baseline parse on arrival, so the system always has a first textual layer to work with, even for scanned PDFs where the baseline has to be an OCR engine because PyMuPDF would return empty.
2. 当廉价解析不够用时。自适应解析分为两个阶段。第一阶段是初始化：根据文档类型（原生 PDF、扫描件、Word 导出件）为每个文档选择基准解析器。在平台环境中，这在摄入时触发：每个新文档在到达时都会进行基准解析，因此系统始终拥有第一层文本可供使用，即使对于必须使用 OCR 引擎作为基准的扫描版 PDF（因为 PyMuPDF 会返回空值）也是如此。

Phase two is the cascade: run cheap deterministic checks on the baseline’s output and escalate the pages that fail to a deeper parser. Most pages stay on the baseline; the few that fail a check get the richer treatment they actually need. The pipeline always starts cheap on phase one. PyMuPDF on native PDFs, a free OCR engine on scans. Both produce the same line_df shape, so the rest of the pipeline (question parsing, retrieval, generation) does not know which parser ran. That works most of the time. It fails on a small but predictable set of content shapes, and phase two has several places to catch the failure, ordered from cheap deterministic checks on the parser’s outputs to a final-line-of-defence LLM call at generation time. 第二阶段是级联：对基准输出运行廉价的确定性检查，并将失败的页面升级到更深层的解析器。大多数页面保留在基准解析层；少数未通过检查的页面则获得它们真正需要的深度处理。流水线在第一阶段总是从廉价解析开始：原生 PDF 使用 PyMuPDF，扫描件使用免费 OCR 引擎。两者产生相同的 line_df 结构，因此流水线的其余部分（问题解析、检索、生成）无需知道运行的是哪个解析器。这在大多数情况下有效。它仅在一小部分可预测的内容结构上失败，而第二阶段有多个位置可以捕获这些失败，顺序从针对解析器输出的廉价确定性检查，一直到生成阶段作为最后一道防线的 LLM 调用。

1.1. Cheap parsing: PyMuPDF for native PDFs, free OCR for scans. Article 5A (what to read in a PDF) introduced PyMuPDF (imported as fitz) as the default for native-digital PDFs: 5 seconds per document, no API calls, no cost, and a clean line-level extraction with bounding boxes. The Attention paper, the NIST Cybersecurity Framework, most office exports, most arXiv papers, almost every contract authored in Word or LaTeX: PyMuPDF is the right starting point. The other half of the corpus is scans: photographed pages, faxed documents, image-only PDFs. PyMuPDF returns empty text on those. A free OCR engine like Tesseract or PaddleOCR fills the gap: same line_df shape out, but slower (minutes per document) and weaker on structure. 1.1. 廉价解析：原生 PDF 使用 PyMuPDF，扫描件使用免费 OCR。第 5A 篇文章（PDF 阅读指南）介绍了将 PyMuPDF（导入为 fitz）作为原生数字 PDF 的默认解析器：每份文档 5 秒，无需 API 调用，零成本，且能提供带有边界框的清晰行级提取。无论是《Attention》论文、NIST 网络安全框架、大多数办公文档导出件、大多数 arXiv 论文，还是几乎所有用 Word 或 LaTeX 编写的合同，PyMuPDF 都是正确的起点。语料库的另一半是扫描件：拍摄的页面、传真文档、纯图像 PDF。PyMuPDF 在这些文件上返回空文本。像 Tesseract 或 PaddleOCR 这样的免费 OCR 引擎填补了这一空白：输出相同的 line_df 结构，但速度较慢（每份文档需几分钟），且在结构识别上较弱。