OmniRetrievalとは？テキスト・テーブル・知識グラフを横断検索する新フレームワーク

テキスト・リレーショナルテーブル・知識グラフなど異質な情報源を、各ソースのネイティブ形式を保持したまま自然言語で横断検索できる
ソース選択・ネイティブクエリ生成・証拠統合の3段階パイプラインで、既存RAGの「テキスト均質化」問題を解決
13データセット・309の知識ベースで評価し、単一ソース特化のベースラインを上回るソース選択精度65.71%を達成

研究の背景

実際のビジネス現場では、情報は一箇所にまとまっていません。製品仕様書はテキスト文書として、売上データはリレーショナルデータベースのテーブルとして、組織間の関係性は知識グラフとして、それぞれ異なる形式で管理されています。

従来のRAG（Retrieval-Augmented Generation）は、こうした多様なデータをすべてテキストに変換してベクトル化する方式が主流でした。しかし、SQLのJOIN演算や知識グラフの多ホップ推論など、構造化データが本来持つ表現力が変換の過程で失われてしまいます。この「テキスト均質化」の問題を解決するために提案されたのがOmniRetrievalです。

企業のデータサイロ問題は深刻で、情報統合の難しさがAI活用の障壁になるケースは少なくありません。Gleanのような企業向けAI検索が急成長している背景にも、この課題があります。OmniRetrievalはそこに対して、ソース固有の構造を壊さないという別のアプローチで応えます。

3段階パイプラインの仕組み

図1: 左側に3種類の異質な知識ソース（テキスト・テーブル・グラフ）と各クエリ言語、右側にOmniRetrievalのソース選択・クエリ生成・証拠統合の3段階パイプライン全体図

OmniRetrievalは自然言語のクエリを受け取り、以下の3段階で回答を導き出します。

第1段階: ソース選択（Source Selection） — 長いコンテキストを扱えるLLMが、登録されたすべての知識ベースの構造情報（スキーマやオントロジーの概要）を一度に読み込み、質問に適したソースをランク付けします。単一のソースに絞り込むのではなく、最大k個の候補を保持することで、曖昧な質問でも柔軟に対応できます。

第2段階: ネイティブクエリ生成（Query Formulation） — 選ばれた各ソースに対して、そのソース固有のクエリ言語でクエリを生成します。リレーショナルデータベースにはSQL、RDF形式の知識グラフにはSPARQL（グラフデータを扱う標準クエリ言語）、ラベル付きプロパティグラフにはCypher（Neo4jなどで使われるグラフ専用のクエリ言語）、テキストコーパスには自由形式の検索クエリを使います。こうして各ソースの表現力を最大限に引き出します。

第3段階: クロスソース証拠統合（Evidence Selection） — 複数ソースから得られた結果（SQL行、RDFトリプル、グラフパス、テキスト段落）をLLMが横断的に評価し、質問への回答に最も適した証拠を選別します。異なる形式の結果をそのまま扱えるため、変換による情報ロスが生じません。