モデル間フォールバックとは？

なぜ任意ではないのか

単一プロバイダーのワークフローは、そのプロバイダーの可用性をそのまま受け継ぎます。特にレート制限はまれな出来事ではなく、混雑した時間帯の通常の帰結であり、フォールバックのないワークフローは単に止まります。

フォールバックは完全な失敗を劣化した応答に変えます。それが改善かどうかは、そうなったことをあなたが知らされるかどうかに完全にかかっています。

順序の選び方

直感的な順序は「次に良いモデル」ですが、それはしばしば間違いです。最初の選択がリクエストが長すぎて失敗したなら、小さいモデルも失敗します。コンテンツを理由に拒否したなら、似たモデルも同様に拒否します。

より有用な順序は何か構造的なものを変えます。同じように失敗する近縁のモデルではなく、全く別のプロバイダーや、別のルールを持つローカルモデルです。

危険な種類

静かなフォールバックとは、別のモデルで黙って応答し、何も知らせないシステムです。あなたはより悪い回答を得て、それを頭の中で選んだモデルのせいにし、そのモデルについて誤った結論を出します。

フォールバックがプライバシーの境界を越えると、誤った結論より悪くなります。ローカルモデルからクラウドプロバイダーへの切り替えは、ユーザーが特に避けようとしていた場所にデータを送ります。ローカル実行を離れうるチェーンは、ユーザーが明示的に同意したチェーンであるべきです。

ClawAIでの実装

ルーティングモードは独自のチェーンを定義し、ローカルのみモードはローカルが混雑しているときにクラウドモデルを求めるのではなく、そのチェーンをローカルプロバイダーに保ちます。各メッセージは実際に応答したモデルを記録するので、フォールバックは口調の変化から推測するのではなく、後から目に見えます。

よくある質問

フォールバックは再試行と同じですか？

再試行は同じリクエストを同じモデルに送り、一時的なエラーに役立ちます。フォールバックはモデルを変え、最初のモデルがリクエストを全く処理できないときに役立ちます。堅牢なシステムはこの順序で両方を行います。

フォールバックはローカルからクラウドへ移るべきですか？

ユーザーがそれを求めた場合に限ります。ローカル実行はフォールバックが尊重できない理由で選ばれることが多く、安全な選択は他所で成功することではなく、失敗してそう伝えることです。

チェーンにはいくつのモデルがあるべきですか？

通常は二つか三つで十分です。長いチェーンは主にレイテンシを加えます。失敗した試みはすべて次が始まる前に時間として支払われるからです。