本番環境のベストプラクティス

連携機能が実際のトラフィックを処理する前に、正しく整えておくべきこと。

信頼性

• 適切なコードの場合に再試行する。 429, 500, 502, 503, 529 指数バックオフとジッターを使用します。無条件に再試行してはいけません： 400, 401, 402 または 403.
• タイムアウトを設定する。 長い生成処理に数分かかるのは正常な場合もありますが、ハングしたソケットにワーカーまで巻き込まれるべきではありません。非ストリーミング呼び出しでは、120秒が妥当な上限です。
• 同時実行数を制限する すべてを一斉に実行して拒否されたリクエストを再試行するのではなく、セマフォを使用します。
• フォールバック用のモデルを用意する。 プライマリモデルが過負荷の場合は、エラーを返すよりも小さなモデルに切り替える方がよいでしょう。

費用

• 設定する項目： max_tokens をすべての呼び出しで設定します。これは目安ではなく、支出の上限です。
• タスクに応じて振り分ける — 参照： コスト管理.
• 有効にする プロンプトキャッシュ で、安定したプレフィックスを確認してください。
• 記録する： usage をリクエストごとにタスクのラベルとともに記録し、後から支出の帰属先を特定できるようにします。

セキュリティ

• キーは環境変数またはシークレットマネージャーに保存し、リポジトリやクライアント側のバンドルには決して含めないでください。
• サービスごとにキーを分け、必要なキーだけを失効できるようにします。
• 信頼できないユーザー入力と指示を文字列連結してプロンプトを作成してはいけません。ユーザーの内容は次の形式のメッセージに格納します： user メッセージに格納し、指示は次に格納します： system.
• モデルの出力は信頼できないものとして扱います。次の操作を行ってはいけません： eval また、生成されたSQLを、書き込み権限を持つロールで実行してはいけません。

可観測性

• モデル、レイテンシー、 usage, stop_reason および独自のタスク種別を、すべての呼び出しで記録します。
• 次の割合に対してアラートを設定します： stop_reason: max_tokens その割合の上昇は、回答が途中で切れていることを示します。
• 合計だけでなく、タスク種別ごとのコストを追跡します。合計値だけでは、どのワークロードで悪化したかが分かりません。