OceanBaseのハイブリッド検索：ベクトル検索・全文検索・フィルタリングを1つのSQLで

AIアプリケーションの検索基盤では、ベクトルデータベース、リレーショナルデータベース、検索エンジンを組み合わせる構成がよく使われます。PoCの段階では合理的に見えるこの構成も、本番運用に入ると、データ同期の遅延、検索処理の複雑化、運用負荷の増大といった課題が顕在化します。

OceanBaseは、V4.4.1からハイブリッド検索をサポートしています。V4.6.0では、SQLから直接利用できるHYBRID_SEARCHインターフェースを追加しました。ベクトル検索、全文検索、スカラー値によるフィルタリングを1つのSQLに集約し、複数のシステムに分散していた検索処理をデータベース内で実行できます。

本記事では、RAG向けナレッジベースを例に、ハイブリッド検索が解決する課題と、その使い方、適したユースケースを解説します。

---

ベクトル検索と全文検索、それぞれが見落とす情報

社内ナレッジベースに、次の4件のドキュメントがあるとします。

※上記は検索方式の違いを説明するためのサンプルです。

ここで、ユーザーが**「OceanBaseベクトルインデックス」**と検索した場合を考えてみましょう。

• ベクトル検索は、意味の近さをもとにドキュメントを探します。「ベクトルインデックス」と「ベクトル検索」の関連性を捉え、ドキュメント1、3、4を見つけられます。一方、ドキュメント2のような一覧形式の資料は、文章による説明が少なく、意味の類似性だけでは検索しにくいことがあります。検索語がそのまま含まれていても、見落とす可能性があるのです。
• 全文検索は、キーワードの一致をもとにドキュメントを探します。「ベクトルインデックス」を含むドキュメント2と3を見つけられますが、同義語への対応がなければ、「ベクトル検索」という表現を使ったドキュメント1と4を取りこぼす可能性があります。

このような場合、両者を組み合わせたハイブリッド検索なら、それぞれが見落としたドキュメントを補い、4件すべてを検索候補に含められます。

キーワード検索は表現の違いに弱く、意味にもとづく検索は、専門用語が一致するドキュメントを見落とすことがあります。両者を組み合わせることで、それぞれの弱点を補えます。

さらに、「ベストプラクティスに絞り込む」「著者の信頼度順に並べる」という条件を加えると、必要な処理は増えていきます。

• カテゴリの絞り込みには、構造化フィールドを対象としたスカラーフィルタリングが必要です。
• 著者の信頼度が別のauthorsテーブルに保存されている場合は、テーブル間の**結合（JOIN）**も必要です。

複数のシステムを組み合わせる場合、条件に合うIDをリレーショナルデータベースで取得し、検索時に指定する方法が考えられます。また、取得した検索結果をアプリケーション側で絞り込み、著者情報と照合する方法もあります。

いずれもシステム間の連携が必要になり、処理が複雑になります。クエリが増えることで応答時間が延び、データの更新タイミングの違いによって不整合が生じる可能性もあります。

---

本番運用で表面化する3つの課題

1. 検索結果の統合処理がアプリケーションに集中する

ベクトルデータベースから上位20件、検索エンジンから上位20件を取得したとして、その後の処理はどうするのでしょうか。

アプリケーション側では、重複を取り除き、2つの検索結果を統合して、最終的な順位を決める必要があります。採用する方式によっては、スコアの正規化も必要です。

結果の統合によく使われるのが、**RRF（Reciprocal Rank Fusion）**です。各検索結果での順位をもとに、$1 / (\text{rank_constant} + \text{rank})$ で算出した値を加算し、最終的な順位を決めます。元のスコアを直接比較しないため、ベクトル距離とBM25スコアのように尺度が異なる検索結果も統合できます。

課題は、重複排除から結果の統合、並べ替えまでをアプリケーション側で実装し、保守しなければならないことです。コードと調整項目が増え、統合方法を変更するたびに再デプロイが必要になる場合もあります。

