LLMゲートウェイの振り分け、障害時の切り替え、情報の取り扱い

メッセージの形式、ストリーミング、ツール、構造化した出力、エラー処理を一覧にします。同じAPIで呼び出せても、事業者やモデルの動作は同じとは限りません。固有の違いを把握し、変更後に業務の試験を行います。変更のしやすさは、モデル名だけでなく、指示、ツール、検索、運用手順にも依存します。

業務やテナントごとに、利用できるモデルとリージョンを決めます。品質、応答、費用で比較する場合も、分類や抽出だから最も安いモデルでよいとは限りません。実際の入力で検証します。分類器が一項目を見落としたために、制限した情報が未承認の事業者に送られないようにします。

再試行の回数、待機時間、許可する代替先を決めます。利用制限、途中までの応答、事業者のエラー、容量不足を試します。切り替えによって回答品質と情報の取り扱いが変わる場合があるため、事前に検証します。許可した送信先が使えない場合は、定めたエラー処理にします。すでに実行された可能性がある操作には、二重実行を防ぐ制御が必要です。

利用量、エラー、所要時間は、すべての入力を保存しなくても把握できる場合があります。本文を記録する必要性、閲覧者、保存期間、削除を決めます。ゲートウェイとログの運用者も、情報の流れの確認に含めます。モデルを自社運用していても、ゲートウェイや監視サービスが別の場所に入力を送る場合があります。

稼働状況、設定の変更、認証情報、利用枠、ゲートウェイ自体の費用を監視します。必要な検査を迂回できないかも試します。共通の内容検査と、アプリケーションごとの閲覧・実行権限の境界を明記します。共通化は保守に役立ちますが、費用の削減や個別の権限制御を自動的に保証するものではありません。

連携の作業は減らせますが、指示、ツール、出力形式、業務の品質は再試験が必要です。

対象データと業務に対して承認された代替先だけを利用します。許可した経路がない場合は、定めたエラー処理にします。