当人工智能应用程序接口宕机时：一种现实世界的故障转移策略

两个月前，当我的用户正在与我的应用程序进行对话时，我盯着一个人工智能接口提供商返回的 503 错误。会话中断，日志中满是红色报错，我的手机因收到愤怒的用户消息而不断震动。就在那时，我吸取了一个惨痛的教训：依赖单一的人工智能接口就像在单根桩基上盖房子。

我构建人工智能驱动的功能已经有一段时间了——包括聊天机器人、摘要生成和内容创作。像我们许多人一样，我从开放人工智能公司（OpenAI）的接口开始入手。它在大多数时候都很可靠，而且质量出色。但是，当你的用户期望全天候可用时，“大多数时候”对于生产环境来说是不够的。

问题所在

我的应用程序使用 GPT-4 实时生成响应。一切运行正常，直到开放人工智能公司出现部分服务中断的那一天。请求开始超时，随后失败。我那幼稚的方法——尝试一次，然后显示错误——让用户陷入困境。我手忙脚乱地切换到另一个提供商，但我必须手动更新代码并重新部署。这花了一个小时。整整一个小时的停机时间。

我需要一个系统，能够自动处理跨多个人工智能提供商的故障，具备回退、重试机制，理想情况下还能平衡成本。我不想降低质量，但也不希望因为某个廉价模型碰巧在大多数时候有效而导致破产。

我最初的尝试

我的第一次尝试很简单：尝试提供商 A，如果失败，则尝试提供商 B。我硬编码了一个列表，并使用了一个“尝试-异常”代码块。

import openai
import anthropic

def generate_response(prompt):
    try:
        return openai.ChatCompletion.create(model="gpt-4", messages=[{"role": "user", "content": prompt}])
    except:
        try:
            return anthropic.complete(prompt=prompt, model="claude-v1")
        except:
            raise Exception("Both providers failed")

这比什么都没有要好，但它存在重大缺陷：

没有针对暂时性错误的重试机制。
卡在单一的回退顺序上——如果 A 宕机，B 承担所有负载，但如果 B 也失败了呢？
没有超时设置：响应缓慢的提供商可能会导致整个系统挂起。
缺乏对故障的洞察
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。