4步搭AI文档抽取流水线：发票合同变结构化数据

每月几百份发票、合同、对账单要录进系统，人工做既慢又容易错。用视觉大模型搭一条抽取流水线，4 步就能把 PDF 变成能直接入库的结构化数据，且把人工介入压到 10% 以内。下面每一步都是踩过坑之后留下来的做法。

第一步：Schema 先行，别让模型自由发挥

绝大多数失败案例，起点都是那句「帮我提取关键信息」。模型会按自己的理解返回一堆字段名不统一的文本，你后面还得写解析代码。正确做法是先定义 JSON Schema：字段名、类型、是否必填、枚举值全部写死。

一张发票通常只需要六个字段：invoice_no、date、vendor、tax_id、amount_total、currency。Schema 定死有三个好处：输出可以直接进数据库；缺字段能立刻发现而不是等到入库报错；prompt 也跟着变短，token 成本下降。提示词里必须加一句硬约束：「找不到的字段填 null，禁止根据上下文推测」。模型在字段缺失时非常喜欢「补一个看起来合理的值」，这句话能挡掉相当一部分脏数据。

第二步：分块送模型，整份文档塞进去是最常见的错

一份 20 页的合同一次性丢给模型，注意力会被稀释，最典型的症状是字段串行——第二页的金额被写到第三页的条目上，而且模型输出得很自信。

拆分方式是先做版面切分，按页或按条款区块送模型，一次只处理一个区段，并在 prompt 里声明「这是第 N 页」。表格类内容优先走视觉模型而不是纯文本解析：PDF 的文本层经过排版后经常错位，直接抽文字得到的数字顺序是乱的，而截图送视觉模型反而稳定。生成参数把 temperature 设成 0，同一份输入至少保证输出不发散。

第三步：模型之外加一层规则校验

不要把模型当成唯一裁判。抽取结果先过一遍确定性规则：金额合计是否等于明细之和、日期是否落在合理区间、税号校验位是否通过、供应商名称与历史库做模糊匹配。这些用几十行代码就能写，命中率却很高。

校验失败时不要直接转人工，先把冲突信息回灌给模型——比如「明细合计为 12400，你填的 amount_total 是 14200，请重新判断」。多数算术类错误在这一轮能自愈，这也是投入产出比最高的一步。第二轮仍不一致，才进入人工队列。

第四步：置信度阈值加抽检，把人工用在刀刃上

让模型对每个字段额外输出一个 confidence 值。低于阈值的字段转人工，这部分约占 5%–10%；高于阈值的也别全信，按 5% 随机抽检。抽检不是为了抓当场的错，而是监控漂移——换模型版本、对方换了发票模板、扫描质量下降，都会让准确率悄悄往下掉，没有抽检你根本不知道。

人工纠正过的样本要存下来，做成 few-shot 示例回灌进 prompt。这是整条流水线里唯一能让准确率随时间上涨的机制，不做这一步，三个月后你还得处理同样比例的异常。

成本控制与三个常见坑

视觉模型按图计费，整页高清图是很贵的。可以先跑一层便宜 OCR 做预筛，只把版面复杂的页送视觉模型，成本通常能降一半以上。

三个高频坑：一是追求 100% 自动化，结果异常处理逻辑比抽取逻辑还复杂，正确目标应该是「人工只处理 10%」；二是不记录原始输出，出问题无法回溯是哪一版 prompt 造成的；三是把嵌套表格硬塞进扁平 Schema，最后字段对不上，该拆子表就拆子表。

流水线搭起来大概一两天，之后每处理一千份文档省下的人力，会远远超过这点开发时间。