こんにちは。エンジニアの大橋です。
以前、Text Embedding（テキスト埋め込み）について書いたブログの中で、ハイブリッド検索について簡単に触れました。いきさつを簡単におさらいすると、Sentence Embeddingでは文全体の意味を表現できる一方、特定の単語やキーワードに対する類似度は考慮されにくい傾向があるため、その解決策としてハイブリッド検索が使われる、ということでした。
ハイブリッド検索は、ベクトル検索とキーワード検索の結果を加味して最終的な順位を決定し、検索結果を返します。RAGでプロンプトに何らかのデータを組み込む場合でも、ベクトル検索ではなくハイブリッド検索が使われることは少なくありません。
例として、カスタマーサポートで過去の問い合わせ履歴を検索するケースが挙げられます。ここでは、「製品Aの電源が入らない」という検索に対し、「製品A」という型番はキーワード検索で確実に捉えつつ、「電源が入らない」に関連する「起動しない」「故障」といった文脈はベクトル検索で拾いたい、のような要件が求められます。このように、固有名詞の一致と意味的な類似検索の両立が必要な場面で、ハイブリッド検索が活用されます。
そんな便利なハイブリッド検索ですが、実際にベクトル検索とキーワード検索がどのように統合されているのか、あまり意識せずに使っていないでしょうか？なんとなく、ベクトル検索とキーワード検索の結果を「良い感じにブレンドしてくれる」というイメージではないでしょうか？少なくとも私はそのような印象を持っていました。
そこで今回は、Data 360のハイブリッド検索において、「ベクトル検索（意味）」と「キーワード検索（単語）」が、それぞれどのくらい最終的な検索順位に影響を与えているのかを検証してみました。「良い感じにブレンドしてくれる」というブラックボックスの中身を、実際の検索挙動から確認してみたいと思います。
※本検証は2025年12月時点のものです
検証の目的
まずは、改めて検証の目的を明確にしたいと思います。冒頭でも触れた通り、Data 360のハイブリッド検索において、「ベクトル検索（意味）」と「キーワード検索（単語）」が、それぞれどういったバランスで最終的な検索順位に影響を与えているのかを確認することが目的です。
事前準備
検証データ
検証データとして、2パターンのデータセットを用意しました。
データセット①:キーワードと意味の「ねじれ」における優先度
まず、「意味は合致するが、主要なキーワード（固有名詞）が欠けているケース」と、「意味は異なるが、主要なキーワードが含まれているケース」を対比させ、どちらが上位にランクされるかを確認します。
検索クエリ:「Salesforce 事例」
| ID | 内容 | 狙い・特徴 |
|---|---|---|
| DOC-001 | A社の導入事例（SFA導入で成約率向上…） | 意味〇 / キーワード△ 内容は「Salesforceの事例」そのものだが、「Salesforce」という固有名詞が含まれていない。 |
| DOC-002 | Salesforce CRMの初期設定マニュアル | 意味× / キーワード△ 内容は事例ではないが、「Salesforce」というキーワードが明記されている。 |
ID,Body DOC-001,世界シェアNo.1の顧客管理クラウドプラットフォームを採用し、営業プロセスを刷新したA社の変革事例です。SFA導入により商談の進捗が可視化され、成約率が20%向上しました。従来のExcel管理からの脱却に成功しています。 DOC-002,Salesforce CRMの基本設定とライセンス体系について解説します。Salesforce CRMを導入する際の初期セットアップ手順、およびCRMの権限セットの割り当て方法は以下の通りです。Salesforce活用の第一歩です。
データセット②:各要素の組み合わせによるスコア変動
次に、キーワードと意味の合致状況を3パターン用意し、それぞれのスコア（ベクトル、キーワード、ハイブリッド）がどのように変化するかを観察します。
検索クエリ:「Data Cloud リアルタイム」
| ID | 内容 | 狙い・特徴 |
|---|---|---|
| DOC-101 | Data Cloudのリアルタイムデータストリーム解説 | 両方高い キーワードも意味も完璧に合致。 |
| DOC-102 | ストリーミングAPIの解説 | 意味〇 / キーワード× 意味は合致するが、「Data Cloud」「リアルタイム」というキーワードを含まない（類語を使用）。 |
| DOC-103 | プロジェクト定例会の案内 | 意味× / キーワード〇 意味は無関係だが、「Data Cloud」「リアルタイム」というキーワードを含む。 |
ID,Body DOC-101,Data Cloudのリアルタイムデータストリームを利用することで、Webやモバイルの顧客行動をミリ秒単位で取り込み、即座にプロファイルを更新・有効化できます。 DOC-102,ストリーミングAPIを活用し、ユーザーのアクティビティ情報を遅延なくプラットフォームに統合する仕組みです。サイト訪問と同時にオファーを提示する即時性の高い体験を実現します。 DOC-103,次回のData Cloudプロジェクト定例会はリアルタイム連携機能の実装スケジュール調整を行います。参加者は会議室Aに集合してください。
データ取り込み・DLO・DMO・検索インデックス
先ほどの検証データをData 360に取り込み、DLO/DMO/検索インデックスを作成します。データ取り込みからDMO作成までの手順には、特に特筆すべき点はないため割愛します。
DMO作成まで完了したら、データセット①と②のDMOについて、検索インデックスを以下の設定値でそれぞれ作成します。
- 検索インデックス
- 検索種別:ハイブリッド検索
- ソースオブジェクト:作成済みのDMO
- チャンク
- フィールド:Body
- チャンク戦略:Passage Extraction
- 埋め込みモデル
- Multilingual E5 Large Embedding Model
ハイブリッド検索用SQLの作成
検索インデックスの作成まで完了したので、ハイブリッド検索用のSQLを作成します。
基本的なSQLの構文はベクトル検索のpre-filteringについて書いたブログに記載の通りですが、ハイブリッド検索の場合は以下の点が異なります。
まず、From句では、ベクトル検索ではvector_search 関数を使用しますが、ハイブリッド検索の場合はhybrid_search関数を使用します。それ以外の引数については同じです。
続いて、SELECT句では、取得可能な項目に違いがあります。ベクトル検索の場合は、score__cでベクトルスコアを取得できます。一方、ハイブリッド検索では、hybrid_score__cでハイブリッドスコア、keyword_score__cでキーワードスコア、vector_score__cでベクトルスコアをそれぞれ取得できます。
上記の変更点を考慮し、作成したSQLは以下になります。
SQL①:データセット①（検索クエリ:Salesforce 事例）
「Salesforce 事例」というキーワードに対する、データセット①のハイブリッド検索結果を取得します。
SELECT dmo.ID__c, hybrid_score__c, keyword_score__c, vector_score__c, chunk.Chunk__c FROM hybrid_search( TABLE(Search_Experiment_Data_Hybrid_index__dlm), 'Salesforce 事例', '', 5 ) index Join Search_Experiment_Data_Hybrid_chunk__dlm chunk ON index.RecordId__c = chunk.RecordId__c Join Search_Experiment_Data__dlm dmo ON chunk.SourceRecordId__c = dmo.id__c
SQL②:データセット②（検索クエリ:Data Cloud リアルタイム）
同様に、「Data Cloud リアルタイム」に対する、データセット②の検索結果を取得します。
SELECT dmo.ID__c, hybrid_score__c, keyword_score__c, vector_score__c, chunk.Chunk__c FROM hybrid_search( TABLE(Search_Experiment_Data2_index__dlm), 'Data Cloud リアルタイム', '', 5 ) index Join Search_Experiment_Data2_chunk__dlm chunk ON index.RecordId__c = chunk.RecordId__c Join Search_Experiment_Data2__dlm dmo ON chunk.SourceRecordId__c = dmo.id__c
検証結果
作成したSQLをData 360の「クエリエディター」で実行した結果は以下となります。
検証①:SQL①の結果
検証②:SQL②の結果
検証③:SQL②の検索クエリを「Data Cloud リアルタイム API」に変更した場合の結果
結果から読み取れること
※本検証は少量のデータセットを用いた簡易的なものです。実際のデータ分布やクエリによって結果は異なる可能性がありますが、ハイブリッド検索の挙動における一つの傾向として、チューニング時の参考にしていただければ幸いです。
一連の検証から読み取れることは以下の通りです。
(1)「キーワードスコア」より「ベクトルスコア」の方が重みは大きい
ハイブリッドスコアへの貢献度を考えると、「キーワードスコア」よりも「ベクトルスコア」の方が重みは大きいことが分かります。
根拠:
- 【事実】 検証②の
DOC-101とDOC-103を見てください。DOC-101に注目すると、DOC-103よりキーワードスコアは0.052小さく、ベクトルスコアは0.016大きいです。単純にスコアを足し算するならDOC-101が負けるはずですが、最終的なハイブリッドスコアではDOC-101が勝っています。 - 【考察】 これは、「ベクトルスコアの0.016ポイント勝ち」が「キーワードスコアの0.052ポイント負け」よりも高く評価された、つまりベクトルの寄与度（重み）の方が大きいことを示しています。
(2)「ベクトル」のスコアは、トピックの一致に影響されやすい
ベクトル検索は、トピックが共通していれば、本来の検索意図と異なるデータにも比較的高い点数を与えてしまい、意味的に近いデータとの差がつきにくい傾向があります。
根拠:
- 【事実】 検証①を見てください。
DOC-001（事例紹介）とDOC-002（マニュアル）に対し、検索ワードは「Salesforce 事例」です。意味的にはDOC-001が正解ですが、実際には不正解であるDOC-002とのベクトルスコア差はわずか0.017となっています。 - 【考察】 これはおそらく、
DOC-002も「Salesforce」というトピック自体は共通しているため、広義には関連性が高いと判定されたためと思われます。また、DOC-001には「Salesforce」という重要単語が含まれていなかったことも、スコアが拮抗した一因と考えられます。
(3) 「キーワード」のスコアは差がつきやすい
キーワード検索は「あるか・ないか」がはっきり出るため、スコア差が激しくなることが分かります。
根拠:
- 【事実】 検証②の
DOC-102を見てください。Data Cloudというキーワードはないものの、プラットフォームのストリーミング機能について言及されていることは明白です。ですが、検索ワードが「Data Cloud リアルタイム」のため、結果的にキーワードスコアは0となっています。
(4) 「キーワード」がないと、「意味は違うがキーワードは含まれる」データが上位にランクされる逆転現象が起きる
ベクトルスコアの差がつきにくく、キーワードスコアの差がつきやすいという傾向から、「キーワードの有無」が最終的なスコアに大きく影響を与えることを示しています。
根拠:
- 【事実】 検証①を見てください。「Salesforce 事例」という検索ワードに対し、
DOC-001（事例紹介）はベクトルスコアでわずかにリードしています。しかし、キーワードスコアではDOC-002（マニュアル）が圧倒しています。その結果、「意味は異なるがキーワードは同じ」データが、「意味は同じだがキーワードは（あまり）含まれない」データのハイブリッドスコアを大きく上回りました。 - 【考察】
DOC-001は意味的に正解であるにもかかわらず、ベクトルスコアでのリードはごく僅かでした。その結果、キーワードスコアでついた大きな差を埋めきれず、トータルの順位で逆転を許してしまったと言えそうです。
(5) 検索クエリの意味の広さ（密度）によって、ベクトルスコアは大きく変動する
AIの「意味理解」も、実はキーワード（単語の具体性）に依存しています。
根拠:
- 【事実】 検証③を見てください。検索クエリを「Data Cloud リアルタイム」から「Data Cloud リアルタイム API」に変更すると、
DOC-102のベクトルスコアが「0.819」から「0.844」に上がっています。 - 【考察】
DOC-102の本文に「API」というキーワードが含まれているため、意味的にも近いと判断された側面はありそうです。しかしそれ以上に、「リアルタイム」という広義な意味を持つキーワードに「API」を追加することで、技術的な意味であるという文脈が加わり、ベクトルスコアが上がったと思われます。
公式見解と実装時のポイント
検証結果から得られた挙動を、公式情報と照らし合わせて整理します。
Salesforce Engineering Blogによると、Data 360のハイブリッド検索は、単純なスコアの加算ではなく、正規化や順位ベースの評価（RRFなど）を含む複雑なロジックで統合されています。
先述の通り、今回の検証データは限定的ですが、検証結果から見えた「理論上の重み設定に関わらず、キーワードの有無が最終順位に決定的な影響を与える可能性がある」という傾向は、実装時に意識しておくべきポイントと言えます。
これを踏まえ、実装時には以下の3点を意識する必要があります。
(1) キーワード検索の「強さ」を前提にする
「ベクトル検索が表記揺れを吸収してくれる」と過信せず、キーワード一致によるスコア変動（0か1か）が順位を大きく左右することを前提に設計する必要があります。
(2) クエリに「文脈」を含める
検証結果のように、「リアルタイム」という広義な単語だけでなく、「API」のような文脈を特定する単語を含めることで、ベクトルスコア（意味の合致度）を有効に機能させることができます。
(3) パフォーマンスとのトレードオフ
今回の検証結果の通り、ハイブリッド検索の結果セットには vector_score__c（ベクトルスコア）も含まれます。つまり、検索結果を取得した後、アプリケーション側でこの vector_score__c を使って並び替えれば、実質的に「意味類似性の高さ」順にデータを提示することも可能です。
「それなら、常にハイブリッド検索を使っておけば良いのでは？」と思うかもしれません。しかし、そこにはパフォーマンスとのトレードオフが存在します。ハイブリッド検索は内部的に「キーワード検索」と「ベクトル検索」の両方を実行し、その結果を統合する処理を行っているため、純粋なベクトル検索と比較して計算コストやレイテンシが高くなる傾向があります。「キーワード検索の要素は不要」な場合や、「パフォーマンスを重視したい」という要件であれば、ハイブリッド検索ではなく、純粋なベクトル検索を選択するのが賢明でしょう。
なお、実際のデータ量に対してハイブリッド検索とベクトル検索でどの程度のパフォーマンス差が出るのかは興味深いため、別の機会があれば調査してみたいと思います。
最後に
ここまで、Data 360のハイブリッド検索について検証してきました。
キーワード検索とベクトル検索をなんとなく「良い感じに統合してくれる」と思っていたハイブリッド検索に対して、今回の検証でその特徴を理解してもらえれば幸いです。
以上となります。最後までお読みいただき、ありがとうございました。
