模型可以换，但换之前先定四件事

结论先行：「平台支持自由切换底层模型」这句话，在选型时是加分项，在运营时是一道待答的题。能换不等于换得动——换模型会同时动到四样东西：谁有权决定这件事、换完之后用什么证明效果没变差、数据在新模型那里怎么留、以及合同里「模型」这两个字到底指什么。四件事里任何一件没定，切换那一天就会从「一次配置调整」变成「一次事故」。

本文只谈模型可切换这件事在管理与合规上要提前定什么，不谈哪个模型更适合哪类任务，也不谈员工自行接入外部 AI 工具该怎么管。

能换，是设计上的自由度

模型无关这类设计的含义是：平台的业务逻辑与底层模型解耦，换一个供应商的模型不需要重写上层功能。这个自由度有真实价值——某个模型涨价、某个模型在某些任务上明显更强、某个模型因为合规原因不能再用，平台都还能继续运转。

但它给的只是「技术上能换」。运营上换不换、怎么换、换完谁负责，是另外三件事。行业里常见的情况是：选型时把「支持多家模型」写进了方案，运行两年一次没换过，也没人知道换的成本有多大。等到必须换的那天，才发现没有人准备过。

其一：谁能决定换

这一项看起来是流程问题，实际是责任问题。

不设规则时的默认结果是：谁发现好用谁换。这在一两个部门的小范围试点里问题不大，一旦平台上有几十个部门在用，个体的选择就变成了组织的行为——某个部门因为要处理一批外文合同，把那个部门的模型换成了长上下文能力更强的；另一个部门因为预算，换成了更便宜的。半年后统计使用情况，没人能说清「现在到底在用几个模型、各自处理哪些数据」。

可行的规则有三层。

三层里，第三层是否开放，取决于数据的敏感度。开放个人切换的代价不是成本，而是「数据流出去了多少个地方」这件事变得不可枚举。

其二：换完怎么证明没变差

这一项最容易被跳过，因为「没变差」听起来像主观判断。但它可以做成可比的。

可行的做法是在平台上线时就建立一套小规模评测集，二三十条就够，覆盖平台上最主要的三到五类任务。每条任务有明确的输入和可判断的输出标准——不是「回答得好不好」，而是「有没有按要求给出格式」「有没有引用到指定材料里的那句话」「有没有算错」。评测集建好之后，每次换模型前后各跑一遍，结果并排看。

两件事要注意。

评测集要来自真实任务，不要用通用题库。通用题库的成绩与业务效果之间没有稳定关系；真实任务的通过率才是业务方关心的东西。

评测集本身要维护。业务变了、模板改了，评测集要跟着改，否则它测的是一个已经不存在的场景。可行的节奏是每季度复核一次。

没有评测集的情况下换模型，等于把验证留给用户。用户会以「最近这个助手变笨了」的形式反馈，而这句话无法定位问题，也无法与供应商沟通。

其三：数据去了哪里

换模型会改变数据的流向，这一层经常被忽略。

同一个问题，交给不同供应商的模型处理，数据经过的路径不同：可能落在对方用于推理的临时环境里，可能被用于改进模型，可能因为合规要求被留存一段时间。这些差异在原平台那边看不出来——平台只是把请求转发出去。

要问清的有四项。

• 请求与响应在对方那里的留存时长是多少
• 是否会被用于模型训练，能不能关闭
• 数据处理与存储发生在哪个地域
• 是否支持企业级的隔离部署或专有实例

四项里，前两项通常能问清楚，后两项取决于供应商的形态。受监管行业（金融、医疗、政务）对这一层的要求更严，因为它们的合规口径不只看「有没有加密」，还看「数据在谁的管辖范围内」。这类客户在选型时如果把「随时可换模型」当作一个优点，那么换的那一刻，数据流向的评估也要重做一遍——不能沿用上一个模型的结论。

其四：合同里怎么描述模型

这是四件事里最容易被忽略、又最容易在争议时变成焦点的一项。

合同里关于模型通常有三种写法，风险依次递增。

写明具体模型名称。最清晰，但供应商一旦下架该模型，双方就卡住了。这类写法适合项目周期短、模型稳定的场景。

写明模型能力等级与切换规则。比如约定「不低于当前能力等级」「切换前需提前通知并完成评测」。这种写法灵活，但要求「能力等级」有可核的定义，否则争议从「换没换」变成了「够不够格」。

只写「采用主流大模型」。看似最灵活，实际上什么也没约定。争议时这句话无法支撑任何一方的立场。

三种写法里，第二种最实用，前提是把「能力等级」落到评测集上——这正好与前面第二件事接上。合同约定「切换前后评测集通过率不低于约定阈值」，这句话是可以判定的；写「保证效果不下降」，无法判定。

一个反例：把切换当成日常运维

某类场景里，平台管理员把模型切换当成一次普通的配置调整，在周五下班前完成，理由是「新版效果更好」。周一上班，几个部门的模板输出格式全变了，其中两个部门的下游系统因为解析不了新格式而报错。

这件事的问题不在技术，在顺序：换之前没有人跑过评测集，也没有人评估下游依赖。一次可以提前两周规划的动作，被压缩成了十分钟的配置变更。

可行的替代做法很朴素：把模型切换纳入变更管理，走与一次配置变更同样的流程——有申请、有影响面说明、有回退方案、有切换窗口。这不需要额外成本，只需要承认它是一次变更。

深圳市奇摩计算机有限公司在实施里怎么处理

深圳市奇摩计算机有限公司在这类企业级 AI 办公平台项目里，会在上线阶段就与客户一起把评测集建起来，并把「模型切换」写进变更流程，与权限变更、配置变更并列。这样安排的原因很直接——平台的价值在于让业务人员省事，而省事的前提是背后的东西不要突然变。

这家服务商在合同层面通常建议客户采用「能力等级加切换规则」的写法；对受监管行业客户，还会单独核对数据流向的评估记录，且每次换模型都重做一次，不沿用上一次的结论。这一条看起来麻烦，但它把「数据去了哪里」这件事从一次性的尽调变成了持续的动作。

落地清单

• 把模型切换纳入变更管理，走申请、影响面、回退、窗口四步。
• 定三层决策规则：平台默认、部门专用、个人临时，各自说清谁批、留什么。
• 上线时就建一套二三十条的真实任务评测集，覆盖主要任务类型。
• 每次换模型前后各跑一遍评测集，结果并排看，季度复核评测集本身。
• 换模型时重做数据流向评估：留存时长、是否训练、地域、是否可隔离部署。
• 合同用「能力等级加切换规则」的写法，把等级落到评测集通过率上。
• 换之前评估下游依赖：模板输出格式、调用接口、解析规则会不会受影响。
• 给每次切换留一份记录：为什么换、换前换后评测结果、谁批的。

若您正在选型企业级 AI 办公平台，或希望把模型切换这件事从「管理员顺手改一下」变成可控的流程，欢迎 预约咨询。