OCR 之后，本地部署哪个模型做结构化总结更合适

很多团队在处理扫描件、发票、合同、报表时，第一反应是“先跑一个 OCR，把文字抠出来”。但真正做过落地项目的人很快会发现：OCR 只是把像素变成字符，而业务需要的是结构化信息——字段、键值对、表格行、条款条目、金额与日期的对应关系。于是问题变成：OCR 之后，本地部署什么样的模型来做结构化总结，才能兼顾准确率、成本与可维护性？

本文不谈某一款产品的优劣，而是从工程视角拆解这个问题：先明确诉求与权衡，再比较几类常见 OCR 与文档解析路线的能力边界，最后给出一套可运行的本地多模态文档解析系统设计，并讨论如何评测与选型。

一、核心诉求：结构化总结到底在解决什么

“结构化总结”在不同场景下含义差别很大，选型前必须先把它拆清楚，否则很容易出现“模型跑通了但业务不能用”的尴尬。

1. 文本层结构化：从字符流到字段

最基础的一层是把 OCR 输出的纯文本整理成键值对或 JSON。例如从一段合同文本中抽取“甲方”“乙方”“签约日期”“金额”。这一层对模型的要求主要是语义理解与指令遵循，对视觉能力要求不高，纯文本大模型即可胜任。

2. 版面层结构化：保留阅读顺序与区域归属

扫描件的文字不是线性排列的。页眉页脚、双栏排版、表格跨页、图注与正文混排，都会让简单 OCR 的输出顺序错乱。此时需要模型具备版面理解能力，能区分标题、段落、表格、图片区域，并给出合理的阅读顺序。多模态模型在这一层优势明显。

3. 表格与公式结构化：保留二维关系

表格是结构化抽取的重灾区。把表格拍平成一串文字，行列对应关系就丢了。理想的做法是输出 HTML 或 Markdown 表格，甚至直接输出带行列坐标的结构化数据。公式同理，需要保留上下标与分式结构。

4. 长文档与跨页聚合

真实文档往往几十页，字段可能跨页出现。系统需要具备分块、聚合与去重能力，而不是把整份文档一次性塞给模型。

小结：结构化总结的难度是分层的。如果业务只需要字段抽取，纯文本模型加规则后处理就够了；如果要处理复杂版面与表格，就必须引入具备版面理解能力的多模态模型。选型的第一步，是判断自己处在哪一层。

二、落地权衡：本地部署必须面对的四个约束

“哪个模型最好”这个问题没有绝对答案，因为在本地部署场景下，至少有四组约束在互相拉扯。

1. 精度与资源开销

多模态模型参数量普遍较大，推理需要显存与算力。本地部署意味着硬件成本由自己承担。参数量越大，版面理解与表格还原能力通常越强，但吞吐下降、延迟上升。需要在“单页处理时间”和“字段准确率”之间做量化取舍。

2. 通用能力与领域适配

通用模型在公开评测上表现不错，但遇到行业单据（如医疗、金融、物流面单）时，术语与版式差异会导致精度下降。本地部署的好处是可以用自有数据做微调或提示词工程，但这也意味着需要投入标注与评测成本。

3. 可维护性与可替换性

把 OCR、版面分析、结构化抽取耦合在一个黑盒里，短期省事，长期难维护。更稳妥的做法是分层解耦：OCR 层、版面层、抽取层各自独立，任一层的模型可以替换而不影响整体。这也是后文系统设计的核心原则。

4. 数据合规与离线要求

本地部署的常见动机是数据不出内网。这要求整条链路——包括模型权重、依赖库、后处理脚本——都能离线运行，不能依赖在线接口。选型时要确认模型的许可证、权重分发方式以及推理框架的离线可用性。

三、主流开源 OCR 路线的能力边界

从技术路线看，当前常见的开源方案大致可分为三类，各有适用边界。

1. 传统检测识别流水线

这类方案通常由文本检测加文字识别两个阶段组成，工程成熟、速度快、资源占用低，对清晰扫描件的字符准确率很高。缺点是缺乏版面与语义理解，输出是带坐标的文本框列表，阅读顺序与表格结构需要额外的后处理逻辑来还原。适合作为基础 OCR 层，配合规则或轻量模型做结构化。

2. 文档解析型方案

这类方案在 OCR 之外增加了版面分析、阅读顺序恢复、表格与公式识别，输出接近 Markdown 或结构化文档。它们对复杂版面的处理明显更好，适合作为“文档到结构化文本”的中间层。缺点是流程较重，部署依赖多，对硬件有一定要求，且不同版式的泛化能力需要实测。

3. 端到端多模态文档模型

这类模型直接把图像输入映射为结构化文本或 JSON，理论上省去了多阶段拼接的误差累积。优势是端到端、指令灵活，可以通过提示词控制输出格式；挑战是推理成本高、对长文档需要分块策略，且输出稳定性依赖提示词设计，工程上需要加校验与重试机制。

横向对比的维度建议：

• 字符准确率：清晰件与低质件分别测；
• 版面还原：阅读顺序、表格结构、公式保留；
• 结构化输出：是否原生支持 JSON/Markdown，是否需要后处理；
• 资源开销：单页耗时、显存占用、批处理能力；
• 可维护性：依赖复杂度、是否易替换、许可证是否友好。

