当大语言模型（LLM）在数据归一化方面超越基于规则的系统时（以及何时无法超越）

我认识的一个团队花了三个月时间构建了一个基于规则的地址标准化器。它处理了最常见的 20 种格式，使用 USPS API 进行验证，并且在他们见过的数据上表现出色。然后他们迎来了一个新的企业客户。第一周的数据中，地址被嵌入在自由格式的备注字段里，邮政编码缺少国家前缀，还有他们的规则从未见过的跨境格式。这个标准化器在 31% 的记录上发生了静默失败。他们尝试用 LLM 作为一个快速修复方案，预期准确率为 80%，结果得到了 94%。令人惊讶的不是 LLM 奏效了 —— 而是他们的评估框架中没有任何指标预见到了这一点。

这就是问题的现状。基于规则的标准化是可预测的、快速且廉价的。当数据分布在预设范围内时，它表现良好。LLM 处理的是长尾部分 —— 那些奇怪的格式、隐含的领域知识以及规则永远无法穷举的边缘情况。但 LLM 也很昂贵、缓慢且不稳定，如果你不小心，它们会破坏生产流水线。对于几乎每个团队来说，正确的答案是采用混合方案，在各自擅长的输入上分别使用这两种方法。

性能现状：基准测试说明了什么

在结构化标准化任务中，大模型的表现出奇地好。在产品属性标准化任务（字符串处理、名称扩展、单位转换、类别分配）的基准测试中，GPT-4 在属性提取和整体标准化方面的 F1 分数达到了约 91%。字符串操作的 F1 分数约为 95%。名称扩展达到了 98% 的 F1 分数。表现最弱的类别是计量单位转换，仅为 84%，这反映了 LLM 在涉及重计算推理方面的普遍弱点。

对于实体解析（entity resolution，即检测两条记录是否指向同一个现实世界的实体），生产基准测试显示：

• GPT-4.1：实体匹配任务的准确率约为 81%
• Llama-4-maverick：准确率约为 80%
• 更小/更便宜的替代方案（GPT-4o-mini、Llama-4-scout）：62–65% 准确率

顶尖模型与经济型模型之间 16–19 个百分点的差距在这里至关重要。而大多数团队没预料到的是，检索深度（retrieval depth）的影响反而较小。在多个基准测试中，将检索的候选对数量从 5 个增加到 10 个，准确率的提升不到 1 个百分点。这意味着，如果你试图提高实体解析的准确率，更换模型带来的影响要比微调向量数据库大出几个数量级。

相比之下，在干净的结构化数据（格式相同、词汇受控）上，基于规则的匹配器通常能在低误报率的情况下实现超过 99% 的召回率 —— 但当数据质量下降或出现新格式时，这种性能就会崩溃。

LLM 胜出的场景

LLM 在一组可预测的场景中优于基于规则的系统：

非结构化或半结构化输入。 嵌入在段落中的地址、带有隐含属性的产品描述、没有文档的遗留代码值。规则需要明确的模式；而 LLM 带来的语言理解能力可以跨格式泛化。

格式差异大且数据量小。 如果你每月处理 50,000 条记录，且涉及十几种不同的地址格式，那么为所有格式编写和维护规则的成本将高于调用 LLM 的费用。在这种规模下，单次 LLM 批处理通常不到 50 美元。

隐含的领域知识。 “NYC” → “New York City” 是轻而易举的。但在家具目录中将 “KOA” → “Koa wood”（相思木）则不然 —— 这需要了解该产品线中会出现木材物种的缩写。LLM 无需你专门教导即可编码这些知识。

少样本适应能力（Few-shot adaptability）。 当出现新的数据格式时 —— 例如新供应商的导出格式或新市场的地址惯例 —— LLM 只需 10 个示例即可适应。而规则需要显式的穷举。

长尾效应。 基于规则的系统在遵循已知模式的 80% 输入中实现了出色的覆盖率。LLM 则无需工程干预即可覆盖剩余的 20%。这最后的 20% 通常代表了风险最高的记录：新客户、边缘案例产品或异常地域。

基于规则的系统胜出的场景

规则并未过时。对于很大一类问题，它们仍然是正确的答案：

