Cortex Search¶
概要¶
Cortex Searchは、Snowflakeデータに対して低遅延で高品質な「ファジー」検索を可能にします。Cortex Searchは、 検索拡張世代(RAG) 大規模言語モデル(LLMs)を活用したアプリケーションなど、Snowflakeユーザーのための幅広い検索体験を提供します。
Cortex Searchは、埋め込み、インフラストラクチャのメンテナンス、検索品質パラメーターのチューニング、継続的なインデックスの更新を心配することなく、数分でテキストデータのハイブリッド(ベクトルとキーワード)検索エンジンを立ち上げ、実行することができます。つまり、インフラや検索品質のチューニングに費やす時間を減らし、データを活用した高品質なチャットや検索体験の開発に多くの時間を費やすことができます。 Cortex Searchチュートリアル で、Cortex Searchを使用して AI チャットおよび検索アプリケーションをパワーアップするためのステップバイステップの手順をご覧ください。
Cortex Searchの使用時期¶
Cortex Searchの2つの主なユースケースは、検索拡張世代(RAG)とエンタープライズ検索です。
LLM チャットボット用 RAG エンジン: Cortex Searchは、セマンティック検索を活用することで、カスタマイズされた文脈に応じた応答を実現し、テキストデータを使用したチャットアプリケーションの RAG エンジンとして使用できます。
エンタープライズ検索: Cortex Searchを、アプリケーションに埋め込まれた高品質の検索バーのバックエンドとして使用します。
RAG 向けのCortex Search¶
検索拡張生成(RAG)は、大規模言語モデルの生成応答を拡張するために、知識ベースからデータを検索する技術です。次のアーキテクチャ図は、Cortex Searchと Cortex LLM 関数 を組み合わせて、Snowflakeデータをナレッジベースとして使用する RAG エンタープライズチャットボットを作成する方法を示しています。