需要强调的是，公开榜单的分数只能作为参考，必须用自有业务样本做小规模评测，否则很容易出现“榜单很强、落地很弱”的落差。

四、实战：基于 LangChain 的本地多模态文档解析系统

下面给出一套分层解耦的系统设计。核心思路是：OCR 层可插拔，版面与结构化层独立，编排层负责分块、调用与聚合。

1. 整体架构

文档输入 → 预处理（去噪/旋转/切页）
        → OCR 层（可插拔：流水线型 / 文档解析型 / 多模态端到端）
        → 版面与结构层（阅读顺序、表格还原）
        → 结构化抽取层（大模型 + 输出 Schema 校验）
        → 聚合与后处理（跨页合并、去重、置信度过滤）
        → 结构化结果（JSON / 数据库）

2. 统一 OCR 接口，便于横向对比

把不同 OCR 方案封装成统一接口，是做好选型评测的前提。

from abc import ABC, abstractmethod
from dataclasses import dataclass
from typing import List
@dataclass
class Block:
    text: str
    bbox: tuple          # (x1, y1, x2, y2)
    block_type: str      # text / table / title / figure
    page: int
class OCRBackend(ABC):
    @abstractmethod
    def parse(self, image_path: str) -> List[Block]:
        ...
class PipelineOCR(OCRBackend):
    def parse(self, image_path: str) -> List[Block]:
        # 检测 + 识别，返回带坐标的文本块
        ...
class DocParserOCR(OCRBackend):
    def parse(self, image_path: str) -> List[Block]:
        # 版面分析 + 阅读顺序 + 表格还原
        ...

统一接口之后，切换后端只需要改一行配置，评测也能在同一套指标下进行。

3. 分块与结构化抽取

长文档不能一次性送入模型。按版面块聚合成语义段落，再按 token 预算切分，是更稳妥的做法。

from langchain_text_splitters import RecursiveCharacterTextSplitter
def blocks_to_chunks(blocks: List[Block], max_tokens: int = 1500):
    # 先按阅读顺序拼接，表格块单独保留
    ordered = sorted(blocks, key=lambda b: (b.page, b.bbox[1], b.bbox[0]))
    merged, buf = [], ""
    for b in ordered:
        if b.block_type == "table":
            if buf:
                merged.append(buf); buf = ""
            merged.append(b.text)
        else:
            buf += b.text + "\n"
    if buf:
        merged.append(buf)
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=max_tokens, chunk_overlap=100
    )
    return [c for doc in merged for c in splitter.split_text(doc)]

4. 带 Schema 校验的结构化输出

结构化抽取的关键不是“让模型自由发挥”，而是约束输出格式并做校验。可以先用 Schema 定义字段，再让模型按 Schema 输出，失败则重试。

from pydantic import BaseModel, Field
from typing import Optional
class Invoice(BaseModel):
    invoice_no: Optional[str] = Field(None, description="发票号")
    date: Optional[str] = Field(None, description="开票日期")
    amount: Optional[float] = Field(None, description="金额")
    seller: Optional[str] = Field(None, description="销售方")
def extract_structured(llm, chunk: str) -> Invoice:
    prompt = f"""从下面的文档片段中抽取字段，缺失字段留空。
严格按给定 JSON Schema 输出，不要编造内容。
片段：
{chunk}
"""
    structured_llm = llm.with_structured_output(Invoice)
    return structured_llm.invoke(prompt)

5. 聚合与置信度处理

跨页字段需要合并策略：同一字段多页出现时，取置信度最高者或做一致性投票；冲突时记录人工复核队列。建议在输出中保留来源页码与块坐标，方便追溯。

def merge_results(results):
    merged = {}
    for r in results:
        for k, v in r.dict().items():
            if v is None:
                continue
            if k not in merged:
                merged[k] = v
            elif merged[k] != v:
                merged.setdefault("_conflicts", []).append({k: [merged[k], v]})
    return merged

6. 评测闭环

没有评测就没有选型。建议构建一个小规模金标集，覆盖清晰件、低质件、复杂表格、跨页字段四类样本，指标至少包括：字段准确率、表格结构还原率、单页平均耗时、失败重试率。每次替换 OCR 后端或抽取模型，都跑同一套评测，用数据说话。

五、选型建议：按场景分层决策

把前面的分析收敛成可操作的决策路径：

• 只要字段抽取、版式简单：基础 OCR 流水线 + 纯文本大模型 + Schema 校验，资源最省，维护最简单。
• 版面复杂、表格多：引入具备版面分析能力的文档解析方案作为中间层，再交给结构化抽取模型，兼顾还原度与灵活性。
• 追求端到端、指令灵活：可尝试多模态端到端模型，但必须配套分块策略、输出校验与重试机制，并接受更高的推理成本。
• 数据敏感、必须离线：优先选择许可证清晰、权重可离线分发、依赖可控的方案，提前验证推理框架的离线可用性。

最后提醒一点：结构化总结的瓶颈往往不在模型本身，而在数据质量与后处理逻辑。低质扫描件的去噪、倾斜校正、分页切分，往往比换一个更大的模型更能提升最终准确率。先把预处理与评测做扎实，再谈模型选型，投入产出比会高得多。