Cortex Analyst REST API¶
この API を使用して、自然言語クエリでデータに関する質問に回答します。
メッセージの送信¶
POST /api/v2/cortex/analyst/message
リクエストで提供されたセマンティックモデルまたは セマンティックビュー を使って、与えられた質問に対する SQL クエリを生成します。1つまたは複数のモデルを指定できます。複数のモデルが指定された場合、 Cortex Analyst は、最も適切なモデルを選択します。以前のクエリを基にしたフォローアップの質問ができるマルチターン会話が可能です。詳細については、 Cortex Analyst におけるマルチターン会話 をご参照ください。
リクエストにはユーザーの質問が含まれ、レスポンスにはユーザーの質問とアナリストのレスポンスが含まれます。応答の各メッセージは、異なるタイプの複数のコンテンツブロックを持つことができます。現在、コンテンツオブジェクトの type フィールドでサポートされている値は、 text、 suggestions および sql の3つです。
レスポンスは、処理完了後に一度に送信することも、生成されるたびに段階的に送信することもできます。
リクエストヘッダー¶
リクエスト本文¶
リクエスト本文で:
最後の
messages[].roleフィールドにスピーカーのロールをセットします。userでなければなりません。ユーザーの質問を
contentオブジェクトに含めます。このオブジェクトの中に:typeをtextに設定します。ユーザーの質問に
textをセットします。
以下のいずれかを含めてください:
セマンティックビューの YAML 仕様 。
セマンティックビューの仕様を含む YAML ファイルへのパス。このファイルはステージ上にある必要があります。
セマンティックビューの名前。
以下のテーブルは、リクエスト本文にセットできるフィールドを説明しています。
フィールド |
説明 |
|---|---|
|
(必須)メッセージを作成するエンティティのロール。Snowflakeは現在、 型: string:enum 例: |
|
(必須)メッセージの一部であるコンテンツオブジェクト。 型: オブジェクト
|
|
(必須)コンテンツタイプ。現在のところ、 型: string:enum 例: |
|
(必須)ユーザーの質問。 型: 文字列 例: |
|
セマンティックモデル YAML ファイルへのパス。データベースとスキーマを含む、完全修飾されたステージ URL でなければなりません。 複数のセマンティックモデルを指定するには、 リクエストで YAML 仕様を直接提供したい場合は、 型: 文字列 例: |
|
セマンティックモデル YAML 全体を含む文字列。 複数のセマンティックモデルを指定するには、代わりに 代わりにファイル内の YAML 仕様をポイントしたい場合は、ステージングされたファイルをアップロードし、 型: 文字列 |
|
JSON オブジェクトを含む配列。各オブジェクトは これらのフィールドは、トップレベルの
各クエリに対して、 Cortex Analyst は、リストから最も適切なモデルまたはビューを選択します。 この機能により、ユーザーと Cortex Analyst とのやり取りが簡単になります。クエリするデータソースを選択する必要はありませんし、それぞれどのセマンティックモデルやセマンティックビューを使用するかを管理する必要もありません。クエリごとにすべてのモデルや表示を指定し、 Cortex Analyst 。 タイプ:配列 Tip Cortex Analyst では、複数のモデルや表示を指定する必要はありません。単一のモデルまたはビューを指定する場合、リクエストはトップレベル 単一モデルのリクエストに |
|
セマンティックビュー の完全修飾名。例: 名前が大文字と小文字を区別するものであったり、 引用符で囲まれていない識別子 では許されない文字が含まれていたりする場合は、その名前をバックスラッシュ・エスケープされた二重引用符で囲む必要があります。例えば、データベース名、スキーマ名、およびビュー名にハイフン ( 複数のセマンティックビューを指定するには、 型: 文字列 |
|
(オプション) 型: ブール値 |
重要
リクエスト本文に以下のフィールドのいずれかを指定する必要があります:
semantic_model_filesemantic_modelsemantic_modelssemantic_view
ステージ上のファイルで意味モデルを指定する例¶
セマンティックビューの指定例¶
ストリーム以外での対応¶
この操作は、以下にリストされている応答コードを返すことができます。応答は常に次のような構造になっています。現在、応答には text、 suggestion、 sql の3つのコンテンツタイプがサポートされています。コンテンツタイプ suggestion と sql は互いに排他的なので、レスポンスに sql コンテンツタイプが含まれる場合は suggestion コンテンツタイプは含まれず、その逆も同様です。suggestion コンテンツタイプは、ユーザーの質問があいまいで、 Cortex Analyst がそのクエリに対する SQL ステートメントを返せなかった場合にのみ、応答に含まれます。
リクエストが semantic_models フィールドを含むとき、レスポンスはリクエストにどのセマンティックモデルが 選択されたかを示す semantic_model_selection フィールドを含みます。
前方互換性を確保するために、実装がコンテンツタイプを考慮し、タイプを処理することを確認してください。
コード |
説明 |
|---|---|
200 |
ステートメントは正常に実行されました。 応答の本文には、以下のフィールドを含むメッセージオブジェクトが含まれます。
|
デフォルトでは、 Cortex Analyst がユーザーの質問を完全に処理した後、レスポンスが一度に返されます。ストリーミングモードの応答形式については、 ストリーミング対応 をご参照ください。
ストリーミング対応¶
ストリーミング・モードでは、クライアントはレスポンス全体が生成されるのを待つのではなく、 Cortex Analyst によって生成されたレスポンスを受け取ることができます。これにより、アプリケーションの応答性が向上し、特に実行時間の長いクエリでは、ユーザーがより早く出力を確認できるようになります。また、ストリーミングレスポンスでは、 Cortex Analyst がレスポンスを生成するプロセスのどの段階にあるのかを理解するのに役立つステータス情報や、 Cortex Analyst が期待通りに動作しない場合に何が問題だったのかを理解するのに役立つ警告も提供されます。
ストリーミング応答を受け取るには、リクエスト本文の stream フィールドを true にセットします。ストリーミング応答は、 サーバーが送信したイベント を使用します。
Cortex Analyst は、ストリーム応答で5つの異なるタイプのイベントを送信します。
status: SQL の生成プロセスに関するステータスを表示します。message.content.delta: レスポンスの一部が含まれています。このイベントは複数回送信されます。error: Cortex Analyst がエラーに遭遇し、リクエストの処理を続行できないことを示します。それ以降、message.content.deltaイベントは送信されません。warnings: 処理中に発生した警告が含まれています。警告は処理を停止しません。response_metadata: リクエスト処理に関するデータを表示するためにレスポンスの最後に送信されます。done: 処理が完了し、今後message.content.deltaイベントが送信されないことを示すために送信されます。
このうち、 message.content.delta イベントは、実際のレスポンス内容が含まれているため、理解することが最も重要です。各 delta には、完全なレスポンスのフィールドのトークンが含まれています。それぞれの delta イベントには、1文字から全レスポンスまでのコンテナーが含まれる可能性があり、それらは異なる長さである可能性があります。生成されたトークンを受け取るのはあなたです。最終的なレスポンスに組み立てるのはあなた次第です。
重要
異なる反応(極めて類似したものであっても)によるイベントは異なる可能性があります。イベントが同じ順番、同じ内容で送信されることを保証するものではありません。
簡単な例¶
以下は、単純なクエリに対する非ストリーミング・レスポンスのサンプルです。
そしてこれは、そのレスポンスに対して起こりうる一連のストリームイベントです(別の一連のイベントも可能です):
message.content.delta レスポンスの index フィールドを使用して、イベントがフルレスポンスのどのフィールドの一部であるかを決定します。例えば、ここでは最初の2つの delta イベントはインデックス0を使用しています。これは、ストリーミング以外のレスポンスの content 配列の最初のフィールド (要素0) の一部であることを意味します。同様に、 SQL レスポンスを含む delta イベントはインデックス1を使用します。
提案例¶
この例には曖昧な質問に対するSuggested Questionsが含まれています。以下はストリーム以外の対応:
そして、その反応を構成する一連のストリームイベントをご紹介します:
この例では、ストリーム以外のレスポンスの content フィールドは配列です。content の要素のひとつは、 suggestions 配列です。つまり、 text と suggestions のデルタイベントの index フィールドの意味は、これら2つの異なる配列の要素の位置を指しています。完全な応答を組み立てる際には、これらのインデックスを別々に追跡する必要があります。
注釈
現在、生成された SQL ステートメントは常に1つのイベントで送信されます。将来はそうでなくなるかもしれません。クライアントは、 SQL ステートメントを複数のイベントで受け取る準備が必要です。
その他の例¶
Cortex Analyst 用の Streamlit ストリーミング・クライアントは Cortex Analyst GitHub リポジトリ にあります。このデモはローカルで実行する必要があります。SiS は現在ストリームをサポートしていません。
ストリーミング応答のインタラクティブなデモについては、 AI/ML Studio(Snowsight内)のCortex Analystプレイグラウンドを参照してください。
ストリームイベントスキーマ¶
以下は、ストリーミングレスポンスで Cortex Analyst から送信されるイベントの OpenAPI/Swagger スキーマです。
- status
- message.content.delta
- error
- warnings
- response_metadata
フィードバックを送信¶
POST /api/v2/cortex/analyst/feedback
定性的なエンドユーザーフィードバックを提供します。Snowsight 内で、フィードバックは Snowsight → AI & ML → Cortex Analyst → Select Semantic View → Monitoring tab に表示されます。
リクエストヘッダー¶
ヘッダー |
説明 |
|---|---|
|
(必須)認証トークン詳細については、 サーバーへの認証 をご参照ください。 |
|
(必須)application/json |
リクエスト本文¶
フィールド |
説明 |
|---|---|
|
(必須)メッセージを送信するために行ったリクエストのID。 型: 文字列 例: |
|
(必須)フィードバックが肯定的か否定的か。肯定的または「サムズアップ」の場合は 型: ブール値 例:
|
|
(オプション)ユーザーからのフィードバックメッセージ。 例: |
応答¶
ステータスコード200の空の応答本文。
アクセス制御の要件¶
必要な権限の情報については、 アクセス制御の要件 をご参照ください。
API への認証コードの詳細については、 Snowflakeでの Snowflake REST APIs 認証 をご参照ください。