Cortex Searchは、L大規模言語モデルに必要なコンテキストを提供し、最新の独自データに基づいた回答を返す検索エンジンです。
例¶
この例では、Cortex Search Serviceを作成し、 REST API を使ってクエリする手順を説明します。サービスのクエリの詳細については、 「Cortex Search Serviceのクエリ」 をご参照ください。
この例では、カスタマーサポートのトランスクリプトデータセットのサンプルを使用します。
以下のコマンドを実行して、サンプルのデータベースとスキーマを設定します。
CREATE DATABASE IF NOT EXISTS cortex_search_db;
CREATE OR REPLACE WAREHOUSE cortex_search_wh WITH
WAREHOUSE_SIZE='X-SMALL';
CREATE OR REPLACE SCHEMA cortex_search_db.services;
以下の SQL コマンドを実行してデータセットを作成します。
CREATE OR REPLACE TABLE support_transcripts (
transcript_text VARCHAR,
region VARCHAR,
agent_id VARCHAR
);
INSERT INTO support_transcripts VALUES
('My internet has been down since yesterday, can you help?', 'North America', 'AG1001'),
('I was overcharged for my last bill, need an explanation.', 'Europe', 'AG1002'),
('How do I reset my password? The email link is not working.', 'Asia', 'AG1003'),
('I received a faulty router, can I get it replaced?', 'North America', 'AG1004');
変更追跡は、Cortex Search Serviceを構築するために必要です。このテーブルの所有権を持たないロールを使用して検索サービスを作成する場合は、以下のステートメントを実行してテーブルの変更追跡を有効にしてください。
ALTER TABLE support_transcripts SET
CHANGE_TRACKING = TRUE;
変更追跡の有効化の詳細については、 変更の追跡を有効にする をご参照ください。
サービスの作成¶
Cortex Search Serviceは、単一の SQL クエリ、またはSnowflake AI & ML Studioから作成できます。Cortex Search Serviceを作成すると、Snowflakeはソースデータに対して変換を実行し、低レイテンシでサービングできるようにします。以下のセクションでは、 SQL と、 Snowsight のSnowflake AI & ML Studioの両方を使用してサービスを作成する方法を示します。
注釈
検索サービスを作成すると、作成プロセスの一部として検索インデックスが構築されます。これは、 CREATE CORTEX SEARCH SERVICE ステートメントが大きなデータセットの場合、完了までに時間がかかる可能性があることを意味します。
SQL を使用する¶
次の例は、前のセクションで作成したサンプルカスタマーサポートのトランスクリプトデータセットに CREATE CORTEX SEARCH SERVICE、Cortex Search Serviceを作成する方法を示しています。
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
ON transcript_text
ATTRIBUTES region
WAREHOUSE = cortex_search_wh
TARGET_LAG = '1 day'
AS (
SELECT
transcript_text,
region,
agent_id
FROM support_transcripts
);
このコマンドは、データの検索サービスを構築するトリガーとなります。この例では:
同サービスへの問い合わせは、
transcript_text
列で一致するものを検索します。
TARGET_LAG
パラメーターは、Cortex Search Serviceがベーステーブルsupport_transcripts
の更新を1日に1回程度チェックすることを指示します。列
region
とagent_id
は、transcript_text
列に対するクエリの結果とともに返されるようにインデックスが付けられます。列
region
は、transcript_text
列をクエリする際にフィルター列として利用できるようになります。ウェアハウス
cortex_search_wh
は、指定されたクエリの結果を最初にマテリアライズするために使用され、ベーステーブルが変更されるたびに使用されます。
注釈
クエリで指定されたウェアハウスのサイズとテーブルの行数によっては、この CREATE コマンドの完了に数時間かかる場合があります。
Snowflakeでは、 MEDIUM 以下のサイズの専用ウェアハウスを各サービスに使用することを推奨しています。
ATTRIBUTES フィールドの列は、明示的な列挙またはワイルドカード(
*
)によって、ソースクエリに含まれている必要があります。
Snowsight を使用する¶
Snowsight でCortex Search Serviceを作成するには、以下の手順に従います。
Snowsight にサインインします。
SNOWFLAKE.CORTEX_USER データベースロールが付与されているロールを選択します。
ナビゲーションメニューで AI & ML » Studio を選択します。
Create a Cortex Search Service ボックスから + Create を選択します。
ロールとウェアハウスを選択します。このロールには、 SNOWFLAKE.CORTEX_USER データベースロールが付与されていなければならなりません。ウェアハウスは、サービスが作成され更新されるときに、ソースクエリの結果を実体化するために使用されます。
サービスを定義するデータベースとスキーマを選択します。
サービス名を入力し、 Let's go を選択します。
検索用にインデックスを作成するテキストデータを含むテーブルまたはビューを選択し、 Next を選択します。この例では、
support_transcripts
テーブルを選択します。注釈
サービス定義時に複数のデータソースを指定したり、変換を実行したりしたい場合は、 SQL を使用してください。
検索結果に含めたい列、
transcript_text
、region
、agent_id
を選択し、 Next を選択します。検索する列、
transcript_text
を選択し、 Next を選択します。特定の列に基づいて検索結果をフィルタリングしたい場合は、それらの列を選択し、 Next を選択します。フィルターが不要な場合は、 Skip this option を選択してください。この例では、このステップは省略できます。
ターゲットラグ(サービスコンテンツがベースデータの更新から遅れる時間)を設定し、 Create search service を選択します。
最後のステップでは、サービスが作成されたことを確認し、サービス名とそのデータソースを表示します。
注釈
Snowsight からサービスを作成する場合、サービス名は二重引用符で囲まれます。SQL でサービスを参照する際の意味については、 二重引用符で囲まれた識別子 をご参照ください。
使用許可の付与¶
サービスとインデックスを作成した後、customer_supportのような他のロールにサービス、そのデータベース、スキーマの使用を許可することができます。
GRANT USAGE ON DATABASE cortex_search_db TO ROLE customer_support;
GRANT USAGE ON SCHEMA services TO ROLE customer_support;
GRANT USAGE ON CORTEX SEARCH SERVICE transcript_search_service TO ROLE customer_support;
サービスのプレビュー¶
サービスにデータが正しく入力されていることを確認するには、 SQL 環境から SEARCH_PREVIEW 関数 を使用してサービスをプレビューできます。
SELECT PARSE_JSON(
SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
'cortex_search_db.services.transcript_search_service',
'{
"query": "internet issues",
"columns":[
"transcript_text",
"region"
],
"filter": {"@eq": {"region": "North America"} },
"limit":1
}'
)
)['results'] as results;
成功したクエリ応答のサンプル:
[
{
"transcript_text" : "My internet has been down since yesterday, can you help?",
"region" : "North America"
}
]
この応答は、サービスにデータが入力され、指定されたクエリに対して妥当な結果が提供されていることを確認します。
アプリケーションからサービスをクエリする¶
検索サービスを作成し、自分のロールに使用許可を付与し、プレビューしたら、 Python API を使ってアプリケーションからクエリすることができます。
次のコードは、 internet issues
に関するクエリに最も関連するサポートチケットを取得するためにPython API を使用し、 North America
リージョン内の結果を返すようにフィルタリングしています。
from snowflake.core import Root
from snowflake.snowpark import Session
CONNECTION_PARAMETERS = {"..."}
session = Session.builder.configs(CONNECTION_PARAMETERS).create()
root = Root(session)
transcript_search_service = (root
.databases["cortex_search_db"]
.schemas["services"]
.cortex_search_services["transcript_search_service"]
)
resp = transcript_search_service.search(
query="internet issues",
columns=["transcript_text", "region"],
filter={"@eq": {"region": "North America"} },
limit=1
)
print(resp.to_json())
成功したクエリ応答のサンプル:
{
"results": [
{
"transcript_text": "My internet has been down since yesterday, can you help?",
"region": "North America"
}
],
"request_id": "5d8eaa5a-800c-493c-a561-134c712945ba"
}
Cortex Search Serviceは、クエリの columns
フィールドで指定されたすべての列を返します。
必要な権限¶
Cortex Search Serviceを作成するには、ロールがCortex LLM 関数に必要な CORTEX_USER データベースロールを持っている必要があります。このロールの付与と取り消しについては、 Cortex LLM 権限が必須の関数 をご参照ください。
Cortex Search Serviceにクエリを実行するには、クエリを実行するユーザーのロールが、サービスが存在するデータベースとスキーマだけでなく、サービス自体に対して USAGE の権限を持っている必要があります。 Cortex Searchアクセス制御の要件 をご参照ください。
ALTER コマンドを使用してCortex Search Serviceを一時停止または再開するには、クエリするユーザーのロールがサービス上で OPERATE 権限を持っている必要があります。 ALTER CORTEX SEARCH SERVICE をご参照ください。
Cortex Searchの品質を理解する¶
Cortex Searchは、検索とランキングモデルのアンサンブルを活用し、ほとんどチューニングの必要なく、高レベルの検索品質を提供します。Cortex Searchは、文書の検索とランキングに「ハイブリッド」なアプローチをとっています。各検索クエリは、以下のものを利用します。
意味的に類似した文書を検索するための ベクトル検索
語彙的に類似した文書を検索するための キーワード検索
結果セットの中で最も関連性の高い文書を再ランク付けするための セマンティック再ランク付け
このハイブリッド検索アプローチは、セマンティックリランキングステップと相まって、幅広いデータセットとクエリにおいて高い検索品質を達成しています。
トークン制限とテキスト分割¶
Cortex Searchで最適な検索結果を得るために、Snowflakeは検索列のテキストを512トークン(約385英単語)以下のチャンクに分割することを推奨します。検索列のエントリーが512以上のトークンを含む場合、Cortex Searchはテキスト全体に対してキーワードベースの検索を実行しますが、セマンティック(つまりベクトルベース)検索には最初の512トークンのみを使用します。
トークンは文字の並びであり、大規模な言語モデルで処理できる最小単位です。近似値として、1トークンは英単語の約3/4、つまり約4文字に相当します。文字列内のトークンの正確な数を計算するには、 TOKEN_COUNT Cortex関数 を snowflake-arctic-embed-m
モデルパラメーターとともに以下のように使用します。
SELECT SNOWFLAKE.CORTEX.COUNT_TOKENS('snowflake-arctic-embed-m', '<input_text>') as token_count
セマンティック検索トークンの制限を理解する¶
512トークン以下のチャンクの推奨は、 チャンクサイズが小さいほど、一般的に検索やダウンストリーム LLM の応答性能が高くなる という研究結果によるものです。現在、 arctic-embed-m-long のような、より長いコンテキストの埋め込みモデルもありますが、Cortex Searchは、より高い検索品質をすぐに提供するために、より小さなコンテキストウィンドウを持つ埋め込みモデルを選択します。
このコンセプトの背後にある直感は、より小さなチャンクを使えば、与えられたクエリに対してより正確な検索ができるということです。これは、チャンクとクエリの埋め込みベクトルを生成する際に、「平均化」するトークンが少なくなるためです。さらに、チャンクが小さいと、モデルへのプロンプトで提供される潜在的にノイズとなるテキストが少なくなるため、下流の LLM、必要な情報だけを提供することができます。
公開されているQ&Aスタイルのベンチマークデータセットでは、一般的に小さなチャンクの方が良い結果を示すという研究結果を、 こちら でご覧いただけます。
リフレッシュ¶
Cortex Search Serviceで提供されるコンテンツは、特定のクエリの結果に基づいています。Cortex Search Serviceの基礎となるデータが変更されると、サービスはその変更を反映して更新されます。これらの更新は リフレッシュ と呼ばれます。このプロセスは自動化されており、テーブルの基礎となるクエリを分析します。
Cortex Search Serviceは動的テーブルと同じ更新プロパティを持っています。Cortex Search Serviceのリフレッシュの特徴については、 動的テーブルリフレッシュについて のトピックをご参照ください。
Cortex Search Serviceのソースクエリは、動的テーブルの増分リフレッシュの候補でなければなりません。これらの要件の詳細については、 増分リフレッシュのサポート をご参照ください。この制限は、ベクトル埋め込み計算に伴う不要なコストの暴走を防ぐためのものです。動的テーブルの増分リフレッシュでサポートされないコンストラクトの詳細については、 サポートされていないコンストラクト、演算子、関数 をご参照ください。
インデックス作成とサービングの停止¶
動的テーブルと同様に、Cortex Search Serviceは、ソースクエリに関連するリフレッシュが5回連続して失敗した場合、インデックス作成状態を自動的に中断します。お客様のサービスでこのエラーが発生した場合、 DESCRIBE CORTEX SEARCH SERVICE または CORTEX_SEARCH_SERVICES ビュー のいずれかを使用して、特定の SQL エラーを表示できます。両者の出力には以下の列が含まれます。
INDEXING_STATE 列の値は SUSPENDED となります。
INDEXING_ERROR 列には、ソースクエリで発生した特定の SQL エラーが格納されます。
ルート問題が解決すれば、 ALTER CORTEX SEARCH SERVICE <名前> RESUME INDEXING
でサービスを再開できます。詳細な構文については、 ALTER CORTEX SEARCH SERVICE をご参照ください。
コストの考慮事項¶
Cortex Search Serviceでは、以下のようなコストが発生します。
コストカテゴリ |
説明 |
---|---|
AI サービス - サービングコスト |
Cortex Search Serviceは、ユーザーが提供する仮想ウェアハウスとは別に、マルチテナントのサービングコンピューターを使用し、低レイテンシの検索クエリを可能にします。計算コストは、 GB /月(GB/月)のインデックス付きデータごとに発生します。インデックス付きデータとは、Cortex Searchのソースクエリに含まれるユーザー提供のデータと、ユーザーの代わりに計算されたベクトル埋め込みデータです。サービング料金の計算では、1ヶ月の使用量は30.5日と仮定し、セカンドレベルで計測されます。 見積もりとして、インデックスされたデータのサイズ(バイト単位)は大体 Cortex Searchサービングにかかるコストは、アカウント内の各Cortex Search Serviceについて、時間ごとの提供トークン利用を示す CORTEX_SEARCH_SERVING_USAGE_HISTORY ビュー で確認できます。 Cortex Searchサービングにかかる費用は、 METERING_HISTORY ビュー の AI_SERVICES の合計にも含まれています。 GB /月のインデックス付きデータあたりのクレジットレートについては、 Snowflakeサービス利用テーブル をご参照ください。 |
AI サービス - 費用の埋め込み |
Cortex Search Serviceは、 SNOWFLAKE.CORTEX.EMBED_TEXT_768 LLM 関数を使用して、検索列の各文書をベクトル空間に埋め込みます。これは、埋め込まれたトークンごとにクレジットコストが発生します。埋め込みはソースクエリの評価の中で段階的に処理されるため、埋め込みコストは追加または変更された文書に対してのみ発生します。ベクトル埋め込みコストの詳細については、 ベクトル埋め込み をご参照ください。 |
仮想ウェアハウスコンピューティング |
Cortex Search Serviceは、ユーザーが提供する仮想ウェアハウスを必要とします。このウェアハウスは、ユーザーがサービスを作成するときと、サービスが更新されるたびにコストが発生します。 |
ストレージ |
Cortex Search Serviceは、ソースクエリをお客様のアカウントに保存されているテーブルに実体化します。このテーブルは、低レイテンシ配信に最適化されたデータ構造に変換され、お客様のアカウントにも保存されます。テーブルと中間データ構造のストレージは、1テラバイトあたりの定額制(TB)基づいています。 |
クラウドサービスコンピューティング |
Cortex Search Serviceは、基盤となるベースオブジェクトが変更されたときにリフレッシュをトリガーするために、クラウドサービスの計算を使用します。クラウドサービスのコンピューティングコストには、日次クラウドサービスコストがアカウントの日次ウェアハウスコストの10%より大きい場合にのみ、Snowflakeによって請求されるという制約が適用されます。 |
Tip
Snowflakeでは、Cortex Search Serviceで MEDIUM 以下のウェアハウスサイズを使用することを推奨しています。この推奨事項は、今後の製品アップデートにより適用されなくなる可能性があります。
既知の制限¶
Cortex Searchの使用には以下の制限があります。
対応言語: この機能は英語の文書やクエリに最適化されています。
ベーステーブルサイズ: 検索サービスのマテリアライズドクエリの結果は、最適なパフォーマンスを維持するために、50M行未満のサイズでなければなりません。クエリのマテリアライズされた結果が50M行を超える場合、作成クエリはエラーになります。
注釈
Cortex Search Serviceの行スケーリング制限を50M以上にするには、Snowflakeアカウントチームまでご連絡ください。
クエリ構造: Cortex Search Serviceのソースクエリは、動的テーブルと同じクエリ制限に従わなければなりません。詳細については 動的テーブルの既知の制限 をご覧ください。
複製とクローニング: Cortex Search Serviceは、 複製 または クローニング をサポートしていません。これらの機能は将来のリリースでサポートされる予定です。
重要
作成したCortex Searchごとに、 Snowsightの動的テーブルのモニタリング UI に表示される2つの動的テーブルエンティティがあります。この2つのエンティティは、 _CORTEX_SEARCH_SOURCE_*
と _CORTEX_SEARCH_REFRESH_*
という形式です。これらのエンティティは動的テーブル情報スキーマビューにも表示されますが、動的テーブル SHOW/DESC コマンドには表示されません。Snowsight UI でこれらのエンティティをクリックすると、 Dynamic Table not found
メッセージが表示されます。これは想定内の動作です。Cortex Search関連のエンティティは、今後のリリースでSnowsight 動的テーブルのモニタリング UI から削除されます。
リージョンの可用性¶
この機能のサポートは、以下のSnowflakeリージョンのアカウントで利用可能です。
AWS |
Azure |
GCP |
---|---|---|
US 西部2(オレゴン州) |
東 US 2(バージニア) |
ヨーロッパ西部2(ロンドン) |
US 東部2(オハイオ) |
南中央 US (テキサス) |
ヨーロッパ西部3(フランクフルト) |
US 東部1(北部バージニア) |
UK 南部(ロンドン) |
ヨーロッパ西部4(オランダ) |
カナダ(中部) |
北ヨーロッパ(アイルランド) |
US 中央部1(アイオワ) |
南米(サンパウロ) |
西ヨーロッパ(オランダ) |
US 東部4(北部バージニア) |
ヨーロッパ(アイルランド) |
スイス北部(チューリッヒ) |
|
ヨーロッパ(ロンドン) |
インド中部(プネー) |
|
ヨーロッパ中部1(フランクフルト) |
日本東部(東京) |
|
ヨーロッパ(ストックホルム) |
東南アジア(シンガポール) |
|
アジア太平洋(東京) |
オーストラリア東部(ニューサウスウェールズ) |
|
アジア太平洋(ムンバイ) |
||
アジア太平洋(シドニー) |
||
アジア太平洋(ジャカルタ) |
||
アジア太平洋(ソウル) |
法的通知¶
インプットとアウトプットのデータ分類は以下の表の通りです。
入力データの分類 |
出力データの分類 |
指定 |
---|---|---|
Usage Data |
Customer Data |
Covered AI Features [1] |
詳細については、 Snowflake AI と ML をご参照ください。