从扫描 PDF 到 JSON 的多模型提取、校验与成本控制
本文为 Pitt Zhang 基于实际 AI 工程实践与个人经验形成的原创文章，首次发布于个人技术博客 https://api-cloud.cc/。
本文允许个人、媒体、技术社区及其他非恶意用途进行引用、讨论、转载或二次分析，但应明确注明原作者与原始出处。
引用或转载时，请至少保留以下信息：
作者：Pitt Zhang
原文首发：2026 年 9 月 17 日（北京时间）
原始出处：https://api-cloud.cc/
可以对本文观点进行批评、验证、反驳或进一步研究，但不应删除原始作者信息后将文章整体或核心原创分析冒充为他人原创成果。
本次使用一份真实类型的个人征信报告作为 POC 样本。样本共 39 个 PDF 页面，属于扫描/图片型 PDF，本身没有可靠的文本层，因此不能简单依靠 pdftotext、PDF Parser 等传统方式直接完成结构化提取。
目标并不是简单地"把 PDF 识别成文字"，而是将其中的个人基本信息、账户概要、贷款账户、信用卡账户、余额、授信额度、逾期信息、还款状态矩阵、查询记录等内容，最终转换为可供程序继续处理的标准 JSON 数据。
POC 已经证明这种需求在技术上可以实现，但同时也暴露出了典型问题：水印覆盖、复杂表格、密集数字、跨页账户、还款月份矩阵以及低清晰度区域都会造成漏识别和错误识别。
因此，正式系统不能依赖"一个大模型 + 一个 Prompt + 一次输出"，而应该构建成一条完整的 AI 文档处理流水线。
整个系统建议采用：
这里最重要的原则是：
AI 负责识别与理解，程序负责流程、约束、校验和追踪。
不能让 AI 同时承担提取、判断、合并、纠错和最终确认，否则数据量一上来，错误很难控制。
原始 PDF 首先保持只读，并计算 SHA256，对文件进行编号。
程序自动检查：
扫描型 PDF 按页转为 PNG/JPEG。
建议：
对于水印页面，不直接"修改原件"，而是创建识别专用副本，例如：
让多个版本分别进入 OCR/VLM，再比较结果。
这样既保留原始证据，又可以提高识别成功率。
39 页不能简单一次扔给模型。
应该生成：
首先判断每页类型，例如：
页面可分成：
不同页面调用不同 Prompt 和 JSON Schema。
这么做以后，即使第 17 页识别失败，也只重新处理第 17 页，而不用重新处理整份报告。
生产系统不能只有：
至少应该保存成：
进一步还可以保存：
最终任何一个字段都可以反查：
这对于金融数据比"模型回答得像不像"重要得多。
这是整个系统必须写进规则里的约束。
例如模型无法确定：
究竟是哪一个，就禁止模型自行推断。
输出：
金融类结构化数据里：
漏一个字段可以进入复核队列；猜错一个金额可能污染整个后续业务。
征信报告最难处理的部分之一不是姓名、身份证号，而是大量类似：
不能保存成：
而应标准化为：
第一层只负责忠实提取。
N / 1 / 2 / C / * 等字符的业务解释放到第二层处理，防止识别模型一边 OCR、一边解释、一边修改原数据。
这里不能一开始就拍脑袋决定"Claude 最好""GPT 最好"或者"千问最好"。
POC 第一批 20～50 份真实样本，建议让多个模型独立跑完整结果。
例如：
然后生成真正的数据：
建立模型的 Error Profile。
例如经过真实数据测试后可能发现：
到了生产阶段，就不应该继续让所有模型每份全部跑一遍。
生产架构转为：
这就是整个系统真正能够盈利的关键。
以下价格按 2026 年 9 月公开 API 标价，模型厂商随时可能调整，因此正式项目应由程序直接记录每次 API 返回的 usage，不能长期依赖人工预算表。
| 模型 | 输入 / 100万 Token | 输出 / 100万 Token | 适合定位 |
|---|---|---|---|
| OpenAI GPT-5.6 Sol | $4 | $20 | 高质量复核/疑难页 |
| OpenAI GPT-5.6 Terra | $2 | $12 | 中档复核 |
| OpenAI GPT-5.6 Luna | $0.20 | $1.20 | 大批量低成本任务 |
| OpenAI GPT-6 Astra | $10 | $50 | 极疑难仲裁，不建议全量 |
| Claude Opus 4.8 | $5 | $25 | 高质量理解/终审 |
| Gemini 3.1 Pro | $2 / $4* | $12 / $18* | 多模态复核 |
| Grok 4.6 | $2 | $6 | 第二/第三模型交叉验证 |
| DeepSeek Flash | $0.15～0.30 | $0.60～1.20 | 低成本批量，支持 Vision |
| Qwen3-VL-30B Instruct | ¥0.75 | ¥3 | 国内主力 VLM |
| Qwen3-VL-Plus | ¥1 起 | ¥10 起 | 高质量国内复核 |
| Qwen-VL-OCR | ¥0.30 | ¥0.50 | OCR 第一层 |
| GLM-4.6V | ¥1～2 | ¥3～6 | 国内视觉复核 |
| GLM-4.6V-FlashX | ¥0.15～0.30 | ¥1.5～3 | 大批量视觉处理 |
* Gemini 3.1 Pro 在超过 200K 上下文后进入更高价格区间。
OpenAI 官方目前列出的 GPT-5.6 Sol 为 $4/$20、Terra 为 $2/$12、Luna 为 $0.20/$1.20；更高端的 GPT-6 Astra 为 $10/$50。[1] Claude Opus 4.8 当前标准 API 标价为 $5 输入、$25 输出，Batch 价格约为标准模式一半。[2] Gemini 3.1 Pro 标准价格为 $2/$12，超过 200K 输入时为 $4/$18；Google 同样提供 Batch 模式。[3] Grok 4.6 当前短上下文价格为 $2/$6。[4]
国内模型成本明显更适合承担全量处理。DeepSeek Flash 当前支持 Vision，缓存未命中输入峰值 $0.30/MTok、输出峰值 $1.20/MTok，非高峰减半。[5] 阿里云目前 Qwen-VL-OCR 北京区原价只有 ¥0.30/MTok 输入、¥0.50/MTok 输出；Qwen3-VL-30B Instruct 为 ¥0.75/¥3，Qwen3-VL-Plus 起步约 ¥1/¥10。[6] 智谱 GLM-4.6V 当前约 ¥1～2 输入、¥3～6 输出，FlashX 更低。[7]
这里必须纠正一个很容易犯的错误：
不能简单说"39 页 × 某个固定价格 = 一份多少钱"。
视觉模型最终按其图片 Token 化方式、分辨率、裁切次数、输出 JSON 长度、推理 Token 和重试次数计费。
Claude 官方给出的参考算法是，在图片不需要再次缩放的情况下，视觉 Token 大致可按：
计算，一张约 1.15MP 的图片大约 1,600 Token。[8]
因此，可以先给这份 39 页样本建立一个预算模型。
假设完成一次完整处理最终产生：
那么四个海外高能力模型——例如 GPT-5.6 Sol、Claude Opus 4.8、Gemini 3.1 Pro、Grok 4.6——各完整跑一次的纯 API 基础成本，大体属于几美元/份，而不是几十美元/份。
加入：
以后，我会把 四模型全量 POC 的工程预算先按约 $3～$8/份准备；极端疑难件可以更高。
所以：
这也解释了为什么：
四个高端海外模型全部全量跑，可以作为第一阶段测试方案，但不适合作为低客单价业务的长期生产架构。
进入生产后，我更倾向于：
如果金融数据的适用合规要求、机构内控或数据跨境条件不允许原始数据发送境外，那么 GPT、Claude 等境外 API 直接退出生产数据链路，改成境内模型、境内云或者私有化 VLM 完成全部复核。
所以架构本身不能绑定某一家模型。
按照当前国内多模态 API 单价，单纯计算 Token，39 页文档一次普通识别的理论模型成本可以非常低，甚至低于 1 元。
但绝对不能拿理论 Token 成本直接当商业成本。
真实成本包括：
因此对于这种 39 页复杂征信报告，我会把第一版生产系统的目标设成：
这不是厂商报价，而是项目预算目标。
最终必须靠真实的 50～100 份样本把数字跑出来。
答案不是简单的"能"或者"不能"。
如果：
那么还有约：
用于研发摊销、销售、税费、管理成本和利润。
如果一个月：
没有太大意义。
但如果：
问题就完全不同。
因为它已经从"一个人拿 Codex 手工处理文件"，变成：
高并发、低单位成本的金融文档处理平台。
所以这个项目最关键的问题最终不是：
AI 能不能做？
答案已经很明确：可以。
真正应该问的是：
这些数字决定项目有没有商业价值。
正式投入以前，我不会直接开发完整 UI，也不会先买大量 API 额度。
先拿 20～50 份脱敏真实样本。
所有候选模型全部独立处理。
记录：
最终直接形成：
然后才能知道：
谁负责主力提取，谁负责复核，谁只值得处理水印，谁虽然最聪明但不值得全量使用。
这是第一阶段最有价值的数据资产。
最终不要只输出一个 result.json。
应该至少有：
例如：
这时它才不是一个 Demo，而是一套可以接 API、Web UI、企业系统和批量任务的平台。
这个系统最终也不应该局限在"征信报告 OCR"。
底层能力实际上是：
复杂金融文档 → 标准数据 → 自动校验 → 异常识别 → 人工闭环。
换掉 Schema 和业务规则以后，同一套架构还可以处理：
再向上一层，才可以连接企业已有的规则引擎、风控平台和人工审核流程。
AI 不应该直接替金融机构作出授信、拒贷等最终决定；这里解决的是数据提取、结构化、校验和审核辅助问题。
这个需求本身并不难证明"能不能做"。
能做。
真正困难的是把它从：
一个人 + Codex/Claude + 手工复制文件 + 不断重新问模型
变成：
批量任务 + 多模态模型 + 标准 JSON + 自动校验 + 异常路由 + 成本控制 + 人工兜底。
第一阶段，多模型全部上，目的不是盈利，而是建立 Benchmark，找出每个模型真正的错误边界。
第二阶段再把系统收敛成：
低成本模型处理 90% 的普通数据，高能力模型只处理 10% 的异常数据，人只处理最后 1%～5% 真正无法判断的问题。
如果真实需求只有每月几十份，这套工程没有必要做得很重。
如果稳定达到 1000 份/月以上，就值得开始认真计算自动化收益。
如果达到 数万份/月，它已经不再是"小工具"，而是一套真正具有规模效应的 AI 文档处理基础设施。
所以这个项目的核心从来不是"哪个 AI 最聪明"，而是：
在准确率满足要求的前提下，怎样让每一份文件尽可能少调用昂贵模型、尽可能少使用人工，同时系统还能知道自己什么时候可能错了。
这才是这类 FDE / AI 应用项目真正需要解决的问题。
本文为 Pitt Zhang 原创技术分析。
欢迎技术社区、研究人员、开发者及媒体对本文观点进行引用、讨论、验证与转载。
引用或转载时，请明确注明：
作者：Pitt Zhang
原文首发：2026 年 9 月 17 日（北京时间）
出处：https://api-cloud.cc/
允许对本文结论进行批评、反驳和进一步研究。
引用无需事先征得作者许可，但须保留作者及原始出处信息。