2. システムが増えるほど、運用と障害対応の負担が増す

ベクトルデータベース、リレーショナルデータベース、検索エンジンを個別に運用すると、監視、バックアップ、スケーリング、セキュリティ設定も、それぞれに必要になります。

さらに、システム間のデータ連携には、CDC、ETL、メッセージキューなどを使った同期の仕組みが必要です。稼働状況を監視する対象も、バージョンアップ時に影響を確認する対象も増えていきます。

コンポーネントが増えるほど、運用対象だけでなく、障害が起こり得る箇所も増えます。

3. 検索結果に古い業務データが残る

業務データベースで価格や公開状態、文書の内容を更新しても、その変更がベクトルデータや全文検索インデックスにすぐ反映されるとは限りません。

整合性を保つには、更新を各システムへ伝える同期パイプラインが必要です。そのパイプライン自体も、運用・監視の対象になります。

同期が遅れれば、販売を終了した商品が検索結果に表示されたり、古い価格が参照されたりします。RAGでは、更新前の情報をもとにAIが回答してしまう可能性もあります。

---

OceanBaseなら、検索処理を単一のSQLに集約できる

OceanBase V4.6.0のSQLインターフェースでは、ベクトル検索、全文検索、スカラーフィルタリングを組み合わせ、データベース内で実行できます。

ベクトルも、同じテーブル内の列として管理する

OceanBaseでは、ベクトルデータも、テキストや数値と同じテーブルに保存できます。

たとえば、次の列を1つのテーブルに定義できます。

• ベクトル：embedding VECTOR(1536)
• 本文：content TEXT
• 価格：price DECIMAL
• カテゴリ：category VARCHAR
• タグ：tags JSON

このテーブルに、用途に応じてベクトルインデックス、全文検索インデックス、検索インデックス（Search Index）を作成します。

検索から結果の統合までをまとめて実行する

検索には、HYBRID_SEARCH()を使います。ベクトル検索、全文検索、フィルタ条件、結果の統合方法をまとめて指定できます。

各指定の役割は、次のとおりです。

ベクトル検索にも同じカテゴリ条件を適用する場合は、knn.filterにも条件を指定します。

従来の構成では、ベクトルデータベースと検索エンジンの両方にリクエストを送り、結果をアプリケーションで統合する必要がありました。OceanBaseでは、データベースへの1回の問い合わせで、検索から結果の統合まで実行できます。

---

データ管理とアプリケーション構成はどう変わるか

• データの整合性を、同じトランザクションで管理できます。
  業務データと対応するベクトルデータを同じトランザクションで更新することで、データベース間の同期処理が不要になります。ACIDトランザクションによって、両方のデータをまとめて更新できます。なお、内容の変更に合わせて埋め込みベクトルを再生成する処理は別途必要です。
• 複数の検索方式を、共通のインターフェースで利用できます。
  ベクトル、テキスト、業務データを同じデータベースに保持し、HYBRID_SEARCHでベクトル検索、全文検索、スカラーフィルタリングを組み合わせられます。
• システム構成をシンプルにできます。
  アプリケーションが複数の検索システムを使い分ける構成から、OceanBaseに検索を集約する構成へ移行できます。個別に運用する検索システムや、その間をつなぐ同期パイプラインを減らすことで、運用負荷も軽減できます。

---

実践：RAGのドキュメント検索に活用する

RAGでは、ユーザーの質問に関連するドキュメントを検索し、LLMに渡します。

たとえば、ユーザーが**「OceanBaseの分散トランザクションは、どのように整合性を保証するのか」**と質問した場合を考えてみましょう。

複数の検索システムを組み合わせる場合

代表的な処理の流れは、次のようになります。

