メインコンテンツまでスキップ

AI Searchインデックスをクエリーする

AI Searchインデックスは、Python SDK、REST API、またはSQL vector_search()関数でクエリできます。AI Searchは、ANN、ハイブリッド、および全文検索のクエリタイプをサポートしており、検索品質を調整するためのページネーション、フィルター、および再ランキングも利用できます。

たとえば、AI Search エンドポイントとインデックスを作成およびクエリする方法を説明するノートブックについては、AI Search サンプル ノートブックを参照してください。リファレンス情報については、 Python SDK リファレンスを参照してください。

Databricks AI Search(旧 Databricks ベクトル検索)でした。

インストール​

AI Search SDK を使用するには、ノートブックにインストールする必要があります。パッケージをインストールするには、次のコードを使用します。

%pip install databricks-ai-search
dbutils.library.restartPython()

次に、AISearchClientをインポートするには、次のコマンドを使用してください。

from databricks.ai_search.client import AISearchClient

認証に関する情報については、「データ保護と認証」を参照してください。

AI Searchインデックスをクエリする方法​

AI Search インデックスのクエリを実行できるのは、Python SDK、REST API、または SQL vector_search() AI 関数を使用した場合のみです。

注記

インデックスにクエリを実行するユーザーまたは Service Principal は、次の Unity Catalog 権限を持っている必要があります。

  • AI Search インデックスを含むカタログに対するUSE CATALOG権限。
  • AI Searchインデックスを含むスキーマに対するUSE SCHEMA。
  • AI Searchインデックスに対するSELECT。インデックスの所有者には、すでにこの権限があります。

Databricks管理のエンベディングモデルを使用するインデックスの場合、呼び出し側のIDには、そのエンベディングモデルのモデルサービングEndpointに対する権限も必要になることがあります。「Service Principalを設定する」を参照してください。これには、本番運用クエリーのためのService Principalの設定も含まれます。

デフォルトのクエリ タイプはann (近似最近傍) です。さまざまな検索アルゴリズムの詳細については、検索アルゴリズムを参照してください。

  • ハイブリッド キーワード類似性検索を実行するには、パラメーターquery_typeをhybridに設定します。デフォルトでは、ハイブリッド検索ではすべてのテキスト メタデータ列が含まれ、最大 200 件の結果が返されます。
  • クエリでリランカーを使用するには、 クエリでリランカーを使用するを参照してください。
備考

ベータ版

全文検索はベータ機能として利用できます。全文検索を実行するには、パラメーターquery_typeをFULL_TEXTに設定します。全文検索では、ベクトルエンべディングを使用せずに、キーワードの一致に基づいて最大 10,000 件の結果を取得できます。全文クエリーは、標準Endpointとストレージ最適化Endpointの両方でサポートされています。ストレージ最適化Endpointでは、埋め込みを使用しない専用の全文検索インデックスを作成することもできます。全文検索インデックスの作成(ベータ版)を参照してください。選択したテキスト列の検索、結果の並べ替え、または全文クエリーやハイブリッドクエリーの集計カウントの取得については、選択したテキスト列の検索、結果の並べ替え、および集計の取得(ベータ版)を参照してください。

全文クエリーの場合、manifest.total_hit_countはnum_resultsとは無関係に一致するドキュメントの数を報告します。10,000以下のカウントは正確です。より大きな一致セットの場合、AI Searchは下限を報告する可能性があります。

manifest.total_hit_count_lower_bound フィールドは、カウントの解釈方法を示します。false の値は、total_hit_count が正確であることを意味します。true の値は、それが下限であることを意味します。

詳細については、 Python SDK リファレンスを参照してください。

Python
# Delta Sync Index with embeddings computed by Databricks
results = index.similarity_search(
query_text="Greek myths",
columns=["id", "field2"],
num_results=2
)

# Delta Sync Index using hybrid search, with embeddings computed by Databricks
results3 = index.similarity_search(
query_text="Greek myths",
columns=["id", "field2"],
num_results=2,
query_type="hybrid"
)

