写点什么

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

  • 2025-02-19
    上海
  • 本文字数:2060 字

    阅读完需:约 7 分钟

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

文档预处理之文本化

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

结构化信息提取的重要性

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

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

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

评价标准

测评

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



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

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

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

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

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

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

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

测试

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

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

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

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

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

识别结构不稳定:

此处本应是一个表格。

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

小结

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

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

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

测试

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

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

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

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

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

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

无限复读机;

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

小结

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

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

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

测试

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

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

识别后:

小结

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

大结论

总表:

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

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

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

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


用户头像

上海合合信息科技股份有限公司人工智能团队 2022-08-01 加入

在上海市领军人才合合信息董事长镇立新博士带领下,于复杂场景文字识别、智能图像处理、自然语言处理等人工智能领域拥有10 余年研发创新与技术积累,具备专业的行业理解与技术成果。

评论

发布
暂无评论
用户的声音 | 文档结构化信息提取方案测评:LLM、开源模型部署与云端API,谁是合适选择?_#大模型_合合技术团队_InfoQ写作社区