Azure DatabricksでRAG、レコメンド、セマンティック検索を作る場合、2026年6月26日時点でまず確認すべきポイントは「Databricks Vector Search」という呼び方が「Databricks AI Search」に変わり、単なるベクター検索ではなく、ハイブリッド検索、フルテキスト検索、フィルター、再ランキングまで含む検索基盤として整理されたことです。
Databricks AI Search – Azure Databricksは、DeltaテーブルからAI Searchインデックスを作成し、生成AIアプリが必要な文書やレコードを検索できるようにする機能です。既存のVector Search利用者にとっては、すぐに全リソースを作り直す変更というより、名称変更、エンドポイント種別、同期方式、権限、コスト管理、制限事項を見直すタイミングと捉えるのが実務的です。Microsoft Learnの公式情報でも、Databricks AI Searchは旧称Databricks Vector Searchであり、Data Intelligence Platformに組み込まれた検索ソリューションとして説明されています。 (Microsoft Learn)
Azure DatabricksのDatabricks AI Searchとは
Databricks AI Searchは、Azure Databricks上で使う検索エンジンです。主な用途は、RAG、レコメンドシステム、画像・動画認識、意味検索などです。検索対象のデータを埋め込みベクトルとして扱い、クエリに近い文書やレコードを返します。
従来のキーワード検索は、入力語句と文書中の単語が一致するかを重視します。一方、Databricks AI Searchでは、文章や画像などの意味を数値化したembeddingsを使うため、「言い回しは違うが意味が近い情報」を探しやすくなります。さらに、Databricks AI Searchはハイブリッド検索にも対応しており、ベクター類似検索とキーワード検索を組み合わせられます。SKU、製品番号、顧客ID、エラーコードのように完全一致が重要な語句を含むRAGでは、純粋なベクター検索よりハイブリッド検索のほうが安定しやすい場面があります。 (Microsoft Learn)
典型的な構成は次の流れです。
| ステップ | 何をするか | 実務上の確認ポイント |
|---|---|---|
| データ準備 | Deltaテーブルに検索対象データを用意する | 主キー、更新頻度、検索対象列、メタデータ列を整理する |
| 埋め込み生成 | Databricks側で生成する、または自前で生成済みのembeddingsを使う | モデル、次元数、再生成コストを決める |
| インデックス作成 | DeltaテーブルからAI Searchインデックスを作る | StandardかStorage-optimizedか、同期方式を選ぶ |
| クエリ実行 | SDK、REST API、SQL関数から検索する | ANN、hybrid、FULL_TEXT、フィルター、再ランキングを使い分ける |
| アプリ連携 | 検索結果をLLMのプロンプトや推薦ロジックに渡す | 権限、レスポンスサイズ、検索品質、監視を設計する |
今回の更新で押さえるべき変更点
今回のポイントは、「Vector SearchからAI Searchへの名称変更」だけではありません。公式ドキュメントでは、AI Searchがサポートする機能として、ハイブリッド検索、フルテキスト検索、フィルタリング、再ランキング、エンドポイントACL、同期対象列の選択、生成済みembeddingsの保存などが整理されています。 (Microsoft Learn)
Vector SearchからAI Searchへ名称が変わった
もっとも分かりやすい変更は、Databricks Vector SearchがDatabricks AI Searchとして説明されるようになった点です。これにより、社内ドキュメント、設計書、運用手順、IaC、監視項目で「Vector Search」と「AI Search」が混在する可能性があります。
ただし、公式ドキュメント上ではREST APIのパスや一部リソース名にvector-searchやvector_search_endpointsという表記が残っています。たとえば、エンドポイント作成のREST API参照は/api/2.0/vector-search/endpointsとして示され、Declarative Automation Bundlesのリソース例でもvector_search_endpointsが使われています。 (Microsoft Learn)
そのため、管理者は名称だけを見て「古いAPIなので使えない」と判断しないよう注意が必要です。現時点では、公式ドキュメントで明示されているAPI名やSDK名を基準にし、画面表示や記事タイトル上の「AI Search」と、API・内部リソース名の「vector search」を対応付けて管理するのが安全です。
検索方式がより明確に整理された
Databricks AI Searchでは、ANN、hybrid、full-textといった検索タイプを使い分けます。クエリはPython SDK、REST API、SQLのvector_search()関数から実行でき、ページネーション、フィルター、再ランキングにも対応します。なお、vector_search() SQL関数はPublic Previewとして説明されています。 (Microsoft Learn)
| 検索方式 | 向いている用途 | 注意点 |
|---|---|---|
| ANN | 意味が近い文書を探すRAG、類似FAQ検索、類似商品検索 | キーワード完全一致が弱い場合がある |
| hybrid | 意味検索とキーワード一致を両立したい検索 | 最大返却件数や対象テキスト列を確認する |
| FULL_TEXT | ID、品番、固有名詞、短いキーワード中心の検索 | ベータ機能として扱われる範囲を確認する |
| reranking | 検索結果の順位を改善したい場合 | レイテンシ、コスト、評価データを確認する |
| filters | ユーザー、部署、地域、カテゴリで絞り込みたい場合 | 行・列レベル権限の代替として設計しすぎない |
特にRAGでは、検索品質が回答品質を大きく左右します。LLMのモデルだけを変更しても、検索で不適切な文書を渡していれば、回答は安定しません。Azure Databricks上の社内ナレッジ検索では、「質問文に近い文書を探す」だけでなく、「権限上見せてよい文書だけを返す」「品番や契約番号を取りこぼさない」「古い文書を優先しない」といった検索設計が重要になります。
Full-text searchがベータとして拡張されている
公式情報では、フルテキスト検索はベータ機能として示されています。query_type="FULL_TEXT"を使うことで、ベクター埋め込みを使わずにキーワード一致で検索できます。また、Storage-optimized endpointsでは、embeddingsを持たない専用のフルテキスト検索インデックスも作成できます。 (Microsoft Learn)
専用フルテキスト検索インデックスは、次のような場面で有効です。
| 活用シーン | 例 | Databricks AI Searchでの考え方 |
|---|---|---|
| 完全一致に近い検索 | 製品番号、SKU、顧客ID、ログID | ベクター化せずFULL_TEXTで探す |
| 日本語を含む文書検索 | 社内規程、FAQ、問い合わせ履歴 | 対応言語とベータ扱いを確認する |
| RAG前の候補抽出 | 関連文書をまずキーワードで絞る | hybridまたはFULL_TEXTを比較評価する |
| 分析画面の検索 | カテゴリ、言語、年などで絞る | facetsやsort_columnsのプレビュー範囲を確認する |
フルテキスト検索インデックスの作成はStorage-optimized endpointのみ、同期方式はTriggeredのみ、embedding_source_column、embedding_vector_column、embedding_dimensionは使用しない、という要件があります。対応言語には日本語も含まれるため、日本語文書の検索基盤をDatabricks内で完結させたい組織にとっては検証価値があります。ただしベータ機能は仕様変更の可能性があるため、本番利用ではプレビュー利用ルール、SLA、サポート条件を確認してから採用すべきです。 (Microsoft Learn)
Azure AI Searchとの違いを混同しない
名称が似ているため、Azure DatabricksのDatabricks AI Searchと、Azureの独立サービスであるAzure AI Searchを混同しやすくなります。両方ともRAGやベクター検索に関係しますが、設計思想と置き場所が異なります。
| 比較項目 | Databricks AI Search – Azure Databricks | Azure AI Search |
|---|---|---|
| 主な位置付け | Azure Databricks内の検索基盤 | Azure上のフルマネージド検索サービス |
| 主なデータ起点 | Deltaテーブル、Unity Catalog配下のデータ | Azure Blob Storage、Cosmos DB、SharePoint、OneLakeなど複数データソース |
| 得意なケース | Databricks上のデータ、RAG、レコメンド、分析基盤との連携 | アプリ向け検索、エージェント検索、マルチソース検索 |
| 管理単位 | AI Search endpointとindex | Search service、index、indexer、skillsetなど |
| ガバナンス | Unity CatalogとDatabricks権限設計が中心 | Azure RBAC、Microsoft Entra、Private LinkなどAzureサービス設計が中心 |
Azure AI SearchはAzureポータル、REST API、Azure SDKから利用するフルマネージド検索サービスで、フルテキスト、ベクター、ハイブリッド、マルチモーダル検索、AI enrichmentなどを提供します。 (Microsoft Learn)
一方、Databricks AI SearchはDeltaテーブルからAI Searchインデックスを作り、Unity Catalogで管理される点が特徴です。社内のデータレイク、Lakehouse、Feature Store、MLパイプラインがDatabricksに寄っている場合は、データ移動を減らして検索基盤を作りやすくなります。 (Microsoft Learn)
判断基準はシンプルです。検索対象データがすでにAzure DatabricksのDeltaテーブルにあり、RAGやレコメンドをDatabricksワークスペース内で作るならDatabricks AI Searchを優先的に検討します。複数の業務システム、Blob、SharePoint、Webコンテンツなどを横断し、Azureアプリケーションから検索APIとして使いたい場合はAzure AI Searchのほうが適する可能性があります。
影響範囲：誰が何を確認すべきか
Databricks AI Searchの更新は、AIアプリ開発者だけでなく、Azure管理者、Databricks管理者、データエンジニア、セキュリティ担当、FinOps担当に影響します。
| 担当者 | 影響範囲 | 確認すべきこと |
|---|---|---|
| Azure管理者 | 認証、ネットワーク、コスト、監視 | サービスプリンシパル、課金、リージョン、監査ログ |
| Databricks管理者 | ワークスペース設定、Unity Catalog、ACL | Serverless compute、CREATE TABLE権限、endpoint ACL |
| データエンジニア | Deltaテーブル、同期、主キー、スキーマ | Change Data Feed、_id列、同期対象列、行サイズ |
| AIアプリ開発者 | RAG、検索品質、SDK/API | hybrid、FULL_TEXT、reranking、filters、ページネーション |
| セキュリティ担当 | 認可、秘密情報、データ保護 | PAT利用の削減、サービスプリンシパル、アプリ側ACL |
| FinOps担当 | endpoint、index、QPS、ストレージ | 未使用endpoint、usage policy、target_qps、同期方式 |
公式情報では、AI Searchを使う前提条件として、Unity Catalogが有効なワークスペース、Serverless compute、Standard endpointsでのChange Data Feed、インデックス作成先スキーマへのCREATE TABLE権限などが示されています。また、AI Search endpointの作成・管理権限はACLで構成します。 (Microsoft Learn)
エンドポイント選択：StandardとStorage-optimizedの判断基準
Databricks AI Searchでは、エンドポイント作成時にStandardまたはStorage-optimizedを選択します。後から簡単に前提を変えられるものではないため、初期設計でデータ量、更新頻度、検索レイテンシ、コストを見積もることが重要です。
| 観点 | Standard endpoint | Storage-optimized endpoint |
|---|---|---|
| 向いている用途 | 通常規模のRAG、低レイテンシ重視、継続同期 | 大規模ベクトル、巨大な検索対象、インデックス作成速度重視 |
| 容量の目安 | 768次元で約3億2,000万vectors | 768次元で10億vectors超 |
| 高QPS | StandardのみPublic Previewで対応 | 対象外 |
| 同期方式 | Continuous、Triggered | Triggeredのみ |
| インデックス作成 | 通常 | 10〜20倍高速と説明 |
| レイテンシ | 標準的 | 約250ms程度増える可能性 |
| 主な注意点 | 大規模化時の容量見積もり | Continuous sync、CMK、FedRAMPなど非対応項目あり |
公式情報では、Standard endpointsは768次元で約3億2,000万vectors、Storage-optimized endpointsは768次元で10億vectors超を扱えると説明されています。また、Storage-optimized endpointsはインデックス作成が10〜20倍高速な一方、クエリレイテンシが約250ms増える可能性があります。 (Microsoft Learn)
実務では、次のように選ぶと判断しやすくなります。
| 条件 | 推奨しやすい選択 |
|---|---|
| 数百万〜数千万件規模で、検索応答の速さを重視する | Standard |
| データ更新を継続的に反映したい | Standard |
| 10億件級のベクトルを扱う可能性がある | Storage-optimized |
| フルテキスト専用インデックスを試したい | Storage-optimized |
| CMKやFedRAMP要件がある | Storage-optimizedの制限を必ず確認 |
| 高QPSを設定したい | Standard。ただしPublic Previewと追加コストに注意 |
Storage-optimized endpointsには、Continuous sync非対応、columns to sync非対応、embedding dimensionが16で割り切れる必要がある、CMK非対応、FedRAMP準拠ワークスペース非対応などの制限があります。大規模データに強い反面、ガバナンスや運用要件に合わないケースがあるため、容量だけで選ばないことが重要です。 (Microsoft Learn)
インデックス方式：Delta SyncかDirect Vector Accessか
Databricks AI Searchでは、主にDelta Sync IndexとDirect Vector Access Indexを使い分けます。どちらを選ぶかで、データ更新の責任範囲が変わります。
| インデックス方式 | 特徴 | 向いているケース |
|---|---|---|
| Delta Sync Index | Deltaテーブルと同期する | Databricks上の業務データ、ナレッジ、ログを検索したい |
| Databricks管理embeddings | Databricksがテキスト列からembeddingsを計算する | まずRAGを立ち上げたい、埋め込み生成を任せたい |
| self-managed embeddings | 事前計算済みのembeddings列を使う | 独自モデル、外部モデル、既存ベクトルを使いたい |
| Direct Vector Access Index | APIやSDKで直接upsert/deleteする | アプリ側でベクトル更新を制御したい |
注意すべき点は、self-managed embedding indexをDatabricks-managed indexへ後から変換できないことです。後で管理方式を変えたい場合は、新しいインデックスを作成し、embeddingsを再計算する必要があります。 (Microsoft Learn)
最初の検証ではDatabricks管理のembeddingsを使うと構築が簡単です。一方、本番運用でモデルの一貫性、コスト、他システムとの互換性を重視するなら、self-managed embeddingsも検討対象になります。特に複数環境で同じ検索品質を再現したい場合や、特定の業界用語に最適化した埋め込みモデルを使う場合は、自前でembeddingsを管理するほうが説明しやすいケースがあります。
設定変更で確認すべきポイント
今回の公式情報を踏まえると、管理者が見るべき設定は大きく5つあります。
Unity Catalogと権限
AI SearchインデックスはUnity Catalog上に表示され、Unity Catalogの権限管理の対象になります。所有者以外のユーザーがインデックスをクエリするには、カタログへのUSE CATALOG、スキーマへのUSE SCHEMA、AI SearchインデックスへのSELECTが必要です。 (Microsoft Learn)
また、AI Search endpoint ACLでは、CAN CREATE、CAN USE、CAN MANAGEといった権限で、エンドポイント取得、一覧表示、作成、インデックス作成、削除、権限変更の可否が整理されています。 (Microsoft Learn)
本番環境では、検証ユーザーに広くCAN MANAGEを付けるのではなく、次のように分けると事故を減らせます。
| 権限設計 | 推奨例 |
|---|---|
| エンドポイント作成 | Databricks管理者または基盤チームに限定 |
| インデックス作成 | データプロダクト単位の管理者に限定 |
| クエリ実行 | アプリ実行用サービスプリンシパルに付与 |
| 権限変更 | 最小人数の管理者に限定 |
| 検証環境 | 本番とは別のendpointとusage policyを使う |
Change Data Feed
Standard endpointsでDelta Sync Indexを使う場合、ソーステーブルにChange Data Feedが必要です。既存のDeltaテーブルを検索対象にする場合、CDFが有効かどうか、過去データの扱い、更新頻度、削除データの反映方法を事前に確認してください。 (Microsoft Learn)
RAG用のナレッジテーブルでは、文書本文だけでなく、文書ID、バージョン、公開日、部署、機密区分、URL、言語などのメタデータも重要です。検索結果をLLMへ渡すだけでなく、回答の根拠表示、アクセス制御、古い文書の除外に使うためです。
同期方式
Continuous syncはソースDeltaテーブルの変更を継続的に反映しますが、その分コストが高くなりやすい点に注意が必要です。Triggered syncはSDKやREST API、UIから同期を開始する方式です。Standard endpointsではContinuousとTriggeredの両方で差分更新が行われますが、Storage-optimized endpointsではTriggeredのみがサポートされ、同期時にインデックスの一部再構築が発生します。 (Microsoft Learn)
| データ更新の性質 | 同期方式の考え方 |
|---|---|
| FAQや規程が1日数回更新される | Triggeredで十分な場合が多い |
| チャットボットが最新問い合わせ履歴を即時参照する | Continuousを検討 |
| 大規模データを夜間バッチで更新する | Storage-optimized + Triggeredを検討 |
| コストを厳密に抑えたい | Continuousの常時コストを見積もる |
| 検索品質評価を定期実行する | 同期後に評価ジョブを組み込む |
認証方式
Databricks AI Searchは、サービスプリンシパルと個人アクセストークンに対応しています。公式情報では、本番アプリケーションではサービスプリンシパルの利用が推奨され、PATと比べてクエリごとのパフォーマンスが最大100ms改善する可能性があると説明されています。 (Microsoft Learn)
本番環境でPATを使い続けると、退職者アカウント、期限切れ、権限過多、トークン漏えい時の影響範囲が問題になりやすくなります。アプリケーションからAI Searchを呼び出す場合は、サービスプリンシパルを標準にし、トークン管理をKey VaultやDatabricks secretsなどの運用ルールに組み込むべきです。
コスト管理
AI Searchの課金対象は、検索用vectorsを保存するindexと、クエリを処理するendpointです。公式のコスト管理ガイドでは、1つのendpointに複数のindexを載せられ、endpointあたり最大50 indexまで対応するため、小規模ワークロードを統合すると総コストを抑えられる場合があると説明されています。 (Microsoft Learn)
また、High QPSはStandard endpointsのみPublic Previewで利用でき、target_qpsを設定すると追加容量がプロビジョニングされます。この追加容量は実際のトラフィック量に関係なく課金対象になり、Public Preview中のスループットスケーリングはベストエフォートです。 (Microsoft Learn)
コスト面で失敗しやすいのは、検証用に作ったendpointやindexを放置するケースです。AI Search endpointはindex作成後に課金され、最後のindex削除から24時間後に課金が止まると説明されています。検証後はindex削除、endpoint棚卸し、usage policyの付与、課金テーブルの確認を運用に入れてください。 (Microsoft Learn)
移行期限はあるのか
2026年6月26日時点で確認できる公式情報の範囲では、Databricks Vector SearchからDatabricks AI Searchへの名称変更に伴う、既存リソースの強制移行期限や廃止期限は明示されていません。したがって、直ちに既存のendpointやindexを作り直すというより、名称変更に伴うドキュメント、運用手順、権限、SDK、API、監視項目の棚卸しを行うのが現実的です。
ただし、注意すべき移行・見直しポイントはあります。
| 確認対象 | 見直す理由 | 対応方針 |
|---|---|---|
| 社内ドキュメント | Vector SearchとAI Searchが混在する | 用語対応表を追加する |
| IaC・Bundle定義 | 公式例にvector_search_endpointsが残る | 公式スキーマ名を優先し、独自に改名しない |
| REST API | /vector-search/パスが使われる | API仕様を確認してから変更する |
| SDK | databricks-ai-searchパッケージを使う | 古いサンプルコードを更新する |
| 監視・課金タグ | endpoint名やusage policyが古い可能性 | チーム、用途、環境で命名規則を整理する |
| セキュリティ | PAT利用や広い権限が残る | サービスプリンシパルと最小権限へ寄せる |
移行期限が見つからないから何もしない、という判断は危険です。名称変更のタイミングは、設計と運用の前提を見直す好機です。特にAI SearchはRAGアプリの回答品質と権限管理に直結するため、古い検証コードや暫定トークンを本番に残さないことが重要です。
制限事項と失敗しやすいポイント
Databricks AI Searchは強力ですが、制限を理解せずに設計すると、後から作り直しが発生しやすい機能でもあります。
公式情報では、_idは予約済み列名であり、ソーステーブルに_id列がある場合はインデックス作成前にリネームが必要です。また、行・列レベル権限はサポートされておらず、必要に応じてアプリケーション側ACLをfilter APIで実装する考え方が示されています。さらに、index容量は作成時のソーステーブルサイズに基づいてプロビジョニングされるため、小さいテーブルで作って後から大きく伸ばすと容量不足になる可能性があります。 (Microsoft Learn)
| 失敗しやすいポイント | 起きる問題 | 予防策 |
|---|---|---|
| 小さなサンプルテーブルで本番indexを作る | 後から容量不足になりやすい | 想定データ量に近いテーブルで設計する |
_id列を残す | インデックス作成前にエラーになる | ソーススキーマを事前チェックする |
| 行レベル権限を前提にする | 見せてはいけない文書が返る設計になる | アプリ側ACLとfilter設計を行う |
| すべての列を同期する | コスト、レスポンス、情報漏えいリスクが増える | 返却・フィルターに必要な列だけを選ぶ |
| Continuous syncを安易に選ぶ | 常時コストが増える | 更新要件から逆算する |
| PATを本番アプリに埋め込む | セキュリティ運用が難しくなる | サービスプリンシパルへ移行する |
| Storage-optimizedを容量だけで選ぶ | CMKやContinuous sync要件に合わない | 制限事項を先に確認する |
クエリAPIにも制限があります。たとえば、ANN検索の最大返却件数は1クエリあたり10,000件、hybrid keyword-similarity searchとfull-text searchの最大返却件数は200件、レスポンスサイズは10MBです。大量件数を返してアプリ側で絞り込む設計ではなく、メタデータフィルター、ページネーション、検索対象列の設計で最初から必要な結果に寄せるべきです。 (Microsoft Learn)
RAGアプリでの実践的な設計例
社内文書検索チャットをAzure Databricksで構築する場合、Databricks AI Searchは次のように使えます。
| 設計項目 | 推奨例 |
|---|---|
| ソース | Unity Catalog配下のDeltaテーブル |
| 主キー | 文書チャンクID |
| 本文列 | チャンク化したテキスト |
| メタデータ | 文書ID、部署、公開日、機密区分、URL、言語 |
| embeddings | まずDatabricks管理で検証し、本番で自社モデル要件を評価 |
| 検索方式 | 通常質問はhybrid、ID検索はFULL_TEXTを検証 |
| フィルター | 部署、権限、公開状態、言語で絞る |
| 同期 | 文書更新が日次ならTriggered、頻繁ならContinuousを検討 |
| 認証 | アプリ用サービスプリンシパル |
| 評価 | 正解文書がtop-kに入るか、回答に根拠が含まれるかを測る |
この構成で重要なのは、検索結果の「意味的な近さ」だけを評価しないことです。RAGでは、次の観点で評価する必要があります。
| 評価観点 | チェック内容 |
|---|---|
| Recall | 正解文書が検索結果に含まれるか |
| Precision | 不要な文書が混ざりすぎていないか |
| 権限 | ユーザーが見られない文書が返らないか |
| 鮮度 | 古い規程や廃止済みFAQが上位に来ないか |
| レイテンシ | チャット応答として許容できるか |
| コスト | 同期、embedding生成、endpoint課金が予算内か |
| 説明性 | 回答に出典や文書IDを付けられるか |
特にグローバル企業では、言語、地域、部門ごとの権限差が出やすくなります。日本語、英語、中国語などが混在するナレッジでは、検索方式ごとの精度を分けて評価し、単一のtop-k設定で全言語を処理しようとしないほうが安定します。
管理者向けチェックリスト
Databricks AI Search – Azure Databricksを利用中、またはこれから検証する管理者は、次の順に確認すると抜け漏れを減らせます。
| 確認項目 | チェック内容 |
|---|---|
| 用語整理 | Vector SearchとAI Searchの対応を社内資料に反映したか |
| 前提条件 | Unity Catalog、Serverless compute、CDF、CREATE TABLE権限を確認したか |
| endpoint設計 | StandardかStorage-optimizedかを容量・同期・制限で選んだか |
| index設計 | 主キー、本文列、metadata列、embedding方式を決めたか |
| 同期方式 | ContinuousとTriggeredのコスト・鮮度差を評価したか |
| 権限 | endpoint ACL、Unity Catalog権限、アプリ側ACLを分けたか |
| 認証 | 本番アプリからPATを排除し、サービスプリンシパルを使う設計にしたか |
| コスト | usage policy、課金テーブル、未使用endpointの棚卸しを用意したか |
| 制限 | _id列、行・列レベル権限非対応、レスポンス10MB制限を確認したか |
| 品質評価 | hybrid、FULL_TEXT、reranking、filtersの効果をテストしたか |
| 運用 | 同期失敗、検索品質低下、権限変更時の確認手順を用意したか |
まず取るべきアクション
Databricks AI Searchの更新ポイントは、名称変更だけでなく、RAGやセマンティック検索をAzure Databricks上で本番運用するための設計項目が明確になったことです。既存のVector Search利用者は、強制移行期限がある前提で慌てて作り直すのではなく、まず名称、API、SDK、権限、コスト、同期方式の棚卸しを行ってください。
これから導入する場合は、最初にStandard endpointで小さくRAG検証を行い、検索品質、権限、同期コストを測定します。そのうえで、大規模データや専用フルテキスト検索が必要になった段階でStorage-optimized endpointsを検討するのが現実的です。
最終的には、Databricks AI Searchを「LLMに渡す文書を探す部品」とだけ見ないことが重要です。検索品質、データ鮮度、アクセス制御、コスト管理がそろって初めて、RAGアプリは業務で使える品質になります。
コメント