多模态大模型在表格解析任务上效果如何？亲身经历全是泪！

最新推荐文章于 2025-04-02 18:07:27 发布

大模型大模型

最新推荐文章于 2025-04-02 18:07:27 发布

阅读量991

点赞数 16

文章标签：人工智能产品经理学习数据库 pdf

本文链接：https://blog.csdn.net/qq_46094651/article/details/144744951

版权

前段时间一直都在尝试用多模态大模型进行落地应用，除了问答之外，那么最容易想到的就是文档解析了。一来多模态大模型本身就有强大的OCR功能，二来知识加工对于大模型落地来说也是重中之重，三来现在很多文档拆解的API或者项目，效果都没有那么理想吧，比如：夹杂公式的文本、复杂表格等。

思路是不是很正，于是乎我就尝试用多模态大模型进行表格解析的任务了。结果就是：全是眼泪！痛，太痛了！

今天此贴主要是分享一下个人的惨痛经历，还有一些实测结果。

懒人版：

多模态大模型做表格解析任务，对于简单表格效果很好，但对于带合并单元格的表格和长表，效果很差；
即使是现在顶尖的闭源模型GPT4-o、Claude3.5的效果也不是好，不可用；
多模态大模型对于表格复杂程度的定义，与传统方法对复杂的定义不同；
多模态大模型输出md格式要比html更好，但复杂表格md根本展现不出来；
训练了10B以下的VLM，效果提升不明显，对于复杂表格效果依旧乱七八糟，也许是2w数据（机器有限）不够？

下面详细介绍测试结果（附各种模型的测试）、个人测试方法说明和一些乱七八糟想说的。

先叠甲，做的时间不是很长，训练也尝试过，效果不理想，也欢迎大家评论区讨论，或给予指点。言外之意，不喜勿喷！！！

各种裸模的测试效果

私下测试的模型和数据比较多，这里主要展示GPT4-o、Claude-3.5、Qwen2-VL-7B、MiniCPM2.6-V、InternVL-2.5-8B、Qwen2-VL-72B。

个人觉得GPT4-o、Claude-3.5可能是闭源上限，而Qwen2-VL-7B、MiniCPM2.6-V、InternVL-2.5-8B是在可本地化部署范围内的模型（虽然依旧很重，但还可以接受），Qwen2-VL-72B是开源模型的上限。

测试1：

你觉得这个表格难吗？从直观感觉上来看，其实是不难的，内容不多，表格规则，主要难点在于有合并单元格。我测试过一些开源的传统模型，有的是可以识别对的，但是在大模型这边，总是有瑕疵。只有Claude3.5-sonnet对了，GPT4-o也没对，7B级别开源模型更是一塌糊涂。

测试2：

这个比上一个有一些难度，主要是字多了一点，然后合并单元的不错有交错（6、7行的2、4列），多模态大模型们全军覆没。

测试3：

这个确实有点难了，我看着都有点眼晕了，依旧全军覆没。

我这里并不是为了证明多模态大模型的效果有多差，而故意贴的效果很差的图，而是在复杂表格和长表上真的很差，我整体测下来，估计也就是20-30%的水平，离可用还有一段距离。

即使是训练了，也不行，当然可能是训练数据不够，也可能是训练的模型不够大，但总之我败了。如果有做过相关任务的同学，欢迎评论区讨论，也可以说出你们的看法。

注意：这里说的是合并单元格以及长表，简单表格，短表前面已经说了，多模态效果很不错，但问题是传统方法也很不错呀，从性价比考虑，多模态大模型还是亏得。

测试细节说明

测试的提示词用的都是相同的提示词，其实也调了比较多，但改善效果并不明显，也欢迎大家尝试修改，有更好的可以留言告诉我。

Role 你是一位有多年经验的OCR表格识别专家。 ## Goals 需要通过给定的图片，识别表格里的内容，并以html表格结果格式输出结果。 ## Constrains - 需要认识识别图片中的内容，将每个表格单元格中的内容完整的识别出来，并填入html表格结构中； - 图片中的表格单元格中可能存在一些占位符需要识别出来，例如"-“、”—“、”/"等； - 输出表格结构一定遵循图片中的结构，表格结构完全一致； - 特别注意图片中存在合并单元格的情况，结构不要出错； - 对于内容较多的图片，一定要输出完整的结果，不要断章取义，更不要随意编造； - 最终输出结果需要是html格式的表格内容。 ## Initialization 请仔细思考后，输出html表格结果。

GPT4-o、Claude-3.5、Qwen2-VL-72B是直接用API测试的，就不多说了，反正就按照文档调用就行，都大差不差。Qwen2-VL-7B、MiniCPM2.6-V、InternVL-2.5-8B等模型，直接在国信超雄上租的4090利用vllm进行推理测试的。

https://www.superti-cloud.com/home

