本動画は、従来の埋め込みベースのセマンティック検索と、ファイル操作を駆使するAIエージェントによる探索を組み合わせた、新しい「エージェント型ファイル検索システム」を解説するものである。RAG（検索拡張生成）における精度の限界を打破するため、エージェントがドキュメント間をバックトラッキングして参照関係を追跡する仕組みや、Geminiを活用したスマートなチャンキング、メタデータ抽出、そしてそれらを統合したハイブリッドな検索パイプラインの構築手法について、デモを交えて詳細に紹介している。
次世代のRAG：エージェントによるファイル探索の試み
コーディングエージェントは、RAG（検索拡張生成）における最大の課題を解決できるのでしょうか。これが、私の新しいエージェント型ファイル検索システムで探求しようとしているテーマです。アイデアは非常にシンプルです。埋め込みベースのセマンティック検索を使う代わりに、単純な検索ツールを使って同レベルの精度を得ることはできないか、という問いです。今日のコーディングエージェントは、コードスニペットの検索を行う必要がありますが、実際にはファイル操作やコード実行といった非常に単純なツールを使用しています。
私は、セマンティック検索コンポーネントを一切使わず、単純なファイルベースの操作だけで検索を行う非常によく似たシステムを構築しました。しかし、埋め込みベースの検索にもそれなりの利点があります。では、なぜそれらを組み合わせることができないのでしょうか。それこそが、まさにこのビデオで行うことです。これは、エージェント型ファイル検索に関するシリーズの3番目のビデオになります。
このプロジェクトはすでにオープンソース化されており、GitHubで500近いスターを獲得しています。もし気に入っていただけたら、ぜひスターをお願いします。このシステム全体がどのようにセットアップされているかをより深く理解するために、他の2つのビデオも視聴することを強くお勧めします。大まかには3つのフェーズがあります。第1フェーズは、私が「パラレルスキャン」と呼んでいるものです。
これは単純に全ドキュメントの冒頭部分を読み込み、ユーザーのクエリに基づいて、どのドキュメントが最も関連性が高いかを特定しようとします。次に、候補となったドキュメントに対して「ディープダイブ」を行います。例えば、最初のスキャンで100個のドキュメントから10個に絞り込んだとしましょう。その後、各ドキュメントをLLM（大規模言語モデル）に送信して深く掘り下げます。しかし、ここからが通常のRAGシステムでは達成できない、最も素晴らしい部分です。
バックトラッキングによる精度の向上
多くの場合、このステップだけでは十分ではありません。関連するドキュメントを見逃してしまう可能性があるからです。そこで、第3フェーズの「バックトラッキング」が登場します。このシステムは非常に賢く、別のドキュメントへの参照を見つけると、最初の2つのフェーズで漏れていたとしても、戻ってそのドキュメントを読みに行くことができます。
これは、特許のような法的文書を扱う実世界のアプリケーションにおいて極めて重要です。特許は他の特許や、別の文書にある図面を参照したりするからです。このシステムを使えば、ドキュメントに関するドメイン知識をエージェントに提供することができ、エージェントはドキュメントを遡ってクロスリファレンス（相互参照）を行うことが可能になります。
これは実社会で非常に役立ちます。ただし、大きな欠点もあります。すべてのドキュメントを読み込まなければならないため、非常に低速なのです。そのため、リアルタイムのアプリケーションにはあまり向いていません。そこで、何人かの方から「これをフィルタリングのステップとして、通常の伝統的なRAGと組み合わせることはできないか」という質問をいただきました。このビデオでは、まさにその手法について見ていきます。
デュアルパス検索パイプラインの仕組み
今回は「デュアルパス検索パイプライン」を使用します。その仕組みを説明しましょう。既存のセットアップでは、すべてのドキュメントをMarkdown形式にするための「docling」による解析を除いて、事前の処理は一切行っていませんでした。しかし、今回の新しいセットアップでは「スマートチャンキング」という概念を導入します。
基本的には、チャンキングを使用してすべてのドキュメントをサブドキュメントに分割します。そして埋め込み（エンベディング）を計算します。現在はそのためにGeminiを使用しています。それと同時に、各ドキュメントからメタデータも抽出します。このメタデータはユーザーが定義することもできますし、システムが自動的に抽出することも可能です。
メタデータ抽出には、Geminiを搭載した情報抽出ライブラリである「lang-extract」を使用しています。これについては以前のビデオで紹介しましたので、ぜひそちらもご覧ください。最終的に、すべてはDuckDBに書き込まれます。作成されるコーパスには4つの異なるテーブルがあります。1つ目はメタデータ付きのオリジナルドキュメント、2つ目は作成されたチャンク、3つ目は埋め込み、そして4つ目がスキーマです。
これらはシステムによって定義された、あるいはユーザーから提供されたメタデータフィールドです。メタデータがユーザー定義であれ、LLMによって自動抽出されたものであれ、これは実世界のアプリケーションにおいて極めて重要です。例えば、請求書のデータセットがある場合、LLMに特定の情報を抽出させたいでしょう。それをメタデータフィールドとして作成すれば、通常のエージェント型検索システムに投入する前に、ドキュメントのフィルタリングに利用できるのです。
クエリ実行時のシステム動作
クエリが入力された時のシステムの動きは以下の通りです。ユーザーからのクエリが届くと、設定されたモードに基づいて、複数の異なるパスで同じクエリを実行します。これについては後ほど詳しく説明します。セマンティック検索のパスがあり、メタデータベースのフィルタリングパスがあります。これはチャンク単位ではなく、実際のドキュメント単位でフィルタリングを行います。
その後、重複を除去してエージェント型ファイル検索に送ります。これにより、エージェントが扱う検索範囲を絞り込むことができ、スピードが大幅に向上します。このセットアップの素晴らしい点は、最初のステップでの検索精度をそれほど心配しなくてよいことです。なぜなら、その後の大部分はエージェントが適切に処理してくれるからです。
このシステムには4つの動作モードがあります。1つ目は、純粋な「エージェント型検索」です。これは以前のビデオで紹介したもので、基本的にはエージェントと利用可能なシンプルなツールを使って、探索的に検索を行います。ちなみに、このアイデアは「ハーネスエンジニアリング（harness engineering）」という新しい分野から着想を得ました。
ここでの考え方は、エージェントに特定のタスク専用のツールではなく、汎用的なツールを与え、硬直化したワークフローに頼るのではなく、エージェントが自ら問題を解決するためにそれらを活用できるようにするというものです。このトピックに興味がある方は、現在ビデオを制作中ですので、ぜひチャンネル登録をお願いします。2つ目のモードは、セマンティック検索を事前フィルタリングとして使用するものです。チャンクレベルでセマンティック検索を行いますが、エージェント型ファイル検索のステップにはドキュメント単位で渡されます。これらは、CLIで実行する際にシンプルなフラグで有効・無効を切り替えられます。
3つ目のモードは、エージェントに渡す前に特定のドキュメントをメタデータに基づいてフィルタリングする機能のみを有効にするものです。そして最後のモードは、すべてを有効にすることです。提供されたメタデータに基づいたフィルタリング、セマンティック検索の両方を行い、候補となるドキュメントをエージェントに渡します。現時点では、コンテキストウィンドウが最も長く、ハヤブサの針（needle in a haystack）問題を解くのが得意なGeminiモデルをすべてに使用していますが、他のプロバイダーを使いたい場合は変更も可能です。
インストールと実際のデモ
インストールプロセスについて説明します。非常に簡単です。リポジトリをクローンして、コマンドを実行して依存関係をインストールするだけです。商用モデルを使用する場合は、Geminiモデルの使用を強くお勧めします。GeminiのAPIキーが必要になります。また、ローカルモデルで実行できる別ブランチのバージョンもあります。ただし、エージェントが多くのツールを使い、多段階のプロセスをこなす必要があるため、小規模なオープンウェイトモデルではあまりうまくいかないことが分かりました。最低でも32B（320億パラメータ）クラスのモデルをお勧めします。これについてもビデオを作りましたので、興味があれば概要欄をチェックしてください。
実行には2つのモードがあります。1つはCLIで、フォルダを指定して質問をする方法。もう1つはWeb UIで、情報を検索するためのウェブインターフェースです。では、Webインターフェースでの検索がどのように見えるかお見せしましょう。
こちらがインターフェースの画面です。まず、フォルダを選択します。今回は11個のドキュメントが入ったフォルダを選びました。デモとして素早くお見せするためです。ドキュメントを初めてインデックス化する際、この画面が表示されます。一度インデックス化すればファイルシステムに保存されるので、再度実行する必要はありません。
いくつかのオプションがあります。セマンティック検索を使いたい場合は、埋め込みを生成する必要があるので、ここをクリックします。また、カスタムスキーマを定義することもでき、これはドキュメントレベルのスキーマとなります。ドキュメントの性質が分かっている場合には非常に役立ちます。例えば、請求書データなら、支払先、金額、日付、住所などを「lang-extract」で抽出するように設定できます。
ここでスキーマを定義するか、「オートディスカバリー（自動検出）」を使うこともできます。これはシステムがいくつかのドキュメントを読み込み、どのような種類のドキュメントが存在し、どのような情報を抽出できるかを自動的に特定しようとする機能です。例えば、私が提供したドキュメントは企業買収に関する法的文書です。システムはこれが買収に関するものだと認識し、関連性が高いと思われるメタデータフィールドを自動的に抽出しようとします。これを実行してから、必要に応じて修正を加えることができます。
実践的なドキュメント解析と要約
設定が終わったらインデックス作成を開始します。このプロセスの間に、ドキュメントの解析が行われ、すべてが標準化されます。次にメタデータが抽出されますが、ここでも標準化処理が行われます。例えば、あるドキュメントでは「財務的影響（financial impact）」という言葉を使い、別のドキュメントでは別の言葉を使っているかもしれません。システムはこれらの正規化プロセスを実行し、抽出されたメタデータに重複がなく、統一されたフィールドが使われるようにします。
準備が整ったら、ドキュメントがインデックス化され、検索を開始できます。ここでは各コンポーネントを個別に有効・無効にできます。例えば、セマンティック検索、メタデータ、エージェント型パイプラインのすべてを有効にしてみましょう。ここで「リスクアセスメントのPDFファイルを要約して」と入力すると、システムはエージェント型であるため、何をすべきかを自動的に判断します。
シンプルなRAGのセットアップであれば、PDFファイル全体を要約するのは難しいかもしれません。しかし、このシステムの場合、まず第1フェーズでセマンティック検索を開始し、対象となるPDFファイルのインデックス内容とメタデータを素早く取得します。ファイル名レベルでのセマンティック検索も行われます。
そして対象のPDFファイルを見つけると、「優先順位付けされたリスク要因、緩和戦略、財務的影響の要約を抽出するためにドキュメント全体を取得します」と判断します。自動的にドキュメント全体を読み込み、Gemini APIに送信して、ドキュメント内の各セクションへの適切な参照（リファレンス）を含んだ詳細なアセスメント結果を返してくれます。これは非常に強力な仕組みです。
このデザインパターンは極めて強力であり、検索拡張生成（RAG）に興味がある方にはぜひチェックしていただきたいものです。ただし、これはまだプロダクション（本番）環境向けのシステムではないという点は覚えておいてください。他にもいくつか試しているアイデアがあります。もし、ご自身のアプリケーションのためにRAGシステムの構築で助けが必要な場合は、ぜひ私に連絡してください。喜んでお手伝いします。詳細はビデオの概要欄にあります。
このビデオが皆さんのお役に立てば幸いです。ご視聴ありがとうございました。それではまた次回のビデオでお会いしましょう。
コメント