AIエージェントを構築するデータチームが、同じ失敗パターンに何度も行き当たっている。構造化データと非構造化コンテンツの結合を必要とする問い、たとえば売上数と顧客レビューを並べたり、引用数と学術論文を並べたりといった問いは、シングルターンのRAG（Retrieval-Augmented Generation）システムを壊してしまう。
Databricksの新しい研究が、その失敗のギャップに数値を与えている。同社のAIリサーチチームは、9つのエンタープライズ知識タスクにわたって、最先端のシングルターンRAGのベースラインに対し、多段のエージェント型アプローチをテストし、研究によれば、スタンフォードのSTaRKベンチマークスイートで20%またはそれ以上の向上を報告したという。さらに、Databricks自身のKARLBench評価フレームワークでも、一貫した改善が見られたとされている。Databricksは、ハイブリッドデータのタスクにおけるシングルターンRAGとマルチステップ・エージェントの間の性能ギャップは、モデル品質の問題ではなく、アーキテクチャ上の問題だと主張している。
この取り組みは、Databricksの以前のinstructed retriever研究に基づいている。この研究では、メタデータに配慮したクエリによって非構造化データの検索が改善することが示された。今回の研究は、同じ推論ループに構造化データソース、リレーショナルテーブル、SQLウェアハウスを追加し、企業が現在のエージェント・アーキテクチャでは最もよく答えられない問いのカテゴリに対処している。
「RAGは機能しますが、スケールしません」とDatabricksのリサーチディレクターであるMichael BenderskyはVentureBeatに語った。「エージェントをさらに良くしたい、そして売上が下がっている理由を理解したいのであれば、エージェントにテーブルが見えるようにし、売上データを参照できるようにする必要があります。そのタスクでは、あなたのRAGパイプラインは無能になってしまいます。」
シングルターンの検索では構造的制約をエンコードできない
中核となる発見は、標準的なRAGシステムが、構造化された厳密なフィルタと、オープンエンドのセマンティック検索を1つのクエリに混ぜたときに失敗する、という点だ。
たとえば「過去3か月で売上が落ちている当社の商品はどれで、さらに、さまざまな販売者サイトでの顧客レビューには潜在的に関連しそうな問題が何として挙げられているのか？」のような問いを考えてみよう。売上データはウェアハウスにある。レビューのセンチメントは、販売者サイト全体にわたる非構造化ドキュメントにある。シングルターンRAGシステムでは、この問いを分割し、各半分を適切なデータソースに振り分けて、結果を結合することができない。
これがモデル品質の問題ではなくアーキテクチャの問題であることを確認するために、Databricksは、最新の最先端基盤モデルを用いて、公開されているSTaRKのベースラインを再実行した。研究によれば、より強力なモデルであっても、多段のエージェントに対して、学術領域では21%、生物医学領域では38%負けていた。
STaRKは、スタンフォードの研究者が公開しているベンチマークで、3つのセミ構造化された検索領域を対象としている。Amazonの商品データ、Microsoft Academic Graph、そして生物医学の知識ベースだ。
RAGにできないことをSupervisor Agentはどう扱うのか
Databricksは、この研究アプローチを本番実装としてSupervisor Agentを構築しており、そのアーキテクチャは、タスクの種類をまたいで向上が一貫する理由を示している。このアプローチには、3つの主要ステップが含まれる：
並列ツール分解。1つの大きなクエリを投げて、その結果が構造化と非構造化の両方のニーズをカバーしてくれることを期待するのではなく、エージェントはSQLとベクトル検索の呼び出しを同時に実行し、その結合された結果を分析したうえで、次に何をするかを判断する。この並列ステップが、最初にデータを正規化する必要なく、データ型の境界をまたぐクエリを扱えるようにしている。
自己修正。 最初の検索の試みが行き詰まった場合、エージェントは失敗を検知し、クエリを言い換え、別の経路を試す。特定のトピックに関して事前出版がちょうど115本である著者による論文を見つけることが必要なSTaRKベンチマークのタスクでは、エージェントは最初にSQLとベクトル検索を並列で問い合わせる。2つの結果セットに重複がないことが分かると、適応して両方の制約を満たすSQL JOINを発行し、その後、答えを返す前にベクトル検索システムで結果を検証する。
宣言的な設定。 エージェントは、特定のデータセットやタスクに合わせて調整されているわけではない。新しいデータソースに接続するには、そのソースが何を含んでおり、どのような種類の問いに答えるべきかを、平易な言葉で説明するだけでよい。カスタムコードは不要だ。
「エージェントは、最初からSQLクエリと検索クエリに質問を分解する、といったことができます」とBenderskyは述べた。「SQLとRAGの結果を組み合わせ、それらの結果について推論し、追加の問い合わせを行い、そして最終的な答えが実際に見つかったかどうかを考察できます。」
それはハイブリッド検索だけの話ではない
Databricksが引いている区別は、検索手法の違いではなく、アーキテクチャの違いだ。
「私たちは、埋め込みと検索結果を組み合わせるような“ハイブリッド検索”として、ほとんど捉えていません。あるいは埋め込みとテーブルを組み合わせる、といったものとして見ているわけでもありません」と彼は言う。「私たちはむしろ、複数のツールにアクセスできるエージェントとして見ています。」
この枠組みの実務上の帰結は、新しいデータソースを追加するには、それをエージェントに接続し、含まれている内容を説明するだけでよい、という点だ。エージェントは追加のコードなしに、ルーティングとオーケストレーションを処理する。
カスタムRAGパイプラインでは、データを検索システムが読める形式に変換する必要がある。通常は、埋め込みを伴うテキストのチャンクだ。SQLテーブルはフラット化し、JSONは正規化しなければならない。パイプラインに追加する新しいデータソースの数だけ、変換作業が増える。Databricksの研究は、エンタープライズのデータがより多くのソースタイプを含むように成長していくにつれて、その負担によって、ネイティブ形式のまま各ソースにクエリを投げるエージェントと比べて、カスタムパイプラインがますます現実的でなくなると主張している。
「ただ、エージェントをデータに連れてくればいいんです」とBenderskyは言った。「基本的には、エージェントにより多くのソースを渡せばよく、エージェントはそれらをかなりうまく使えるようになります。」
これがエンタープライズにもたらすもの
データエンジニアが、カスタムRAGパイプラインを構築するか、宣言的なエージェント・フレームワークを採用するかを評価する際、研究は明確な指針を提示している。つまり、そのタスクが構造化データと非構造化データにまたがる問いを含むなら、カスタム検索を作ることはより困難な道である。研究では、テストしたすべてのタスクにおいて、デプロイ間で異なっていたのは指示とツールの説明だけであり、それ以外はエージェントが処理していたことが分かった。
実務上の限界はあるが、管理可能だ。 このアプローチは、5〜10のデータソースでうまく機能する。一度にあまり多く追加し、相補的であるのに対して矛盾しているわけではないソースをうまく見極めないと、エージェントが遅くなり、信頼性も低下する。Benderskyは、利用可能なすべてのデータを最初に接続するのではなく、段階的にスケールし、各ステップで結果を検証することを勧めている。
データの正確さは前提条件だ。 エージェントは、形式が食い違うデータをまたいで問い合わせができる。たとえば、SQLの売上テーブルとJSONのレビュー配信を組み合わせても、正規化を要求せずに行える。事実に誤りがあるソースデータを修正することはできない。取り込み（ingestion）時に各データソースの内容を平易な言葉で説明しておくと、エージェントは最初からクエリを正しく振り分けられるようになる。
この研究は、これをより長い軌道における初期ステップとして位置づけている。エンタープライズのAIワークロードが成熟するにつれて、エージェントには、ダッシュボード、コードリポジトリ、外部データフィードなど、数十種類のソースタイプをまたいで推論することが求められるようになるだろう。この研究は、そのスケーリングを現実的にするのが宣言的アプローチであると主張している。というのも、新しいソースを追加することが「エンジニアリングの問題」ではなく「設定の問題」に留まるからだ。
「これは梯子みたいなものです」とBenderskyは言った。「エージェントは徐々に、より多くの情報を得て、その後、全体として徐々に改善していきます。」