实时、高吞吐量的标准化。 LLM 处理每条记录最快也需要几秒钟。而基于规则的系统每秒可以处理数千条。欺诈检测、订单处理、会话时段富化 —— 任何会阻塞用户交易的环节都无法承受 LLM 的延迟。

对精确度要求极高的应用。 征信机构、医疗记录去重和身份匹配要求误报率低于 0.1%。LLM 对于表述略有不同的相同查询会产生不一致的结果，这破坏了这些系统所需的精确度保证。例如，“123 Main St 的 John Smith 是否与 123 Main Street 的 J. Smith 是同一个人？” 这个问题会根据你的提问方式产生不同的置信度。这种不一致性在受监管的身份匹配中是不可接受的。

审计追踪。 在金融、医疗或法律背景下，“LLM 这么说的” 不是一个符合审计要求的回答。规则会产生你可以追踪和解释的确定性决策。当数据处理决策需要由人类审计员审查时，这一点至关重要。

数学标准化。 单位转换、数量计算、派生字段。LLM 在单位转换基准测试中仅达到 84%，并且会产生算术幻觉。对于数学运算，请使用确定性的代码。

大多数团队都会掉入的成本陷阱

这种失败模式通常是这样演变的：一个团队对 LLM 归一化（normalization）进行了原型设计，在 10,000 条记录的测试集上运行良好，于是他们批准将其投入生产环境。六周后，基础设施账单翻了三倍。

背后的数学逻辑简单且残酷。一条包含 100 个单词描述的产品记录，通过包含 Schema 上下文和指令的 Prompt 处理，很容易就会消耗 500 个 Token。在 100 万条记录的情况下，那就是 5 亿个 Token。按每百万 Token 5 美元计算，仅输入 Token 就需要 2,500 美元。加上输出 Token、重试开销以及用于验证的多次 API 调用，一个针对中型电商目录的简单 LLM 归一化流水线，每次运行的成本可能高达数万美元。

真正有效的优化杠杆：

批处理（Batch processing）。 OpenAI 的 Batch API 收费仅为实时价格的 50%。Anthropic 的批处理同样比标准费率优惠约 50%。大多数归一化工作对延迟并不敏感。将记录排队进行批处理，可以在不对模型选择或 Prompt 设计做任何工程改动的情况下，立即将 API 成本降低一半。

选择性查询。 使用规则（或廉价的 Embedding 相似度评分）根据难度对记录进行分类。将高置信度的记录直接通过基于规则的归一化进行处理。仅将模糊不清的记录发送给 LLM。这种减少不确定性的框架通常能在保持整体准确性的同时，将 LLM API 的调用次数减少 4–5 倍。

混合过滤。 使用廉价的 Embedding 检索来缩小候选范围，然后仅对模糊案例应用 LLM 验证。在实体解析（entity resolution）基准测试中，这种混合方法能以极低的成本达到或超过纯 LLM 的表现。

数据进入生产环境前的验证

LLM 归一化的输出在没有验证层的情况下，不能直接进入你的生产数据库。其失败模式往往非常隐蔽：一个看起来很合理的幻觉分类、一个被误匹配到错误记录的实体、或者一个通过了 Schema 验证但包含错误数据的归一化值。

一致性检查。 针对同一条记录生成两个或三个独立的 LLM 响应。当它们不一致时，说明该记录具有不确定性——应将其路由到人工审核，而不是自动解决。这种方法捕捉到的错误比单次生成多出约 20%，而代价是 3 倍的 Token 成本，这通常是值得的权衡。

Schema 强制执行。 尽可能将 LLM 的输出限制在已知的有效值集中。如果你正在归一化产品类别，且你的分类体系有 847 个节点，请在 Prompt 中列出有效的类别列表，并根据该列表验证输出。拒绝不匹配的输出。这能将隐性错误转化为你可以处理的显性失败。

统计抽样。 对于批量归一化运行，在提交完整批次之前，随机抽取 100–200 条记录进行人工审查。这可以在系统性错误（例如模型持续错误标记某个产品线，或 Prompt 删除了必需的限定字段）大规模进入生产环境之前将其截获。

测试集纪律。 实体解析和数据归一化任务的公开基准测试自 2023–2024 年以来就已存在于 LLM 的训练数据中。你在公开基准测试上的评估准确率并不是生产环境准确率的可靠预测指标。请根据你真实的生产记录构建专有的测试集，定期轮换，并将其视为受控资产。

