7 月是模型发布的密集期GPT-5.67 月 10 日、Gemini 3.6 Flash7 月 21 日、Claude Opus 57 月 24 日先后上线。每次新模型潮做企业客服系统的团队都会收到同一个需求「能不能把新模型接进来听说效果好很多。」能接。但「换模型」在客服场景里是收益最被高估、风险最被低估的动作。这篇从工程视角把账算清楚新模型能改善什么、改善不了什么、接入前要过哪张清单。一、新模型能改善的和不能改善的能改善多轮对话的连贯性、小语种质量、长上下文的稳定性、复杂意图的理解。这些是模型能力的直接函数底座升级确实有肉眼可见的提升——尤其小语种客服场景新一代模型的提升普遍明显。不能改善幻觉的存在性。更强的模型编造事实的概率更低但编起来更流畅、更自信、更难被人工复核发现。客服场景的核心风险始终是同一个模型的错误输出直达客户——这个风险结构不随模型版本变化。2024 年加拿大航空的判例聊天机器人误承诺折扣、法院判公司照赔就是标尺那套机器人用的是哪一代技术并不重要判决落在「公司对其自动化系统的对外陈述负责」上这一点换成今天的旗舰模型也一样。结论先行模型升级值得做但它替代不了架构层的防线。防线在流程里。图知识检索与模型解耦低置信度有降级路径高风险动作卡在应用层。二、接入前的架构清单1. 检索增强RAG层与模型解耦了吗知识库检索、召回、重排的管线应当独立于模型供应商。答案生成必须约束在检索结果的依据范围内——换模型换的是「生成器」不该动「事实源」。检索命中率低于阈值时的行为转人工/澄清追问由管线控制不交给模型自由发挥。2. 有没有回答的置信度阈值与降级路径这里的「置信度」需要先定口径检索得分、模型自评、还是独立的校准分类器——logprob 不等于语义置信度口径不明的阈值没有意义。新模型上线初期阈值应当收紧低置信度回答进入「AI 起草、人工确认后发送」模式观察一到两周再逐步放开。直接全量切换等于拿真实客户做回归测试。3. 高风险动作的审批闸在应用层吗退款、赔付、改价、账户操作类意图无论模型多确信一律路由到人工审批。这道闸必须实现在应用层的意图路由里而不是写在 system prompt 里——提示词约束的是概率不是权限。4. 学习与知识更新有没有人工评审环节从对话中沉淀新知识FAQ 补充、话术优化的管线新条目先进评审队列不自动生效并且保留版本与回滚能力。模型越强自动沉淀的「看起来很对」的知识越多评审环节反而越重要——错误知识入库是比单次答错更持久的污染。5. 换模型的回归测试集准备好了吗用真实历史会话构建测试集覆盖高频问题、边界问题、多语言样本、历史翻车案例新旧模型跑同一测试集对比正确率、幻觉率、转人工触发率、平均响应长度。没有测试集的模型切换效果全靠感觉——「感觉更聪明了」不是可上线的验收标准。6. 成本模型重算了吗新模型的定价、上下文长度、缓存策略都可能变化。客服场景的调用量大、单轮价值低token 单价的小幅变化在月账单上会被放大。按你的真实会话量与平均轮次重算再决定全量切换还是分层路由简单问题走轻量模型、复杂问题走旗舰。图影子模式对比低风险流量灰度保留一键回退。三、一个务实的接入节奏第一周影子模式——新模型并行运行但不面客输出与现有模型对比。第二周低风险流量灰度如物流查询类意图人工抽检。第三、四周逐步放量同步观察幻觉率与转人工率。全程保留一键回退到旧模型的能力。我们自己的系统云答 YundaDesk出海全渠道 AI 客服就是按上面第 1、3、4 条的结构做的所以换底座对我们是常规操作。利益相关说明完毕这张清单本身与任何特定产品无关自建客服系统的团队同样适用。这张清单本身与任何特定产品无关自建客服系统的团队同样适用。模型会一直变强也会一直发布。追着每个新模型跑算不上工程能力把系统做成「换什么模型都不慌」的结构才算。模型发布日期来自公开报道判例为公开司法事件。YundaDesk云答智能客服: https://yundadesk.com