用户的声音 | 文档结构化信息提取方案测评：LLM、开源模型部署与云端API，谁是合适选择？

文档预处理之文本化

近日，我们收到来自专业用户的使用心得，通过测试浅析结构化信息提取技术，辅助完成技术选型。

结构化信息提取的重要性

数据作为大模型时代的核心生产资料，其结构化处理能力直接影响AI系统的实用价值。尽管知识图谱、RAG等技术依赖海量文本资源，但现实中的历史档案、法律文书等重要数据多以扫描件、图像等非结构化形式存在，导致信息抽取、语义解析等环节面临显著技术障碍。

当前结构化信息提取技术虽呈现多样化发展，但对于开发者而言，结构化信息提取的“落地”与“可用性”才是真正的考验，研究论文中的指标和高精度模型在生产环境中可能面临性能瓶颈、成本过高、部署难度大等现实挑战。

本文将梳理主流技术方案，立足实际需求，结合一系列实测数据与实践经验，评估各方法在不同场景下的表现与优劣势。从技术指标到生产可行性，我们将为开发者提供一份实用的兼顾算法效能与部署成本的参考指南。

评价标准

测评

使用的待测试pdf：随机选取的一份上交所上市公司的2023年年报，全文193页。

金融年报是电子文档中相对复杂的一类，文字密度大，表格复杂度高，标题层级多，对模型能力有较大考验。遂选取之作为测试素材。

基于大模型的识别方案举例

市面上流行的几个开源pdf转markdown方法，大体可以分为两种，一类走传统版面分析+公式表格识别+OCR方案，另一类则是走视觉大模型路线。

利用大模型执行pdf转markdown算是一种逻辑上比较容易的办法，借助大模型本身强大的视觉识别能力，进行力大砖飞的转换。

从原理上，这种方法可以自如地进行转换，同时可以在转换过程中保留尽可能多的视觉信息，基础的诸如标题层级，进阶的还可以对图片进行一定的语义解释。

视觉大模型的接口也容易获得，有条件的情况下可以本地部署。

本次实验采取识别能力靠前[2]且常用的gpt-4o模型配合 gptpdf 来进行实验：

测试

gptpdf的封装度较高，且依赖较少，一次pip即可安装。

如果是使用openai服务的话，只需填写上自己的key即可。如果自己有大模型部署的话，也可改成自己的代理地址，也可使用本地的视觉模型。

测试代码用的是单线程，由于速度较慢远低于预期，遂只拆出前30页进行测试。效果如下：

可以看到，问题还是比较多的，比如幻觉问题：

大模型幻觉出了一些奇怪的标题。

识别结构不稳定：

此处本应是一个表格。

我使用的是gptpdf默认的prompt，可能有优化空间。但是效果的确不尽如人意。

小结

名称	访问地址	文本正确性	表格正确性	标题正确性	识别速度	成本	本地部署	便捷使用
gptpdf	https://github.com/CosmosShadow/gptpdf	偶有差错	语义正确格式错误	基本无误	16s/页	本地算力/gpt4o 约0.112￥/页（含读取和输出）	可行（基于视觉大模型，显存要求高）	部署便捷

本次测试还有一些可以优化的点，例如使用经过调试的提示词，或者换用对中文视觉支持更好的大模型。但该方案整体上价格偏高，单管道处理速度也较慢，除非和一些基于大模型的预处理进行步骤合并，否则不推荐使用。

基于本地OCR的识别方案举例

相对视觉大模型方案，OCR方案则小巧且复杂，其使用较小的模型各司其职，并对结果进行拼接。其算力要求相对低的特点也使其适用于本地部署，一个广受好评的解决方案是MinerU，作为开源的数据提取工具，目前在github上已经有24.3k stars.

测试

minerU的安装相对复杂些，且如果要安装gpu版本需要额外的步骤。

该方案是完全开源的，好消息是有些组件可以根据需求定制化更改。坏消息是，可能有一些bug，需要查issues自行修复。

解析速度还算过关，在i7-2700+3090上运行，平均4.52s每页。在不同阶段使用的算力硬件也不同，多线程情况下速度或许会更快。

值得注意的是，由于markdown格式表格不易于显示复杂表，minerU的默认表格识别将会把表格转换为html格式，从纯文本打开的话会像是这样：

