换了两代模型，用户还是走了：问题可能不在模型

声明：本文讨论的是 AI 产品在持续运营阶段的工程与决策问题，不含任何产品与厂商推广，也不针对任何具体模型的优劣。文中阈值均为经验参考值，需要结合自身业务数据校准。

0 先给结论

一个很常见的场景：产品上线三个月，用量开始掉。团队复盘，第一个结论是"模型不够强"。于是换模型，第一代换完，跌势缓了两周；过一个月继续掉，再换第二代。到第三个月看数据，留存曲线和第一次换模型之前几乎没有区别。

换模型不是错，错的是把它当成第一反应。

原因是这样一件事：留存问题是一个多变量系统的输出，而换模型只移动了其中一个变量。 当其他变量不变时，改变一个变量不会改变系统输出——只会改变你对"问题已经处理过了"的感知。

更具体地说，模型换代主要改善的是能力上限，而用户流失几乎全部由结果下限决定。上限是分布的右尾，下限是分布里那几次糟糕的失败。一次模型换代能让右尾更长，但如果失败的类型没有变，左尾就还是那么长。

这篇文章给出一个可执行的判断方法：把留存失败拆成四类，只有第一类换模型有用，而且要先算清第一类占比多少，再决定换不换。

全文按四层展开：为什么换模型总是第一反应（组织诱因）→ 换模型究竟移动了哪个变量（机制）→ 四类失败与决策门槛（判断）→ 迁移工程与配置（落地）。

1 换模型为什么总是成为第一反应

这个判断在技术上不一定对，但在组织上几乎是必然的。三个原因叠加在一起。

第一，它是唯一一个"看得见、换得动、能拿结果说事"的变量。

场景选得对不对、入口放得远不远、有没有人真正负责——这些问题的验证周期都以月计，而且很难在周会上讲清楚。模型不一样：它有版本号、有榜单、有跑分、有对比报告。一周之内就能拿出一份"新模型在我们评测集上提升了 X 个点"的材料。对一个需要向上汇报的团队来说，这是最好交付的东西。

第二，它是一次采购动作，不是一次设计返工。

换模型在流程上等价于"升级一个依赖"：申请预算、做集成、测一轮、切流量。承认场景错了、入口太远、没有数据沉淀，意味着要回到需求评审、改产品结构、重新分配指标归属——是设计返工，涉及的不只是技术团队。两件事的组织成本差一个量级。

第三，它天然政治正确。

"我们在持续跟进最新技术"这句话在任何一层汇报里都站得住。而"这个场景其实一周只需要做一次，所以再怎么优化也不会有留存"——这句话需要有人承担责任。

三条合起来，形成了一个非常稳定的行为模式：用量下滑 → 复盘 → 归因到模型 → 换模型 → 短期反弹（新鲜感 + 真实提升混合）→ 再次下滑 → 再换模型。 每一轮都推进了进度，但没有一轮触及真正的原因。

一个可用的自检问题是：过去十二个月，你的产品有没有哪一次改版，是明确做给"降低失败率"的，而不是"提升最好情况下限"的？ 如果答不出来，说明资源分配已经偏了。

2 换模型移动的是哪一个变量

先建立一个最简模型，把"换模型到底改变了什么"说清楚。

用户的每一次使用，可以看成从同一个任务分布里抽一次样。产品质量不是一个数，而是一个分布：好的时候有多好，坏的时候有多坏，中间有多密。留存取决于这个分布里某个区间的表现，而不是它的均值。

换模型做的是两件事：

1. 整体平移——能力普遍变强，中位数和右尾都向右移动。
2. 形状改变——不同类型的失败率发生相对变化，有的降低，有的反而升高。

第二点常被忽略。模型换代不是同一把尺子上的刻度变化，它是行为风格的变化——指令遵循的严格程度、格式输出的倾向、拒答的边界、长上下文里的注意力分布、对边界输入的处置方式，都可能和上一代不同。这些变化落在具体产品上，表现就是有些以前常犯的错不犯了，有些以前不犯的错开始犯。

所以换模型的正收益，取决于"被修掉的那类失败"在你的失败样本里占多大比重。这就是后面要给的门槛。

