Zerox：用视觉大模型重塑文档 OCR 的开源利器

想象一下：你手里有一份 200 页的扫描版 PDF 合同，里面有密密麻麻的表格、印章和手写批注。传统 OCR 工具要么把表格搅成一团乱码，要么把印章当成背景噪音忽略不计。Zerox 告诉你：别费劲转文字了，让视觉大模型直接"看"这份文档——它比你想象的更懂什么叫"文档"。

为什么文档 OCR 这么难？

传统的 OCR 技术（如 Tesseract）诞生于上世纪 80 年代，设计初衷是处理干净的打字文档。这类工具对扫描质量要求极高，一旦遇到以下情况就容易"发疯"：

• 复杂版式：双栏排版、图文混排、跨越多页的表格
• 低质量扫描：倾斜页面、水印干扰、反光、褶皱
• 特殊元素：印章、签字、手写批注、高亮标注
• 多样格式：PDF、DOCX、图片、Excel 表格混合

问题的根源在于：传统 OCR 把文档当成"一维文字流"来处理，丢失了文档的视觉结构信息。而文档本质上是一种视觉媒体——它的意义很大程度上来自排版、层级和空间关系。

Zerox 的解决思路：视觉大模型 + PDF 转图片

Zerox 的核心逻辑出奇地简单：

1. 把文档转成一系列图片：无论输入是 PDF、DOCX 还是其他格式，统一转成高清图片序列
2. 逐页喂给视觉大模型：用 GPT-4o、Gemini、Claude 等模型的视觉理解能力，直接从图片中提取 Markdown
3. 聚合输出：把每页的 Markdown 结果合并成完整的文档

这个思路的反直觉之处在于：为什么不用文字识别，反而要用视觉模型？答案在于，视觉大模型对文档结构的理解远超传统 OCR——它能识别表格的行列关系、理解标题层级的缩进、判断注释和正文的位置。这些都是传统 OCR 的盲区。

核心功能：不止于文字提取

格式保持（Maintain Format）

最让 Zerox 引以为傲的功能是 maintainFormat 模式。标准模式下，每页图片独立处理；开启格式保持后，Zerox 会把前一页的 Markdown 输出作为上下文，传入下一页的提示词中。这解决了跨页表格这个 OCR 领域的老大难问题：上一页表格的下半部分在下一页开头，标准模式会把它们当成两张独立的表格。格式保持模式让模型知道"这是在延续上一页的表格"，从而正确合并。

结构化数据提取（Schema Extraction）

Zerox 支持 JSON Schema 驱动的结构化提取。开发者可以定义一个 schema，告诉 Zerox"我只需要发票号、日期、总金额这三个字段"，它会直接返回干净的 JSON，而不是一整页混着格式标记的 Markdown。这对于 RAG（检索增强生成）流水线尤其有价值——从大量非结构化文档中提取特定字段，Zerox 比正则表达式+OCR 的传统方案可靠得多。

多模型支持

Zerox 的另一大优势是多模型路由。它不绑定任何一家模型提供商，支持以下组合：

• OpenAI: GPT-4o、GPT-4o-mini、GPT-4.1 系列
• Azure OpenAI: 企业级 GPT-4 Vision 部署
• AWS Bedrock: Claude 3 Haiku/Sonnet/Opus（AWS 专区）
• Google Gemini: Gemini 1.5/2.0 系列

这意味着企业可以根据成本、隐私合规、数据主权等需求，自由选择最适合的模型组合，而无需修改业务代码。

高级图像处理

Zerox 包含一系列图像预处理能力，改善输入图片质量：

• 自动方向校正（correctOrientation）：识别并旋转倒置的页面
• 边缘裁剪（trimEdges）：去除扫描仪产生的白边
• 图像密度控制（imageDensity）：300 DPI 是默认推荐值
• HEIC 格式支持：iOS 截图的原生格式，无需转换

技术架构：双 SDK、双路径

