構造化データと非構造化データを横断して推論するエージェント基盤のDatabricks、単発RAGを上回る新アーキテクチャを提示

Databricksは、企業向けAIエージェントが直面しやすい重要な課題として、構造化データと非構造化データをまたぐ複雑な問い合わせへの対応不足を挙げ、その解決策としてマルチステップのエージェント型アプローチの有効性を示しました。従来の単発RAGは、売上テーブルと顧客レビュー、学術論文の引用件数と論文本文のように、異なる形式の情報を組み合わせて答えを導く場面で性能が大きく落ちることが多く、Databricksはその原因をモデル性能ではなくアーキテクチャの限界にあると位置づけています。同社のAI研究チームは、StanfordのSTaRKベンチマークや自社のKARLBench評価フレームワークを用いて、マルチステップ型エージェントと最先端の単発RAG手法を比較しました。その結果、STaRKでは20％以上の性能向上が確認され、自社評価でも一貫した改善が見られたとしています。さらに、より高性能な基盤モデルを単発RAG側に適用して再検証しても、学術分野で21％、バイオメディカル分野で38％、マルチステップ型エージェントが上回ったと報告しています。

Databricksによれば、単発RAGは、厳密な条件指定が必要な構造化検索と、意味的な関連性を探す非構造化検索を一つの問い合わせの中で適切に分解できません。たとえば、過去3カ月で売上が落ちた製品を特定し、その原因として顧客レビューでどのような問題が指摘されているかを調べる場合、売上データはSQLやデータウェアハウスにあり、レビュー内容は外部サイト上の文書群に存在します。単発RAGでは、こうした問い合わせを二つの探索に分け、それぞれ適切なデータソースに振り分けたうえで結果を統合することが難しいとされています。この課題に対し、DatabricksはSupervisor Agentを本番実装として設計しました。この仕組みでは、まずSQL検索とベクトル検索を並列に実行し、その結果を統合して次の行動を判断します。初回の取得に失敗した場合には、問い合わせの内容を再構成して別の経路で再試行する自己修正機能も備えています。加えて、特定のデータセット向けに個別最適化するのではなく、各データソースが何を含み、どのような質問に答えるべきかを自然言語で記述する宣言的な設定方式を採用しており、新しいデータソースを追加する際にカスタムコードをほとんど必要としない点も特徴です。

Databricksは、この研究の本質は単なるハイブリッド検索ではなく、複数のツールにアクセスできるエージェント設計にあると説明しています。従来のカスタムRAGパイプラインでは、SQLテーブルをテキスト化したり、JSONを正規化したりして、検索基盤が読める形へ変換する作業が必要でした。しかし企業内データの種類が増えるほど、この変換と保守の負担が大きくなります。これに対し、エージェントが各データソースをネイティブな形式のまま扱える構成であれば、追加作業は接続設定と説明文の整備が中心となり、拡張性が大きく高まるというのがDatabricksの主張です。同社は、このアプローチが企業のAI実装に与える示唆として、構造化データと非構造化データをまたぐ問い合わせが中心になる場合、カスタムRAGを積み上げるよりも、宣言的なエージェントフレームワークを採用する方が現実的であると示しています。一方で、接続するデータソースを一度に増やしすぎると、エージェントの速度と信頼性が下がるため、まずは5〜10程度の相補的なデータソースから始め、段階的に拡張することが推奨されています。また、エージェントは形式の違いをまたいで問い合わせできますが、元データ自体の誤りを修正できるわけではないため、データ品質の確保は前提条件になります。

Databricksは、この研究を企業向けAIエージェントの発展に向けた初期段階と位置づけています。今後は、ダッシュボード、コードリポジトリ、外部データフィードなど、さらに多様な情報源をまたいで推論することが求められるとみられており、その拡張を設定の問題として扱える宣言的な設計が、実用的なスケールの実現に重要になるとしています。

Databricksについて
Databricksは、データ分析、機械学習、AIアプリケーション開発を統合するデータ・AI基盤を提供するテクノロジー企業です。大規模データ処理、データウェアハウス、生成AI、エージェント構築までを一つの環境で扱える点を強みとしており、企業が分散したデータ資産を活用して高度な分析やAI活用を進められるよう支援しています。