# Delta Sync Index using full-text search (Beta)
results4 = index.similarity_search(
query_text="Greek myths",
columns=["id", "field2"],
num_results=2,
query_type="FULL_TEXT"
)

# Delta Sync Index with pre-calculated embeddings
results2 = index.similarity_search(
query_vector=[0.9] * 1024,
columns=["id", "text"],
num_results=2
)

ノートブックからOAuthトークンを取得する​

Databricksコンピュートで実行されるノートブックでは、Service PrincipalなしでインデックスをクエリーするためのOAuthトークンを取得できます。そのためには、OAuth 2.0 トークン交換 (RFC 8693) を使用して、ワークスペース /oidc/v1/token Endpointでノートブックのトークンを OAuth トークンと交換します。REST API tabのService Principalの例と同様に、交換されたトークンにはインデックスの authorization_details があり、それをインデックスURLと共に使用します。

注記

この交換は、同じワークスペース内のDatabricksコンピュート上のノートブックからのみ機能します。ユーザー設定で作成した個人用アクセストークンや、ラップトップなどのDatabricksコンピュートの外部からは使用できません。Databricksコンピュートの外部では、代わりにOAuthユーザーマシン間 (U2M) 承認またはOAuthトークンを持つService Principalを使用してください。

トークン交換リクエストでは、次のフィールドを使用します。

  • grant_type: urn:ietf:params:oauth:grant-type:token-exchange。
  • subject_token: ノートブックのトークン。
  • subject_token_type: urn:databricks:params:oauth:token-type:personal-access-token。
  • requested_token_type: urn:ietf:params:oauth:token-type:access_token。
  • scope: all-apis。
  • authorization_details: インデックスに対する ReadVectorIndex 操作を許可するJSON配列。各ルート最適化埋め込みサービングEndpointで query_inference_endpoint を許可する workspace_permission エントリも 1 つ追加します。サービングEndpointの名前ではなく、Endpoint ID を使用してください。

ノートブックをランする ID には、インデックスの「AI Searchインデックスをクエリーする方法」にリストされているUnity Catalog権限と、「Service Principalの設定」のサービング Endpoint権限が必要です。

交換されたトークンは、そのアイデンティティとしてインデックスへのアクセスを許可します。印刷、ログ記録、または共有しないでください。

次の例はノートブックで実行されます。ノートブックコンテキストからノートブックのトークンを読み取ります。

Python
import json
import requests

WORKSPACE_URL = "https://<workspace-url>"
INDEX_NAME = "<catalog>.<schema>.<index>"
TIMEOUT_SECONDS = 30

AUTHORIZATION_DETAILS = [
{
"type": "unity_catalog_permission",
"securable_type": "table",
"securable_object_name": INDEX_NAME,
"operation": "ReadVectorIndex",
},
# If the index uses a route-optimized embedding model serving endpoint, also allow querying it:
# {
# "type": "workspace_permission",
# "object_type": "serving-endpoints",
# "object_path": "/serving-endpoints/<serving-endpoint-id>",
# "actions": ["query_inference_endpoint"],
# },
]

def get_oauth_token():
# Read the notebook token on each call so that a refresh uses a current token.
notebook_token = dbutils.notebook.entry_point.getDbutils().notebook().getContext().apiToken().get()
response = requests.post(
f"{WORKSPACE_URL}/oidc/v1/token",
data={
"grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
"subject_token": notebook_token,
"subject_token_type": "urn:databricks:params:oauth:token-type:personal-access-token",
"requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
"scope": "all-apis",
"authorization_details": json.dumps(AUTHORIZATION_DETAILS),
},
timeout=TIMEOUT_SECONDS,
)
if response.ok:
return response.json()["access_token"]
try:
error = response.json().get("error")
except ValueError:
error = None
# Report the status and OAuth error code, not the full response.
raise RuntimeError(f"Token exchange failed: status {response.status_code}, error {error}")