还有一个更本质的问题：留存是相对于使用习惯的一个差值。

用户是否持续使用，取决于 周收益 − 切换成本 里的差值。换模型能改善的只有前项的一部分——它提升的是每次使用的最好情况，而周收益取决于重复任务的稳定成功。切换成本那一侧，换模型完全影响不到，甚至可能让它变差（行为漂移打破既有预期，见第 5 节）。

一个直接的推论：

在一个已经因为失败而流失的用户身上，模型提升带来的改善幅度，通常小于重新建立信任所需的成本。他不回来了。

这不是情绪判断，是收益结构决定的。用户流失的那一刻，他记住的是"这个东西上次把我坑了"；而这个记忆的修正需要连续多次不出错。换模型能提高不出错的概率，但不能缩短修正所需要的次数。

3 留存由尾部决定，不由均值决定

这一节是整篇论证的关键，值得单独说清楚。

假设一个功能每天被某位用户使用 5 次。一次失败会不会影响他明天是否继续用？取决于失败的性质，而不是失败率：

对第三类要特别说一下。它不产生即时的痛感，所以修复动作不会立刻发生。 而信任的破坏是累积的：用户第一次没发现，第二次开始怀疑，第三次就默认"它说的我不核实不安心"——一旦到这个状态，工具就失去了"省时间"这个核心价值，因为他必须把省下的时间再花回校验上。

这带来一个反直觉的推论：提升平均质量对留存的边际收益，通常低于降低最严重那类失败的边际收益。 把 P50 的体验从"不错"提到"很好"，用户感知有限；把"引用不存在的来源"这一类失败从 5% 降到 0.5%，用户感知很强。

而换模型对这两件事的作用是不一样的：它对"整体体验"往往有正向作用，对"特定类型的最严重失败"不一定——如果那类失败来自你的检索、你的数据、你的拼接逻辑、你的提示词，换模型不动它。

这就是"换了两次模型用户还是走了"最常见的机制：被换掉的是分布的形状参数，没被换掉的是那条造成信任崩塌的路径。

4 四类失败：只有一类换模型有用

把留存失败按归因拆成四类。这张表是全文最该被截图带走的东西。

只有 A 类是模型问题。而且即使是 A 类，也要先算占比——这就是下面这个门槛。

决策门槛（经验值，需按业务校准）

把线上失败样本抽样（建议不少于 200 条），逐条归因到上面四类，得到一个占比分布，然后：

• A 类占比 ≥ 40%：换模型是对症的，值得做，按第 9 节的迁移流程执行。
• A 类占比 20%–40%：换模型能带来可见但有限的改善，建议先做 B 类工程，再评估是否需要换。这一档最容易出现"换了有点用，但问题还在"的结果。
• A 类占比 < 20%：换模型的期望收益低于迁移成本。此时正确的动作是处理 C 类和 D 类——这两类问题不会因为任何模型变强而消失。

一个常见的误判是：把 B 类问题归到 A 类。因为方差型的表现是"它有时候答得不好"，从用户的描述听上去像是"模型不够聪明"，但真正的差异来源可能是你的 prompt 缺少输出约束，或你的检索召回不稳定。区分方法很简单：同一输入重复调用 N 次（N ≥ 10），看结果是否收敛。 如果同一输入的结果差异很大，那是方差问题，换模型通常只会换一种方式振荡。

5 换模型不是免费的：四项隐性成本

换模型的收益会被四项成本吃掉相当一部分。它们几乎从不出现在立项材料里。

成本一：提示词资产与新模型不匹配。

现有的提示词和规则集，是围绕上一代模型的行为特征写的——包括它的指令遵循习惯、它对格式描述的理解方式、它对"不要做某事"这类否定表述的反应。换模型相当于把这些适配作废，从"针对性调优"退回到"通用适配"。短期表现可能比换之前更差，这是正常的，但不了解这一点的人会误判为"新模型不行"或者"集成没做好"。

成本二：行为漂移打破既有用户预期。

老用户已经形成了对产品行为的心智模型：它大概会怎样组织答案、什么情况下会拒绝、输出多长。行为一漂，这些预期全部失效，用户需要重新学习——而重新学习本身是一种切换成本。对已经养成习惯的用户来说，"稳定但一般"的价值可能高于"更好但变了"。