1. 質問を拡張する：LLMで元の質問から3〜5個の関連質問を生成し、検索の取りこぼしを減らします。
2. ベクトル検索を実行する：各質問をベクトル化し、意味が近いドキュメントをそれぞれ上位20件取得します。絞り込みが必要な場合は、ベクトルデータベースのフィルタ機能を使います。対応していなければ、検索結果を取得してから絞り込む必要があります。
3. 全文検索を実行する：質問からキーワードを抽出し、各クエリで上位20件を取得します。こちらにも、必要に応じて絞り込み条件を指定します。
4. 業務データと照合する：カテゴリや著者情報など、ベクトルデータベースや検索エンジンだけでは処理できない条件がある場合は、リレーショナルデータベースから必要な情報を取得し、アプリケーション側で照合します。
5. 結果を統合する：検索結果の重複を取り除き、RRFなどで最終的な順位を決めます。
6. 上位5件を返す：関連性の高い上位5件をLLMに渡します。

ハイブリッド検索を使う場合

OceanBaseでは、ベクトル検索と全文検索、検索対象の絞り込み、結果の統合と件数指定を1つのSQLにまとめられます。

titleとcontentの両方を全文検索の対象にする場合は、それぞれに全文検索インデックスを作成します。

ベクトル検索で表現の異なる関連ドキュメントを探し、全文検索で製品名や専門用語に一致するドキュメントを補います。両者の結果は、rank.rrfとknn.boostを使った重み付きRRF（WRRF）で統合できます。

パラメータは、たとえば次のように設定します。

• 距離指標にコサイン距離を使う：テキストの意味にもとづく検索でよく使われる選択肢です。使用する埋め込みモデルに合う指標を選びます。
• k = 20 で候補を多めに取得する：ベクトル検索でまず20件を取得し、全文検索の結果と統合したうえで、最終的に上位5件に絞ります。
• boost = 1.5 でベクトル検索の重みを上げる：意味の近さを重視したい場合の設定例です。キーワードの完全一致が重要な用途では、実際の検索結果を見ながら重みを調整します。

---

パラメータ調整の目安

検索処理を1つのSQLにまとめても、用途に応じた調整は必要です。代表的な調整項目を以下に示します。

---

ハイブリッド検索が適しているユースケース

OceanBaseのハイブリッド検索は、特に次のような要件に適しています。

• 複数の検索方式を組み合わせたい
  RAG向けナレッジベースや、ECサイトのマルチモーダル検索などが該当します。たとえば、「この画像に似た商品を、指定した価格帯かつ在庫ありの条件で探す」といった検索です。
• 業務データと検索用データの整合性を重視したい
  金融、取引、リスク管理など、業務データとベクトルデータを同時に更新し、整合性を保ちたい用途に適しています。
• 運用するシステムを減らしたい
  ベクトルデータベース、検索エンジン、リレーショナルデータベースを個別に保守する負担を減らし、検索基盤を集約できます。
• 今後の検索要件の追加に備えたい
  当初はベクトル検索だけでも、後からキーワード検索や属性による絞り込みが必要になることがあります。同じデータベース上で、段階的に検索機能を拡張できます。

ベクトル検索だけを検証するPoCであれば、専用のベクトルデータベースも有効な選択肢です。ただし、本番利用が進むと、製品型番の完全一致、価格帯の指定、在庫の有無による絞り込みなど、自然言語の意味だけでは対応できない要件が増えていきます。

こうした要件を見据えると、ハイブリッド検索は検索品質の改善だけでなく、システム構成を考えるうえでも有力な選択肢になります。

---

OceanBaseは、V4.4.1のPLインターフェースに続き、V4.6.0でHYBRID_SEARCH()によるSQLインターフェースを提供しました。ベクトル検索と全文検索で取りこぼしを補い、検索処理を1つのSQLに集約し、検索用データと業務データを同じトランザクションで更新できます。

意味にもとづく検索とキーワード検索の両方が必要なAIアプリケーションでは、OceanBaseのハイブリッド検索を活用してみてください。