※ 本記事は、Andy Rivenesによる”Why We Built AI Vector Search“を翻訳したものです。
2026年11月4日
Oracle AI Vector Searchは、検索の種類をもう1つ増やしたいという考えから生まれたわけではありません。出発点は単純な問題でした。人が検索に使う言葉は、必要な情報に書かれている言葉と必ずしも一致するわけではではない、ということです。
従来の検索は、一致する単語、値、属性を探します。ユーザーが正確な用語を知っている場合には有効です。しかし、表現が異なると、役立つ情報を見逃すことがあります。たとえば「データベースのメモリ使用量を減らす方法」と検索しても、文書では「In-Memory列ストアのサイズ設定」と説明されているかもしれません。言葉は違っていても、意味には密接な関係があります。
AI Vector Searchは、その意味に基づいて検索するために設計されています。
意味で検索する
これを実現するため、埋込みモデルと呼ぶAIモデルが、テキスト、画像、音声、その他のコンテンツを、ベクトルという数値表現に変換します。ベクトルは元のコンテンツを置き換えるものではありません。似た意味を持つほかのコンテンツとの関係において、そのコンテンツがどこに位置するかを示す地図のようなものです。
ユーザーが質問すると、その質問も同種の数値表現に変換されます。データベースは、保存済みコンテンツから、質問に意味が最も近いものを探せます。検索モデルの選択も重要です。同じ意味空間で比較できるよう、保存するコンテンツとユーザーの質問には、同じ埋込みモデルを使う必要があります。
これによって、「この単語を含む文書を探す」体験が、「自分が尋ねていることに関連する情報を探す」体験に変わります。
この違いは、さまざまな場面で重要です。商品検索では、自然言語の説明から始めつつ、価格、在庫、場所、メーカーも考慮する必要があります。サポートアシスタントでは、質問の意図を理解しながら、顧客、製品、日付のフィルタを適用する必要があります。法律や金融の検索では、幅広いテーマを理解すると同時に、正確な会社名、商品コード、規制を見つける必要があります。
目的は従来の検索を置き換えることではなく、非構造化データから適切な情報を見つける別の方法を、アプリケーションに提供することです。
なぜデータベースに組み込むのか
企業情報の多くは、すでにデータベースにあります。顧客レコード、注文、在庫、文書、権限、業務ルールは、一緒に格納されていたり、データベースを通じて関連付けられていたりします。
情報を別の検索システムに移すと、コピーやパイプラインが増え、データアクセスとセキュリティ制御の管理で考慮すべきことも増えます。最新の業務情報を検索することも難しくなり得ます。別システムは文書の内容を把握していても、関連商品がまだ入手可能か、質問者に閲覧権限があるかまでは分からないかもしれません。 ベクトル検索を業務データと同じ場所に置けば、両方の種類の問いを組み合わせられます。意味の似た情報を検索しながら、通常の業務条件と、適用対象のデータベースアクセス制御を適用できます。
これが、Oracle AI DatabaseにAI Vector Searchを組み込んだ主な理由の1つです。価値は、データベースがベクトルを比較できることだけではありません。業務データ、関係、トランザクション、制御がすでに存在する同じ場所で比較できることに価値があります。
なぜ高速化に複数の方法が必要なのか
似たコンテンツを見つける最も直接的な方法は、質問と保存済みのすべてのベクトルを比較することです。完全な答えが得られますが、データが増えるにつれコストが高くなります。
従来のリレーショナル索引は、索引のデータ構造で「より小さい」「等しい」「より大きい」という概念を使い、完全一致や範囲の問合せを効率的に実行します。数値の集合であるベクトルには、「より小さい」「より大きい」という概念は適しません。代わりに、ベクトル間の距離を使います。この距離の計算は高コストなので、精度とパフォーマンスのトレードオフが必要です。これは意図的な選択です。多くのアプリケーションでは、厳密に最も近い結果を探すために長時間かけるより、十分に関連する結果を短時間で得る方が役立ちます。
オラクルは、そのための主な方法を2つ提供します。
- HNSW索引は、検索構造をメモリに保持します。高速な応答が重要で、利用可能なメモリに索引を余裕を持って収められる場合に有力な選択です。
- IVF索引は、ベクトルをグループに整理し、最も関連の深いグループを検索します。全体をインメモリ構造に収めるには大きすぎるデータ集合に適しています。パーティション化データや、より大規模な企業ワークロードでも有効です。
どちらかが常に優れているわけではありません。適切な選択は、データの規模、利用可能なメモリ、期待する応答時間、アプリケーションが必要とする精度によって変わります。
なぜ意味とキーワードを組み合わせるのか
セマンティック検索は強力ですが、大量のテキストデータに対して、それだけで十分とは限りません。 「ABC Corporationが関係する不正」について調べたいとします。セマンティック検索は不正や関連概念の理解に役立ちます。キーワード検索は、結果が実際にABC Corporationに関するものであることを確かめるのに役立ちます。
そこで役立つのがハイブリッド検索です。意味に基づく検索と、正確な単語に基づく検索を組み合わせ、両方の結果集合を統合して1つの順位を付けます。
名前、商品コード、専門用語、日付、組織など、曖昧に解釈すべきでない詳細を含む質問に、ハイブリッド検索は特に有効です。セマンティック検索は表現が異なる場合に探索範囲を広げ、キーワード検索は結果の焦点を保ちます。
大きな文書には、より丁寧な前処理も必要です。通常は、各部分が絞り込まれた考えを表し、AIモデルの制限内に収まるよう、小さい部分に分割します。小分けにすると関連性が高まることが多い一方、周辺の文脈を失うことがあります。文書単位のキーワード検索と、部分単位のセマンティック検索を組み合わせると、検索の関連性と文脈のバランスを取れます。文書を小さな部分に分割することをチャンキングと呼びます。適切なチャンキングと検索の戦略により、大きな文書での検索関連性を高められます。
RAGの位置付け
検索拡張生成（RAG）は、ベクトル検索の結果を使い、大規模言語モデルが回答するための関連する文脈を提供します。
言語モデルは多くのことを知っていても、企業の非公開情報や、社内文書の最新版を自動的に把握するわけではありません。RAGはまず組織のデータをベクトル検索し、最も関連する部分を選び、回答用の文脈として言語モデルに渡します。
モデルは、元の学習内容だけに頼らず、最新の業務固有の情報を使って自然言語で回答できるようになります。関連情報を適切に検索、利用すれば、裏付けのない回答や不正確な回答を減らし、非公開情報や変化する情報に依存する質問への回答を、より有用にできます。
回答の質は、検索した情報の質に大きく左右されます。結果が少なすぎると重要な事実が抜け、多すぎると無関係な情報が加わってモデルの注意がそれる可能性があります。目的は、有用で焦点の定まった少量のコンテンツを取得することです。ベクトル検索は、このプロセスを支える重要な役割を果たせます。
全体像
AI Vector Searchは、データベース、従来の検索、慎重なデータ設計を置き換えるものではありません。アプリケーションがデータを扱う方法に、意味を組み込む手段です。
AI Vector Searchは、いくつかの実践的な考えに基づいて開発しました。
- 検索は、単語の文字列の完全一致を超えて理解すべきです。
- 業務データと非構造化データを一緒に検索できるべきです。
- 速度と精度をアプリケーションに合わせて調整できるべきです。
- 企業の非構造化データが変わるとき、それを表すベクトルも同時に変更できるべきです。
- 大量のテキストデータでは、キーワード検索とセマンティック検索を連携させられるべきです。
- 検索された情報は、元のソースと業務上の文脈とのつながりを維持すべきです。
- 生成AIにすべてを自力で知ることを期待せず、関連する最新情報を与えるべきです。
その結果、より充実した検索アプローチが得られます。アプリケーションは、意味で情報を探し、業務ルールで絞り込み、適切に設定された既存のデータベースアクセス制御を適用し、AIが自然言語の応答を生成するための文脈として結果を提供できます。
企業データがすでに存在する場所で、AI検索を役立てること。それがAI Vector Searchを開発した理由です。