成本三：评估基线失效。

你原有的评测集，是按旧模型的失败模式挑出来的——那些恰好是旧模型容易犯错的样本。新模型的失败模式不同，所以这套评测集测不出新模型的问题。换完之后评测分数很好看，线上问题却变多，机制就在这里。

正确做法是每次换代都重新做一轮失败样本采集，而不是只跑老评测集。这一条写进流程很重要（见第 9 节的评估卡）。

成本四：成本结构变化。

单价、上下文窗口、缓存机制、并发限制、长文本的计费方式，通常都会变。这意味着原有的分级路由策略、预算上限、超时阈值全部需要重新标定。如果只看"单 token 单价降了"，很容易漏掉"平均输入长度变长导致总成本上升"这种情况。

还有一项不是成本但同样重要：时间。

一次模型换代，从集成到观察稳定，通常需要 2–6 周。如果两个月换了两次，等于产品长期处于"迁移中"状态。迁移期的用户看到的是一个不断变化的产品——这对留存是负向的。

6 一个反直觉结论：频繁换代本身会降低留存

把上面的成本合起来看，会得到一个与常识相反但成立的判断：

结果的一致性，是留存的基础。而换模型是在主动破坏一致性。

用户很难说出"我要的是稳定"，但他会用行为回答。一个每次结果都差不多的工具，会被当作基础设施来用——放进日常流程、写进操作规范、介绍给同事。一个结果风格一直在变的工具，只能被当作"有时候挺好用的东西"，永远不会进入基础设施的位置。

"不是最强"和"每次都不一样"，后者有害得多。

这一点对已经有一定用户基础的产品尤其重要。新用户对行为漂移不敏感（他本来就在学习），老用户非常敏感。换模型的收益是全局的，但漂移的伤害集中在老用户身上——而老用户恰好是留存的基本盘。

所以一个实用的立场是：模型换代应该是一个有节奏的动作，不是一个随时的动作。 它需要评估、需要灰度、需要回滚预案，也需要一个"什么时候不该换"的明确判断。下一节给的就是这个判断。

7 正确的顺序：先归因，再决策

把整个决策流程固化成四步。

第一步：拉失败样本，而不是拉使用数据。

用量数据告诉你"掉了"，失败样本告诉你"为什么掉"。取最近 30 天的失败请求，加上投诉、人工介入、以及"生成了但用户没有使用"的记录（这一类最关键，用户不会投诉，只会消失）。

第二步：分类归因。

按第 4 节的四类逐条打标。这一件事必须由理解产品的人做，不能只看日志——"这个回答用户为什么没用"需要结合下游行为判断。

第三步：算 A 类占比，对照门槛。

低于 20% 就不换，先做 C 类和 D 类。这一条建议直接写进决策模板，避免每次讨论都被"新模型效果很好"的氛围带走。

第四步：如果决定换，按迁移流程走，而不是直接切。

8 什么情况下换模型是对的：六个真信号

上面讲的是"不要条件反射地换"。反过来，有六种情况换模型是正确的，甚至必须换：

1. A 类失败占比超过门槛，且失败样本明确指向能力边界。
2. 外部强制：旧模型的版本下线、涨价、限流、区域策略变化。
3. 出现架构上做不到的能力，而不是"做得更好一点"。例如上下文窗口从 8K 级别跃升到能容纳完整业务文档的量级，或者具备可稳定使用的原生工具调用——这类变化能改变产品形态，而不是只改变回答质量。
4. 单位成本下降幅度足以改变产品形态。成本不是运营变量而是设计约束：只有当单位成本跨过某个界限，之前做不起的形态才成为可能（例如从"按次调用要计费"变成"可以无限制嵌进流程"）。
5. 合规与可用性要求。所在区域内不可用、或备案信息需要更新底座模型（注意：更换底座模型属于备案信息变更事项，不可沿用原编号）。
6. 已具备能证明收益的评估体系。你有独立的、按当前失败模式构建的评测集，并且它显示换代有明确收益。

判断这六条有一个共同特征：它们都是"外部条件变化"或"有证据支撑的判断"，而不是"内部焦虑的表达"。 前者该换，后者该先做归因。

