为什么最强大的AI模型并不总是适合您的应用程序

选择最强大的模型似乎是一种自然的选择。当您构建一个AI驱动的产品时，选择最强大的模型似乎是一种责任（几乎是逻辑性的）。GPT-4o、Claude Opus、Gemini Ultra都是令人印象深刻的技术，选择最聪明的工具似乎是一个安全的选择。

但是，有一个问题。项目变得臃肿，成本飙升，延迟开始出现。大约在第三个月，团队开始问为什么一个简单的自动补全功能会消耗掉API积分，就像一个没有责任感的初创公司一样。

关键在于，“最强大”和“最合适”是两个不同的标准。提供AI应用开发服务的供应商会根据评估选择模型，而不是排行榜排名。

更大并不总是更好

一个前沿模型在理想条件下表现非常好，但操作成本很高，处理不完美的输入很差，并且超过了简单任务的要求。

GPT-4o可以写诗，推理法律合同，调试代码，并向10岁的孩子解释量子纠缠，有时在同一个响应中。这种能力确实令人印象深刻。但是，如果您的应用程序只是总结客户支持票或从发票中提取结构化数据，您将为未使用的功能付费。

较小的、专门的模型可以以令人印象深刻的准确性处理专注的任务：

• GPT-4o迷你版可以以大约15倍较低的成本覆盖大多数语言任务
• Claude Haiku专为高容量、结构化工作负载的速度和效率而设计
• Mistral 7B和Llama 3.1 8B是可以快速运行和微调的开源选项

当任务狭窄，提示精心设计时，这些模型与前沿模型之间的差距会大大缩小。

规划会议中没有人讨论的成本数学

前沿模型的API定价可能比其较轻的对应模型每个令牌高出10到30倍。这种差距听起来很抽象，直到你在大规模上建模它。

假设您的应用程序每月进行500,000次API调用：

相同的功能，非常不同的利润故事。

一些团队运行混合架构，将简单的分类任务路由到轻量级模型，同时为复杂的生成或推理步骤保留较重的模型。像Martian和RouteLLM这样的公司已经为此类模型路由构建了工具。这不是很光鲜的工程，但它是让CFO感到放松的东西。

延迟是一个用户体验问题

快餐的存在是有原因的。人们并不总是想要五道菜。有时他们想要立即得到答案。

前沿模型更慢。并非总是慢很多，但足以在实时应用中产生影响。如果您的用户正在等待AI响应，在对话式UI、聊天界面或实时编码助手中，响应延迟直接影响产品的感觉。一个需要4-6秒才能响应的模型开始感觉不可靠，即使输出在技术上更好。

经验法则：如果用户看到加载旋转器，每多一秒都会减少信任。

Haiku、Mistral和Llama 3.1 8B在类似的负载条件下运行速度明显更快（有时快3到5倍）。对于用户面向的功能，感知到的速度很重要，这不是一个小问题。这是一个产品决策。

改变一切的提示工程变量

在模型比较线程中经常被忽略的一件事是：在较小的模型上精心设计的提示往往可以击败前沿模型上的懒惰提示。

输出质量是模型能力和提示质量的产物。当团队投资提示工程（清晰的指令、结构化的输出格式、少次示例、明确定义的约束）时，较小的模型可以远远超出其明显的上限。

以下是一些值得了解的工具：

• LangChain和DSPy用于组成和优化提示管道
• Guidance用于约束生成和结构化输出
• PromptFoo用于在模型上运行系统提示评估

今天生产中的一些最令人印象深刻的AI功能实际上是在不会进入前五名的任何能力排行榜的模型上运行。它们只是运行在非常好的提示上。

微调改变了等式

一旦微调进入画面，前沿模型和较小的开源模型之间的比较看起来就完全不同。在您的特定域数据（您的术语、您的边缘情况、您的首选输出格式）上微调的Llama 3.1 8B模型可以在您的特定任务上超越GPT-4o。

这不是一个假设性的例子。医疗保健、法律技术和电子商务公司已经反复证明了这一点。

微调的起点：

• Hugging Face用于开源模型托管、数据集和训练基础设施
• Together AI用于在热门开源模型上进行快速、经济的微调运行
• Replicate用于在不管理自己的GPU基础设施的情况下部署自定义模型

微调需要前期投资：数据策划、计算时间和评估工作。但是，对于高容量、特定领域的任务，经济学往往会有利地发展。

安全性和数据居住权不是事后补充

一些应用程序根本无法将数据发送到第三方API。考虑：

• 在HIPAA下运营的医疗保健平台
• 处理PII或受监管交易数据的金融工具
• 具有严格数据居住权要求的企业软件

这些环境有前沿模型API无法绕过的约束，无论其能力如何。自托管模型，无论是在本地还是在私有云中，都是唯一的前进道路。这意味着像Llama 3、Mistral或Phi-3这样的开源模型在您的基础设施上运行。您无法在生产中使用的前沿模型不是正确的选择，毫无疑问。

团队经常跳过的评估步骤

大多数团队通过假设最昂贵的模型是最好的来选择模型，而没有进行测试。他们应该做的是在代表性样本的实际用例上运行结构化评估。

以下是一个有效的过程：

1. 构建一个包含100到200个代表性输入和预期输出的评估集
2. 在现实条件下将它们运行在两个或三个候选模型上
3. 根据您的实际标准进行评分：准确性、格式合规性、语气、延迟、每次调用成本
4. 根据数据进行决策，而不是依赖直觉或排行榜排名

像Braintrust、PromptFoo和Weights & Biases Prompts这样的工具可以让没有研究背景的团队进行系统的评估。设置需要几个小时。回报是不会选择六个月的错误模型。

何时真正需要前沿模型

公平地说，有些任务真正需要前沿模型。

使用前沿模型时：

• 任务需要复杂的、多步骤的推理，没有明确的模板
• 输出质量差异很昂贵，且体积相对较低
• 您需要广泛的世界知识或细致的判断，无法通过提示来实现
• 您正在进行原型设计，尚未定义任务边界

使用较轻的模型时：

• 任务明确定义且重复
• 速度和成本在您运行的体积上很重要
• 您可以投资提示工程或微调
• 数据居住权或合规性规则排除了第三方API

关键点不是避免强大的模型。关键点是要有意图地选择，基于证据，而不是默认选择排行榜上最大的名字，因为它感觉像是一个安全的选择。

总结

为您的应用程序选择AI模型不应该感觉像是一场声望竞争。纸面上最强大的模型并不总是适合您的问题，或者通常如此。

将模型与任务相匹配。运行真实数据的评估。考虑延迟、成本、安全要求和您的团队进行提示工程或微调的能力。最好的AI产品决策是基于这些具体因素，而不是基于哪家公司在上个季度发布了最令人印象深刻的数字。

交付出色AI产品的团队并不一定是在运行最强大的模型。他们正在运行最合适的模型。