Cortex Search Serviceにクエリする¶
Cortex Search Serviceを作成すると、システムは低レイテンシでクエリを処理する API エンドポイントを用意します。Cortex Search Serviceをクエリするために3つの APIs を使用できます:
:ref:`SQL SEARCH_PREVIEW 関数 <label-cortex_search_query_syntax_sql_preview>
パラメーター¶
すべての APIs で同じクエリパラメーターのセットをサポートします。
パラメーター |
説明 |
|
|---|---|---|
必須 |
|
サービスのテキスト列で検索される検索クエリ。 |
オプション |
|
カンマ区切りのリストで、応答内の関連する結果ごとに返す列を指定します。これらの列は、サービスのソースクエリに含まれている必要があります。 このパラメーターが提供されない場合は、応答で検索列のみが返されます。 |
|
|
|
|
検索ランキングの動作をカスタマイズするための構成オブジェクト。構文については、 Cortex Searchスコアリングのカスタマイズ をご参照ください。 |
|
|
ALTER CORTEX SEARCH SERVICE ... ADD SCORING PROFILE で定義された、クエリで使用される名前付きスコアリングプロファイル。 |
|
|
応答で返す結果の最大数。最大1000。デフォルトの上限は10。 |
マルチインデックス検索のパラメーター¶
さらに、 SQL およびPython APIs は マルチインデックスクエリ をサポートしています。マルチインデックスパラメーターを使用すると、Cortex Searchからの結果を絞り込むことができ、検索される列の数を制限することでクエリコストを削減することができます。
パラメーター |
説明 |
|---|---|
|
クエリするインデックスを決定するために使用されるマップ。マップの各キーはインデックス付き列の名前で、各値はクエリを定義するマップを含む配列です。
|
注釈
マルチインデックスCortex Search Serviceは、引き続き RESTAPI を介して、または multi_index_query パラメーターを使用せずに検索できます。これにより、すべて のインデックス付き列に対して無制限の検索が行われ、クエリコストに影響します。マルチインデックスクエリコンピューティングのコスト見積もりの詳細については、 Cortex Search Serviceのコストについて - マルチインデックス検索 をご参照ください。
構文¶
Cortex Search Serviceへの単純なクエリは、以下の構文を使います。
マルチインデックスのクエリ構文¶
特定のインデックスのみをクエリする場合や、マルチインデックスのCortex Search Serviceにベクトル埋め込みを使用するサービスを使用する場合は、以下の構文を使用します。
設定と認証¶
Python API¶
Cortex Search Serviceのクエリは、バージョン0.8.0以降の Snowflake Python APIs を使用して行えます。Snowflake Python APIsの詳細情報については Snowflake Python APIs:PythonによるSnowflakeオブジェクトの管理 をご参照ください。.
Snowflake Python API ライブラリをインストールする¶
まず、PyPI からSnowflake Python APIs パッケージの最新バージョンをインストールします。PyPI からこのパッケージをインストールする手順については :doc:` インストールSnowflake PythonAPIs ライブラリ </developer-guide/snowflake-python-api/snowflake-python-installing>` をご参照ください。
Snowflakeに接続する¶
Snowpark Session またはPython Connector Connection のいずれかを使用してSnowflakeに接続し、 Root オブジェクトを作成します。Snowflake Python APIs を使用してSnowflakeに接続する方法については :doc:` </developer-guide/snowflake-python-api/snowflake-python-connecting-snowflake> をご参照ください。Snowflakeへの接続方法については、` をご参照ください。以下の例では、設定にSnowpark Session オブジェクトとPythonディクショナリを使用しています。
注釈
Cortex Search Serviceにクエリするには、Snowflake Python APIs ライブラリのバージョン0.8.0以降が必要です。
REST に API¶
Cortex Searchは、 Snowflake REST APIs のスイートで REST API エンドポイントを公開しています。Cortex Search Service用に生成される REST エンドポイントの構造は以下の通りです。
条件:
<account_url>:Snowflakeアカウント URL。アカウント URL を見つける手順については 、アカウントの組織名とアカウント名の検索 をご参照ください。<db_name>: サービスが存在するデータベース。<schema_name>: サービスが存在するスキーマ。<service_name>: サービス名。:query:サービスを呼びだすメソッド。この場合はqueryメソッド。
詳細については、 RESTCortex Search Service API` の <https://docs.snowflake.com/developer-guide/snowflake-rest-api/reference/cortex-search-service> `_ リファレンスをご参照ください。
認証¶
Snowflake REST APIs は、プログラムのアクセストークン(PATs)による認証、 JSON ウェブトークン(JWTs)を使用したキーペア認証 および OAuth をサポートしています。詳細については、 Snowflakeの認証 REST APIs Snowflakeを使用した をご参照ください
SQLSEARCH_PREVIEW 関数¶
SNOWFLAKE.CORTEX.SEARCH_PREVIEW 関数により、ワークシートやSnowflakeノートブックのセルなどの SQL 環境内から、Cortex Search Serviceに対する個々のクエリの結果をプレビューすることができます。この関数により、サービスが正しく入力され、妥当な結果を提供していることを簡単に検証できます。
重要
SEARCH_PREVIEW機能は、Cortex Search Servicesのテストと検証のために提供されます。エンドユーザーアプリケーションで検索クエリを提供するためのものではありません。
この関数は文字列リテラルに対してのみ動作します。バッチテキストデータは受け入れません。
この関数は RESTや Python APIsよりもレイテンシが高いです。
フィルター構文¶
Cortex Searchは、CREATE CORTEX SEARCH SERVICE コマンドで指定された ATTRIBUTES 列でのフィルタリングをサポートします。
Cortex Searchは4つのマッチング演算子をサポートしています。
ARRAY contains:
@containsNUMERIC または DATE/TIMESTAMP 同等またはそれ以上:
@gteNUMERIC または DATE/TIMESTAMP 同等またはそれ以下:
@lte主キー 等価:
@primarykey
これらのマッチング演算子は、さまざまな論理演算子と組み合わせることができます。
@and@or@not
使用上の注意¶
ソースクエリの
NaN(「非数値」)値との一致は、 特別な価値 で説明されているように処理されます。19桁(先頭のゼロを含まない)を超える固定小数点の数値は、
@eqまたは@gteおよび@lteでは機能せず、これらの演算子によって返されません(ただし、@notを使用すると、クエリ全体で返される可能性があります )。``TIMESTAMP``フィルターは、``YYYY-MM-DDTHH:MM:SS.sss+HH:MM``の形式の値を受け入れます。タイムゾーンオフセットを指定しない場合、日付は UTC で解釈されます。
``DATE``フィルターは、``YYYY-MM-DD``の形式の値を受け入れます。時間またはタイムゾーンが指定されている場合、それらは切り捨てられます。
@primarykeyは 主キー で構成されたサービスでのみサポートされます。フィルターの値は、すべての主キー列を対応する値(またはNULL)にマッピングする JSON オブジェクトである必要があります。
これらの演算子は1つのフィルターオブジェクトにまとめることができます。
例¶
文字列のような列
string_colが値valueと等しい行に対するフィルタリング。指定された主キー値
us-west-1内のregion列とabc123内のagent_id列を持つ行へのフィルタリング:ARRAY 列
array_colに値valueが含まれる行のフィルタリング。NUMERIC 列
numeric_colが 10.5 から 12.5 (含む) の間の行のフィルター:TIMESTAMP 列
timestamp_colが2024-11-19と2024-12-19の間にある行のフィルタリング。論理演算子でフィルターを構成する
マルチインデックスクエリ¶
CREATE CORTEX SEARCH SERVICE ... TEXT INDEXES ... VECTOR INDEXES 構文を使用してマルチインデックスのCortex Search Serviceとして作成された場合、オプションの multi_index_query パラメーターが使用されます。このパラメーターを省略すると、すべてのインデックスが検索に使用されます。
使用上の注意¶
クエリする各インデックスは、
multi_index_queryマップ内でキー値ペアとして表されます。各クエリでは、少なくとも1つのベクトルインデックスを提供する必要があります。テキストインデックスのみをクエリするとエラーになります。
マルチインデックスのCortex Search Serviceをクエリする場合、以下の動作が適用されます。
フィールドでの AND:ドキュメントが返されるには、クエリされたテキストまたはベクトルフィールドのすべてに一致する必要があります。
テキストインデックスフィールド内の用語での OR:クエリに「wash hold」などの複数の用語が含まれている場合、ドキュメント内にクエリ用語の いずれか があれば、ドキュメントが返されます。
テキストクエリは、Snowflakeのカスタムアナライザーを介して、ステミング、レマタイゼーション、ドメイン固有の書き換えを使用して自動的に正規化されます。これにより、「wasing」を「wash」にリンクしたり、「laundromat」を「laundry」にリンクしたりするなど、関連する用語を一致させることでリコールが向上します。
scoring_config.weightsフィールドは、指定されたクエリで3つのハイレベルなスコアリング技術(ベクトル、キーワード、再ランク付け)それぞれの相対的な重みを変更します。このフィールド内では、重みは相互に 相対的 に適用されます。たとえば、
{ "texts": 3, "vectors": 2, "reranker": 1 }および{ "texts": 30, "vectors": 20, "reranker": 10 }は同等です。scoring_config.functions.vector_boostsおよびscoring_config.functions.text_boostsフィールドの使用:これらのフィールドでは、ユーザーは特定のクエリ内で、各ベクトルインデックスとテキストインデックスクエリの相対的な重みをそれぞれ変更できます。
各フィールド内では、
scoring_config.weightsのように重みが相互に適用されます。
マルチインデックスクエリは、数値ブースト、時間減算、および再ランク付けを無効にするクエリと組み合わせることができます。これらの機能の使用に関する情報については、 数値ブーストと時間減衰 および 再ランキング をご参照ください。
マルチインデックスサービスをクエリする場合、
queryパラメーターは、サービスにユーザー指定のベクトル埋め込みを持つベクトルインデックスが含まれていない限り、すべてのフィールドに適用されるクエリを指定するために使用できます。検索のパフォーマンスとレイテンシを最適化するため、ユーザーが指定したベクトルインデックスに対してクエリを発行した場合、ベクトル埋め込みを含む列は結果で返されません。
Snowflakeは、コストに影響するリソースの消費量を削減するために、マルチインデックスCortex Search Serviceで
multi_index_queryを使用するクエリを絞り込むことを推奨しています。マルチインデックスのクエリの価格見積もりについては、 マルチインデックスCortex Searchのコスト見積もり をご参照ください。
アクセス制御の要件¶
Cortex Search Serviceをクエリするロールは、結果を取得するために以下の権限を持っている必要があります。
権限 |
オブジェクト |
|---|---|
USAGE |
Cortex Search Service |
USAGE |
Cortex Search Serviceが存在するデータベース。 |
USAGE |
Cortex Search Serviceが存在するスキーマ。 |
所有者権限でのクエリ¶
Cortex Search Serviceは、 所有者権限 で検索を実行し、所有者権限で実行される他のSnowflakeオブジェクトと同じセキュリティモデルに従います。
特に、これは、Cortex Search Serviceにクエリするのに十分な権限を持つロールであれば、サービスのソースクエリで参照される基になるオブジェクト(テーブルやビューなど)に対する権限に関係なく、サービスがインデックスしたデータをクエリできることを意味します。
例えば、行レベルマスキングポリシーを持つテーブルをリファレンスとするCortex Search Serviceでは、クエリユーザーのロールがソーステーブルの行を読めなくても、所有者のロールが読み取り権限を持つ行の検索結果を、クエリユーザーは見ることができます。
例えば、Cortex Search Serviceの USAGE 権限を持つロールを別のSnowflakeユーザーにGrantする場合は注意してください。
既知の制限¶
Cortex Search Serviceへのクエリには、以下の制限があります:
レスポンスサイズ:Cortex Search Serviceへの検索クエリから返されるレスポンスペイロードの合計サイズは、以下の制限を超えてはなりません。
REST API および Python API:10メガバイト (MB)
SQL SEARCH_PREVIEW 関数:300キロバイト(KB)
マルチインデックスCortex Searchには追加の制限が適用されます。これはプレビュー中に変更される可能性があります。
Snowsight UI のCortex Search Playgroundは、マルチインデックスサービスへのクエリをサポートしていません。Playgroundのマルチインデックスサービスに対するクエリは、「検索サービスをクエリできません。無効なリクエストパラメーターまたはフィルター構文です。」というメッセージを表示します。
multi_index_queryパラメーターを使用するマルチインデックスサービスクエリ構文は、 Python API のバージョン1.6.0以降でのみサポートされます。
例¶
このセクションでは、3つの API メソッドすべてにわたってCortex Search Serviceをクエリするための包括的な例を示します。
例のセットアップ:¶
以下の例では、タイムスタンプと数値列でさまざまな機能をすために、business_documents という名前のテーブルを使用しています。
フィルターの例¶
等価フィルターを使用した単純なクエリ¶
範囲フィルター¶
スコアリングの例¶
数値ブースト¶
お気に入り列とコメント列の両方に数値ブーストを適用し、お気に入り値の値に対するコメント値の2倍の強化重みを適用します。
結果では、以下のことに注目してください。
ブーストの効果により、「プロダクトロードマップ 2024」ドキュメントは「技術」というクエリとの関連性が若干低いにもかかわらず、お気に入りおよびコメントの数が多いため、上位の結果になります。
ブーストなしでは、クエリの最上位結果は「 従業員向け IT マニュアル:..."」です。
時間は経過します¶
LAST_MODIFIED_TIMESTAMP 列に基づいて時間減算を適用します。
現在のタイムスタンプから比較して、最新の LAST_MODIFIED_TIMESTAMP 値があるドキュメントは強化されます
現在のタイムスタンプから240時間より大きい LAST_MODIFIED_TIMESTAMP 値を使用したドキュメントはほとんど強化されません
結果では、以下のことに注目してください。
減衰を適用すると、「製品ロードマップ2024:...」ドキュメントは「技術」クエリへの関連性が若干低くなりますが、現在のタイムスタンプへの更新性により上位の結果になります
減衰を適用しない場合、クエリの最上位結果は「従業員向け IT マニュアル:...」です
再ランク付けの無効化¶
再ランク付けを無効にするには
Tip
リランキングはデフォルトの動作であるため、 scoring_config オブジェクトから "reranker": "none" パラメーターを省略し、リランカー で サービスをクエリします。
マルチインデックスクエリの例¶
このセクションでは、Pythonおよび SQL APIs 用に、検索するインデックスが制限されたマルチインデックスCortex Search Serviceをクエリする例を示します。
管理されたベクトル埋め込みを使用したサービスのクエリ¶
このセクションの例では、次の business_directory および example_search_service 定義を使用します。
特定のインデックスのクエリ¶
name テキストフィールドと description ベクトルフィールドに対して example_search_service をクエリするには:
管理されたベクトル列のみのクエリ¶
管理された埋め込みを使用して、ベクトルインデックス description で「 PCs の更新されたコンポーネント」について example_search_service をクエリするには:
インデックスの重みを使用したクエリ¶
テキストインデックス name で「sparkle」について、ベクトルインデックス description で「clothing washing」について example_search_service をクエリし、テキストまたは再ランク付けよりもベクトルスコアリングに4倍高い重み付けをするには:
description ベクトルインデックス列の重みは任意の text 列よりも高いので、「clothes washing」に最も関連するビジネスは、その名前に「sparkle」を含むビジネスの上に表示されます。
個別の重み付けされたインデックスを使用したクエリ¶
すべてのフィールドで「circuit」について example_search_service をクエリして、相対的な重み付けを適用し、 description 列ではなく name 列で一致をブーストするには:
住所よりも名前をブーストすると、「Circuit Town」という名前のビジネスが、「Circuit Blvd」の住所にあるビジネスよりも上にランク付けされることに注意してください。
カスタムベクトル埋め込みを使用したサービスのクエリ¶
このセクションの例では、次の business_documents および example_search_service 定義を使用します。
注釈
これらの例では、簡潔にするためにモック埋め込みを使用しています。実稼働のユースケースでは、 Snowflakeベクトル埋め込みモデル または外部ホスト埋め込みモデルを介してベクトルを生成する必要があります。
カスタム埋め込みを使用したインデックスのクエリ¶
document_contents および document_embedding 列で「 IT 」と対応する埋め込みを使用して example_search_service をクエリするには:
