AI模型演进：从规模竞赛转向速度优先的模块化设计

更大并不总是更好，尤其是在人工智能模型领域。大型模型能力更强，但资源消耗也更大，它们利用更大的模型来提供增强的推理、总结甚至代码生成能力。然而，生成式AI模型的规模和可扩展性有其极限。

大型模型设计用于处理开放式问题，这类问题本质上常见于聊天场景。然而，当AI驱动的产品（如CRM系统）使用AI模型时，产品要解决的问题实际上是高度固定和结构化的。这与最初的聊天形式已大相径庭，聊天形式要求AI模型自己定义问题并提出解决方案的步骤。

展望2026年，我们可以预见更灵活的系统设计。AI正从研究转向生产，特别是在企业生态系统中，大型语言模型（LLM）的局限性开始显现。延迟、成本和缺乏控制使得利用LLM处理固定的业务流程变得更加困难。使用LLM解决常规业务问题就像用大锤砸坚果——你并不需要那么大的AI处理能力。

何时“更小”才是“更好”

以AI驱动的电子商务客户支持为例，这是生成式AI最流行的商业用例之一。在实施AI客户支持代理时，第一反应往往是部署像GPT-5 Thinking或Sonnet 4.5这样的大型思考模型来处理完整的客户查询，因为这些思考模型据说足够强大，可以做任何事情，包括理解客户语气、解释请求、生成有同理心的回复、检查库存、处理退货以及升级复杂问题。然而，当实际实施时，会出现一些关键问题：

响应速度慢：大型思考模型通常比小型模型慢。对于电子邮件支持这可能问题不大，但对于聊天支持来说则是个大问题。
成本高昂：大型模型的成本可能是处理完全相同输入的小型模型的10倍。
结果不一致：使用大型模型可能90%的时间能正确回答客户询问，但很难改进最后10%的准确率，因为我们对模型“如何”思考的控制力非常有限。

下一波AI系统将优先考虑架构而非规模。是时候采用更小、更快、更专业的AI模型了，这些模型被设计成模块化组件协同工作，以解决特定的业务问题。

“更大即更好”思维的误区

过去五年，开发者一直专注于优化能够使用对话语言处理开放式推理的“思考”型AI模型。支持此类思考模型的LLM非常适合自由形式的任务，如构思、创意写作和复杂逻辑。它们不太适合结构化的、基于规则的应用，如CRM、ERP和电子商务，但许多组织正在将LLM适配到基于规则的工作流中。

许多业务问题的解决空间在特定工作流内是明确定义的。LLM非常适合自由形式的推理，但AI的任务实际上通常是明确定义的；要创建解决方案的路径并不需要太多的自由推理，而是要在考虑成本和延迟等约束条件的前提下，高效且可预测地执行该路径。

对于处理诸如常规客户问题等问题的交互式系统，企业需要的是可预测性和一致性，而不是不透明的“AI天才”。

模块化意味着更高的效率

与其采用庞大的AI模型，不如将问题分解为一系列更窄的AI任务，每个任务由特定的、轻量级的AI模型处理，这样更有意义。每个较小的模型都执行一个离散的、定义明确的功能。将它们组合在一起，可以形成一个可组合的工作流，在处理明确定义的函数时性能优于LLMs。组装一系列任务特定的模型可以优化速度、成本和可靠性。

例如，我们已经有一套明确的规则来处理客户咨询。让我们从高层次概述如何使用小型模型进行分而治之：

意图分类 – 在开始时使用一个微型模型作为意图分类器。它的唯一工作是读取客户消息并识别客户的需求，无论是退款、订单跟踪、产品信息等。
政策执行 – 根据意图分类器的结果，按照其类别运行预定义的标准操作程序。假设客户要求退款；它可以首先运行一个小型模型来检查商店的退货政策。它可以接受或拒绝请求，要求提供更多信息，或者升级并转交给人工支持。
数据交互 – 如果退款被接受，运行一个模型来生成检查并更新数据库中客户订单数据的操作。
响应生成 – 基于更新订单的结果，AI使用一个小型模型起草回复，甚至无需使用AI，直接使用模板发送简单回复给客户。

虽然这里有多次模型调用，但每一次都比使用单个LLM更小、更快、更便宜。这种方法可以将处理时间减少70%，成本降低50%以上。查询越简单，处理时间越短，成本越低。它也更容易调试。由于每个功能都有特定的职责，开发者可以观察和测试结果。每个组件都可以单独进行基准测试，以识别弱点。

在大多数情况下，这种“一群”较小模型方法的准确性要远高于单个大型思考模型的方法，因为小型模型被要求做一个更简单、更具体的任务，它们产生幻觉的几率要小得多。它的输出自由度也少得多，成功标准更清晰，这减少了出错的可能性。

回归经典软件原则

使用模块化方法可能看起来很熟悉。这标志着回归经典软件工程，而不是将AI系统视为黑盒，开发者可以创建透明和可衡量的元素。

在一个例子中，每个模型的行为就像一个微服务。诸如延迟、每令牌成本和准确性等可观察指标在每个阶段都被跟踪。分类器或文本生成器可以在无需重新训练整个系统的情况下进行更换。工作流可以根据用户上下文或业务逻辑重新配置。

这种模块化方法使AI与现代DevOps实践保持一致。部署管道可以扩展以包含模型组件。监控工具可以记录模型级别的性能、错误率和漂移。其结果是，AI开发成为一种迭代的工程方法，而不是构建一个黑盒。由此产生的系统不仅更快、更可预测，而且更容易大规模维护。

最大的AI采用者的用例大多非常适合这种“一群”较小模型的方法。OpenAI的前30大客户已经使用了超过1万亿个AI令牌。对于这些公司中的大多数来说，AI的使用是明确定义的，因此它们可能会受益于使用一群小模型。

Duolingo是前30名名单中的公司之一。该公司正在将AI用于语言学习，这不需要太多的批判性思维。它需要的是以一致的方式生成多种语言的回复。所需要的只是一系列结构化的、可重复的任务。

生成式AI设计的初衷是应对利用自然语言处理（NLP）的更大挑战。大多数AI应用程序都在利用这种能力，但到2026年，我们可以预期看到从AI模型规模到系统设计的转变。最先进的产品将由其架构而非参数数量来定义。成功的关键在于智能且高效地编排专用模型，以实现特定的业务成果。

AI正在进入DevOps时代。未来不会由单一的巨型大脑构建，而是由一系列分布式微智能体协同工作，以机器速度运行。