# 规则 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 好”，而应该是：

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

## 推荐判断标准

### 优先用规则的场景

- 少数模板覆盖大部分业务。
- 文档字段稳定。
- 每天处理量很大。
- 延迟和成本敏感。
- 需要明确可解释和可审计。

一个简单判断：如果前 5 种模板覆盖 90% 以上订单，先用规则，不要过早引入 LLM。

### 优先考虑 LLM 的场景

- 客户很多，每个客户文档都不同。
- 字段名、位置、格式经常变化。
- 长尾模板维护成本很高。
- 提取任务需要语义理解。
- 可以接受更高延迟和成本。

如果是 200 个客户对应 200 种模板，而且还在持续变化，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 的算力、延迟和审计成本”。