模型交付稳定性与灵活性的冲突

背景

在某交付项目中，采用 workflow + agent 的方式，实现了电商 AI 客服的售前售后流程覆盖，在项目约束范围内，完成了交付目标。
但是，在交付实际上线后，我们发现了新的问题：经过严格、高质量微调的模型几乎完全丧失了泛化能力，可满足项目目标，却无法适应实际应用时可能发生的业务侧变化。
以这个问题为始，在本文档中讨论，使用模型交付时，稳定性与灵活性的冲突。

客户遇到了什么问题？

话术的要求会变，比如回复风格、需要回复的关键内容、要注意/避免的关键事项；
业务的逻辑会变，比如在售后时对事项的判定、对事项的处理逻辑。
与此同时，同一集团内，不同品牌的变化频率、变化逻辑、变化内容都各不相同。

客户实际收获了什么？

在项目约束范围内，极高的准确率和稳定性——全场景 90～95% 准确率
几乎为 0 的可持续性——每次业务侧变化都意味着新的微调成本投入

在这个前提下，我们给到客户的交付物（方案、指令、模型），可想而知会有两种可能的结局：

在业务侧发生变动后，客户自行投入成本对模型进行微调升级
在业务侧发生变动后，客户不愿承担后续持续投入的变更成本，放弃方案，转向其他解决方式

类似问题会在哪些场景出现？

这个客户所面对的问题，并不是个例，宏观来看，在做项目交付时，什么样的场景是需要持续迭代、对灵活性有高要求的？

高时效性的场景：场景的“正确答案”会随着时间的推进发生变化，甚至变成完全错误的答案
多方消费的场景：虽然是同一个场景应用，却被多个不同业务方消费，各方立场和目标的变化会导致场景需求分化甚至对立
难以预定义的场景：即使是业务方本身也无法准确给出非黑即白的标准，需要根据经验和累积反馈来逐步调整
将这些场景特征进一步抽象的话，本质上可用一句话概括：
正确答案会随时间推进产生漂移、分化甚至变得完全错误，同时这种漂移会按季度、月度甚至更高频率发生。

如何看待稳定性与灵活性的冲突？

这种冲突的核心原因是对模型“能力”和“知识”的耦合，理想的模型应用实施准则应当是：

会随时间高频漂移的“知识”通过上下文管理（例如退货的流程逻辑）
相对稳定不变的“能力”通过微调内化（例如固定用于工程捕获的输出格式）。
但一旦“知识”成为了微调参数的一部分，这种冲突就会发生。

那么看起来我们未来只要遵循这个原则进行实施，严格通过上下文管理高频变化的内容、不微调，这个问题就可以迎刃而解？不一定。
受限于模型能力、场景复杂度等因素，实际交付实施时，模型基线效果有可能无法在这套准则框架下满足业务需求（例如 95% 准确率，首响 P90＜2S），导致必须打破这套规则，将“知识”训练为能力。
但前提必须是：微调周期＜答案变动周期，且，微调成本 × 单位时间内迭代次数＜单位时间内微调业务收益
同时，业务方本身，或者在交付侧帮助指导下，必须拥有持续的数据治理能力、成熟的微调能力、稳定的 ops 能力，才有可能让上述前提成立。
这种实施方式，最关键的是交付与客户双方，基于实际项目约束条件，都对此种手段潜在的效果、风险与投入有清晰且一致的认知，否则交付将变成一锤子买卖，无法持续在生产中创造真实价值。

延伸思考

准确率有多重要，性能又有多重要？当我们只关注单一指标时，其实这两者可以互相造血，用时间换准确（复杂逻辑处理、多次校验、交叉验证），或用模糊换速度。
但是当两者需要同时满足时，实施就会变得十分棘手，极易被动进入稳定性与灵活性的冲突漩涡，在选择落地垂域和场景时，要尽可能避免。
两者二选一时，高准确、低时效性能的场景，有更大的方案设计空间和消耗潜力，优先级应当更高。

随着模型能力的跃进，我们该如何看待微调？此时此刻的微调是否会被半年后的基模更新超越？在做项目交付和方案设计时，如何考虑未来的可维护性/扩展性/升级能力？
放下对传统软件工程时代“用正确的代码一次性解决问题”的执念，拥抱大模型的“高柔性”，可能是我们和客户都需要扭转的观念。