真值（Ground-Truth）难题

许多数据归一化任务并没有标准的正确答案。“J. Smith, 123 Main St”和“John Smith, 123 Main Street, Apt 4B”是同一个人吗？这取决于其他信号——出生日期、电话、电子邮件、交易历史。真值是概率性的，而非二元的。

这产生了一个测量问题。如果你的测试集为本质上不确定的记录分配了二元标签，那么你的 F1 分数衡量的是模型与随意标注决策的一致性，而不是其真实的准确性。在实践中：

• 对于真正模糊的记录，接受多标签真值
• 使用基于集合的指标（Jaccard 相似度、标签集之间的 F1）进行评估，而不是二元准确率
• 报告指标的置信区间，而不是点估计值
• 当使用 LLM 生成真值标签（一种常见的冷启动方法）时，要意识到这会使评估偏向于同一系列模型——你的准确率估算会看起来比实际情况更好

真正提升系统的反馈闭环

人工纠错是宝贵的训练信号，但大多数团队在收集这些信号后并没有将其路由到任何地方。始终有效的模式是：

• 高置信度的预测直接进入生产环境——无需人工干预
• 低置信度的预测（基于一致性检查不一致、低相似度评分或 Prompt 提取的不确定性）进入审核队列
• 人工审核员对低置信度记录进行纠正
• 纠错记录不断积累；每月或每季度，针对纠正后的数据集进行微调（fine-tuning）或 Few-shot 更新
• 在上线更新后的系统之前，先与之前的版本进行 A/B 测试

实施了结构化反馈闭环的团队报告称，在三个月内，其特定归一化任务的准确率提高了 15–30%。关键在于路由架构——如果没有它，人工纠错只是针对特定记录的一次性修复，而不是系统性的改进。

实践中的混合架构

在生产负载下能够稳健运行的架构结合了三个层级：

1. 基于规则的标准化处理高置信度、高吞吐量的大部分数据。针对标准格式的正则（Regex）、受控词汇的查找表、数学运算的确定性逻辑。这一层以极低的单条记录成本处理 60–80% 的记录。

2. 基于嵌入（Embedding）的预过滤缩小了实体解析的候选范围。廉价的向量相似度搜索可以识别可能匹配的记录；这不是最终答案，只是一个候选名单。

3. LLM 验证仅解决前两层标记的模糊案例。在典型的生产语料库中，这可能占记录的 10–20%。通过批量定价，这种方式是可负担的。

每一层根据置信度而非记录类型将任务移交给下一层。路由逻辑是大部分工程工作的核心所在——也是在你为每一层选择了合理的组件后，大部分准确率提升的来源。

真正需要衡量的指标

在将 LLM 标准化上线到生产环境之前，你需要关注三个数字：

分层准确率。不是所有记录的综合准确率，而是每一层实际处理记录的准确率。如果你的规则层以 99.5% 的准确率处理了 70% 的记录，而你的 LLM 层以 91% 的准确率处理了 30% 的记录，你的综合准确率看起来是 97%。但 LLM 层 9% 的错误率可能集中在你最复杂、价值最高的记录上。

误报（False Positive）成本与漏报（False Negative）成本。对于实体解析，误报（将两个不同的实体合并）的下游成本通常比漏报（未能合并重复项）要高得多。根据核心成本来调整你的阈值。

每条正确记录的处理成本。处理的 Token 数量、批量与实时处理的比例、重试开销。随着数据量的增长，这个数字需要保持稳定。如果它在没有优化的情况下随数据量线性增长，那么你正在为一个尚未发现的错误买单。

统领全局的法则

规则在世界改变之前是快速且廉价的。LLM 在你约束它们之前是灵活且昂贵的。早期构建混合系统的团队——通过置信度进行路由、验证输出、运行反馈循环——并没有把时间花在维护脆弱的规则集或调试不明原因的 API 账单上。他们把时间花在改进路由逻辑上，这才是真正的杠杆点。

如果你从零开始：先让基于规则的层跑起来，为其增加置信度检测工具，并且仅针对规则失败的记录添加 LLM 处理。LLM 层不是规则的替代品。它是当规则穷尽时你所使用的那一层。