多模态大模型解析表格任务：效果分析与实战总结

背景与动机

近期在探索多模态大模型（VLM）的落地应用场景时，除了常见的问答交互外，文档解析被视为最具潜力的方向之一。多模态大模型具备强大的 OCR 能力，且知识加工对于大模型应用至关重要。然而，现有的文档拆解 API 或项目在复杂场景下表现往往不尽如人意，特别是涉及夹杂公式的文本、复杂表格等结构。

基于此思路，我们尝试利用多模态大模型进行表格解析任务。经过一系列实测，发现虽然简单表格处理效果尚可，但在面对合并单元格及长表时，现有模型的表现存在显著瓶颈。本文旨在分享测试过程中的技术细节、结果分析以及针对该问题的思考。

核心结论摘要

简单表格：多模态大模型效果较好，能够准确还原内容。
复杂表格：对于带合并单元格的表格和长表，效果较差，错误率较高。
模型对比：即使是顶尖闭源模型（如 GPT-4o、Claude 3.5）在处理复杂结构时也存在瑕疵；开源模型（如 Qwen2-VL、MiniCPM、InternVL）在本地部署范围内效果提升有限。
格式输出：模型输出 Markdown 格式通常优于 HTML，但复杂表格的 Markdown 渲染本身存在局限性。
训练效果：小规模数据（如 2w 条）微调 10B 以下 VLM 对复杂表格识别能力提升不明显。

模型测试结果详解

本次测试涵盖了多个主流模型，包括闭源上限模型 GPT-4o、Claude 3.5，以及开源模型 Qwen2-VL-7B、MiniCPM2.6-V、InternVL-2.5-8B 和 Qwen2-VL-72B。

测试案例一：基础合并单元格

测试对象为一个规则表格，主要难点在于包含合并单元格。从直观感受来看，此类表格难度中等。

传统模型：部分传统 OCR 模型可以正确识别结构。
GPT-4o：未能完全正确还原合并关系。
Claude 3.5：表现最佳，成功识别了合并单元格结构。
7B 级别开源模型：表现混乱，无法维持表格结构。

测试案例二：交错合并与长表

此案例增加了文字密度，并引入了交错的合并单元格（如第 6、7 行的 2、4 列）。

结果：所有参与测试的多模态大模型均出现不同程度的结构错乱，未能正确对齐行列关系。

测试案例三：高复杂度长表

这是一个视觉上较为复杂的长表格，包含多层嵌套和密集信息。

结果：模型整体表现不佳，出现了严重的断章取义和结构丢失现象。

综合评估，在复杂表格和长表场景下，多模态大模型的可用水平估计仅为 20%-30%，距离生产环境要求仍有较大差距。即便进行了微调，若数据量不足或模型基座不够强，效果改善依然有限。

注意：以上结论主要针对合并单元格及长表场景。对于简单短表，多模态效果确实不错，但考虑到传统方法在此类场景下同样成熟且性价比更高，引入大模型可能并非最优解。

测试方法与配置说明

提示词工程

测试中使用了统一的系统提示词，旨在规范模型输出为 HTML 表格格式。尽管尝试过多种调优，但对最终效果的提升并不明显。

## Role
你是一位有多年经验的 OCR 表格识别专家。

## Goals
需要通过给定的图片，识别表格里的内容，并以 html 表格结果格式输出结果。

## Constrains
- 需要认识识别图片中的内容，将每个表格单元格中的内容完整的识别出来，并填入 html 表格结构中；
- 图片中的表格单元格中可能存在一些占位符需要识别出来，例如 "-"、"—"、"/" 等；
- 输出表格结构一定遵循图片中的结构，表格结构完全一致；
- 特别注意图片中存在合并单元格的情况，结构不要出错；
- 对于内容较多的图片，一定要输出完整的结果，不要断章取义，更不要随意编造；
- 最终输出结果需要是 html 格式的表格内容。

## Initialization
请仔细思考后，输出 html 表格结果。

推理环境搭建

API 调用：GPT-4o、Claude-3.5、Qwen2-VL-72B 直接使用官方 API 进行测试。
本地部署：Qwen2-VL-7B、MiniCPM2.6-V、InternVL-2.5-8B 使用 vLLM 框架进行推理。
硬件资源：测试环境基于 NVIDIA 4090 显卡，单卡或双卡并行。
软件版本：vLLM 0.6.3 版本，PyTorch 2.4。

vLLM 启动命令示例

以 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/：模型本地路径。
--served-model-name：调用时的模型名称标识。
--tensor-parallel-size：多卡并行数量，显存不足时可通过增加显卡数量解决。

测试代码实现

使用 OpenAI SDK 兼容接口进行调用，支持 Base64 编码的图片输入。

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)

为了优化 HTML 表格的展示效果，可额外添加 CSS 样式：

<style>
    table {
        border-collapse: collapse;
        width: 40%;
        margin: 0 auto;
    }
    th, td {
        border: 1px solid black;
        padding: 8px;
        text-align: left;
    }
</style>
<div>{生成的表格结果}</div>

技术深度分析

为什么多模态大模型难以处理复杂表格？

Tokenizer 切块机制：视觉语言模型（VLM）通常将图像切分为固定大小的 Patch 序列。这种序列化过程可能导致空间信息的丢失，使得模型对合并单元格这种依赖二维空间关系的结构天生不敏感。
预训练数据分布：通用大模型的预训练数据主要集中在自然语言和常见图像上，互联网上的高质量复杂表格数据相对稀缺，导致模型缺乏足够的监督信号来学习复杂的表格拓扑结构。
推理能力限制：当前 VLM 的注意力机制在处理长序列时容易分散，对于包含大量行列信息的长表，容易出现上下文遗忘或错位。

训练与微调的局限性

在尝试通过微调提升效果时，发现即使收敛很快，效果提升也不明显。可能的原因包括：

数据规模：机器资源限制了训练数据量（如仅 2w 条），不足以覆盖复杂的表格变体。
Loss 计算策略：简单的像素级或 Token 级 Loss 可能无法有效惩罚结构错误，需要设计区域感知的权重损失函数。
基座模型能力：小参数量的基座模型（<10B）本身的空间理解能力有限，微调难以突破架构瓶颈。

生产环境建议与替代方案

鉴于多模态大模型在复杂表格解析上的不确定性，在生产环境中建议采取以下策略：

混合架构：对于简单表格可直接使用 VLM；对于复杂表格，建议先使用专用 OCR 工具（如 PaddleOCR、TableMaster）提取布局信息，再结合 LLM 进行语义理解。
后处理校验：如果必须使用 VLM，需增加正则表达式或规则引擎对输出的 HTML/Markdown 结构进行校验，修复明显的行列错位。
分步处理：将长表拆分为子表分别处理，最后再进行逻辑拼接，降低单次推理的复杂度。
成本考量：从性价比角度考虑，传统方法在处理简单表格时更具优势，应优先评估是否需要引入大模型。

总结

多模态大模型在文档解析领域展现了巨大的潜力，特别是在非结构化文本的理解上。然而，在表格解析这一特定任务上，尤其是涉及合并单元格和长表时，其表现尚未达到稳定可用的标准。目前的瓶颈主要源于模型架构对空间结构的感知能力不足以及训练数据的匮乏。开发者在构建 RAG 或文档处理系统时，应理性评估任务复杂度，避免盲目依赖单一的大模型方案，采用混合技术栈可能是更稳健的选择。

多模态大模型解析表格任务：效果分析与实战总结