Zerox 项目同时维护 Node.js 和 Python 两个 SDK，体现了对不同开发者生态的重视。

Node.js SDK（主要实现）

Node 版使用 TypeScript 开发，依赖链中值得关注的技术组件：

• pdf2pic + sharp：PDF 转图片的核心工具
• tesseract.js：在浏览器/Node 中运行的 Tesseract OCR（用于预检测）
• libreoffice-convert：LibreOffice 引擎，处理 DOCX/Excel 等 Office 格式
• xlsx：直接解析 Excel 文件
• heic-convert：处理 HEIC 格式
• @openai/sdk + @aws-sdk/client-bedrock-runtime：多模型客户端

项目采用 monorepo 结构，node-zerox/ 是 TypeScript 源码，py_zerox/ 是 Python 实现，共享 shared/ 中的通用逻辑。构建系统用 Makefile 统一管理，支持 pre-commit 检查、commitlint 规范。

Python SDK

Python 版通过 litellm 库实现多模型统一调用，litellm 是一个 LLM 路由中间件，屏蔽了不同模型提供商的 API 差异。PDF 处理依赖 pdf2image + poppler（系统级依赖）。Python SDK 的优势在于可以无缝集成到 FastAPI、Django 等 Python Web 框架中。

部署体验：门槛比想象中低

Zerox 没有提供 Docker 支持，这是目前最大的遗憾。部署需要手动处理两类系统依赖：

• Node 版：需要 graphicsmagick（处理 PDF 转图片）和 ghostscript
• Python 版：需要 poppler-utils（pdf2image 的后端）

安装本身很简单：npm install zerox 或 pip install py-zerox，但系统依赖的安装在不同操作系统上有差异，Linux 下通常是一行 apt-get 命令，macOS 需要 Homebrew，Windows 则建议用 WSL2。这增加了首次部署的学习成本。

好在项目提供了完整的 preinstall 脚本，会自动检测并提示缺失的依赖。项目使用 postinstall 钩子在 npm 安装后自动运行依赖检查，减少了"装上了但跑不起来"的挫败感。

应用场景与局限

Zerox 最适合以下场景：

• RAG 流水线：将 PDF/DOC 合同、报告、手册转为 Markdown，供 LLM 检索
• 发票/表单处理：用 Schema Extraction 提取结构化字段
• 历史文档数字化：扫描版书籍、报纸、杂志的全文提取
• 多格式转换：任意办公文档转 Markdown

局限性也需要正视：

1. 成本：每页文档对应一次 LLM API 调用，200 页 PDF 就是 200 次调用。GPT-4o-mini 的单价虽低，大批量处理时仍不可忽视。
2. 速度：视觉模型的推理速度远慢于 Tesseract 单线程 OCR，处理大批量文档时耗时显著。
3. 准确性：虽然远超传统 OCR，但在极小字号、手写体、高度图像化的 PDF（如信息图海报）上仍有出错概率。
4. 数据隐私：文档内容会发送到模型提供商的 API，涉及敏感数据时需谨慎评估合规性。

行业意义：重新定义文档理解的第一步

Zerox 的出现反映了一个更大的趋势：视觉大模型正在接管传统计算机视觉领域的各项细分任务。OCR 曾是计算机视觉的经典问题，如今它被重新定义为"文档图像理解"——不是识别文字，而是理解文档的结构与语义。

从 2024 年 7 月开源至今，Zerox 已在 GitHub 获得超过 12,000 颗星，845 个 Fork，88 个 open issues 说明社区活跃度相当高。作为 GetOmni 公司的开源旗舰项目，Zerox 同时提供商业化托管服务（getomni.ai），体现了开源获客 + SaaS 变现的经典路径。

对于 AI 开发者而言，Zerox 是构建文档处理流水线时值得优先考虑的基础组件；对于 AI 爱好者，它展示了"用 AI 方法解决 AI 问题的巧妙路径"——与其在文字层面和 OCR 错误搏斗，不如让视觉大模型直接理解文档的视觉本质。