Documind: 用 AI 把 PDF 变成结构化数据

一、痛点场景：为什么需要 Documind

想象一下：你是一家保险公司的理赔专员，每天要处理上百份 PDF 格式的事故报告、医疗单据和发票。每一份文档里关键数据（日期、金额、诊断结论）都以自然语言形式散落在 PDF 的各个角落，根本没法直接导入 Excel 或数据库。传统的 OCR 只能识别文字，无法理解"这张发票的总金额是 2340 元"这样的语义信息；人工录入一份文档平均耗时 15 分钟，效率极低。

Documind 正是为解决这个痛点而生：它用大型语言模型（LLM）理解 PDF 的语义内容，再按你定义的 Schema 提取出结构化的 JSON 数据——就像给 PDF 装了一个"智能读卡器"。

二、项目背景与起源

Documind 由独立开发者 Tami 创建，GitHub 社区代号 DocumindHQ。该项目最初于 2024 年初发布，依托于另一个优秀的开源项目 Zerox（由 MIT 协议授权）——Zerox 负责将 PDF 高保真转换为 Markdown，Documind 则在此基础上叠加了 LLM 驱动的 Schema 提取层。

项目的技术选型非常务实：主体语言为 JavaScript/Node.js，依赖生态成熟的 npm 生态（如 pdf2pic、sharp、tesseract.js），而非从零造轮子。这使得它天然适合嵌入到现有 Node.js 后端服务中。

Documind 还提供托管版本（documind.xyz），处于 beta 测试阶段，可通过 Discord 社区申请访问资格。

三、核心功能：Schema 驱动的数据提取

Documind 的工作流程非常清晰，五步完成提取：

1. 文件预处理：支持 PDF、DOCX、PNG、JPG、TXT、HTML 六种格式，通过 pdf2pic 将 PDF 转图片、用 sharp 压缩、tesseract.js 做 OCR 识别
2. 高保真转换：调用 OpenAI GPT-4o-mini（或本地 Llama3.2-vision）将文档内容转换为 Markdown 格式，保留表格、标题等结构化信息
3. Schema 验证：用 zod 库验证用户传入的 Schema 定义是否合法，支持 string/number/array/object/boolean/enum 六种字段类型
4. LLM 提取：将 Schema 和 Markdown 一起发给 LLM，LLM 按 Schema 格式输出 JSON 结果
5. 输出格式化：返回 success / pages / data / fileName / markdown 五个字段，其中 data 即结构化提取结果

Schema 模板：开箱即用

Documind 内置了三个常用模板：

import { extract } from 'documind';
const result = await extract({
  file: 'invoice.pdf',
  template: 'invoice'
});
console.log(result.data);

自动 Schema 生成（AutoSchema）

如果你不知道该定义什么字段，可以开启 autoSchema: true，Documind 会先用 LLM 分析文档内容，自动推断出合适的 Schema 再执行提取。这个功能特别适合对陌生文档做快速摸底。

四、技术架构：npm Monorepo 双 Workspace

Documind 采用 npm workspaces 管理 Monorepo 结构，根目录包含两个子包：

documind/
├── core/                    # LLM 抽象层
│   └── src/providers/       # OpenAI / Google / Ollama 三种后端
│       ├── openAI.ts        # GPT-4o-mini 默认
│       ├── google.ts        # Gemini 支持
│       └── ollama.ts        # 本地 Llama3.2-vision
│
└── extractor/               # 文档处理核心
    └── src/
        ├── autoschema/      # 自动生成 Schema 模块
        ├── extractors/      # 各 LLM provider 的提取实现
        ├── services/
        │   ├── extract.js   # 主提取服务（核心入口）
        │   ├── formatter.js # Markdown 格式化
        │   └── templates.js # 内置模板管理
        ├── utils/           # 工具函数
        └── prompts.js       # LLM 系统提示词

这种架构的优势是解耦：core 包负责 LLM 通信，extractor 包负责文档处理，两者通过 extract.js 中的 getExtractor() 工厂函数衔接。未来要接入新的 LLM，只需在 core/src/providers/ 下新增一个文件即可，无需改动核心逻辑。

五、本地 LLM 支持：隐私优先

对于处理敏感财务、医疗等数据不希望上传到 OpenAI 的场景，Documind 支持切换到本地模型：

import { extract } from 'documind';
process.env.OLLAMA_BASE_URL = 'http://localhost:11434';
const result = await extract({
  file: 'contract.pdf',
  schema: mySchema,
  model: 'llama3.2-vision'
});

本地模式依赖 Ollama 运行时，需提前拉取模型（ollama pull llama3.2-vision）。这个功能对隐私敏感型企业场景有直接价值。

六、部署与上手

安装方式：npm install documind

系统依赖（必须预装）：Ghostscript（PDF 处理）和 GraphicsMagick（图片处理），macOS 用 brew，Ubuntu 用 apt。

最小使用示例：定义 Schema → 调用 extract → 获得 JSON 结果，代码不超过 10 行。

部署评分：无 Docker/Compose，无 Web UI，纯 Node.js npm 包，适合集成到现有 Node.js 服务中作为依赖包使用。

七、局限与争议

1. 重度依赖 OpenAI：默认使用 GPT-4o-mini，切换本地模型需手动配置 Ollama，对国内用户不友好
2. 系统依赖繁琐：Ghostscript + GraphicsMagick 两个系统级依赖增加了 CI/CD 配置成本
3. 多页文档性能：超过 50 页的 PDF 产生大量 token 消耗，上下文窗口可能成为瓶颈
4. Schema 调试成本：Schema 设计不当会导致提取质量严重下降

八、行业意义

文档智能提取（IDP）是 RPA 的下一个演进方向。传统 OCR + 规则引擎只能处理高度结构化的表单，而 LLM 驱动的方案可以处理半结构化甚至非结构化的文档。Documind 作为少数完全开源（AGPL-3.0）的 IDP 方案，为开发者提供了透明、可审计的数据处理管道，避免了闭源 SaaS 的"黑盒"风险，对金融、医疗、政府类需要私有化部署的客户尤为重要。

核心一句话：用 Schema 定义的"结构化意图"引导 LLM，从任意格式文档中精准提取结构化数据——介于通用 OCR（太浅）和定制化 NLP 管道（太重）之间的最佳平衡点。