あなたのAIプロバイダーは単一障害点である
先週の金曜日、米国商務省がAnthropicに書簡を送った。その日の夕方までに、Fable 5とMythos 5が消えた。
それらは非推奨になったわけでも、制限（スロットリング）されたわけでもない。ただ、単純に消え去ったのだ。
APIコールは404エラーを返し、ライブセッションは会話の途中で失敗した。それらのモデルに依存していたアプリケーションは動作を停止した。これはリリースからわずか3日後の出来事だった。警告も、移行期間も一切なかった。
私たちは運が良かった。それらのモデルは新しかったからだ。まだ誰もそれらに深い依存関係を構築していなかった。もし、6ヶ月間毎日使っているモデルにこれが起きたらと想像してみてほしい。
もし政府からの書簡一つでプライマリデータベースが停止するとしたら、フェイルオーバーなしで運用しますか？しないはずだ。しかし、ほとんどのチームがAIに対してこれを行っている。
多くのチームはAIを電気のように扱っている。スイッチを入れれば明かりが灯ると期待する。供給源のことや、停電したときに何が起きるかについては考えない。モデルを選び、エンドポイントをハードコードして、リリースする。
これはエンジニアリングではない。「希望に基づいたアーキテクチャ」だ。
モデルは以下の理由で消失する可能性がある：
- 規制上の理由
- ポリシーの変更
- 地政学的な問題
Anthropicの状況は、バグやインフラの障害ではなかった。それは「規制によるキルスイッチ」だった。
モデルレイヤーにレジリエンス（回復力）を組み込まなければならない。以下のパターンを活用せよ：
- モデルコールを抽象化する。 インターフェースを使用し、アプリがどのプロバイダーからレスポンスを受け取るかを気にしないようにする。
- 複数のプロバイダーを使用する。 プロバイダーの切り替えは、全面的な書き直しではなく、設定変更だけで済むべきだ。
- オープンウェイトモデルを使用する。 モデルを自前で動かしていれば、誰にもリモートで停止されることはない。これらのモデルは、グリッド（送電網）が停止したときの発電機のような役割を果たす。
- グレイスフル・デグラデーション（段階的な機能縮小）を実装する。 アプリケーションが完全に壊れてしまうよりは、より小型または旧式のモデルが動作している方がマシだ。
エラー率を監視せよ。スパイクが発生したら、ブレーカーを落としてトラフィックをフォールバック先にルーティングする。
AIを他の重要な本番環境の依存関係と同様に扱うこと。障害を前提に設計せよ。
あなたのアーキテクチャは、プロバイダーが失敗することを想定していますか？もしそうでないなら、あなたはリスクにさらされています。
スタックにマルチプロバイダーのフォールバックを組み込んでいますか？コメントで教えてください。
Source: https://dev.to/aws/your-ai-provider-is-a-single-point-of-failure-26i2
Optional learning community: https://t.me/GyaanSetuAi