企业 AI 模型怎么选？先按任务分层，不要押注单一模型

本文目录

企业做模型选型时，最容易拿到的是排行榜，最难拿到的却是一个能长期执行的决定。公开评测可以帮助发现候选模型，但它回答不了企业自己的问题：这条流程需要多快返回，错误会造成什么后果，数据能否离开当前环境，调用失败后又该怎样继续。在国内，这些问题还要叠加一层约束：面向公众的生成式 AI 服务需要完成安全评估与算法备案，敏感数据通常要求不出境，部分行业对国产化有明确要求。选型因此更像是能力、成本与合规三者之间的权衡，而不是一次性的榜单排名。

更实用的选型单位，与其说是“整个公司用哪个模型”，不如说是某一类任务由什么能力等级的模型处理，并在什么条件下升级、降级或转人工。

先把流程拆成不同的任务

同一条 AI 工作流里，任务难度往往差别很大。例如处理一封售后邮件，可能同时包含：

• 判断来信属于哪个业务类别；
• 提取订单号、产品和故障现象；
• 从知识库检索相关制度；
• 根据材料生成回复草稿；
• 判断是否需要退款、换货或转给专人。

分类和字段提取通常边界清楚，复杂判断与对外回复则更依赖上下文。把它们全部交给同一个高能力模型，实施简单，却可能让低难度、高频步骤承担不必要的时延和费用；全部交给轻量模型，又会把风险集中到最难的节点。

所以，先画出任务清单，再为每一项写明输入、输出、允许的错误和失败后果。Anthropic 关于 Agent 的工程建议同样强调从最简单、足够用的方案开始，只在确有需要时增加复杂度。这个原则也适用于模型选择。

用五个维度建立候选表

模型能力不是唯一维度。至少要同时比较下面五项：

维度	要回答的问题	验证方式
任务质量	关键字段、判断和引用是否达到业务要求	用本企业样本做盲测和人工复核
响应与吞吐	用户能等多久，高峰期是否会积压	记录端到端时延，而非只看模型生成速度
综合成本	一次合格结果实际花多少钱	计入重试、长上下文、工具调用和人工复核
工程适配	是否支持所需上下文、结构化输出和工具调用	用真实接口跑通完整链路
治理约束	数据区域、权限、日志、备案与供应商要求是否满足	由安全、法务和系统负责人共同确认

治理约束在国内比想象的更早介入选型。《生成式人工智能服务管理暂行办法》要求，面向公众提供具有舆论属性或社会动员能力的生成式人工智能服务，应当按照国家有关规定开展安全评估，并履行算法备案手续；配套的国家标准《网络安全技术 生成式人工智能服务安全基本要求》（GB/T 45654-2025）已于 2025 年 11 月实施，把安全评估的技术要求落到可执行的程度。对多数企业来说，选型时要先确认三件事：模型基座是否来自已备案的供应商；数据是否会离开境内，是否允许私有化部署；以及如果自己基于基座对外提供服务，备案与内容安全审核的义务落在谁头上。这些约束应写进候选表的治理列，而不是等模型选完再补。

这里的“综合成本”尤其容易算错。2026 年上半年起，国产模型 API 价格一路下探，以 DeepSeek 为例，V4 系列官方定价中百万 token 输入只有 1 到 3 元，缓存命中时低至 0.02 到 0.025 元，输出也在个位数元区间（DeepSeek 定价页，2026 年 7 月访问）。单价压到这种程度，反而更容易让人只盯着单价。但低单价模型如果需要多次重试，或者给人工留下大量修正工作，未必更便宜；上下文长度、工具调用次数和缓存命中率也会显著改变实际费用。反过来，高能力模型也不该因为一次回答更好，就自动获得所有请求。

测自己的样本，不追逐一个总分

选型测试应复用上线后的验收思路。先准备一组代表性样本，覆盖常见输入、边界情况、资料不足和高风险动作，再为每类任务定义通过标准。关于指标设计，可以参考站内的AI 工作流验收框架。

测试时应保留每个候选模型的原始输出，不要只留下最后的主观印象。至少记录：

• 首次通过率，而不是允许反复调提示词后的最好结果；
• 严重错误数量，例如错误授权、错误引用或遗漏关键限制；
• P50 与 P95 端到端时延，分别观察中位数和较慢的 5% 请求；
• 单次通过结果的平均成本；
• 需要人工修正的比例和修正时间。

公开基准仍然有用，但更适合缩小候选范围。真正决定上线与否的，应是自己的任务分布和错误成本。

从固定分层开始，再考虑自动路由

先简单，再复杂，不要倒过来。

第一版不必马上训练复杂的模型路由器。固定规则更容易解释和排查，例如：

• 批量分类、格式转换和明确字段提取，默认走轻量模型；
• 长文综合、复杂推理和高价值草稿，走能力更强的模型；
• 输入超长、证据不足或结果未通过校验时，升级模型或转人工；
• 高后果动作无论使用什么模型，都保留业务审批。

国产大模型平台也在朝同样的方向演进。阿里云百炼、百度智能云千帆、火山方舟、腾讯云等都已接入多家国产模型，支持在同一应用里配置不同模型并按需切换。对大多数企业来说，采购时可以绑定平台而不是绑定某一家模型，这比同时维护多份供应商接口更省事。但平台的便捷不等于免评测，路由配置是否合理，仍然要用自己的样本验证。

当请求量和任务类型稳定后，团队可以再评估自动路由。微软的模型路由器（Model Router）文档展示了一种产品化做法：根据任务特征，在质量、成本和时延之间选择底层模型。它说明自动路由已经是可实现的工程能力，但并不意味着每个团队都应立刻引入。路由器本身也需要评测、监控和回退。

把降级能力写进选型结果

选模型时就要想好它挂了怎么办。

可运营的模型方案还要回答“首选模型不可用时怎么办”。降级不只是换一个接口地址，因为不同模型在上下文长度、结构化输出、工具调用和安全策略上可能存在差异。

对数据不出境或要求本地化部署的企业，还有一个额外选项：把开源模型部署到自有或专属环境。DeepSeek、通义千问等都有可私有化部署的开源版本，训练输入和运行日志可以不离开企业边界。这也带来新要求：私有化不等于免运维，模型的评测、更新和降级仍要纳入同一套流程，服务器与运维成本也要和调用成本一起算进综合成本。

上线前至少验证三条路径：

1. 首选模型失败后，备用模型能否完成同一任务；
2. 备用模型质量不足时，能否退回只生成草稿或只读模式；
3. 两个模型都不可用时，业务能否转人工或回到原流程。

同时把模型名称、版本、参数、提示词版本和路由规则记录在每次调用中。否则出现质量波动时，团队只能看到“AI 变差了”，却无法判断是哪一项发生了变化。

一页选型结论应该写什么

最终决策不需要是一份厚报告。一页表格就可以说清：

任务	默认模型等级	升级条件	降级方式	关键指标	责任人
邮件分类	轻量	置信不足或类别冲突	转人工队列	分类召回率、P95 时延	客服运营
回复草稿	标准	涉及例外政策	仅返回检索材料	严重错误率、修正时间	业务负责人
高后果判断	不自动执行	始终进入审批	保留原流程	审批准确性、漏拦截数	风险负责人

模型选型不是一次采购动作，而是一套任务分配规则。先用场景筛选表确认流程值得改，再用真实样本选出足够好的候选，最后通过路由、降级和持续评测保留调整空间。国内环境还要在结论里写明模型基座是否来自已备案供应商、数据部署区域以及备案义务归属，否则合规问题会在上线前变成阻塞项。这样，模型更新才不会迫使整个系统推倒重来。