Adaptive PDFs: Embedding Markdown for LLM-Ready Documents

Adaptive PDFs 使单个 .pdf 文件能够服务于两类不同的受众:看到视觉格式化文档的人类,以及提取干净、结构化 Markdown 的机器(如 LLMs)。这种方法解决了文本提取器在从通常仅存储字形坐标和字体大小的视觉格式中重建文档层级结构的常见问题。

How Adaptive PDFs Work

Adaptive PDFs 利用了 PDF 规范中的一个属性(自 PDF 1.4,2001 年起可用),该属性允许为标记内容定义替换文本。虽然 PDF 渲染器会忽略此属性并绘制视觉内容流,但兼容的文本提取器会返回替换文本而不是视觉文本。

此功能最初旨在用于连字或无法自然映射到 Unicode 的字符。Adaptive PDFs 在文档级别应用此功能,通过 marked-content 序列将替换文本附加到内容流中。这确保了像 PyMuPDF 和 Poppler 这样的工具可以返回结构化的 Markdown(包括标题、表格和列表),而视觉外观在 Adobe Acrobat 或 macOS Preview 等查看器中保持不变。

Performance and Extraction Benchmarks

基准测试表明,嵌入结构化 Markdown 不会对文件大小或 LLMs 的 token 计数产生显著影响,但它极大地提高了信息密度。

Token and Size Impact

Document Pages Size Δ Normal Token Smart Token
Resume 1 +15.7% 650 668
Textbook 417 -8.5% 193,064 195,858
Novel Chapter 38 +4.7% 16,472 15,958
Research paper 18 +2.5% 7,897 7,897

Key Findings

  • Token Efficiency: Token 计数在普通 PDF 和 smart PDFs 之间大致相当。其价值在于 token 现在携带了显式的结构(例如,## OverviewOverview),从而减少了 LLMs 需要猜测文档层级结构的需要。
  • File Size: 体积开销通常在个位数百分比范围内。某些体积的减少(如教科书示例所示)归功于 PyMuPDF 的 garbage=3 设置等通用 PDF 优化工具,而非该技术本身。
  • LLM Verification: 使用 ChatGPT 和 Claude 进行测试表明,当要求它们复制粘贴原始文本时,两个模型都返回了嵌入的 Markdown 格式(例如 #- 项目符号),这证实了模型正在访问嵌入层。

Technical Considerations and Limitations

虽然 Adaptive PDFs 提供了一种流线化的方式来交付结构化数据,但存在若干技术和安全方面的考虑。

Extractor Compatibility

此方法的有效性取决于提取器是否遵循替换文本属性。如果工具忽略此属性,它将退回到标准的、混乱的提取过程,且用户可能不会意识到结构化版本是可用的。

Security and Prompt Injection

由于替换文本对人类读者是不可见的,它为“prompt injection”或恶意指令创建了一个潜在的向量。用户可以嵌入针对 LLM 的隐藏命令(例如,指示招聘机器人推荐某位候选人),而人类审核员永远不会注意到。

Comparison to Tagged PDFs

虽然作者指出许多常见的导出工具(如 Chrome 的 print-to-PDF)不生成标签,但一些用户指出 LaTeX 是能够生成 tagged PDFs 的,尽管它通常被利用率较低。此外,美国政府指令(Section 508)已经要求 PDF 中必须具备用于屏幕阅读器和辅助技术的语义结构。

Community Perspectives

围绕该技术的讨论突出了文档格式之间的一种根本性紧张关系。一些人认为 PDF 格式本质上不适合机器阅读,而应该使用 HTML 或其他标记语言。其他人则将其视为一个在文档越来越多地被 AI agents consumed by AI agents 的世界中必要的桥梁。

"Optimizing for humans vs. agents feels like the new wave of Desktop vs. Mobile... agents are going to win even faster."

项目代码可在 github.com/iminoaru/adaptivepdf 获取。

Sources