OceanBase AIが実現するRAGパイプラインの全体像

前回の記事「AI時代のデータベースはどう進化するのか。ベクトル検索だけでは足りない」では、アーキテクチャと価値の観点から、OceanBase AI がマルチモデル統合アプローチを採用する理由を解説しました。1 つのデータベースで業務データ、ベクトル、全文検索、AI 呼び出しを扱い、SQL によってデータからインテリジェンスまでの流れをつなぐ、という考え方です。

本記事では、このコンセプトを実際の技術フローとして実現する方法を掘り下げます。RAG（Retrieval-Augmented Generation）やハイブリッド検索の導入を検討している開発チームが直面する具体的な課題は、以下のような点です。

• 外部ドキュメントをデータベース内にどのように取り込むか
• ドキュメントの分割、埋め込み、インデックス作成をどの機能で実現するか
• SQL上でハイブリッド検索をどのように構築するか
• 検索結果をリランキングやLLMによる推論処理にどうつなげるか

これらの処理が複数のシステムやスクリプトに分散すると、一体化は単なる概念に留まります。一方、同一データベース内で一連の処理を完結できれば、検証可能で運用性の高いエンジニアリングソリューションとして実現できます。

そこで本記事では、典型的な AI データパイプラインを軸に、「取り込み → 分割・エンベディング → 保存・インデックス作成 → ハイブリッド検索 → リランキング・回答生成」という6つのフェーズに分けて解説します。各フェーズで解決すべき課題、OceanBase AI が提供する技術的な支援、そして各ステップ間の依存関係を説明します。

---

AI ワークフロー全体像

表 1：AI ワークフロー全体像

---

技術的実装の詳細

図1：ワークフロー（青色はデータ形式およびユーザー・モデルに関する処理、白色は各段階で使用されるOceanBaseの技術を示す）

1. ドキュメントの取り込み

RAGアプリケーションを構築するうえで、最初に必要になるのは、外部ドキュメントをデータベースで扱える状態にすることです。ここが整ってはじめて、後続のチャンク分割、埋め込み、検索に進めます。

PDF、Markdown、Office文書などがオブジェクトストレージやファイルシステムに置かれているだけで、まだデータベースの管理対象になっていない場合、その後のチャンク分割、ベクトル化、ハイブリッド検索を同一エンジン内で完結させることはできません。多くのチームでは、まずETLでコンテンツを中間システムに取り出し、その後ベクトルデータベースへ同期します。そのため、RAGの処理フローは最初の段階から長くなりがちです。

OceanBase AIは、データベース側でドキュメントを取り込む機能を備えています。外部ファイルを取り込んだうえで、そのまま統一されたチャンク分割・インデックス作成のフローに組み込めます。ファイルの内容、業務テーブル、ベクトルデータを同じデータベースドメインに格納できるため、いったん外に取り出してから再度取り込むような往復は不要です。データベースが対応する形式であれば、ファイルをそのままデータベース内に取り込めます。対応していない形式は、アプリケーション側で解析したうえで、データベース内のチャンク分割・埋め込み処理に渡せます。ドキュメントを取り込んだ時点で統一されたデータプレーンに組み込まれ、その後のRAG処理をデータベース内で継続して実行できます。

2. チャンク分割と埋め込み

ドキュメントの解析が終わっても、それだけではセマンティック検索には使えません。長い文書をそのまま扱うのは難しいです。モデル側には適切な粒度のテキストチャンクが必要ですし、検索側には計算可能なベクトル表現が必要です。

チャンク分割と埋め込みを外部スクリプトや独立したサービスに任せる構成もあります。ただ、その場合はドキュメント形式や埋め込みモデルを追加するたびに、別のパイプラインを構築しなければなりません。結果として、RAGの準備段階における開発運用コストが増えていきます。

OceanBase AIでは、チャンク分割と埋め込みをSQLから実行できます。AI_SPLIT_DOCUMENT 関数は、長いテキストを検索に適したチャンクへ分割します。この処理はデータベース内で完結するため、モデルを登録する必要はありません。AI_EMBED 関数は、各チャンクをベクトルに変換し、後続のANN検索に使える入力を生成します。

セマンティックインデックスを利用する場合は、原文の書き込み時にデータベース内で埋め込みを自動生成することもできます。そのため、アプリケーション側で同じ処理を何度も実装する必要がありません。これにより、RAGの準備段階は「スクリプトによるジョブ制御＋複数サービスの連携」から、「データの書き込み＋関数の呼び出し」へとシンプルになります。処理フローが短くなるだけでなく、業務データの書き込みフローともつなぎやすくなります。

3. ストレージとインデックス作成

