规则 vs LLM：B2B 文档提取该怎么选？

一句话结论

不要把 LLM 当成所有文档提取问题的默认答案。模板稳定、吞吐量高、审计要求强时，规则系统更合适；客户多、版式变化大、字段命名不可控时，LLM 才真正体现价值。

这篇文章讲了什么

原文作者用同一个 B2B 订单 PDF 提取任务做了两遍实现：

第一版：OCR 加正则规则。
第二版：OCR 加本地 LLM。

任务看起来很简单：从 PDF 订单里提取客户 ID、采购订单号、交付日期和订单明细。

现实问题是，不同客户的 PDF 长得不一样：

有的写 PO Number。
有的写 Order Reference。
有的把字段放在左上角。
有的把字段放在右下角。
日期格式也可能不同。

人看一眼就知道这些字段是什么意思，但传统自动化系统并不天然理解“语义等价”。

规则方案的优点和问题

规则方案的典型链路是：

用 OCR 把 PDF 转成文本。
用正则表达式匹配字段。
把匹配结果写入结构化输出。

它的优点很明确：

快。
便宜。
可解释。
方便审计。
对固定模板非常稳定。

但它的问题也很明确：

字段名一变，规则可能失效。
版式一变，定位逻辑可能失效。
客户越多，规则越多。
长尾模板会把维护成本拖高。

文章里的例子很典型：当文档使用 PO Number 时，正则能正常提取；当另一个文档把同一含义字段写成 Order Reference 时，原规则直接返回空值。

这不是正则写得差，而是规则系统本来就缺少上下文理解能力。

LLM 方案的价值

LLM 方案仍然需要 OCR，但后面的提取逻辑变了：

不再逐个写字段规则。
而是告诉模型：请提取这些业务字段，不管它们在文档中怎么命名。

它的优势在于语义理解：

能把 PO Number 和 Order Reference 理解为同类字段。
能从不同位置找到目标信息。
能顺手做一些格式归一化，例如把不同日期格式转成统一格式。

这就是 LLM 在非标准化文档里的核心价值：减少模板适配和规则维护。

但 LLM 不是免费午餐

LLM 方案带来的不是“无成本智能”，而是另一组成本：

推理慢：文章测试中单份文档约 20 到 40 秒。
资源重：本地 LLaMA 3 模型约 4.7GB。
成本更高：大批量文档会放大算力和并发压力。
可解释性弱：模型为什么这样抽取，不如正则清楚。
合规更难：金融、医疗等场景可能需要更强审计链路。

所以问题不应该是“规则好还是 LLM 好”，而应该是：

文档变化有多大？
模板长尾有多长？
每天处理多少份？
错误成本有多高？
是否需要审计可解释？

更现实的方案：混合架构

生产里通常不必二选一。更稳的方案是混合架构：

高频稳定模板：用规则处理。
低频长尾模板：用 LLM 处理。
规则失败或置信度低：交给 LLM 兜底。
LLM 输出：再做结构校验和人工抽检。
高风险字段：保留人工复核或二次验证。

这样可以同时保留规则系统的速度和成本优势，也利用 LLM 处理变化和长尾。

对团队的启发

引入 AI 前，先算一笔账：

规则维护成本是多少？
LLM 推理成本是多少？
错误修复成本是多少？
业务增长后哪一项会先失控？

如果规则维护已经成为主要瓶颈，LLM 是好工具。

如果现有模板稳定、吞吐量很大，贸然上 LLM 可能只是把简单问题复杂化。

可执行落地建议

先统计历史文档模板分布，找出高频模板和长尾模板。
对高频模板继续使用规则，保证速度和成本。
抽取一批长尾样本，用本地 LLM 或 API 做小规模验证。
不只看准确率，也要记录延迟、成本、失败类型和人工复核成本。
如果采用 LLM，必须加结构化校验、置信度策略和异常回退流程。

原文信息

原文标题：I Built the Same B2B Document Extractor Twice: Rules vs. LLM
原文链接：http://towardsdatascience.com/i-built-the-same-b2b-document-extractor-twice-rules-vs-llm/
项目代码：https://github.com/Sari95/ocr-pdf-extraction-regex-vs-llm

适合转发的一句话

文档提取不是“上不上 LLM”的问题，而是“模板变化带来的维护成本，是否已经超过 LLM 的算力、延迟和审计成本”。