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

server/2025/2/21 7:16:16/

文档预处理之文本化

近日,我们收到来自专业用户的使用心得,浅析结构化信息提取技术、技术选型及一些个人测试。

结构化信息提取的重要性

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

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

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

评价标准

作为测评,首先确定标准,目标输出格式设定为markdown。

Markdown 作为一种增强的文本格式,相较纯文本而言,为数据保有了其中固有的结构(表格、标题、列表等)。同时作为大模型原生支持的文本格式,使用markdown作为输入格式也能让输出效果更好。

对于测试结果要求,首先,最重要的标准是结果可用。我们定了3个正确性指标:其中,文本准确性是所有文本解析的基础,有研究[1]指出,解析正确性将显著影响RAG的效果;表格准确性则是一个难点,尤其是有多个单元格合并的情况下,很难识别准确;标题正确性主要考察标题层级是否正确。其次需要评估识别速度、成本等问题。考虑到有些组织内信息不能上传外网,添加了隐私性,即能否本地部署这一指标。最后考虑到有些方法路径尚不成熟,部署复杂度大,因此能否便捷使用也是需要考察的点。最终得到的评价表格如下:

评价表格:*

名称

访问地址

文本正确性

表格正确性

标题正确性

识别速度

成本

本地部署

便捷使用

  • 由于参与后处理的是LLM,所以关于文本识别准确有一定容错,如果需要关于正确性的量化评价,可以采用Markdown Tester。

测评

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

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

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

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

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

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

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

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

测试

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

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

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

可以看到,问题还是比较多的,比如幻觉问题:

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

识别结构不稳定:

此处本应是一个表格。

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

而且速度也是有够慢,仅仅三十页运行了477.34s,就算可以多线程,单页16s的开销也使其很难用于快速文档解析场景。

小结

名称

访问地址

文本正确性

表格正确性

标题正确性

识别速度

成本

本地部署

便捷使用

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

参考文献

[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.09871


http://www.ppmy.cn/server/169193.html

相关文章

解决MySQL错误:You can‘t specify target table ‘xxx‘ for update in FROM clause

目录 错误复现场景原因分析解决方案方法1:使用派生表(推荐)方法2:改用JOIN操作方法3:使用临时表 总结 在编写MySQL的UPDATE或DELETE语句时,如果子查询中直接引用了要操作的目标表,可能会遇到一个…

性格测评小程序08测评功能搭建

目录 1 答题功能需求分析2 页面设计3 搭建后端API4 搭建页面5 创建变量6 自定义方法7 数据绑定及事件绑定总结 我们已经用7篇的篇幅介绍了测评小程序的基础功能搭建,包括用户注册、登录以及题库的后台管理功能。就像盖楼一样,地基打好之后我们就可以往高…

项目2 数据可视化--- 第十五章 生成数据

数据分析是使用代码来探索数据内的规律和关联。 数据可视化是通过可视化表示来 探索和呈现数据集内的规律。 好的数据可视化,可以发现数据集中未知的规律和意义。 一个流行的工具是Matplotlib,他是一个数据绘图库; 还有Plotly包&#xff…

MyBatis-Plus之通用枚举

MyBatis-Plus之通用枚举 前言 MyBatis-Plus中提供了通用枚举,简单来说就是将数据库中的某一字段的代替的含义转换成真实的含义将数据展示给用户,用户在存储时也会将真实值转换成代替的数字存入到数据库中。举个例子:用户性别在数据库中存储…

Java 大视界 -- 企业数字化转型中的 Java 大数据战略与实践(93)

💖亲爱的朋友们,热烈欢迎来到 青云交的博客!能与诸位在此相逢,我倍感荣幸。在这飞速更迭的时代,我们都渴望一方心灵净土,而 我的博客 正是这样温暖的所在。这里为你呈上趣味与实用兼具的知识,也…

【深度学习】计算机视觉(CV)-目标检测-DETR(DEtection TRansformer)—— 基于 Transformer 的端到端目标检测

1.什么是 DETR? DETR(DEtection TRansformer) 是 Facebook AI(FAIR)于 2020 年提出的 端到端目标检测算法,它基于 Transformer 架构,消除了 Faster R-CNN、YOLO 等方法中的 候选框(…

IM聊天系统架构实现

一、IM系统整体架构 二、企业级IM系统如何实现心跳与断线重连机制; 1、重连机制(服务端下线) 服务端下线,客户端netty可以感知到,在感知的方法中进行重连的操作,注意重连可能连接到旧的服务器继续报错&…

深入解析iOS视频录制(二):自定义UI的实现

深入解析 iOS 视频录制(一):录制管理核心MWRecordingController 类的设计与实现 深入解析iOS视频录制(二):自定义UI的实现​​​​​​​ 深入解析 iOS 视频录制(三):完…