你的 AI 功能应该先输给正则表达式一次

一个团队花了三周时间集成一个基础模型，将收到的支持工单分类到不同的路由类别中。该模型在测试中达到了 87% 的准确率。他们发布了。六个月后，一名工程师注意到 70% 的工单在主题行中包含产品名称，而一个简单的查找表就能以 99% 的准确率处理这些工单。LLM 正在处理那困难的 30%，而在其余时间里则在胡言乱语。

这并非一个少见的故事。之所以会发生这种情况，是因为团队将“使用 LLM”作为首选的实现方案，而不是最后的手段。解决方法是设立一个强制性的关卡：在被允许构建 AI 版本之前，你的 AI 功能必须先输给一个笨规则。

基准测试关卡究竟是什么

基准测试关卡（Baseline gate）并不是建议去尝试简单的东西。它是一个结构化的检查点，位于任何 LLM 集成、微调或 RAG 投入之前。规则是：

构建一个可能解决该问题的最简单的确定性系统。测量它。只有当 LLM 在对业务至关重要的指标上明显优于该系统时，才继续使用 LLM。

这听起来显而易见。但几乎普遍被忽略了。原因是基础模型的 API 触手可及，以至于跳过基准测试感觉像是在节省时间。而在实践中，你正在以高利率借入技术债。

Google 在十多年前的机器学习工程指南中就将其成文：不要害怕在没有机器学习的情况下发布产品。如果你认为机器学习能带来 100% 的提升，启发式方法也能带你走完 50% 的路程。这种洞察并没有因为 LLM 的出现而变得过时。它反而变得更加紧迫，因为调用 LLM 需要花费真金白银，而确定性规则的成本基本为零。

笨规则的分类

一个有用的基准测试不是占位符。它应该是你在没有模型的情况下能构建的最好的确定性系统。根据问题的不同，这有不同的形式。

关键词和正则表达式匹配可以处理现实世界中大部分输入的分类、路由和提取。主题行分类、垃圾邮件检测、意图路由、从结构化字段中提取实体——在这些场景中，很大一部分样本的信号在文本中是显性的，模式匹配就能找到。失败模式在于工程师估计覆盖率只有 20%，而实际上是 70%。

查找表和精确匹配在相关项目预先已知的情况下处理推荐、检索和个性化。展示下载量最高的内容、最近使用的联系人、某个类别的畅销产品——这些方法在高频分布上表现良好，且完全不需要推理预算。

决策树和阈值规则处理决策逻辑已知且稳定的评分、异常检测和审批工作流。如果交易金额超过 10,000 美元且账户创建时间少于 30 天，则进行标记。如果用户的会话次数少于三次，则显示引导流程。逻辑透明、可审计，且运行时间以微秒计。

频率和新鲜度启发式方法处理时间信号预测相关性的排序情况。在证明需要任何个性化模型之前，按最后使用、最高浏览或最高评分排序可以涵盖惊人比例的排序问题。

共同点是：这些系统的构建成本低廉，只需一小部分开发时间，并且产生的输出完全可解释。一个只需 10% 的努力就能覆盖 60–70% 输入的基准系统并不是安慰奖。它是你 60–70% 流量的正确架构。

你正在忽略的成本算术

LLM 推理在抽象概念上并不昂贵。但在规模化之后，以及与替代方案相比时，它就很昂贵了。

按当前定价，中端前沿模型的成本约为每百万 token 3–18 美元。一个典型的分类或提取调用可能会消耗 300–800 个 token。每天 10,000 次请求，每天就是 9–54 美元，或每年 3,000–20,000 美元——这仅仅是针对单一功能。匹配相同输入的正则表达式所需的 CPU 时间几乎可以忽略不计。

这个比例不是 10 倍。对于常见的模式匹配任务，一旦考虑到延迟、重试成本以及对供应商依赖的操作开销，这个比例更接近 100 倍或 1,000 倍。

当 LLM 真正必要时，这种算术会发生变化。对于信号隐含在语义中而非显式语法中的输入——模糊的意图、多语言文本、非结构化的自由格式输入、多步推理——基于规则的系统无法完成工作，成本是合理的。但这种成本只有在你确定廉价系统无法达到可接受的性能后才是合理的。在测量之前，你只是在猜测。

