选模型的决策框架——不是哪个最强选哪个
选模型的决策框架——不是哪个最强选哪个
适读人群：AI工程师、技术负责人、独立开发者 | 阅读时长：约12分钟 | 核心价值：建立实用的模型选型决策框架，避免盲目追新
去年底，一个朋友找我帮他看一个内部工具项目，他们用 GPT-4o 做了一个给客服团队用的 FAQ 问答系统。我问了一下日均调用量——大概两千次。我又问了一下每次平均 Prompt 长度——大概五六百 Token。我脑子里大概算了一下，一个月光模型费就要一两千块人民币。
然后我问他：你试过 GPT-4o mini 吗？
他愣了一下，说没有，觉得 mini 版本不够准。
我让他拿出几个之前失败的案例，我们一起过了一遍——全是客服 FAQ 这种有标准答案的场景，根本就不需要 GPT-4o 的那种复杂推理能力。我们花了半下午把模型换成 GPT-4o mini，质量没有肉眼可见的下降，成本直接砍掉 85%。
这个故事说明一个问题：很多人选模型的逻辑是「选最强的」，而不是「选最合适的」。
为什么「选最强的」是个陷阱
这个陷阱很好理解，人的本能是风险规避。选最贵最好的，出了问题好解释；选个便宜的然后出了问题，会被质疑是不是你选型失误。
但在模型选型上，「最强」是个伪命题。
不同模型在不同任务上的表现差距天差地别。GPT-4o 在需要长链条推理、多步骤规划的任务上确实厉害，但你让它做一个结构固定的数据抽取，它跟 Claude Haiku 的差距基本可以忽略不计。你花了 10 倍的价格，买到的是你根本用不上的能力。
我现在的原则很简单：用能完成任务的最小模型。这不是抠门，是工程判断。
我的模型选型决策框架
做了两年 AI 应用，我给自己整理了一套决策框架。不复杂，四个维度打分，最后根据约束条件筛选。
维度一：任务复杂度
这是最核心的维度。我把任务分成三类：
简单任务：有标准答案或明确格式的任务。分类、打标签、从结构化文本里抽取字段、翻译、FAQ 问答（知识库已经给了上下文的那种）。这类任务小模型完全够用。
中等任务：需要理解语义、进行有限推理的任务。摘要生成、改写、基于文档的问答（文档比较长且信息分散）、代码解释、写作辅助。中等模型（GPT-4o mini、Claude Haiku/Sonnet、Qwen-Plus）能覆盖大部分。
复杂任务：需要多步推理、复杂规划、代码生成（有复杂业务逻辑的那种）、数学推导、跨文档综合分析。这才需要顶级模型（GPT-4o、Claude Sonnet/Opus、Gemini Pro）。
维度二：延迟要求
用户是实时等结果，还是后台异步处理？
实时交互（比如对话、Copilot 类功能）对延迟非常敏感，用户等超过 3 秒就开始不耐烦。这时候首 Token 延迟（TTFT）比总生成时间更重要。大模型在这里就是硬伤。
批量处理（夜间跑一批文档分析、定时生成报告）对延迟不敏感，可以用更大更准的模型。
维度三：成本预算
这个没什么好说的，算清楚就行。
我自己有一个简单的估算公式：
月成本 = 日均调用次数 × 平均Token数（输入+输出）/ 1000 × 每千Token价格 × 30把这个数字算出来，你才知道「能不能用贵模型」。很多人跳过这步，等账单来了才傻眼。
维度四：隐私和数据合规要求
这个是硬约束，不是加分项。
如果数据涉及用户个人信息、医疗数据、金融数据，或者合同里有明确的数据不出境要求，闭源 API 就直接出局。不管效果多好。这时候必须考虑开源模型自部署，或者用国内有数据合规资质的服务（阿里云百炼、腾讯混元等）。
决策矩阵
把四个维度组合起来，我画了一个简化版的决策矩阵。
任务复杂度 × 延迟要求 → 候选模型池
低延迟要求 高延迟容忍
简单任务 小模型 小模型
中等任务 中等模型 中等/大模型
复杂任务 中等模型(接受折中) 大模型
隐私合规要求高 → 从候选池中排除所有闭源API
成本约束紧 → 从候选池中选最便宜的能过关的这个矩阵不是公式，是一个筛选逻辑。先用复杂度和延迟缩小范围，再用合规排除，最后在剩下的里面用成本选。
我自己在不同项目里的判断记录
说几个真实的案例，比抽象框架更有说服力。
案例一：内部知识库问答
公司内部用的，员工问产品手册里的问题。文档已经做好了 RAG，每次给模型的上下文都是检索出来的相关段落，不超过 2000 Token。
任务复杂度：简单（有上下文，只需要基于上下文回答） 延迟要求：中等（内部工具，3-5 秒可接受） 合规要求：无（都是内部文档） 成本：尽量低
选型：GPT-4o mini。用了一个月，回答质量没问题，Token 用量可控。
后来有人提议换成 GPT-4o，理由是「更准」。我拒绝了，理由是没有数据证明 GPT-4o 在这个场景下的 accuracy 更高，而且成本会涨 10 倍。如果要升级，先拿出 eval 数据来。
案例二：合同条款抽取
法务部门要从扫描版合同里抽取特定字段（甲乙方、金额、日期、违约条款）。文档长，字段有固定格式。
任务复杂度：中等（需要理解长文档，但输出格式固定） 延迟要求：低（批量处理，隔夜出结果） 合规要求：高（合同不能出境） 成本：中等
选型：Qwen-Long（支持超长上下文，价格合理，数据不出境）。
这里闭源 API 直接被合规要求排除，不用考虑。
案例三：代码 Review 助手
给工程师用的代码审查工具，分析 PR，给出安全漏洞、性能问题、代码规范的建议。
任务复杂度：高（需要理解代码逻辑，做多维度分析） 延迟要求：中（PR 提交后5分钟内出结果可接受） 合规要求：中（代码不包含用户数据，但业务代码敏感） 成本：中
选型：Claude Sonnet（通过企业版，代码数据不用于训练）。
这里复杂度决定了不能用小模型，合规要求排除了普通的 API 调用方式，选企业级服务解决合规问题。
案例四：用户评论情感分析
电商平台，每天几十万条用户评论要做情感分类（正面/负面/中性）和主题抽取（物流/质量/客服等）。
任务复杂度：简单 延迟要求：低（T+1 处理即可） 合规要求：低（用户评论是公开数据） 成本：必须极低，量太大
选型：先试了 GPT-4o mini，质量没问题，但算了一下月成本要小一万块，有点高。最终用了 Qwen-Turbo 的批量接口，成本降到了两千多。
几个常见的选型误区
误区一：用 Benchmark 选模型
MMLU、HumanEval、各种排行榜，这些数据有参考价值，但跟你的实际任务可能差很远。
我的原则：选型前必须用你自己的测试集跑一遍，哪怕只有 50 个样本。Benchmark 高的模型在你的任务上不一定好。
误区二：忽略模型的「一致性」
有些模型平均分高，但方差大——大部分时候很好，偶尔出奇怪的结果。在生产环境里，不稳定比平均差更要命。
我会专门测极端案例：边界输入、异常输入、很长的输入。这比跑标准测试集更能暴露问题。
误区三：不考虑模型迭代带来的风险
闭源 API 会悄悄更新模型版本，你的 Prompt 可能突然不好使了。这是真实发生过的事，GPT-3.5 到 GPT-4 升级、GPT-4 各个快照版本之间都有过不兼容的情况。
我的做法：在生产环境锁定具体的模型版本（比如 gpt-4o-2024-11-20 而不是 gpt-4o），版本升级单独做评估再切换。
误区四：把模型选型当一次性决定
业务发展了，流量上来了，任务变化了，需要重新评估。我大概每半年做一次系统性的选型复盘，看有没有更适合的选项出现。
一个快速评估模板
最后给一个我自己用的快速评估模板，下次遇到新项目可以直接套：
项目名称：
任务描述（一句话）：
1. 任务复杂度评估
- 输出是否有固定格式？Y/N
- 需要多步推理？Y/N
- 输入文档长度：___Token
- 复杂度判断：简单/中等/复杂
2. 延迟要求
- 用户实时等待？Y/N
- 可接受延迟：___秒
- 延迟敏感度：高/中/低
3. 成本估算
- 日均调用次数：___
- 平均Token数：___
- 可接受月成本：___元
4. 合规要求
- 数据包含个人信息？Y/N
- 数据不出境要求？Y/N
- 有明确合规限制？Y/N
5. 候选模型（基于以上）：
方案A（成本优先）：
方案B（质量优先）：
6. 验证计划：
- 测试集样本数：___
- 质量指标：___
- 上线标准：___这个模板不是让你填完就完事，是逼你在做决定之前把关键问题想清楚。
选模型没有标准答案，但有正确的提问方式。你的任务需要什么，你的约束是什么，然后在这个范围内找最优解——这才是工程师该有的判断方式，不是看谁最贵选谁。