9 迁移工程：换模型必须做的六件事

如果决定换，这六件事按顺序做，不要跳步。

第一，重新采集失败样本，重建评测集。

不要只用旧评测集。用新模型跑一批真实流量（影子模式），收集它自己的失败样本，和旧模型对比失败类型的迁移，而不是只比总分。

第二，把输出从"自然语言承诺"改成"结构契约"。

这是降低行为漂移伤害最有效的一招。凡是下游要用的输出，一律走结构化格式 + 字段校验；凡是校验不过的，走重试或降级，而不是直接交给用户。这一层做厚了，模型换代对用户的影响会小一个量级。

第三，把提示词按"可迁移"与"需重调"分开。

区分哪些提示词表达的是稳定意图（长期不变的业务规则、格式要求、安全边界），哪些是针对旧模型行为的补丁（"不要说这句话""请务必分点"）。换代时前者保留，后者全部重审。

第四，灰度迁移，不要直切。

新模型先接一部分流量、或先接低风险场景，并行观察。判断标准不能只是"新模型表现更好"，还要看用户侧的失败率是否下降——前者是模型指标，后者是产品指标。

第五，钉死模型版本，准备好回滚。

不要跟着浮动别名走。生产环境必须锁定具体版本，并保留回滚到上一版本的能力与数据。"随时可以回到上一个已知稳定态"是换代这件事的心理基础，没有它，团队会在出问题时陷入被动救火。

第六，迁移窗口内冻结其他变量。

迁移期不要再叠加其他改版。否则出问题时你无法归因——到底是新模型的问题，还是那三个同时上线的功能的问题。这一点在排期上经常被忽略。

10 输出契约：让产品跨模型稳定

这是最容易落地也最被低估的一节。它的逻辑很简单：

如果产品的体验依赖于某个模型的具体行为，那这个产品就永远被模型换代绑住。

反过来，把对模型的依赖收窄到"能力"这一项上，把格式、结构、边界、兜底这些从模型手里拿回到自己的代码里，换代就从一个项目级事件变成一个配置级事件。

具体做四件事：

一是格式由代码确定，不由模型确定。 用结构化输出能力 + 本地 schema 校验。模型负责填内容，代码负责保证形状。

二是给输出加显式的长度与内容约束。 输出截断、过长、跑题这三类失败，很多来自没有任何上限约束。

三是所有拿不准的情况走同一条兜底路径。 校验不过 → 重试一次 → 仍不过则降级（返回模板化结果或转人工），而不是把不确定性直接抛给用户。降级优于拒绝，原因在留存上很直接：用户觉得"产品坏了"会离开，觉得"慢了一点"不会。

四是把置信度阈值按下游用途分档。 内部草稿、团队共享、对外交付，三档要求不同。同一套阈值用在两种用途上，必然一边太严一边太松。

顺带把版本台账也钉住。这一份台账的意义在于：当三个月后有人问"我们中间换过几次模型、每次之后失败率怎么变的"，你能直接答出来。

11 换模型决策检查表

按 P0/P1/P2 分级。P0 未完成不应启动换代。

P0（缺一项不启动）

• [ ] 已完成失败样本归因，样本量 ≥ 200 条
• [ ] A 类失败占比已量化，且 ≥ 40%（或存在第 8 节的强制触发条件）
• [ ] 预期收益已量化到"哪一类失败、降多少、影响多少用户"
• [ ] 已重建评测集（不是只跑旧评测集）
• [ ] 提示词资产已按"可迁移／需重调"分类重审
• [ ] 成本结构已重新标定（单价、平均长度、缓存、并发）
• [ ] 生产版本已锁定，回滚方案与数据就绪
• [ ] 迁移窗口内其他改版已冻结

P1（换代期间应完成）

• [ ] 影子模式或灰度对比已完成，对比口径是用户侧失败率而非模型总分
• [ ] 输出契约已上线（结构校验、长度约束、兜底路径）
• [ ] 置信度阈值已按下游用途分档
• [ ] 版本台账已记录本次换代的原因与前后失败类型迁移
• [ ] 老用户的行为预期变化已有说明或引导

P2（持续运营）

