1
リクエストの仕様を確認する
選択したモデル固有の手順を開きます。入力をどこに配置するか、どのフィールドが必須か、どのような出力が想定されるかを確認します。同じくBasetenで動作するというだけで、別のモデルのペイロードをコピーしないでください。通信方式が同じでも、モデルの入力が同じとは限りません。後から変更を追跡しやすいよう、テストしたモデルとペイロードをローカルに簡単に記録しておきます。
推論チュートリアル
開発者向けbaseten推論の使い方ガイド
baseten推論の使い方を学ぶなら、まずアクセスできるモデルと小さなテスト入力を1つ用意しましょう。このガイドでは、特定のモデルの入力形式を前提とせずに、準備からレスポンスの確認までの流れを説明します。
番号付きの手順
推論を大きなアプリケーションに組み込む前に、1つのモデルと代表的な入力を1つ使って、次の手順を進めてください。
-
1
モデルを選ぶ
呼び出すモデルを決め、現在の入力と出力に関する説明を確認します。テキストモデル、画像モデル、埋め込みモデルでは、必要なリクエストフィールドが異なる場合があります。
-
2
小さなテストを実行する
そのモデルに示されているアクセス方法を使い、必要最小限の有効なペイロードを指定します。認証情報はソースファイルやブラウザーから参照できるコードに含めないでください。
-
3
結果を確認する
リクエストが成功したか確認し、特定のレスポンス形式を前提とするコードを書く前に、返されたデータを調べます。
番号付きの手順
最初のBaseten推論リクエストを送る前に、以下の要件を確認してください。一般的な例よりも、モデル固有のドキュメントを優先してください。
必須
任意
-
利用可能なモデルと、そのモデルの最新の推論手順を確認します。 — 選んだモデルのモデル識別子またはエンドポイントを、提供されたとおりに正確に記録します。
-
呼び出すサービスで必要な認証方法を準備します。 — シークレットは、コミットするコードやクライアント側のアプリケーションの外に保存します。
-
モデルのドキュメントに記載されたスキーマに従って入力を1つ作成します。 — バッチ全体ではなく、小さく代表的な例を使用します。
-
リクエストを送信し、レスポンス全体を表示できるツールを選びます。 — APIクライアントや短いサーバー側スクリプトを使うと、ステータスと返されたフィールドを確認できます。
-
最初のリクエストが成功した後に比較できるよう、2つ目の入力を準備します。任意 — 対照的な例を使うと、レスポンス処理コードに潜む思い込みを見つけられます。
番号付きの手順
推論をどこに組み込むか、またはデプロイ前に何を確認するかを検討中の場合は、以下の関連ガイドが参考になります。
番号付きの手順
最初のリクエストの成功によって確かめるべきなのは、単に接続できることではなく、モデル、入力、レスポンス処理が噛み合っていることです。
2
条件を絞って1回呼び出す
そのモデルでサポートされているインターフェースを通じて、最小限の有効な入力を送信します。最初のBaseten推論テストは意図的に小規模にしてください。テキストタスクなら短いテキストサンプル、ほかのメディアを受け付けるモデルなら適切に準備したアセットを使用します。機密情報をログに記録せずに、リクエストのステータスとエラーメッセージを記録します。呼び出しに失敗した場合は、連携全体を書き直すのではなく、変数を一度に1つずつ変更してください。
3
使用前に出力を確認する
受け取ったフィールドだけでなく、返された構造全体を確認します。出力が入力に対応していること、空の結果や想定外の結果でもアプリケーションが安全に処理できることを確かめてください。この確認を終えてから、レスポンスを独自の型やユーザーインターフェースにマッピングします。ハードコードされた前提を見つけるため、別の入力でもテストを繰り返してください。
よくあるエラーと対処法
一般的なガイドですべてのモデルを診断することはできませんが、以下の確認によって、推論失敗のよくある原因を絞り込めます。
1
アクセスが拒否される
認証情報、モデルの参照先、アクセス権限のいずれかが正しくなければ、リクエストは成功しません。エラーが出たからといって、モデル自体が利用できないと決めつけないでください。
代わりに行うこと
設定したアクセス方法とモデルの参照先を、最新の手順と照らし合わせて確認してください。漏えいしたシークレットは再利用せず、ローテーションしてください。
2
入力が無効である
モデルのドキュメントに記載されたスキーマと一致しないフィールドやメディアを、そのモデルに解釈させることはBasetenにもできません。ネットワークリクエストとして有効でも、ペイロードが使用できない場合があります。
代わりに行うこと
ペイロードをドキュメントに記載された例まで簡素化し、フィールド名とデータ型を確認してから、独自の入力を少しずつ戻してください。
3
レスポンスが想定と異なる
モデルによって返す構造は異なり、呼び出しが成功しても、コードが期待するフィールドが存在するとは限りません。
代わりに行うこと
レスポンス全体を確認し、必須フィールドは読み取る前に検証して、欠損値や想定外の値を明示的に処理してください。
4
呼び出しが遅い、または失敗した理由がわかりにくい
このチュートリアルだけでは、レイテンシーを保証したり、クライアント側だけであらゆるタイムアウトの原因を特定したりすることはできません。
代わりに行うこと
リクエストの所要時間と機密性のないエラーの詳細を記録し、より小さい入力でテストして、モデルの最新の運用ガイダンスを確認してください。
応用的なヒント
Basetenでの推論呼び出しが1回成功したら、検証済みの同じ入出力仕様を、実際に使用する環境に合わせて適用してください。
アプリケーション開発者
モデル呼び出しを安定した境界内にまとめる
モデル固有のリクエスト構築処理を、サーバー側の1つのモジュールにまとめます。アプリケーションが受け取ったデータをモデルのペイロードに変換する前に検証し、推論が失敗した場合は予測可能なアプリケーションレベルのエラーを返します。これにより、コードベース全体に前提を分散させずに、モデルやリクエストのマッピングを変更できます。
- 認証情報は、保護されたサーバー側の設定で管理してください。
- 送信する入力と受信する出力の両方を検証してください。
- 成功時の応答だけでなく、エラー処理もテストしてください。
モデル評価担当者
一貫した入力で出力を比較する
扱いにくい入力や境界的な入力を1つ含め、代表的なテストケースを少数用意します。各結果を生成したモデルとリクエスト設定を記録してください。Basetenの推論動作を評価する際は、応答が成功したというステータスを品質スコアとみなさず、タスクの評価基準に照らして出力を比較してください。
- 再現可能なテストケースを使用してください。
- 評価基準と通信の確認を分けてください。
- 判断を自動化する前に、予期しない出力を確認してください。
運用チーム
データを露出させずに障害を把握できるようにする
デバッグに役立つ機密性のないリクエスト情報を決め、通常のログには認証情報や非公開の入力を保存しないようにします。自社アプリケーションの状況に即して、障害の分類と応答時間を追跡してください。モデル、ペイロード、またはアプリケーション側のタイムアウト設定を変更した際は、連携を再確認してください。
- アクセスエラーと無効な入力によるエラーを区別してください。
- シークレットや機密性の高いペイロードをログに記録しないでください。
- 設定を変更した後に再テストします。
高度なヒント
検証済みリクエストの手順を使います。モデルを選び、最新の手順に従い、小さな入力でテストし、アプリケーションに組み込む前に結果を確認してください。接続先には、独自のアクセス要件やモデル固有のガイダンスがある場合があります。
チュートリアルのよくある質問
アクセスできるモデルを選び、最新の推論手順を確認します。そのスキーマに合う最小限の入力を用意し、サポートされているインターフェースからリクエストを1回送信してください。アプリケーションのロジックを接続する前に、レスポンス全体を確認します。
モデルの参照情報、必要なアクセス方法、文書化された入力形式を確認します。認証情報をクライアント側のコードに含めず、成功時の出力だけでなくエラーも確認できるリクエストツールを使用してください。
まず、アクセスの問題、無効なペイロード、レスポンス処理の問題のどれに当たるかを切り分けます。モデルの参照情報と入力フィールドを最新の手順と照らし合わせ、使用できる最小限の文書化された入力で再試行してください。
まず、正常に動作したテストリクエストのレスポンスを確認し、アプリケーションに実際に必要なフィールドを特定します。使用前にそれらのフィールドを検証し、欠落した値や予期しない値に対処してください。また、モデル固有の解析処理を1か所にまとめ、更新しやすくします。