2020 年卡内基梅隆大学 (CMU) 的一项分析发现，基准模型通常只需 10% 的开发时间，就能达到 90% 的生产质量结果。发表在《Nature》杂志上、拥有 13,000 个参数的地震余震预测深度学习模型，被一个仅有两个参数的逻辑回归模型击败了。复杂度并不自动胜出。问题在于工程师在 LLM 超过某个阈值后就停止了测量，而没有检查更简单的系统是否也能超过同样的阈值。

构建基准：一个实用的协议

基准门槛需要是一个真实的产出物，而不仅仅是一句“我们考虑过规则，然后跳过了”的口头免责声明。这意味着：

第一步：枚举输入分布。 在构建任何东西之前，从问题域中抽取 200–500 个真实输入示例。对它们进行聚类或人工审查。识别出哪些部分具有明显的确定性信号，哪些部分确实存在歧义。仅这一步通常就会显著改变工程计划。

第二步：完整构建确定性系统。 不要只写个占位符或仅实现简单情况。编写正则表达式。构建查找表。编写决策树。使其针对它所处理的输入达到生产级质量。对于一个界定良好的问题，这通常需要一到两天时间。

第三步：分别测量覆盖率和准确率。 覆盖率是基准系统处理的输入比例。准确率是基准系统在所覆盖部分中的正确性。一个能以 97% 的准确率覆盖 65% 输入的基准系统是非常强劲的结果——这意味着 LLM 只需要处理剩余的 35%，从而大幅降低推理成本和故障面。

第四步：在未覆盖的长尾部分确定 LLM 的增量价值（delta）。 应该专门针对基准系统无法处理的输入对 LLM 进行评估。如果 LLM 在这部分长尾输入上的准确率并不比回退方案（返回默认值、请求用户澄清或转接人工）有实质性提升，那么 LLM 就没有赚回它的成本。

第五步：在团队流程中明确这一门槛。 “我们击败规则了吗？”这个问题应该出现在设计文档、PR 描述或功能评审中。如果没有明确的检查点，在进度压力下，这个门槛通常会被跳过。

LLM 在哪些场景下真正胜出

诚实地执行这一协议，将能够识别出 LLM 确实比确定性系统更有价值的场景。

歧义的自然语言意图 是最典型的例子。当用户输入“我的账户需要帮助”时，查找表无法进行路由。正则表达式会出现过度匹配或匹配不足。而一个拥有用户近期活动上下文的 LLM 则可以推理出最可能的意图。这就是 LLM 投资能获得回报的那 30% 的长尾场景。

跨语言输入。规则系统必须使用特定语言的显式模式来处理，而多语言模型可以统一处理。对于全球化产品，确定性规则会无限膨胀，基准方法就会失效。

从真正的非结构化文本中进行组合式提取——例如法律文件、包含多个嵌套问题的支持邮件、字段边界隐含的技术规范——这需要模式匹配无法提供的语义理解。这种复杂性是真实存在的，当你衡量基准系统时，它会清晰地显现出来。

动态领域。在这些领域，相关实体和关系的变化速度超过了查找表的更新速度，这便受益于模型的泛化能力。静态规则会失效；而模型可以定期重新训练，或者通过更新上下文进行提示。

在 LLM 胜出的案例中，共同点在于：输入具有歧义性、多语言性，或在结构复杂性上使得显式规则无法以经济的方式捕捉。这些情况确实存在。它们在真实产品中占据了真实的比例。但它们并不是 100% 的输入，而将所有输入都视为此类情况，正是基准门槛所要防止的核心错误。

将“我们击败规则了吗？”设为必选门槛

那些在 LLM 上持续过度投入的团队并非因为粗心。而是因为他们的评估流程是从模型开始的。他们问的问题是“LLM 有多好？”，而不是“LLM 相比替代方案是否增加了足够的价值来支撑其成本？”

反转这个问题会改变一切。它会让那些 60–70% 可以由查找表或正则表达式处理的情况浮出水面。它让 LLM 的投入集中在真正能推动指标的长尾部分。它产生了一种混合架构，这种架构比纯模型方法更便宜、更快速、更易调试且更易维护。

这个门槛不需要官僚化。它必须是不可逾越的。在批准任何微调预算、设计任何 RAG 管道或将任何基础模型 API 集成到生产路径之前，必须用测量数据回答一个问题：最简单的确定性基准在该问题上实现了什么效果，以及 LLM 在基准无法处理的输入上相比该基准的增量（delta）是多少？

如果你没有做过这个实验，你不知道你是否需要这个模型。如果你不知道这一点，你花费的每一个 token 都是在凭空猜测。