headers = {"Authorization": f"Bearer {get_oauth_token()}"}

# Get the index URL, then query the index
index_response = requests.get(
f"{WORKSPACE_URL}/api/2.0/vector-search/indexes/{INDEX_NAME}", headers=headers, timeout=TIMEOUT_SECONDS
)
index_response.raise_for_status()
index_url = index_response.json()["status"]["index_url"]

query_response = requests.post(
f"https://{index_url}/query",
headers=headers,
json={"num_results": 3, "query_text": "...", "columns": ["id", "text"]},
timeout=TIMEOUT_SECONDS,
)
query_response.raise_for_status()
results = query_response.json()

交換されたトークンは短命であり、通常は1時間です。トークン応答の expires_in フィールドは、秒単位の有効期間を提供します。トークンを更新するには、トークンの有効期限が切れる前に交換を繰り返します。

注記

本番運用アプリケーションの場合、 Databricks はノートブックから交換されたトークンの代わりに OAuth トークンを備えたService Principal を使用することをお勧めします。

ログクエリーペイロード(ベータ版)​

クエリーペイロードロギングは、モニタリングおよび取得品質分析のために、AI Searchクエリーのリクエストとレスポンスを system.telemetry.otel_logs システムテーブルに書き込みます。これは、標準およびストレージ最適化されたEndpoint上のインデックスで利用できます。 AI Search品質Mode プレビューが有効になっているカタログエクスプローラ でインデックスを作成すると、クエリーペイロードロギングがdefaultでオンになります。

クエリーペイロードのログ記録を使用するには、ワークスペースでUnity Catalogが有効になっており、 プレビュー ページで AI Search Quality Mode ベータ版に登録されている必要があります。設定を変更するには、インデックスのカタログに対するUSE CATALOG、スキーマに対するUSE SCHEMA、インデックスに対するMODIFYが必要です。

カタログエクスプローラのインデックスページの右側のサイドバーにある 「クエリーペイロードのロギング」(Query payload logging ) を使用して、ロギングをオンまたはオフにします。

Python SDKでクエリーペイロードのロギングをオンまたはオフにするには、update_index_payload_logging()を使用します。SDKで作成されたインデックスは、インデックス作成時にpayload_logging_enabled=Trueを渡さない限り、クエリーペイロードのロギングがオフになっています。

Python
from databricks.ai_search.client import AISearchClient

client = AISearchClient()
client.update_index_payload_logging(
index_name="catalog.schema.index_name",
payload_logging_enabled=True,
)

ロギングをオフにするには、payload_logging_enabled=Falseを設定します。

defaultでは、メタストア管理者でもあるアカウント管理者のみがクエリーペイロードLogsを読み取ることができます。他のユーザーにアクセス権を付与するには、 システムテーブルへのアクセス権限の付与を参照してください。

次のクエリーは、インデックスの AI Search ペイロードの Logs を返します。

SQL
SELECT time, attributes, body
FROM system.telemetry.otel_logs
WHERE service_name = 'ai-search'
AND attributes:['index_id']::STRING = '<index-id>'
ORDER BY time DESC;

ページ分割​

クエリが1,000件を超える結果を要求する場合、結果は自動的に最大1,000件ずつのページで返されます。単一のクエリですべてのページにわたって返される結果の最大数は 10,000 です。標準とストレージ最適化エンドポイントの両方がページネーションをサポートしています。

ページ分割はすべてのクエリタイプに対応しています。

Python SDKはページネーションを透過的に処理します。num_results を 1,000 より大きい値に設定すると、SDK はすべてのページを自動的に取得し、完全な結果セットを返します。追加のコードは不要です。

Python
# The SDK automatically paginates and returns all 5000 results
results = index.similarity_search(
query_text="Greek myths",
columns=["id", "text"],
num_results=5000
)

クエリーでフィルターを使用する​

クエリーでは、Deltaテーブル内のインデックス化された任意の列に基づいてフィルターを定義できます。similarity_searchは、指定されたフィルターに一致する行のみを返します。