• [ ] 换代后 2 / 4 / 8 周各看一次用户侧失败率与次周留存
• [ ] 把"这次换代修掉了哪类失败"写进复盘，形成可累积的经验
• [ ] 每季度重估一次四类失败占比，防止归因漂移
• [ ] 明确"什么时候不该换"的判断也进入决策模板

12 成熟度分级

用换模型这件事本身，可以看出一个团队的工程成熟度。

有价值的判断是：从 L0 到 L3 的路径上，"换模型"这件事的频率是下降的，而每次换的必要性是上升的。 如果一个团队换代越来越频繁，通常说明它停在 L0 或 L1，而不是在变得更快。

13 八个反模式

1. 把换代当复盘结论。 复盘的第一步应该是拉失败样本，不是看新模型榜单。
2. 只看模型总分。 总分提升与你的失败类型迁移无关，你的评测集本来就偏离真实分布。
3. 浮动版本别名上生产。 换模型变成了"某天早上它自己变了"，出问题无法归因。
4. 换代和改版同期上线。 出问题时无法区分是模型还是功能导致的。
5. 靠提示词约束行为，而不写进代码。 提示词表达的是数据层约束，能被绕过，也能被新一代模型的不同理解方式改变。
6. 用满意度代替行为指标。 满意度是滞后指标；修正率、拒绝率、次周留存才是可归因的。
7. 把方差问题当能力问题。 同输入重复调用不收敛的，是约束缺失，不是模型不够强。
8. 用换代代替 owner。 没有人对三个月后负责时，一次换代只是把问题推迟了一个季度。

14 FAQ

Q1：新模型确实更强，为什么还是别急着换？

因为"更强"通常指平均值或难题通过率，而留存由失败类型分布决定。如果你的失败集中在集成型和组织型，模型再强也不改变它们。判断标准不是"新模型多强"，而是"它能修掉我那 40% 失败里的哪几类"。

Q2：小团队没有资源做失败归因怎么办？

归因不需要工具，需要一下午。抽 200 条失败记录，两个人各打一遍标签，对不齐的地方讨论——这个过程本身就会改变团队对问题的认知。工具是后续的事。

Q3：怎么判断一个失败是方差还是能力问题？

同一输入重复调用 10 次。结果收敛但都不对 → 能力问题；结果发散 → 方差问题。前者的解法是模型，后者是约束。

Q4：换代之后变差了，是不是说明不该换？

不一定，短期内表现下降是提示词资产失效的正常表现（见成本一）。判断依据是失败类型是否发生了预期的迁移，而不是当期分数。如果目标失败类型没有下降，那才是真的不该换。

Q5：什么指标最适合用来判断换代是否成功？

用户侧的失败率（含"生成了但未被使用"）与次周留存。模型总分可以作为过程指标，不能作为结论指标。

Q6：换底座模型会影响备案吗？

会。更换底座模型属于备案信息的实质性变更事项，需要更新备案信息，不可沿用原编号。这一点要在换代排期时同步到合规侧，而不是等上线后再补。

Q7：如果一个产品就是靠模型能力吃饭的呢？

那它更需要注意两件事：一是能力来自公共投入，会被更快的迭代抹平（今天最强的能力，一年后是基线）；二是要把能力转化为沉淀——用户数据、业务规则、集成深度。产品里唯一可替代的部分，不值得投入全部资源去加固。

15 结语

回到标题那个场景。换了两代模型，用户还是走了。

原因不复杂：你优化的是产品里唯一可以被替换的部分，而用户留下是因为那些不能被替换的部分。

模型会一直变强，这是确定的事。所以"换模型"永远会是那个最顺手的选择——它有版本号、有对比数据、有明确动作，看上去每一步都在推进。真正难的是另外两个问题：用户在哪一步被哪一类失败赶走的，以及这个问题归谁负责。

最后把判断收敛成一句话：

先归因，再换模型。四类失败里只有一类是模型问题，而那一类通常占不到一半。

本文为工程实践方法整理，不构成对任何具体产品或技术选型的推荐。文中阈值（40%／20%、2–6 周、10 次重复调用等）均为经验参考值，请结合自身业务数据校准。涉及备案信息变更的表述以属地监管部门口径为准。