多模型降级不能只替换模型名
备用模型可能在延迟、上下文、工具调用、结构化输出和成本上与主模型不同,照搬原工作流容易造成二次失败。文章主张按任务所需能力定义降级策略,并同步缩减产品功能。
完整中文译文
大多数多模型 fallback 逻辑看起来都是这样的:
if (primaryRouteFailed) {
return callModel(fallbackModel);
}
这总比直接返回错误要好。
但它并不是一套完整的可靠性策略。
fallback model 可能在延迟、上下文限制、工具调用行为、结构化输出可靠性、语言质量、安全行为或成本方面存在差异。
因此,当路由发生变化时,产品也可能需要随之调整。
Model fallback 往往也是产品 fallback
假设有一个客服助手,通常会:
- 检索内部文档
- 调用 primary model
- 返回带引用来源的回答
- 建议后续操作
- 在需要时创建支持工单
如果主要路由出现异常,fallback model 或许仍然能够回答一些简单问题。
但它能否可靠地:
- 使用相同的工具?
- 遵循相同的 JSON schema?
- 处理同样大小的上下文?
- 提供同等质量的引用?
- 在相同的截止时间内完成响应?
如果答案是否定的,那么把完全相同的工作流交给 fallback,可能只会引发第二次失败。
路由已经变了。
产品也应该随之调整。
定义能力,而不只是模型名称
一套实用的 fallback 策略,应该先明确工作流需要哪些能力。
例如:
const workflowRequirements = {
needsStructuredOutput: true,
needsToolCalling: true,
needsCitations: true,
maxLatencyMs: 5000,
languages: ["en", "zh"],
};
然后定义每条获准使用的路由能够安全提供哪些能力:
const routes = {
primary: {
structuredOutput: true,
toolCalling: true,
citations: true,
maxLatencyMs: 5000,
},
fallback: {
structuredOutput: true,
toolCalling: false,
citations: true,
maxLatencyMs: 3500,
},
};
fallback 不只是一个备用模型名称。
它代表的是另一套能力配置。
有意识地降级
当主要路由失败时,应用应该决定保留什么、移除什么。
对于面向客户的工作流,降级版本可以:
- 保留文档检索
- 返回更简短的回答
- 保留引用来源
- 禁用非必要的工具调用
- 移除后续自动化操作
- 当某项操作需要人工审核时,清楚地说明这一点
对于后台工作流,则可以:
- 将任务加入队列,稍后处理
- 使用成本更低或速度更慢的路由
- 要求更严格的验证
- 避免自动写入
- 记录 fallback 决策,供后续分析
目标不是让用户察觉不到 fallback。
目标是让体验依然有用且安全。
并非所有工作流都应该降级
有些工作流应该直接停止,而不是简化执行。
例如:
- 账单变更
- 账户权限更新
- 影响重大的业务决策
- 代码执行
- 向客户系统写入数据的操作
- 必须严格符合特定 schema 的输出
不完整或未经验证的结果,可能比明确失败更加糟糕。
因此,每个工作流都需要为以下三种状态制定策略:
- 完整模式:使用首选路由和完整功能集。
- 降级模式:使用经过批准的精简功能集。
- 安全失败模式:保留请求、说明限制,并避免执行不安全的操作。
Fallback 需要独立的可观测性
使用 fallback 时,记录的内容不能只有模型名称。
还应记录:
- 工作流
- 主要路由失败的原因
- 选中的 fallback
- 被禁用的功能
- 延迟
- 输出验证结果
- 成本
- 用户侧结果
- 任务之后是否需要人工审核
否则,团队可能会因为请求成功返回,就误以为 fallback 运行良好。
与此同时,用户得到的结果可能更慢、更不完整,也更不可靠。
必须考虑故障时间预算
fallback 同样需要执行时间。
如果主要路由在反复重试中耗尽了全部截止时间,fallback 实际上就没有成功的机会。
一个可行的执行顺序是:
- 尝试主要路由。
- 只有在明确属于瞬时故障时才重试。
- 当 circuit breaker 打开时,停止调用该路由。
- 根据剩余能力和时间预算选择合适的 fallback。
- 必要时削减产品功能。
- 记录执行结果。
fallback 应该成为工作流设计的一部分,而不是错误处理程序的最后一行代码。
最后的思考
多模型 AI 并不意味着每个模型都是彼此的复制品。
如需采取进一步措施,可以考虑屏蔽此人和/或举报滥用行为。