次の表は、サポートされているフィルターの一覧です。

注記

ストレージ最適化エンドポイントでは、結果が過剰に取得されます。num_results を k に設定すると、k を超える結果が取得され、取得された結果にフィルターが適用されます。フィルター条件に一致するデータセットに結果が存在する場合でも、それらのドキュメントのスコアが上位ではない場合、結果が返却されない可能性があります。

フィルタ演算子

挙動

例

NOT

標準 :フィルターを否定します。キーの末尾は「NOT」でなければなりません。たとえば、値が"red"の"color NOT"は、色の値が赤ではないドキュメントと一致します。

ストレージ最適化 :!=(bangeq sign)operatorを参照してください。

標準 : {"id NOT": 2} {“color NOT”: “red”}

ストレージ最適化 : "id != 2" "color != 'red'"

<

標準: フィールド値がフィルター値より小さいかどうかを確認します。キーの末尾は「<」でなければなりません。たとえば、値が 200 の price < は、価格が 200 未満のドキュメントと一致します。

ストレージ最適化 :< 演算子を参照してください。

標準 : {"id <": 200}

ストレージ最適化 : "id < 200"

<=

Standard :フィールド値がフィルター値以下であるかどうかを確認します。キーの末尾は「<=」でなければなりません。たとえば、値が 200 の price <= は、価格が 200 以下であるドキュメントと一致します。

ストレージ最適化 : <= ≤ 演算子を参照してください。

標準 : {"id <=": 200}

ストレージ最適化 : "id <= 200"

>

標準:フィールド値がフィルター値より大きいかどうかを確認します。キーの末尾は「\>」でなければなりません。たとえば、値が 200 の「price \>」は、価格が 200 より大きいドキュメントと一致します。

ストレージ最適化 : > > 演算子を参照してください。

標準 : {"id >": 200}

ストレージ最適化 : "id > 200"

>=

標準 :フィールド値がフィルター値以上であるかどうかを確認します。キーの末尾は「\>=」でなければなりません。たとえば、値が 200 の price \>= は、価格が 200 以上であるドキュメントと一致します。

ストレージ最適化 :>= `>=` 演算子を参照してください。

標準 : {"id >=": 200}

ストレージ最適化 : "id >= 200"

OR

標準 : フィールド値がいずれかのフィルター値に一致するかどうかを確認します。キーには、複数のサブキーを区切るためにORを含めてください。例えば、値が["red", "blue"]のcolor1 OR color2は、color1がredであるか、またはcolor2がblueであるドキュメントに一致します。

ストレージ最適化 :or 演算子を参照してください。

標準 : {"color1 OR color2": ["red", "blue"]}

ストレージ最適化 : "color1 = 'red' OR color2 = 'blue'"

LIKE

「Standard」:文字列内の空白で区切られたトークンに一致します。

ストレージ最適化 :like 演算子を参照してください。

LIKE の使用に関する注意事項を参照してください。

フィルタ演算子が指定されていません

標準:フィルターは完全一致を確認します。複数の値が指定されている場合、いずれかの値に一致します。

ストレージ最適化 : = 等号演算子およびin 述語を参照してください。

標準 : {"id": 200} {"id": [200, 300]}

ストレージ最適化 : "id = 200" "id IN (200, 300)"

to_timestamp (ストレージ最適化エンドポイントのみ)

ストレージ最適化:タイムスタンプでフィルターします。to_timestamp関数を参照してください。

ストレージ最適化 : "date > TO_TIMESTAMP('1995-01-01')"

フィルタ演算子

挙動

例

NOT

標準 :フィルターを否定します。キーの末尾は「NOT」でなければなりません。たとえば、値が"red"の"color NOT"は、色の値が赤ではないドキュメントと一致します。

ストレージ最適化 :!=(bangeq sign)operatorを参照してください。

標準 : {"id NOT": 2} {“color NOT”: “red”}

