北京
分享至
有人分享过一个真实的重试事故：一个智能体把同一个格式错误的请求重试了11次，每次重试都把整段对话重新回放一遍，直到有人发现为止。这个请求从一开始就不可能成功——400错误不会自愈——但重试策略并不关心这一点，因为它只看一件事：这次调用有没有抛错。
问题就出在这个判断标准上。只要"抛了"，就重试；至于抛出来的是不是可修复的错误，策略并不区分。于是本该立刻失败的请求，被反复送出去，白白消耗时间和预算。
现在他们采用的几条工作规则：
- 重试超时、4295xx，配合退避与抖动，并且服务端返回的Retry-After优先于自己的重试节奏。
- 400/401/403一律不重试。快速失败，把错误暴露出来，去修请求本身。
- 用重试预算而不是重试次数：重试只能占用任务总预算的一部分，超出后任务就如实失败。
- 如果调用在流式输出中途断掉，干净地重新开始这条消息，绝不在半截答案后面继续追加。
还有一处没有定论：高峰期遇到服务商的529或过载错误时，是原地重试，还是立刻切换到另一个模型、并接受质量上的变化？
这套规则的分界线其实很清楚——错误分两类，一类等一等可能就好了，一类等多久都不会好。重试策略要做的，是先分清手里这个错误属于哪一类。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
