从扫描的实验报告到结构化数据：OCR架构的权衡取舍
预算有限的医疗初创公司在将医学扫描文件转换为结构化JSON时，该如何权衡OCR库、Google Cloud API以及自托管的视觉大语言模型？
来源: How We Chose Our OCR Architecture for a Medical Reports Pipeline (Part 1 of 2)
将实验室打印结果的照片转换成“血红蛋白，13.2，g/dL，参考值12.0–15.5”这样的文字行，看似是OCR问题，但纯文本识别仅是第一步。真正的挑战在于以低成本、高可靠性且不泄露患者数据的方式，从杂乱的扫描图像中提取出有意义的信息。本指南将介绍为医疗报告MVP设计的此类数据提取流程背后的架构决策，这样在预算有限的情况下遇到类似的文档理解问题时，便可复用这些思路。
驱动一切的核心需求
想象一款处于早期阶段的健康产品。患者上传扫描后的医疗报告，可以是PDF格式，也可以是打印的检验单的照片。系统必须将其转换为结构化的健康记录，以便患者和医生查看，同时也能供后续的AI分析使用。每条记录需要包含四项内容：参数名称、测量值、单位以及参考范围。
最后这一点才是关键。仅仅能返回一组已识别字符的工具并不足以满足要求。仍需有系统来判断哪个数字对应哪项检测、哪段字符串是单位，以及哪对数字属于正常范围。所有相关决策都关乎“理解”环节的位置及其所需成本。
这种限制在MVP项目中很常见：团队规模小、基础设施预算有限，预计初始每日上传的报告量约为500份，换算下来每月大约有3万页。
决策1：选择开发语言
Python的生态系统优势确实存在
如果从“哪种语言拥有最好的OCR和机器学习工具”这一标准来看，Python无疑是最优选择。像PaddleOCR和EasyOCR这样的成熟开源引擎都是以Python为开发基础的，OpenCV也在Python中有完善的绑定接口，而且大多数计算机视觉示例也都以Python为前提。从头构建OCR处理流程时，自然也会选择Python作为起点。
对于那些并非差异化的因素，坦诚相待也是必要的。Google的Vision API曾是考虑过的付费选项之一，而且Google还提供了Python和Go版本的客户端库。因此，SDK的可用性并不会偏向任何一种语言。
为何Go仍胜出
决定性因素在于整个系统架构而非OCR技术本身。其余的异步处理流程早已规划为使用Go语言编写的worker：它从Redis Streams中获取任务，从Cloudflare R2对象存储中下载上传的文件，并将结果写入Postgres数据库。如果用Python来实现提取步骤，那就意味着为了同一个功能需要运行两种不同的worker环境，还要分别处理部署、依赖管理及监控等问题。此外，负责开发的工程师在处理这类基础设施类服务时，使用Go语言的效率也最高。
核心教训是：拥有最庞大库目录的语言并不一定就是最佳选择。如果数据提取步骤可以简化为通过HTTP调用模型（这也是该设计的最终方案），那么为整个工作层保持单一运行时环境，往往比使用那些几乎用不上的庞大库目录更有价值。
决策二：云API与自托管方案的成本对比
团队针对每月预计30,000页的处理量对比了四种方案。以下数据为评估时的估算值；云服务价格会变动，因此在依赖这些数值之前请先查看当前的价格表。
- 使用
DOCUMENT_TEXT_DETECTION功能的Google Cloud Vision。它返回带坐标信息的原始文本，且不包含结构化字段。费用约为每1,000页1.50美元，即每月大约45美元。
正确理解这些数字
Vision API看似价格低廉，但实际上解决的是不同的问题。它只能告诉你“13.2”这些字符出现在特定坐标上，却无法识别它们其实是血红蛋白检测数值。你仍需自行构建完整的解析层，因此其价格无法与那些能返回结构化数据的选项相提并论。
Document AI虽然也能输出结构化数据，但每月1000到2000美元的昂贵成本，对于一款尚未产生收入的产品来说实在是个沉重的负担。
Gemini Flash才是真正值得关注的竞争者。基于令牌的扫描页面定价与自托管方案处于同一价格区间，而且无需搭建任何GPU基础设施。那为何不选择它呢？
为何自托管仍更具优势
有三个因素决定了最终选择：
- 成本上限。无论处理5,000页还是50,000页，专用节点的成本都保持不变。而按使用量计费的API则没有上限：流量激增、重复请求风暴或批量导入都会直接体现在账单上。
- 数据隔离。医疗报告包含受保护的健康信息。在团队自身的私有网络内进行数据提取，意味着每次上传时患者的文档都不会被发送到第三方API，从而避免了MVP团队难以应对的各种合规性及供应商审核问题。
- 无外部配额或延迟。不存在速率限制、并发层级或关键路径上的额外网络跳转。
最终，我们放弃了Google Cloud和Vertex AI这两种方案，决定采用完全自托管的架构。
看看另一面也有帮助。服务器费用只有在单个设备能够处理的吞吐量范围内才是可预测的；超出这个范围，就需要自行购买更多硬件，并承担容量规划和系统正常运行时间的管理工作。自托管也无法免除合规义务，因为您仍然需要对存储、访问控制以及数据审计负责。对于处理量较小且稳定、涉及敏感信息的工作负载，自托管通常更为合适；而对于流量波动大、增长迅速，且团队没有运维能力的情况，使用托管型 API 可能是更好的选择。
决策 3：跳过传统的 OCR 库
像 PaddleOCR 和 Docling 这样的开源引擎虽然功能强大，但其输出结果是为显示而设计的。内容通常会被包裹在布局标签中或以 Markdown 格式呈现，以便在 UI 或 HTML 页面上良好显示。当需要有人阅读结果时这很理想，但若代码需要将“血红蛋白：13.2 g/dL”以整洁的字段形式提取出来时，这种方式就显得很不方便。
填补这一差距本身就是一个独立的项目。你需要从标签结构中提取数据，通过大量试错来应对不同的实验室和报告格式，并且可能还需要为引擎未能准确分割的表格及区域添加OpenCV预处理或后处理功能。所有这些工作都是在最初集成和部署OCR引擎的基础上进一步开展的。对于最小可行产品而言，这无疑意味着大量的工程工作量，而且这属于基础设施而非最终产品本身。
有一点需要特别强调：此评估仅代表团队的看法，并非对这些工具的最终定论。那些拥有更丰富PaddleOCR或Docling使用经验的工程师或许能找到更快捷的方法将结构化输出转换为整洁的数据字段，而且这两个项目都在快速发展，因此值得重新审视它们当前的输出格式。
决策4：根据预算选择自托管的视觉大语言模型
提取含义而非字符
与“先进行OCR处理，再为OCR输出编写解析器”相比，另一种方法是让具备视觉能力的自然语言模型同时完成这两步工作。传统OCR只能识别字符，而视觉大语言模型在获得结构良好的提示后，可以直接查看扫描后的页面，并直接返回参数、数值和单位字段，无需经过提取带标签的Markdown内容的中间步骤。
在这里，视觉能力是必不可少的，并非可选的升级功能。纯文本模型无法处理扫描图像，因为此时还没有可供识别的文本，模型必须自行读取像素信息。
这种方法存在自身的风险，从一开始就应做好应对规划。语言模型可能会误读数字，或生成看似合理但实际上并不存在于页面上的数值，尤其是较小的模型，并不总能返回符合要求的JSON格式。对于健康数据而言，这就需要以防御性方式解析模型的响应，根据预期的类型和范围对数值进行验证，并让用户或临床医生能够查看并修正原始文档。
选择真正可运行的模型
模型选择也遵循了同样的预算考量。Qwen那些具备更强视觉处理能力的较大模型性能优异，但要在该规模级别自托管此类模型需要大量的VRAM和计算资源，这超出了团队用MVP预算所能够承担的基础设施成本。最终他们选择了MiniCPM-V：这是一个体积小得多的模型，Ollama可以在低成本硬件上轻松运行它，同时仍足以从实验报告图片中提取结构化信息。
如果再次进行此类测试，应在真实文档的代表性样本上评估候选模型，包括模糊的手机照片和特殊的实验室布局，而不要仅依赖排行榜上的分数。即便某模型在理论上的表现最佳，若无法承担其运行成本，也毫无意义。
后续实现需要什么
上述架构决定了运行什么内容；而生产流程仍需处理如何运行的问题。后续工作包括将PDF转换为模型可识别的图像、构建Ollama API请求与提示词、在小型模型偏离预期格式时进行防御性JSON解析，以及在工作进程中使用Redis Streams，以便在数据量增加时仍能可靠地处理报告。
关键要点
- 在比较工具之前先明确所需的输出格式（此处为名称、数值、单位及参考范围）；原始OCR文本与结构化数据是不同的产品，价格也各不相同。
- 应为整个系统选择合适的工作进程语言，而非仅依据某个组件的功能库是否最丰富来决定。
- 在比较云服务选项时，应基于相同的输出标准进行评估，同时考虑成本上限、数据隔离机制及配额等因素，而不仅仅是标价。