ストレージ最適化 : "id != 2" "color != 'red'"

<

標準: フィールド値がフィルター値より小さいかどうかを確認します。キーの末尾は「<」でなければなりません。たとえば、値が 200 の price < は、価格が 200 未満のドキュメントと一致します。

ストレージ最適化 :< 演算子を参照してください。

標準 : {"id <": 200}

ストレージ最適化 : "id < 200"

<=

Standard :フィールド値がフィルター値以下であるかどうかを確認します。キーの末尾は「<=」でなければなりません。たとえば、値が 200 の price <= は、価格が 200 以下であるドキュメントと一致します。

ストレージ最適化 : <= ≤ 演算子を参照してください。

標準 : {"id <=": 200}

ストレージ最適化 : "id <= 200"

>

標準:フィールド値がフィルター値より大きいかどうかを確認します。キーの末尾は「\>」でなければなりません。たとえば、値が 200 の「price \>」は、価格が 200 より大きいドキュメントと一致します。

ストレージ最適化 : > > 演算子を参照してください。

標準 : {"id >": 200}

ストレージ最適化 : "id > 200"

>=

標準 :フィールド値がフィルター値以上であるかどうかを確認します。キーの末尾は「\>=」でなければなりません。たとえば、値が 200 の price \>= は、価格が 200 以上であるドキュメントと一致します。

ストレージ最適化 :>= `>=` 演算子を参照してください。

標準 : {"id >=": 200}

ストレージ最適化 : "id >= 200"

OR

標準 : フィールド値がいずれかのフィルター値に一致するかどうかを確認します。キーには、複数のサブキーを区切るためにORを含めてください。例えば、値が["red", "blue"]のcolor1 OR color2は、color1がredであるか、またはcolor2がblueであるドキュメントに一致します。

ストレージ最適化 :or 演算子を参照してください。

標準 : {"color1 OR color2": ["red", "blue"]}

ストレージ最適化 : "color1 = 'red' OR color2 = 'blue'"

LIKE

「Standard」:文字列内の空白で区切られたトークンに一致します。

ストレージ最適化 :like 演算子を参照してください。

LIKE の使用に関する注意事項を参照してください。

フィルタ演算子が指定されていません

標準:フィルターは完全一致を確認します。複数の値が指定されている場合、いずれかの値に一致します。

ストレージ最適化 : = 等号演算子およびin 述語を参照してください。

標準 : {"id": 200} {"id": [200, 300]}

ストレージ最適化 : "id = 200" "id IN (200, 300)"

to_timestamp (ストレージ最適化エンドポイントのみ)

ストレージ最適化:タイムスタンプでフィルターします。to_timestamp関数を参照してください。

ストレージ最適化 : "date > TO_TIMESTAMP('1995-01-01')"

使用上の注意 LIKE​

LIKE 標準エンドポイントの例

{"column LIKE": "apple"}: 「apple」と「apple pear」に一致しますが、「pineapple」には一致しません。「apple」という部分文字列を含むにもかかわらず、「pineapple」とは一致しないことに注意してください。これは、「apple pear」のように、空白で区切られたトークンで完全に一致するものを探します。

{"column NOT LIKE": "apple"} 反対です。「pineapple」と「pear」とは一致しますが、「apple」や「apple pear」とは一致しません。

LIKE ストレージ最適化エンドポイントの例

フォーマット

一致

"column LIKE 'apple'"

=演算子に相当します。完全一致のみが表示されます。

"column LIKE 'apple%'"

プレフィックスが apple に一致する行を返します。例: applepie

"column LIKE '%apple'"

サフィックスがappleに一致する行(例: pineapple)を返します。

"column LIKE '%apple%'"

appleに一致する部分文字列を含む行を返します。例: pineapplecake。

フォーマット

一致

"column LIKE 'apple'"

=演算子に相当します。完全一致のみが表示されます。

"column LIKE 'apple%'"

プレフィックスが apple に一致する行を返します。例: applepie

"column LIKE '%apple'"

