重要ポイント
- Context windows combine prompt and completion, so long histories drain limits faster than expected.
- ストリーミングでは、JSON の破損やトークンの消失を防ぐために、SSE イベントの処理を慎重に行う必要があります。
- JSON mode demands strict schema adherence; malformed responses cause silent parsing failures.
- プリペイドの暗号通貨課金ではエラーは無料ですが、予期せぬ事態を避けるためにトークンカウントは正確に行う必要があります。
APIキーが拒否される理由
APIキーは、クライアントが不正なヘッダーを送信した場合や、リクエストボディの制限を超えた場合に拒否されます。サーバーは、ロジックを処理する前に認証ヘッダーを検証します。ヘッダーが欠落している場合、または余分な空白が含まれている場合、リクエストは直ちに失敗します。
もう一つの一般的な原因は、8 MB のボディサイズ制限を超えるペイロードを送信することです。多くのメッセージを含む大きなコンテキストウィンドウはこの閾値を簡単に超える可能性があります。送信前にメッセージ配列の長さとトークン数を確認してください。
- Authorization ヘッダーに 'Bearer' プレフィックスを正しく使用していることを確認してください。
- Verify the request body size stays under 8 MB.
- APIキーが有効で、期限が切れていないことを確認してください。
コンテキストウィンドウの制限について理解する
コンテキストウィンドウには、入力プロンプトと生成された補完の両方が含まれます。当社のAPIは100,000トークンのウィンドウをサポートしていますが、両方の側を考慮する必要があります。コンテキストとして80,000トークンを送信する場合、応答に残っているのは20,000トークンだけです。
指定しない場合、ほとんどのモデルは小さな出力制限にデフォルト設定されます。max_tokens を指定しない場合、これは予期せぬ長い回答の切り捨てを引き起こす可能性があります。max_tokens を制限したい場合にのみ、希望する長さに設定してください。制限はプロンプトだけでなく、リクエスト全体に適用されることを覚えておいてください。
ストリーミングの中断を正しく処理する
Server-Sent Events (SSE) を介したストリーミングには、堅牢なエラー処理が必要です。接続が切れると、最終トークンまたは使用量メタデータを失う可能性があります。常に受信チャンクをバッファリングし、クライアント側で完全なレスポンスを再構築してください。
トークン使用量は通常、ストリームの最後のチャンクで送信されます。接続を早期に閉じると、正確なトークン数が取得できない可能性があります。これはプリペイド課金システムの課金精度に影響します。一時的なネットワーク障害に対応するため、指数バックオフ付きのリトライメカニズムを実装してください。
SSE パースを自動で処理する専用ストリーミングクライアントを使用してください。これにより、パースエラーのリスクを軽減し、すべてのデータを確実に取得できます。
JSONモードの解析エラー
response_format: {"type": "json_object"}を使用する場合、モデルは有効なJSONを返す必要があります。これに違反すると、アプリケーションで解析エラーが発生します。プロンプトで、モデルがJSONのみを出力するように明示的に指示してください。
モデルはJSONの周りにマークダウンのコードブロックを含めることがあり、厳格なパーサーが壊れることがあります。解析する前にラッパーを削除してください。また、データを使用する前にクライアント側でJSON構造を検証してください。
スキーマ検証ライブラリを使用して、早期にエラーを検出してください。これにより、モデルが予期しないキーやタイプを返した場合のクラッシュを防ぐことができます。
トークンカウントと請求の予期せぬ出来事
前払い課金は実際のトークン使用量に対してのみ課金されます。エラーや拒否は無料であり、これはサブスクリプションモデルに対して大きな利点です。ただし、コンテキスト全体を考慮しない場合、トークンカウントは複雑になる可能性があります。
会話履歴の各メッセージは、入力トークンの制限にカウントされます。長い会話は、予想以上にプリペイドクレジットを消費します。セッションの途中でクレジットが枯渇しないよう、定期的に使用状況を確認してください。
残高が少なくなったことを通知するアラートを設定してください。これにより、リクエストが失敗する前にチャージを行うことができます。クレジットは期限が切れないため、都合の良い時にチャージしてください。
NSFWプロンプトでのソフトリフューサルを回避する
ソフトリフザルは、モデルがhesitateしたり、直接的な応答の代わりに部分的な回答を提供する場合に発生します。これは、論争的な話題や成人向けトピックでよく見られます。無検閲モデルであっても、特定のトリガーがhesitationを引き起こすことがあります。
temperature パラメータを調整してランダム性を低減します。温度を低くすると、モデルの決定論的な挙動が強まり、曖昧な表現を避けるようになります。また、プロンプトを明確かつ直接的にしてください。モデルを混乱させる可能性のある曖昧な表現を避けてください。
頻繁にソフトリフューザルが発生する場合は、プロンプトを少し書き換えてみてください。言葉のわずかな変更で、躊躇を回避し、直接的な回答を得られることがあります。
レートリミットの急増とバックオフ戦略
APIは1分あたり300リクエスト、キーあたり8つの同時リクエストを許可します。トラフィックの急増により、これらの制限にすぐに到達する可能性があります。レート制限エラーを適切に処理するために、指数バックオフを実装してください。
429ステータスコードを受信した場合は、再試行する前に待ちましょう。短い遅延から始め、再試行ごとに遅延時間を増やしてください。これにより、ピーク時にサーバーが過負荷になるのを防ぎます。
リクエストレートを確認し、それに応じて同時実行数を調整してください。多くのリクエストを同時に送信する場合は、時間をかけて分散することを検討してください。これにより、制限に達することなく安定したスループットが確保されます。
Function callingペイロード構造
Function calling には特定のペイロード構造が必要です。tools パラメータで関数を定義し、tool_choice を指定してください。モデルは、それが適切な応答であると判断した場合、関数呼び出しを返します。
関数定義が正確かつ完全であることを確認してください。パラメータの欠落や型の誤りは、モデルが無効な呼び出しを生成する原因となります。実行する前に、常に関数呼び出しの引数を検証してください。
tool_choiceパラメータを使用して、モデルが関数を呼び出すタイミングを制御します。関数呼び出しを強制するか、モデルに判断を任せるか、関数呼び出しを完全に無効にすることができます。これにより、モデルの動作を細かく制御できます。
400と500エラーのデバッグ
400エラーは、無効なJSONやパラメータの不足など、クライアント側の問題を示します。500エラーは、内部エラーやタイムアウトなど、サーバー側の問題を示唆します。これらを区別することで、デバッグがより迅速に行えます。
400エラーの場合、レスポンスに含まれるエラーメッセージを確認してください。通常、これが問題の原因を直接示しています。500エラーの場合、少し待ってからリクエストを再試行してください。エラーが継続する場合は、リクエストIDを添えてサポートに連絡してください。
各エラーについてリクエストとレスポンスの詳細を両方ともログに記録します。これにより、パターンや繰り返し発生する問題を特定するのに役立ちます。ログサービスを使用して、時間経過に伴うエラーを追跡し、API統合を改善しましょう。
