当大语言模型（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 的表现。

加载中…