サフィックスがappleに一致する行(例: pineapple)を返します。

"column LIKE '%apple%'"

appleに一致する部分文字列を含む行を返します。例: pineapplecake。

コードの例​

Python
# Match rows where `title` exactly matches `Athena` or `Ares`
results = index.similarity_search(
query_text="Greek myths",
columns=["id", "text"],
filters={"title": ["Ares", "Athena"]},
num_results=2
)

# Match rows where `title` or `id` exactly matches `Athena` or `Ares`
results = index.similarity_search(
query_text="Greek myths",
columns=["id", "text"],
filters={"title OR id": ["Ares", "Athena"]},
num_results=2
)

# Match only rows where `title` is not `Hercules`
results = index.similarity_search(
query_text="Greek myths",
columns=["id", "text"],
filters={"title NOT": "Hercules"},
num_results=2
)

構造体フィールドとマップ値をフィルター処理する​

ドット区切りのパスを使用して、プリミティブな構造体フィールドをフィルタリングします。マップキーにブラケット表記を使用して、プリミティブなマップ値をフィルタリングします。

次の例では、profile 構造体の age フィールドと attrs マップの voltage キーをフィルター処理します:

Python
results = index.similarity_search(
query_text="Greek myths",
columns=["id", "text"],
filters={"profile.age": 18, "attrs['voltage']": 9},
num_results=10
)

選択したテキスト列を検索し、結果を並べ替え、集計を返します (ベータ版)​

備考

ベータ版

選択したテキスト列の検索、並べ替え、および集計の戻り値に関するオプションは、 ベクトル検索:全文検索 ベータ版の一部です。query_columns、sort_columns、またはfacetsを使用するには、 「プレビュー」 で 「ベクトル検索:全文検索」 を有効にします。プレビューを有効にするには、アカウントチームに連絡するか、「Databricks プレビューの管理」を参照してください。

これらのオプションを使用して、選択したテキストフィールドを検索したり、明示的な結果順序を適用したり、一致する結果の集計を返したりできます。

これらのオプションはフルテキストおよびハイブリッドクエリでサポートされています。ANNクエリではサポートされていません。

選択したテキスト列を検索

query_columns を使用して、指定したテキスト列のみを検索します。列名を省略すると、クエリはすべてのテキスト列を検索します。

Python
query_columns=["title", "text"]

結果の並べ替え

sort_columns を使用して、デフォルトの関連度順ではなく列の値で結果を並べ替えます。エントリは"<column> ASC"または"<column> DESC"の形式を使用します。

Python
sort_columns=["rating DESC", "publication_year DESC"]

集計を返します。

facets を使用して、一致する結果の集計件数を返します。

値ファセットは、言語やカテゴリなどの列内の個別の値に基づいて、一致する結果をカウントします。TOP は返される値の数を制限し、省略された場合、デフォルトで10です。

Python
facets=["language TOP 5"]

応答例:

JSON
{
"facet_result": {
"facet_array": [
["language", "en", 28],
["language", "el", 14]
]
}
}

数値バケットは、出版年や価格などの指定された数値範囲に該当する一致する結果をカウントします。バケット境界は包括的です。

Python
facets=["publication_year BUCKETS [[1900,1949],[1950,1999],[2000,2025]]"]

応答例:

JSON
{
"facet_result": {
"facet_array": [
["publication_year", "[1900,1949]", 8],
["publication_year", "[1950,1999]", 14],
["publication_year", "[2000,2025]", 20]
]
}
}

全文クエリの場合、AI Searchは、クエリとフィルタに一致するすべての結果について集計をコンピュートします。これは、レスポンスで返された行に限定されません。ハイブリッド クエリの場合、AI Search は、インデックスのすべての行に対してではなく、ハイブリッド検索によって生成されるバインドされた候補セットに並べ替えと集計を適用します。

REST API のリクエストフィールドとレスポンススキーマについては、POST /api/2.0/vector-search/indexes/{index_name}/queryを参照してください。

