回落触发时怎么记：建一份回落事件日志，搞清到底是哪个模型答的

为什么回落日志值得单独建

在多模型聚合的调用链里，主模型超时、限流或返回错误时，请求可能被静默转发到备用模型。对调用方来说，HTTP 200 和一段正常的文本返回，看起来和主模型回答没有区别——除非你主动记录。

没有回落日志，你会遇到几类难以定位的问题：

• 输出风格或能力突然变化，但排查时找不到对应变更；
• 成本核算对不上，因为不同模型的计费基准不同；
• 无法回答'这个模型这周到底稳不稳'，只能靠体感。

回落本身不是故障，它是可用性设计的一部分。问题在于它必须是可观测的。

回落事件应该记哪些字段

一份够用的回落日志，核心是回答三个问题：谁被请求了、谁实际回答了、为什么切换。建议至少包含：

• 请求标识：请求 ID、时间戳（含时区）、调用方标识（如 API key 别名或项目名）。
• 预期模型：客户端原本指定的模型名与厂商。
• 实际模型：最终生成该响应的模型名与厂商。
• 触发原因：超时、限流、连接错误、上游 5xx、内容策略拒绝等，尽量用枚举值而非自由文本。
• 回落层级：这是第几次尝试（主模型 → 备用 1 → 备用 2），以及是否最终失败。
• 耗时拆解：首次尝试耗时、回落尝试耗时、总耗时。
• 用量：本次实际消耗的 token 数或计费单位，用于成本归因。
• 结果状态：成功、部分成功、彻底失败。

字段不必一次到位，但请求标识、预期模型、实际模型、触发原因这四项是最小集。缺了它们，日志就只能看趋势，无法做归因。

怎么给响应打上'实际服务厂商'标记

日志是服务端的事，但调用方也需要知道'这次是谁答的'。有几种常见做法，可以按你的架构组合使用：

• 响应头：在返回中附加自定义头部，例如标明实际模型与实际厂商。这是对现有客户端侵入最小的方式。
• 响应体元数据：在返回的 JSON 里增加一个非内容字段，存放模型、厂商、是否回落。注意保持与既有字段的兼容。
• 独立的观测通道：把回落事件写入日志或指标系统，客户端通过请求 ID 去查询。适合不希望改动响应结构、但已有可观测体系的团队。

无论用哪种方式，关键约定是：'实际模型'字段永远反映真实生成方，而不是客户端请求的那个名字。这是后续所有成本和效果分析的前提。

如果你在客户端做了模型别名映射（比如用'默认模型'指向某个具体模型），记得把别名解析后的真实模型也一并记录，否则别名一改，历史数据就没法对比。

每周复盘回落率，而不是靠猜

有了日志，下一步是把它变成周期性的判断依据。建议按周做一次轻量复盘，流程可以固定下来：

1. 算总体回落率：回落请求数 / 总请求数，按模型和厂商分组。
2. 看触发原因分布：是集中在超时，还是限流，还是上游错误。原因分布决定了该找谁解决。
3. 看时间分布：回落是否集中在某些时段，可能和上游负载高峰或你的调用峰值有关。
4. 看成本影响：回落目标的计费基准与主模型不同，统计因回落产生的额外成本。
5. 看尾部影响：回落是否集中在少数调用方或少数接口，避免被平均值掩盖。
6. 形成一条行动项：例如调整超时阈值、调整回落顺序、或与上游沟通。没有行动项的复盘容易流于形式。

复盘的目的不是把回落率压到零——那既不现实也不经济。目的是知道当前的回落是否在预期范围内，以及每次回落是否合理。

记录时的几个注意事项

• 不要把回落当成静默的兜底。即使对调用方透明，服务端也必须有记录。
• 区分'回落成功'和'回落也失败'。后者才是真正影响可用性的事件，应该单独告警。
• 采样与全量要分清。高流量下可以对日志采样，但回落事件本身建议全量保留，因为它数量相对少、价值高。
• 字段用枚举，不用自然语言。'上游超时'和'连接超时'如果混写，后面就没法聚合。
• 注意隐私与合规：日志里避免记录完整的用户输入内容，只保留标识和元数据。

回落机制的价值在于提升可用性，但它的可管理性取决于你是否真的知道每次回落发生了什么。先把字段定下来，再谈优化，顺序不要反。