上面4090价格还可以，1.98元/时，冲得多还可以进一步打折。因为是个新平台，暂时只有4090，不过好在卡多，可以租到8卡的；最重要的是，新用户送20代金券，我整个测试过程没花钱，送的9小时，足够，又白嫖了一波，白嫖使我快乐，哈哈哈哈。还有一点就是4090做推理卡的性价比还是挺高的。

问了客服，后续会增加更多的的卡，暂时推理来说4090性价比还是挺高的。不过，大家理性消费哈，可以白嫖先用用，用的舒服再说。

vllm我用的是0.6.3版本，双卡推理（所以开的时候选两张卡），由于需要torch2.4，但是平台上现场的镜像最高只有torch2.3，所以我又自己重新装了一下torch2.4，装包啥的这里就不说了，也不难，不会就去百度、Google吧。

服务器可以直接ssh链接，用mobax在平台上上传数据啥的就直接拖就行，操作都差不多，也不过多介绍了，也可以无卡操作，节省卡时。

用vllm测试的主要原因，就是简单，接口就是openai接口，目前对各大模型适配的也很好，上手简单，无脑执行命令就行。

以Qwen2-VL-7B为例，直接执行以下命令：

vllm serve ./Qwen2-VL-7B-Instruct/ --served-model-name Qwen2-VL-7B-Instruct --port 54188 --host 0.0.0.0 --trust-remote-code --gpu-memory-utilization 0.98 --tensor-parallel-size 2

其中，./Qwen2-VL-7B-Instruct/是模型下载的本地路径，也可以用HF的repo，但是会有网络问题；served-model-name表示调用时使用的名称；tensor-parallel-size是多卡并行，显存不够，显卡来凑。

测试代码：

from openai import OpenAI import base64 api_key = “EMPTY” base_url = “http://0.0.0.0:54188/v1” client = OpenAI( api_key=api_key, base_url=base_url ) image_path = “test.png” with open(image_path, “rb”) as image_file: encoded_string = base64.b64encode(image_file.read()) base64_image = encoded_string.decode(‘utf-8’) response = client.chat.completions.create( model=“Qwen2-VL-7B-Instruct”, messages=[ { “role”: “user”, “content”: [ { “type”: “image_url”, “image_url”: { “url”: f"data:image/png;base64,{base64_image}" } }, { “type”: “text”, “text”: “”“## Role 你是一位有多年经验的OCR表格识别专家。 ## Goals 需要通过给定的图片，识别表格里的内容，并以html表格结果格式输出结果。 ## Constrains - 需要认识识别图片中的内容，将每个表格单元格中的内容完整的识别出来，并填入html表格结构中； - 图片中的表格单元格中可能存在一些占位符需要识别出来，例如”-“、”—“、”/“等； - 输出表格结构一定遵循图片中的结构，表格结构完全一致； - 特别注意图片中存在合并单元格的情况，结构不要出错； - 对于内容较多的图片，一定要输出完整的结果，不要断章取义，更不要随意编造； - 最终输出结果需要是html格式的表格内容。 ## Initialization 请仔细思考后，输出html表格结果。 “”” } ] }] ) res = response.choices[0].message.content print(res)

输出结果，表格一般没有格式，看起来可能不方便，可以额外增加下面代码做展示。

{生成的表格结果}

碎碎念

利用多模态大模型进行表格解析的出发点是因为在RAG场景上，很多是因为文档解析错误导致的最终文档效果不理想。当然很多人可能会觉得用多模态做表格解析是在用大炮打蚊子，但从我目前体验来看，大炮还打不到蚊子。

从训练过程上来看，模型在训练的时候，收敛的很快，但效果依旧不理想；当时也有把一些特殊字符独立化，或者loss计算的时候分区域设置权重等等等，而这些带来了改善，但是效果依旧不明显。但每一次都觉得魔改的思路很正，祈祷成功，哈哈哈哈。大模型时代，已经很少魔改了，要不无脑洗数据，要不无脑加数据，人都麻木了。

一直在思考，再分析，是不是VLM本身tokenizer切块导致对合并单元格天生不敏感，是不是VLM本身基模不够强，整体预训练过程中表格数据不够多，或者说网络上复杂表格不够多，感觉即使够多也很难认真矫正数据的准确性。

并且这个任务多少数据可以达到一定的效果，已经超出了我对纯文本LLM的认知，当然，也许其他任务的VLM也很文本差不多，但这个任务真的好奇怪。

然后也发现了一个多模态大模型做OCR的榜单-CC-OCR，确实在tabel上的效果，也不理想。但上面还是略高，估计并没有区分表格的难度吧。

Title：CC-OCR: A Comprehensive and Challenging OCR Benchmark for Evaluating Large Multimodal Models in Literacy   Link：https://arxiv.org/abs/2412.02210