クエリでリランカーを使用する​

エージェントのパフォーマンスは、クエリに最も関連性の高い情報を取得するかどうかに依存します。再ランク付けは、取得したドキュメントを評価して、意味的に最も関連性の高いドキュメントを特定することで、検索品質を向上させる手法です。Databricks は、これらの文書を識別するための研究ベースの複合AI システムを開発しました。また、各ドキュメントの関連性を評価するときに、リランカーが追加のコンテキストに使用するメタデータを含む列を指定することもできます。

リランキングは、わずかなレイテンシ遅延が発生しますが、検索品質とエージェントのパフォーマンスを大幅に改善できます。Databricks は、あらゆる RAG エージェントのユースケースで再ランキングを試すことを推奨しています。

AI Search リランカーは、データ所在地を管理するためにDatabricks Geos を使用するDatabricks 指定サービス です。米国、EU、オーストラリア、ニュージーランド以外の顧客は、リランカーを使用するために Geo間処理を有効にする必要がある場合があります。

このセクションの例では、AI Search リランカーの使用方法を示しています。リランカーを使用する際は、返す列(columns)と再ランキングに使用するメタデータ列(columns_to_rerank)を別々に設定します。num_results は、最終的に返される結果の数です。これは、リランキングに使用される結果の数に影響しません。

クエリのデバッグメッセージには、リランキングステップにかかった時間に関する情報が含まれています。例えば:

Bash
'debug_info': {'response_time': 693.0, 'ann_time': 29.0, 'reranker_time': 619.0}

リランカーの呼び出しに失敗した場合、その情報はデバッグメッセージに含まれます。

Bash
'debug_info': {'response_time': 587.0, 'ann_time': 331.0, 'reranker_time': 246.0, 'warnings': [{'status_code': 'RERANKER_TEMPORARILY_UNAVAILABLE', 'message': 'The reranker is temporarily unavailable. Results returned have not been processed by the reranker. Please try again later for reranked results.'}]}
注記

列がcolumns_to_rerankに記載されている順序は重要です。リランキング計算は、リストされている順序で列を受け取り、見つかった最初の2000文字のみを考慮します。

Python
# Install the most recent version.
# Databricks SDK version 0.57 or above is required to use the reranker.
%pip install databricks-ai-search --force-reinstall
dbutils.library.restartPython()
Python
from databricks.ai_search.reranker import DatabricksReranker

results = index.similarity_search(
query_text = "How to create an AI Search index",
columns = ["id", "text", "parent_doc_summary", "date"],
num_results = 10,
query_type = "hybrid",
reranker=DatabricksReranker(columns_to_rerank=["text", "parent_doc_summary", "other_column"])
)

フィルター専用クエリーとポイントルックアップ​

フィルターのみのクエリーは、ベクトル検索やキーワード検索を実行せずに、フィルターに一致する行を返します。query_text、query_vector、および query_type を省略し、filters を指定します。フィルターのみのクエリーは、標準およびストレージ最適化されたEndpoint上の、インデックス化されたフィルター可能なすべての列をサポートします。

次の例では、statusがactiveである行を返します:

Python
results = index.similarity_search(
columns=["id", "status"],
filters={"status": "active"},
num_results=100
)

num_results およびページネーションの制限は、フィルターのみのクエリーに適用されます。ポイントルックアップの場合は、主キー列でフィルター処理します。

検索アルゴリズム​

このセクションでは、さまざまな取得アルゴリズムまたはクエリタイプと、それぞれがいつ使用されるかについて説明します。query_typeパラメーターを使用して、使用する取得アルゴリズムを指定します。インデックスの異なるアルゴリズムのパフォーマンスを自動的に比較する方法については、AI Search 取得品質の評価を参照してください。

戦略

仕組み

どのようなタスクにベストなのか

ANN (近似最近傍)

ベクトル埋め込みを使用して、セマンティック類似ドキュメントを検索します。

