Cortex Analyst REST API¶
この API を使用して、自然言語クエリでデータに関する質問に回答します。
メッセージの送信¶
POST /api/v2/cortex/analyst/message
リクエストで提供されたセマンティックモデルまたは セマンティックビュー を使って、与えられた質問に対する SQL クエリを生成します。1つまたは複数のモデルを指定できます。複数のモデルが指定された場合、 Cortex Analyst は、最も適切なモデルを選択します。以前のクエリを基にしたフォローアップの質問ができるマルチターン会話が可能です。詳細については、 Cortex Analyst におけるマルチターン会話 をご参照ください。
リクエストにはユーザーの質問が含まれ、レスポンスにはユーザーの質問とアナリストのレスポンスが含まれます。応答の各メッセージは、異なるタイプの複数のコンテンツブロックを持つことができます。現在、コンテンツオブジェクトの type
フィールドでサポートされている値は、 text
、 suggestions
および sql
の3つです。
レスポンスは、処理完了後に一度に送信することも、生成されるたびに段階的に送信することもできます。
リクエストヘッダー¶
ヘッダー |
説明 |
---|---|
|
(必須)認証トークン詳細については、 サーバーへの認証 をご参照ください。 |
|
(必須)application/json |
|
(オプション) 認証トークンのタイプ。デフォルトは OAuth です。詳細については、 サーバーへの認証 をご参照ください。 |
リクエスト本文¶
リクエスト本文で:
最後の
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_view": "MY_DB.MY_SCHEMA.SEMANTIC_VIEW"
/* ... */
}
名前が大文字と小文字を区別するものであったり、 引用符で囲まれていない識別子 では許されない文字が含まれていたりする場合は、その名前をバックスラッシュ・エスケープされた二重引用符で囲む必要があります。例えば、データベース名、スキーマ名、およびビュー名にハイフン ( {
/* ... */
"semantic_view": "\"my-database\".\"my-schema\".\"\"my-semantic-view\"\""
/* ... */
}
複数のセマンティックビューを指定するには、 型: 文字列 |
|
(オプション) 型: ブール値 |
重要
リクエスト本文に以下のフィールドのいずれかを指定する必要があります:
semantic_model_file
semantic_model
semantic_models
semantic_view
ステージ上のファイルで意味モデルを指定する例¶
{
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "which company had the most revenue?"
}
]
}
],
"semantic_model_file": "@my_db.my_schema.my_stage/my_semantic_model.yaml"
}
セマンティックビューの指定例¶
{
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "which company had the most revenue?"
}
]
}
],
"semantic_view": "MY_DB.MY_SCH.MY_SEMANTIC_VIEW"
}
ストリーム以外での対応¶
この操作は、以下にリストされている応答コードを返すことができます。応答は常に次のような構造になっています。現在、応答には text
、 suggestion
、 sql
の3つのコンテンツタイプがサポートされています。コンテンツタイプ suggestion
と sql
は互いに排他的なので、レスポンスに sql
コンテンツタイプが含まれる場合は suggestion
コンテンツタイプは含まれず、その逆も同様です。 suggestion
コンテンツタイプは、ユーザーの質問があいまいで、 Cortex Analyst がそのクエリに対する SQL ステートメントを返せなかった場合にのみ、応答に含まれます。
リクエストが semantic_models
フィールドを含むとき、レスポンスはリクエストにどのセマンティックモデルが 選択されたかを示す semantic_model_selection
フィールドを含みます。
前方互換性を確保するために、実装がコンテンツタイプを考慮し、タイプを処理することを確認してください。
コード |
説明 |
---|---|
200 |
ステートメントは正常に実行されました。 応答の本文には、以下のフィールドを含むメッセージオブジェクトが含まれます。
|
デフォルトでは、 Cortex Analyst がユーザーの質問を完全に処理した後、レスポンスが一度に返されます。ストリーミングモードの応答形式については、 ストリーミング対応 をご参照ください。
{ "request_id": "75d343ee-699c-483f-83a1-e314609fb563", "message": { "role": "analyst", "content": [ { "type": "text", "text": "We interpreted your question as ..." }, { "type": "sql", "statement": "SELECT * FROM table", "confidence": { "verified_query_used": { "name": "My verified query", "question": "What was the total revenue?", "sql": "SELECT * FROM table2", "verified_at": 1714497970, "verified_by": "Jane Doe" } } } ] }, "warnings": [ { "message": "Table table1 has (30) columns, which exceeds the recommended maximum of 10" }, { "message": "Table table2 has (40) columns, which exceeds the recommended maximum of 10" } ], "response_metadata": { "model_names": [ "claude-3-5-sonnet" ], "cortex_search_retrieval": [ { "service": "my_db.my_schema.my_search_service", "response_body": { "results": [ { "CUST_NAME": "customer1" } ], "request_id": "request1" }, "query": "'customer1'" } ], "question_category": "CLEAR_SQL" } }
ストリーミング対応¶
ストリーミング・モードでは、クライアントはレスポンス全体が生成されるのを待つのではなく、 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": {
"role": "analyst",
"content": [
{
"type": "text",
"text": "This is how we interpreted your question and this is how the sql is generated"
},
{
"type": "sql",
"statement": "SELECT * FROM table"
}
]
}
}
そしてこれは、そのレスポンスに対して起こりうる一連のストリームイベントです(別の一連のイベントも可能です):
event: status
data: { status: "interpreting_question" }
event: message.content.delta
data: {
index: 0,
type: "text",
text_delta: "This is how we interpreted your question"
}
event: status
data: { status: "generating_sql" }
event: status
data: { status: "validating_sql" }
event: message.content.delta
data: {
index: 0,
type: "text",
text_delta: " and this is how the sql is generated"
}
event: message.content.delta
data: {
index: 1,
type: "sql",
statement_delta: "SELECT * FROM table"
}
event: status
data: { status: "done" }
message.content.delta
レスポンスの index
フィールドを使用して、イベントがフルレスポンスのどのフィールドの一部であるかを決定します。例えば、ここでは最初の2つの delta
イベントはインデックス0を使用しています。これは、ストリーミング以外のレスポンスの content
配列の最初のフィールド (要素0) の一部であることを意味します。同様に、 SQL レスポンスを含む delta
イベントはインデックス1を使用します。
提案例¶
この例には曖昧な質問に対するSuggested Questionsが含まれています。以下はストリーム以外の対応:
{
"message": {
"role": "analyst",
"content": [
{
"type": "text",
"text": "Your question is ambigous, here are some alternatives:"
},
{
"type": "suggestions",
"suggestions": [
"which company had the most revenue?",
"which company placed the most orders?"
]
}
]
}
}
そして、その反応を構成する一連のストリームイベントをご紹介します:
event: status
data: { status: "interpreting_question" }
event: message.content.delta
data: {
index: 0,
type: "text",
text_delta: "Your question is ambigous,"
}
event: status
data: { status: "generating_suggestions" }
event: message.content.delta
data: {
index: 0,
type: "text",
text_delta: " here are some alternatives:"
}
event: message.content.delta
data: {
index: 1,
type: "suggestions",
suggestions_delta: {
index: 0,
suggestion_delta: "which company had",
}
}
event: message.content.delta
data: {
index: 1,
type: "suggestions",
suggestions_delta: {
index: 0,
suggestion_delta: " the most revenue?",
}
}
event: message.content.delta
data: {
index: 1,
type: "suggestions",
suggestions_delta: {
index: 1,
suggestion_delta: "which company placed",
}
}
event: message.content.delta
data: {
index: 1,
type: "suggestions",
suggestions_delta: {
index: 1,
suggestion_delta: " the most orders?",
}
}
event: status
data: { status: "done" }
この例では、ストリーム以外のレスポンスの 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
StreamingError: type: object properties: message: type: string description: A description of the error code: type: string description: The Snowflake error code categorizing the error request_id: type: string description: Unique request ID
- warnings
Warnings: type: object description: Warnings found while processing the request properties: warnings: type: array items: $ref: "#/components/schemas/Warning" Warning: type: object title: The warning object description: Represents a warning within a chat. properties: message: type: string description: A human-readable message describing the warning
- response_metadata
ResponseMetadata: type: object description: Details about request processing
フィードバックを送信¶
POST /api/v2/cortex/analyst/feedback
質的なエンドユーザーフィードバックを提供します。 Snowsight 内で、フィードバックは Monitoring にある Semantic Model Admins に表示されます。
リクエストヘッダー¶
ヘッダー |
説明 |
---|---|
|
(必須)認証トークン詳細については、 サーバーへの認証 をご参照ください。 |
|
(必須)application/json |
リクエスト本文¶
フィールド |
説明 |
---|---|
|
(必須)メッセージを送信するために行ったリクエストのID。 型: 文字列 例: |
|
(必須)フィードバックが肯定的か否定的か。肯定的または「サムズアップ」の場合は 型: ブール値 例:
|
|
(オプション)ユーザーからのフィードバックメッセージ。 例: |
応答¶
ステータスコード200の空の応答本文。
アクセス制御の要件¶
必要な権限の情報については、 アクセス制御の要件 をご参照ください。
API への認証コードの詳細については、 Snowflakeでの Snowflake REST APIs 認証 をご参照ください。