8,005 文字
リトリーバル拡張生成システム（RAG）について誰もが気になる質問は、どのチャンキング戦略を使うか、最適な埋め込みモデルは何か、そして最適なベクトルストアは何かということです。OpenAIにはその答えがあります。彼らは最近、人間が情報を読む方法を模倣した新しいマルチエージェントのリトリーバル拡張生成システムを導入しました。
そしてこれはインデックスフリーです。つまり、チャンキング戦略や埋め込みモデルの選択について心配する必要がなくなりました。これはすべて、GPT-4.1のような100万トークンのコンテキストウィンドウを持つ長文コンテキストモデルによって可能になりました。彼らは基本的に、マルチエージェントシステムと長いコンテキストウィンドウを組み合わせて、非常に優れた検索結果を得る方法を見つけ出しました。
しかしこのシステムは万人向けではありません。素晴らしい結果が得られる特定のユースケースがあります。この新しいシステムの長所と短所、そしていつ使うべきかについて話していきましょう。この新しい技術は、「実世界のユースケースのためのモデル選択実践ガイド」というブログ記事で紹介されました。
このブログでは、異なるLLMによって動作するマルチエージェントシステムを使用して、実世界で機能する堅牢なシステムを構築する方法が示されています。彼らが議論しているユースケースの一つは、長文の法律文書に対する複雑な質問応答で、長文コンテキストのリトリーバル拡張生成システムを使用しています。このビデオでは、このシステムがどのように機能するかをお見せします。
具体的なコード例を見て、また実際の例を通じて、どのように自分のワークフローでこれを使い始めることができるかを説明します。アプローチの仕組みは非常に高いレベルでは次のようになります。まず文書を取り、最初のパスでは文書に目を通します。
アイデアとしては、文書の構造を見て、それを管理しやすいサブセクション、例えば章に分け、どの章がユーザーのクエリに関連しているか、そうでないかを特定したいということです。このように、文書に目を通すだけでチャンクや章のサブセットを単純に破棄することができます。
そして、関連性があると特定された章やセクションについては、同じプロセスを繰り返すことができます。各セクションをサブセクションに分割し、システムは各サブセクションを見て、高いレベルで関連性があるかどうかを判断します。関連性がなければ破棄します。このプロセスを複数の深さで繰り返します。
これはユーザーによって制御されるハイパーパラメータです。最終的に、サブセクションが得られます。これらは段落であり、システムが回答を生成するために使用されます。そして最後に検証ステップがあり、生成している回答が実際に選択したテキストに基づいているかを確認します。
これによりシステムが幻覚を起こしていないことが保証されます。これらの各ステップはサブエージェントとして扱うことができ、それぞれに異なる能力を持つLLMが必要です。それがまさにOpenAIチームがここで提案していることです。実装の観点から見た詳細なアーキテクチャの内訳は次のとおりです。
最初のステップは、最初の段階の高レベル分解で何章欲しいか、または何チャンク欲しいかを判断することです。彼らは20の同じサイズのチャンクを使用することを推奨しています。唯一の条件は、各チャンクが有効な文で終わるべきだということです。つまり、文書全体を20の異なる部分に分割し、GPT-4.1 miniのような長文コンテキストLLMを使用します。
あるいはGemini flashモデルを使用することもできますが、目標は長いコンテキストながら非常に安価なモデルを使用して、各チャンクを質問とともに見て、高レベルでこのユーザーの質問に基づいてこのチャンクから回答できるか、このチャンクにユーザーの質問に回答するために使用できる十分な情報が含まれているかを判断することです。
これらのサブドキュメントやサブチャンクを特定します。彼らはスクラッチパッドという概念を使用しています。これにより、推論モデルではないモデルでもこの評価プロセスを通じて推論する能力を得られます。これはとても興味深いアイデアなので、詳しく見ていきましょう。しかし最終的には、ユーザーの質問に回答するために使用できる可能性のあるドキュメントのサブセットまたはチャンクのサブセットが得られます。
これらの各サブチャンクについて、さらに細かく分解します。これは複数のステップからなるプロセスです。アイデアや目標は、正確な回答を提供するために使用できる特定の段落を特定することです。それらの段落を特定したら、GPT-4.1のようなより強力なモデルを使用して構造化された出力を生成します。
しかしそれは最終的な出力ではありません。また、O4 miniのような推論モデルを使用した検証ステップも必要です。これが審判として機能し、システムが生成した回答を検証または確認します。ご覧のように、これは事前に作成されたインデックスを使用せず、すべてのテキストをクエリごとに処理しています。
したがって、システムは非常に正確になりますが、すべてのアプリケーションにこのシステムを使用することはできません。例えば、シンプルなドキュメントとのチャットでは、はるかに高価で非常に遅くなります。しかし、レポート生成に取り組んでいて、レイテンシーが問題にならない事実データが必要な場合、これは非常に正確な検索システムの実装となり、本当に良い回答を提供します。
そのような例の一つが法律文書の閲覧です。これは商標審判上訴委員会の手続きマニュアルで、約1,200ページの文書です。これを特許庁での参考として使用できます。一つのアイデアは、この文書全体を長文コンテキストモデルのコンテキストに入れ、モデルが情報を取得できることを祈るというものですが、これは本当に難しいことです。
長文コンテキストモデルは通常、干し草の山からの針探しテストが非常に得意です。しかし、何らかの推論が関わる場合、特に複数の場所に含まれる情報を見つけ出そうとし、モデルが応答を生成するためにそれを通じて推論しなければならない場合、これらのモデルは実際に多くの苦労をします。
それではその例を見てみましょう。一般的なワークフローは次のとおりです。文書をロードし、20のチャンクに分割し、関連情報を含むチャンクをLLMに尋ねます。このプロセスを複数回実行します。定義する必要がある深さパラメータがあります。
ある深さに達したら、関連情報を使用して回答を生成し、検証ステップがあります。各ステージで異なるモデルを使用します。私が見てきたのは、人々がこれらのエージェントシステムを構築する際、Gemini 2.5 ProやO3シリーズ、あるいはGPT-4.1シリーズなどの最先端モデルを使用することが多いということです。
しかし、すべてのステップで最も強力なモデルを必要としないのです。「ワークホースモデル」という概念があり、これは比較的低コストで比較的低いレイテンシーで多くのトークンを処理できます。多くの推論を必要としないタスクには、これらの小型モデルが本当に有能であり、使用すべきです。
しかし、推論能力やより深い分析を必要とするタスクには、より大きなモデルや推論モデルを使用したいでしょう。パフォーマンス、精度、レイテンシーのバランスを見つける必要があります。では、このシステム全体がコードでどのように見えるかを簡単に説明しましょう。
彼らの実装に基づいてGoogle Collabノートブックをまとめました。最初のステップは文書をダウンロードすることです。ここでは920ページに制限しています。基本的にこれが文書をロードします。この文書を見ると、約1,200ページ、約60万語あり、これは約90万トークンに相当します。モデルのコンテキストよりも長い文書がある可能性があります。
例えば、文書に100万トークン以上ある場合は、それをサブドキュメントに分割し、それぞれに対して同じプロセスを並行して実行し、最終的な応答を生成してユーザーに表示したいでしょう。次のステップは、文書を同じサイズのチャンクに分割することです。
ここでテキストをトークン化します。その後、個々の文を選択し、それらの文を繰り返し追加して、同じサイズのチャンクを作れるかどうかを判断します。この分布を見ると、約33,000トークンのチャンクがあります。これはおそらく最小のチャンクで、最大のチャンクは62,000トークンまでです。
文書の構造、段落によって同じような範囲ですが、目標は比較的同じサイズの文書に分割することです。ここに一つのチャンクがあります。実際には文書やテキストの構造を保存していないことがわかります。
文書をマークダウンに分割し、そのマークダウン上でこのチャンキングプロセスを行うこともできます。これがフローの見え方です。文書を20のチャンクに処理します。次に、特定した各チャンクを見て、ユーザーが尋ねている質問に答えるためにそのチャンクを使用できるかどうかを判断したいと思います。
ここでコンテンツルーティングのステップが登場します。これがメイン関数です。ユーザーの質問とともにすべての個々のチャンクを取得します。そして、このプロセスをユーザーの質問ごとに繰り返す必要があります。これは比較的高価なプロセスになります。こちらがシステムプロンプトです。
「あなたは専門的な文書ナビゲーターです。あなたの任務は、ユーザーの質問に答えるための情報を含む可能性のあるテキストチャンクを特定することです。後で参照するために、あなたの推論をスクラッチパッドに記録してください。最も関連性が高い可能性のあるチャンクを選んでください。選択的かつ徹底的に行ってください。質問に答えるために必要な数のチャンクを選択し、まず質問に答えるのに役立つ情報が何かを慎重に考え、次に各チャンクを評価してください。」
彼らはここでスクラッチパッドというアイデアを導入しています。これは「あなたの作業を示す：言語モデルによる中間計算のためのスクラッチパッド」という論文で紹介されました。Entropicは基盤LLM企業として初めてこのアイデア全体を普及させました。そのアイデアは、推論モデルを使用していなくても、推論モデルではないモデルでも行っている作業をチェックするよう指示できるということです。
この場合、スクラッチパッドは内部思考のためだけです。すべてのチャンクを取得し、このスクラッチパッドをツールとして使用します。基本的にはテキスト文字列で、LLMは特定のチャンクが特定の質問に関連していると考える理由や推論を追加し、それを更新する能力も持っています。
LLMにツールとしてスクラッチパッドを提供し、出力はこの非常に特定のJSONスキーマに従います。関連性があると考えるチャンクのIDと、LLMに提供されるスクラッチパッドツールに基づく推論を提供し、分析している各チャンクに対してツールとしてスクラッチパッドを使用することを確認します。
モデルに対していくつかの呼び出しを行います。まず、すべてのチャンクを個別に分析します。関連情報をスクラッチパッドに入れます。次に、それを使用して初期パスで返されたチャンクを選択します。このプロセスを再帰的に行う必要があります。
仕組みとしては、最初に文書の実際のテキストを提供します。最小トークンサイズは500トークンです。これをチャンクに分割します。次に、同じ関数を再帰的に呼び出して、ユーザーとしてコントロールする特定の深さに達するまで、より小さなサブセクションにさらに分割します。
最終的な出力は段落のリストになります。すべてをまとめると、こんな質問です。「発見遵守のための申立はどのような形式で提出すべきか？署名はどのように扱われるべきか？」まず、その再帰的分解関数を呼び出します。結果を取得すると、この再帰的分割または分割統治がどのように見えるかがわかります。
最初に文書を20のチャンクに分割します。次に、各チャンクを通じて推論し、最も関連性が高いと思われる5つのチャンクを選択しました。これはスクラッチパッドからの推論です。次に、サブチャンクの一つを取り、さらに小さなチャンクに分割します。
再び20のチャンクです。こちらは別のもの、そしてもう一つです。このプロセスが繰り返されます。これは推論の2番目の深さです。これを続けることもできます。こちらは別のものです。40,000トークンの代わりに、サブチャンクをはるかに小さなトークンに分割していることがわかります。
これらの最終チャンクがどれだけ小さくなるかにも制限があります。停止するタイミングを判断しようとする際には、それを考慮する必要があります。そして、これらの各サブチャンクについては、スクラッチパッド内で推論があります。実際に関連情報を提供できることを確認するために、各段落を検証し確認します。
この場合、グローバルコンテキストから始めて、質問に最も関連する小さな部分に分解していきます。これは完全にインデックスフリーです。最初に埋め込みベースのインデックスを作成していないため、このシステムはより小さな段落を選択しても、グローバルコンテキストを保持する能力があります。
段落の数も制限していません。長文コンテキストモデルを使用しているためです。これは非常に動的な性質を持っています。このプロセスを繰り返した後、最終的な回答を生成する必要があります。これがどのように見えるかの詳細な実装です。システムプロンプトは「あなたは商標審判上訴委員会の手続きマニュアルに関する質問に答える法律研究アシスタントです」です。
ここで強調すべき点があります。生成モデルに十分なコンテキストを提供することが非常に重要です。「提供されたコンテキストに基づいて質問に答えなさい」と言うだけでは、ユーザーが何を探しているのかを実際には知りません。しかし役割を割り当て、言語がどのように見えるべきかを伝えると、はるかに良い回答が得られます。
ここでは、コンテキストがどこから来ているのか、そして回答がどのように見えるべきかを正確に伝えています。「提供された段落のみに基づいて質問に答えなさい。情報や基礎知識、外部情報に頼らないでください。回答に関連する段落の語句を引用してください」
段落に分解しているので、それらを参照することが実際に可能です。このシステムプロンプトとこれまでに取得した段落を渡し、システムが回答を生成します。ここで特定の段落への具体的な引用とともに最終的な回答を生成し始めているのがわかります。
最後のステップは回答の検証です。同じ実装なのでここで簡単に説明します。基本的に個々の段落を見て、LLMを審判として使用します。この場合、LLMを審判として制御する別のシステムプロンプトがあります。「あなたは法的情報の事実確認者です」と伝えています。
ここでも、検証すべきことについて十分なコンテキストを提供しています。「あなたの仕事は、提供された回答がソース段落に従って事実的に正確かどうかを確認することです。引用を正しく使用し、事実の誤りや裏付けのない主張を批判的に探します。段落が質問にどれだけ直接答えているかに基づいて信頼度を割り当てます」
各段落を分類したいのです。強力なLLMを審判として機機させたいので推論モデルを使用します。システムは回答とソースコンテンツ（提供された実際の段落）を見て、信頼スコアを与えます。この場合、信頼スコアはかなり高いです。
これがこのシステムの仕組みの簡単な概要でした。ご覧のように、LLMに対して複数の呼び出しを行い、検証ステップがあるため、得られる回答は合理的に正確です。しかし、それはまた多くのコストを追加します。ここにコスト分割があります。彼らは推定固定コストと変動コストと言っています。
従来のRAGシステムを使用する場合、埋め込みとメタデータ生成に約40セントかかります。ストレージコストも追加する必要があると思います。エージェントシステムの場合、インデックスを作成しないため、事前処理コストはゼロです。ただし、クエリごとに複数の異なるLLMへの複数の呼び出しを行います。
例えば、初期ルーティングは10セント、2つの再帰レベルはさらに20セントです。一般的に、この仮説的なクエリについてすべてを合計すると、約36セントになります。これは標準的なRAGシステムと比較して非常に高価です。ここで異なるアプリケーションを理解することが非常に重要だと思います。
例えば、法律分野のアプリケーションや非常に正確な回答が必要な場所を見ている場合、より高いコストを検討することになります。また、システムが低レイテンシーの実装を必要とするかどうかも考慮する必要があります。その場合、検証者を伴うエージェントソリューションはおそらく適切ではありません。
ニーズに応じて、非常に高価だが非常に正確なシステムのユースケースは確かにあります。いくつかの利点が列挙されています。まず、前処理を行わないため、インデックス作成のレイテンシーがゼロであること、動的ナビゲーション、これは人間の読書パターンを模倣し、有望なセクションに焦点を当てます。
次にセクション間の推論について言及しています。トレードオフはクエリあたりのコストが高くなること、レイテンシーが増加すること、現在の形ではスケーラビリティが制限されることです。しかし、行うことができる特定のことがあります。一つはキャッシュを使用することです。現在ほとんどのLLMプロバイダーはコンテンツをキャッシュする機能も提供していると思います。
これにより、レイテンシーとコストの両方が改善される可能性があります。彼らが提案している別のアイデアは、ナレッジグラフを生成することです。これは一度だけのプロセスで、その後GPT-4.1のようなモデルがそのナレッジグラフを走査できるようになります。これはインデックスの作成に戻ります。しかし、どのような異なるエンティティが存在し、それらの関係は何かを把握したい場合、ナレッジグラフはそれらの関係を保存するのに本当に優れています。
スクラッチパッドを改善することもできます。現在の仕組みでは、情報を追加してユーザークエリに関連するチャンクを追跡しています。情報を削除したり編集したりする機能も持ち、深さを調整することもできます。より高い深さを持つことができますが、それによりレイテンシーとコストが増加します。
法律文書のような特定のケースでは、おそらくより多くの深さが必要です。例えば、文レベルの引用を探している場合、現在は段落レベルの引用だけを行っています。これらすべては、これらの巨大なコンテキストウィンドウのおかげで可能です。従来の意味でのRAGと、文書が取得された後にGPT-4.1やGeminiモデルなどの長文コンテキストLLMに渡すハイブリッド実装が見られ始めると思います。
このアプローチについてどう思うか教えてください。これには多くの可能性があると思います。特定の実装や改善点があれば教えてください。コメントセクションで議論しましょう。このビデオがお役に立てば幸いです。
ご視聴ありがとうございました。いつものように、次回もお会いしましょう。
コメント