厳密な表現よりも意味が重視される、概念的およびセマンティックなクエリ。

全文

キーワードの正確な一致による検索。

特定の用語、固有名詞、製品ID、または専門用語を含むクエリ

ハイブリッド

ANNと全文検索の結果は、Reciprocal Rank Fusion(RRF)を使用して結合されます。

汎用検索。ほとんどのユースケースにおける推奨される開始点です。

ハイブリッド + リランカー

ハイブリッド検索を実行し、その後、クロスエンコーダーリランカーモデルで結果を再スコア付けします。

レイテンシが許容される場合(通常、1クエリあたり1秒未満の追加)は、より高い精度。

戦略

仕組み

どのようなタスクにベストなのか

ANN (近似最近傍)

ベクトル埋め込みを使用して、セマンティック類似ドキュメントを検索します。

厳密な表現よりも意味が重視される、概念的およびセマンティックなクエリ。

全文

キーワードの正確な一致による検索。

特定の用語、固有名詞、製品ID、または専門用語を含むクエリ

ハイブリッド

ANNと全文検索の結果は、Reciprocal Rank Fusion(RRF)を使用して結合されます。

汎用検索。ほとんどのユースケースにおける推奨される開始点です。

ハイブリッド + リランカー

ハイブリッド検索を実行し、その後、クロスエンコーダーリランカーモデルで結果を再スコア付けします。

レイテンシが許容される場合(通常、1クエリあたり1秒未満の追加)は、より高い精度。

ANN(ベクトル検索)​

ANN検索は、クエリをベクトルエンベディングに変換し、エンベディングが最も類似しているドキュメントを見つけます。これは 意味 を理解するのに効果的です。例えば、「how to fix a broken pipe」のようなクエリーは、それらの正確な単語が含まれていない場合でも、配管に関するドキュメントと一致します。

  • ANNのパフォーマンスが良好な場合: クエリは概念的、会話的であるか、ドキュメントとは異なる語彙を使用します。
  • ANN のパフォーマンスが低下する可能性のある状況 : クエリーは、埋め込みが正確に捉えきれない可能性のある、正確なキーワード、固有名詞、またはドメイン固有の専門用語に依存しています。

全文検索(キーワード検索)​

全文検索は、クエリの用語を含むドキュメントに一致します。全文検索は精度が高いです。ユーザーが特定の名前、コード、または専門用語を検索する場合、キーワード一致は、ベクトル検索が見逃す可能性のある完全一致を検出します。

全文検索またはハイブリッドクエリオプションを使用して、選択したテキスト列を検索したり、結果を並べ替えたり、集計数を返したりします。「選択したテキスト列を検索し、結果を並べ替えて集計を返す (ベータ版)」を参照してください。

  • 全文検索のパフォーマンスが良い場合: クエリには、特定の識別子、製品名、エラーコード、またはドメイン固有の用語が含まれます。
  • 全文検索のパフォーマンスが低下する可能性: クエリがドキュメントとは異なる表現で記述されているか、類義語や言い換えが使用されている場合。

ハイブリッド検索​

ハイブリッド検索は、ANNと全文検索の両方を並行して実行し、その後、Reciprocal Rank Fusion(RRF)を使用して結果を結合します。これは、ベクトル検索の意味的理解とキーワードマッチングの精度を組み合わせたものです。

  • ハイブリッド検索が効果を発揮する場面 :クエリのワークロードが、概念的なクエリとキーワードを多用するクエリの組み合わせである場合。Hybrid は最も堅牢な汎用戦略です。

リランカー​

リランカーは、任意の戦略の上に適用されるオプションのセカンドパスです。初期取得後、クロスエンコーダーモデルはクエリのコンテキストで各結果を再評価し、より正確な関連性の順序付けを生成します。

再ランカーは通常、品質を約10%向上させますが、レイテンシが増加します。品質が最も重要なRAGチャットボットなどのアプリケーションには適していますが、高スループット、低レイテンシーの検索アプリケーションには向いていない可能性があります。