文档预处理之文本化

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

以下为正文。

阅读小Tip：拉到文末可以找到测试结论总表。

结构化信息提取的重要性

数据作为大模型时代的核心生产资料，其结构化处理能力直接影响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的开销也使其很难用于快速文档解析场景。

• 小结

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

基于本地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

欢迎各位用户通过电话400-6666-582与我们共同探讨技术发展与AI应用的可能性。如在使用过程中遇到任何问题，或对功能有进一步的需求，可以随时联系TextIn技术团队交流沟通！