なぜ私は単一のAIプロバイダーに依存するのをやめたのか
コミュニティフォーラム向けにリアルタイムチャットボットを構築しました。一つのAPIを使えば十分だと思っていましたが、それは間違いでした。
3週間後、ピーク時に5xxエラーが発生しました。チャットボットが停止し、ユーザーは不満を募らせました。本番環境のアプリでは、一つのプロバイダーを信頼しきれないことに気づいたのです。
GPT-4を使用していました。うまく動いていましたが、ある時突然ダメになりました。レート制限、タイムアウト、そして完全なサービス停止に直面しました。上位ティアの料金を支払うことは、問題そのものではなく、症状を抑えているだけに感じられました。
他のプロバイダーも試しましたが、それぞれフォーマットや認証方法が異なっていました。コードはswitch-case文の塊になり、ひどい状態になりました。私には以下の機能を持つシステムが必要でした：
- プロバイダー間の差異を隠蔽する。
- 失敗時にバックアップのプロバイダーに切り替える。
- レスポンスをキャッシュする。
- ベンダーロックインを避ける。
サードパーティのライブラリは複雑すぎて壊れやすいため、避けました。代わりに、シンプルなルーターを構築しました。
まず、すべてのプロバイダーに対して共通のインターフェースを定義しました。各プロバイダーは generate メソッドとヘルスチェックを実装します。
次に、ルータークラスを構築しました。これは特定の順序でプロバイダーを試行します。指数バックオフ（exponential backoff）とシンプルなキャッシュを使用します。最初のプロバイダーが失敗した場合、システムは待機してから次のプロバイダーを試します。
このシステムのおかげで、3度の障害時に週末を無駄にせずに済みました。主要なプロバイダーがダウンしても、アプリを稼働させ続けることができます。
これを構築する場合は、以下の点に注意してください：
- 本番環境では、ローカルの辞書型ではなくRedisを使用してキャッシュする。
- ヘルスチェックは成功を保証しない。チェックを通過しても、実際の要求が失敗することがある。
- レート制限を適切に処理するために、
Retry-Afterヘッダーを解析する。 - コストを追跡するために、トークン使用量のロギングを追加する。
- 高いパフォーマンスを得るために
asyncioを使用する。
プロジェクトが小さい場合は、オーバーエンジニアリングを避けてください。ストリーミングが必要な場合、このパターンはレイテンシを増加させます。規模に合わせて適切なツールを選んでください。
あなたはプロバイダーの信頼性をどのように管理していますか？一つのプロバイダーに絞りますか、それともフォールバック層を構築しますか？
Optional learning community: https://t.me/GyaanSetuAi