ベクトル検索で十分なパフォーマンスを得るには、ベクトル検索だけでは不十分です。業務データに対するフィルタリングも欠かせません。部門、日時、ステータス、権限などのスカラー条件は、セマンティックな類似度と組み合わせて使われます。これらは、検索結果が実際に利用可能かどうかを左右する重要な条件です。

ベクトルデータと業務データが別々のシステムに保存されている場合、検索時には複数のデータベースから結果を取得し、それらを組み合わせる必要があります。さらに、データ更新時には両者の整合性も別途確保しなければなりません。

OceanBase AIでは、業務テーブル、原文またはチャンク、ベクトルデータを同じデータベースに格納できます。必要に応じて、ベクトルインデックス（HNSW系など）、全文インデックス（Analyzer／分かち書き器を含む）、セマンティックインデックス（自動埋め込み）、スカラー値／JSONのフィルタリングに対応した検索インデックスを作成できます。

データとインデックスは、同一クラスタ、同一のトランザクションセマンティクスのもとで管理されます。これにより、ハイブリッド検索や権限によるフィルタリングのための統一基盤を提供できます。AI用途のために、別のストレージや同期基盤を用意する必要もありません。

4. ハイブリッド検索

ユーザーからの質問には、セマンティックな理解とキーワードの完全一致という、2種類の要求が同時に含まれることが少なくありません。たとえば、固有名詞、製品型番、定型的な用語が使われる場合があります。また、特定の部門、期間、業務ステータスなどの条件を指定して結果を絞り込むケースもあります。

ベクトル検索だけでは、キーワードの完全一致を取りこぼす可能性があります。全文検索だけでは、同義表現を十分にカバーできません。さらに、スカラー条件によるフィルタリングだけでセマンティック検索を代替することもできません。

HYBRID_SEARCH 句を使うと、1つのSQLで全文検索、ベクトル検索、スカラー値／JSON／配列などによるフィルタリング条件を組み合わせられます。さらに、RRFなどの手法で検索結果を統合し、ランキングできます。ユーザーの質問をあらかじめクエリベクトルに変換し、データベース内のインデックスと組み合わせて検索することも可能です。

アクセス方法は、ネイティブSQLに加えて、SDKやLangChain、LlamaIndexなどのAIフレームワークにも対応しています。1回の検索で、セマンティックな類似性とキーワード一致を同時に考慮できます。さらに、業務上の制約条件も適用できます。そのため、実際の利用シーンに即した検索を実現できます。アプリケーション側で複数の検索結果を手作業で統合する負担も軽減できます。

5. リランキングと生成

ハイブリッド検索で取得した候補チャンクは、多くのケースで、そのままコンテキストとしてアプリケーションに表示したり、外部の大規模言語モデルに渡したりできます。

リランキングは、RAGを最小構成で動かすうえで必須のステップではありません。ただし、データベース内で検索結果の関連性をさらに高めたい場合や、データベース側でプロンプトの組み立てから大規模言語モデルによる推論まで行いたい場合には、この段階を追加できます。

特に、検索対象となる候補が多い場合や、複数の検索手法による結果を統合する場合、リランキングは最終的な検索精度を高める重要な手段になります。OceanBase AIでは、AI_RERANK 関数を利用し、取得したチャンクを関連性に基づいて再ランキングできます。

生成はRAGパイプラインの最後のステップです。OceanBaseでは、AI_PROMPT 関数を使ってユーザーの質問と検索結果をテンプレートに組み込み、その後 AI_COMPLETE 関数を呼び出すことで、自然言語による回答を生成できます。検索と推論はSQLとAI関数によって連携され、クエリに応じてプロンプトを動的に組み立てることも可能です。RAGの処理をデータベース内で完結させたいシナリオでは、このステップによって「検索 → 回答」という最後の処理まで補完できます。

まとめ

RAGパイプラインの効率は、どこまでの処理をデータベース内で完結できるかに大きく左右されます。外部システムとの受け渡しが増えるほど、同期処理は複雑になり、障害ポイントや構築・運用の負担も増えます。

OceanBase AIは、これまで複数のシステムに分散しがちだった処理を、単一のデータベース基盤に集約します。SQLと組み込み機能を軸に、データの取り込み、分割、埋め込み、検索、生成までを一連の流れとしてつなげられます。

システム境界が減ることで、構成と処理経路を把握しやすくなり、同期処理や障害対応もシンプルになります。また、パイプライン全体をエンドツーエンドで検証しやすく、開発・運用の負担軽減にもつながります。

OceanBase AIは、RAGに必要な処理を一体化し、技術チームが無理なく構築・運用できるように支援します。