issues中有人给出了能转换为markdown格式的替代方案，但是这同样需要额外的配置，在此暂不讨论。
来看看效果：

标题只有一层，即是标题/不是标题。在表格识别能力上偏弱，偶尔会出现例如：

无限复读机；

换页时文本错误/表格结构错误。

小结

名称	访问地址	文本正确性	表格正确性	标题正确性	识别速度	成本	本地部署	便捷使用
MinerU	https://github.com/opendatalab/MinerU	基本正确	较差	只能简单区分是否为标题，且识别准确性不高	正相关于硬件算力（i7-2700+3090上4.52s/页）	本地部署（硬件折旧+电力损耗）	可本地部署	不甚便捷

大概是开源领域最好的ocr方案了，如果有本地算力且文件保密要求高的话还是比较推荐的。默认的html格式个人认为有些鸡肋，不能保证准确性，同时也不利于大模型读取。先前提到的转换为markdown格式的替代方案我也尝试过，能一定程度减少识别错误，但会增加使用难度，且还是有较多错误。

基于云端OCR的识别方案举例

如果项目没有本地部署需求，那么云端OCR是个好方案，价格相对大模型方法低廉许多，且响应速度快。横评了一众中文OCR方案，Textin的数据是最好的。

测试

速度奇快，一份193页的pdf文件仅消耗了13s，几乎是其余方案的百倍。
几乎没有错误，只是偶有标题会被漏标：

只有极复杂的表格才能使其产生小错误：
原表格：

识别后：

小结

名称	访问地址	文本正确性	表格正确性	标题正确性	识别速度	成本	本地部署	便捷使用
TextIn	https://www.textin.com/document/pdf_to_markdown	基本正确	基本正确	层级支持，偶有错误	极快，平均0.07s/页	0.05￥/页	可定制	非常便捷

综合下来是速度且效果最好的OCR方案了，适用大多数场景，非常推荐。

大结论

总表：

名称	访问地址	文本正确性	表格正确性	标题正确性	识别速度	成本	本地部署	便捷使用
gptpdf	https://github.com/CosmosShadow/gptpdf	偶有差错	语义正确格式错误	基本无误	16s/页	可行（基于视觉大模型，显存要求高）	可行	部署便捷
MinerU	https://github.com/opendatalab/MinerU	基本正确	较差	只能简单区分是否为标题，且识别准确性不高	正相关于硬件算力（i7-2700+3090上4.52s/页）	本地部署（硬件折旧+电力损耗）	可本地部署	不甚便捷
TextIn	https://www.textin.com/document/pdf_to_markdown	基本正确	基本正确	层级支持，偶有错误	极快，平均0.07s/页	详见官网	可定制	非常便捷

从效果上，几种方法都在可接受的范围内。

视觉大模型方案成本高昂且可靠性较差，尽管近来有较多类似功能的开源仓库，但效果较差，价格高，速度慢，因此不建议使用此类方案。

从部署成本来说，如果有较强的本地算力，用量大且成本有限，建议使用本地OCR识别方案；如果对精确度要求高，资金充足，则建议使用云端OCR的识别方案；如果对精确度和数据安全都有较高的要求，可以选择TextIn本地部署。

最后附上测试代码和结果，也可以帮助你便捷完成批量转换。
mdfy_test：https://github.com/RwandanMtGorilla/mdfy_test

---

欢迎扫描下方二维码，加入技术交流社群，与我们共同探讨技术发展与AI应用的可能性。
更多福利、大模型应用技术学习材料，关注公众号即刻领取。

参考文献
[1] OCR Hinders RAG: Evaluating the Cascading Impact of OCR on Retrieval-Augmented Generation https://arxiv.org/abs/2412.02592v1
[2] llm的基础OCR识字能力 CC-OCR: A Comprehensive and Challenging OCR Benchmark for Evaluating Large Multimodal Models in Literacy https://arxiv.org/pdf/2412.02210
[3] Document Parsing Unveiled: Techniques, Challenges,and Prospects for Structured Information Extraction 文档解析综述 https://arxiv.org/pdf/2410.21169
[4] A Comparative Study of PDF Parsing Tools Across Diverse Document Categories https://arxiv.org/pdf/2410.0987