モジュラーRAGシステムにおける推論モデルの使用に関する応用評価

本稿では、Kapa.aiが最近取り組んでいるOpenAIのRAG（Retrieval-Augmented Generation）システムについて紹介する。 o3-ミニ 推論の語源モデルの探求の概要報告。

Kapa.aiは、大規模言語モデル（LLM）を搭載したAIアシスタントです。 ラグ このプロセスはナレッジベースと統合されており、ユーザーからの技術的な質問に答えたり、テクニカルサポートの作業指示を処理したりすることができる。

安定した汎用性の高いRAGシステムを構築し、維持することは容易なことではない。多くのパラメータや設定が最終的なアウトプットの品質に影響し、これらの要素の間には複雑な相互作用が存在する：

• キュー・ワードのテンプレート
• コンテクストのサイズ
• クエリー・エクステンション
• チャンク
• 再注文
• ちょっと待ってくれ！

RAGシステムを調整する際、特に新しいモデルを統合する際、これらのパラメーターを再検討し最適化することは、良好なパフォーマンスを維持するために不可欠である。しかし、この作業は時間がかかるだけでなく、うまくやるには多くの経験が必要です。

類似 ディープシーク-R1 OpenAIのo3-miniのような新しい推論モデルは、組み込みの思考連鎖（CoT）プロンプトを使用して、問題について「考え」、段階的に推論し、必要に応じて自己修正することで、印象的な結果を達成している。このモデルは、論理的な推論と検証可能な答えを必要とする複雑なタスクにおいて、より優れたパフォーマンスを発揮すると報告されている。関連記事RAGにおけるDeepSeek R1：実務経験のまとめ そしてプロジェクトレベルのコード生成結果が出た！ o3/Claude 3.7がリードし、R1がトップクラス！

Kapa.aiは、推論モデルが複雑な問題を分解し、自己修正することができるのであれば、クエリ展開、文書検索、並び替えなどのタスクを処理するRAGプロセスに適用することができるのではないだろうか？情報検索ツールキットを構築し、それを推論モデルに渡すことで、パラメータの手動チューニングの必要性を減らし、より適応的なシステムを構築できるかもしれない。

このパラダイムはモジュラー検索拡張生成（Modular Retrieval-Augmented Generation: Modular RAG）と呼ばれることもある。本稿では、標準的なRAGプロセスを推論モデルベースのプロセスにリファクタリングしたKapa.aiの最近の研究成果を紹介する。

とすると

このアイデアを探求するKapa.aiの主な目標は、RAGプロセスを簡素化し、パラメータの手動微調整への依存を減らすことである。典型的な高レベルのRAGプロセスは以下の通りである：

1. ユーザーからのプロンプトを受け取る。
2. 情報検索を改善するためのクエリの前処理。
3. 関連文書は、ベクトル・データベースの類似性検索によって発見される。
4. 結果を並べ替え、最も関連性の高い文書を使用する。
5. 反応を起こす。

プロセスの各ステップは、関連するデータに優先順位をつけるためのフィルタリングルールやソート調整などのヒューリスティックスによって最適化されている。これらのハードコード化された最適化は、プロセスの挙動を定義するが、同時に適応性を制限する。

推論モデルがRAGプロセスの様々なコンポーネントを利用するために、Kapa.aiはシステムを異なる方法でセットアップする必要があった。ステップの線形シーケンスを定義する代わりに、各コンポーネントはモデルが呼び出すための独立したモジュールとして扱われる。

このアーキテクチャでは、固定されたプロセスに従う代わりに、推論機能を持つモデルは、よりダイナミックに自身のワークフローを制御することができる。ツールを利用することで、モデルは、いつ、どのくらいの頻度で、完全検索または簡易検索を実行するか、どのような検索パラメータを使用するかを決定することができる。このアプローチが成功すれば、LangGraphのような従来のRAGオーケストレーションフレームワークに取って代わる可能性がある。

加えて、よりモジュール化されたシステムには、さらなる利点もある：

• プロセス全体を完全に刷新することなく、個々のモジュールの交換やアップグレードが可能です。
• 職務分掌をより明確にすることで、デバッグやテストの管理が容易になる。
• 異なるモジュール（例えば、異なるエンベッディングを持つリトリーバー）をテストし、性能を比較するために置き換えることができる。
• モジュールは、異なるデータソース用に独立して拡張することができる。
• これにより、Kapa.aiは特定のタスクやドメイン用にカスタマイズされた異なるモジュールを構築できる可能性がある。

最後に、Kapa.aiは、このアプローチが、不正なクエリやトピックから外れたクエリをより効果的に「ショートカット」するのに役立つかどうかも調べたいと考えている。最も困難なケースは、通常、曖昧さ、つまり、クエリが製品に関連しているかどうかが明確でないことである。濫用的なクエリは、検出を逃れるために意図的に設計されていることが多い。単純なケースはすでに効果的に処理することができますが、Kapa.aiは推論モデルがより複雑な問題を早期に特定し、終了するのに役立つことを期待しています。

テストセットアップ

このワークフローを実験するために、Kapa.aiは、必要なコンポーネント、静的データ、およびLLMをレフリーとする評価スイートを含むサンドボックス化されたRAGシステムを構築した。ある構成では、Kapa.aiはハードコードされた最適化を組み込んだ典型的な固定線形プロセスを使用した。

モジュラーRAGプロセスでは、Kapa.aiは推論モデルとしてo3-miniモデルを使用し、様々なポリシーの下でプロセスの様々な構成を実行し、どのアプローチがうまくいき、どのアプローチがうまくいかなかったかを評価した：

• 道具を使う： Kapa.aiは、モデルにすべてのツールとプロセス全体への完全なアクセスを与えようとし、また、ツールの使用を単一のツールと固定された線形プロセスの組み合わせに制限しようとする。
• ヒントとパラメータ化： Kapa.aiは、最小限の指示によるオープンエンドなキューと、高度に構造化されたキューの両方をテストした。Kapa.aiはまた、モデル自身にパラメータを決定させるのではなく、事前にパラメータ化されたツールの呼び出しをさまざまな程度で実験した。

Kapa.aiが実施したすべてのテストにおいて、ツールの呼び出し回数は最大20回に制限された。任意のクエリに対して、モデルは最大20回のツール呼び出ししか使用できない。Kapa.aiはまた、すべてのテストを推論強度が中程度と高程度で実施した：

• ミディアムだ： より短いCoT（思考の連鎖）ステップ
• もっと高い： より詳細な推論を伴う長いCoTステップ

Kapa.aiは合計で、さまざまなモジュール式RAGの構成について58の評価を行った。

結局

実験の結果はまちまちだった。いくつかの構成では、Kapa.aiは、特にコード生成と、限られた範囲ではあるがファクタリングにおいて、若干の改善を観察した。しかし、情報検索の品質や知識抽出などの主要な指標は、Kapa.aiの従来の手作業で調整されたワークフローと比較して、ほとんど変わっていなかった。

テストプロセスを通して繰り返し問題になるのは、Chain of Thought（CoT）推論が待ち時間を増やすことです。より深い推論により、モデルは複雑なクエリを分解し、自己修正することができますが、その代償として、ツールの反復呼び出しに必要な時間が追加されます。

Kapa.aiが特定した最大の課題は、「推論≠経験の誤り」である。推論モデルは、ステップバイステップで考えることができるにもかかわらず、検索ツールの使用に関する先験的な経験が不足している。厳密なヒントがあっても、高品質の検索結果を得ることや、良い出力と悪い出力を区別することに苦労した。このモデルは、昨年Kapa.aiがo1モデルを用いて行った実験と同様に、Kapa.aiが提供するツールの使用を躊躇することが多かった。推論モデルは抽象的な問題解決には長けているが、事前のトレーニングなしにツールの使用を最適化することは、依然として未解決の課題である。

主な調査結果

• この実験では、推論モデル自身が検索ツールを「理解していない」という、明らかな「推論≠経験の誤り」が明らかになった。推論モデル自身は検索ツールを "理解して "いない。推論モデルは検索ツールの機能と目的を理解しているが、その使い方を知らない。経験がヒューリスティックスと最適化で符号化される従来のプロセスとは異なり、推論モデルはツールを効果的に使用する方法を明示的に教えられなければならない。
• o3-miniモデルはより大きなコンテキストを扱うことができるが、Kapa.aiは、知識抽出という点では4oやSonnetのようなモデルに比べて大きな改善はないと見ている。単にコンテキストサイズを大きくするだけでは、検索性能を向上させる万能薬にはならない。
• kapa.aiのデータセットは、数学の競技問題や高度なコーディングの課題ではなく、実際のユースケースに関連する技術的な内容に重点を置いています。推論強度の影響はドメインによって異なる可能性があり、より構造化されたクエリや計算が複雑なクエリを含むデータセットでは異なる結果が得られる可能性があります。
• このモデルが優れている分野のひとつはコード生成で、推論モデルが純粋な検索ではなく、構造化された論理的出力を必要とするドメインに特に適している可能性を示唆している。
• 推論モデルは道具に関する知識を持たない。

推論≠経験的誤謬

実験の重要な結論は、推論モデルはツール固有の知識を自然に持っているわけではないということである。事前に定義されたステップに検索ロジックをエンコードする、きめ細かく調整されたRAGプロセスとは異なり、推論モデルは各検索呼び出しをゼロから処理する。これは非効率、優柔不断、最適とは言えないツールの使用につながる。

これを軽減するために、いくつかの戦略が考えられる。キューイング戦略をさらに洗練させること、すなわち、モデルにより明確なガイダンスを与えるような方法で、道具に特化した指示を構成することが有効であろう。また、道具を使用するための事前訓練や微調整を行うことで、特定の検索メカニズムに慣れさせることもできる。

さらに、事前に定義されたヒューリスティックが特定のタスクを処理し、必要なときに推論モデルが選択的に介入するハイブリッドアプローチも考えられる。

これらのアイデアはまだ推測の段階だが、推論能力と実際のツール実装のギャップを埋める方法を指し示している。

概要

モジュール式推論ベースのRAGは、Kapa.aiのユースケースの文脈では、従来のプロセスに比べて大きな優位性は示さなかったが、この実験は、その可能性と限界について貴重な洞察を提供した。モジュラーアプローチの柔軟性は依然として魅力的である。それは、適応性の向上、アップグレードの簡素化、新しいモデルやデータソースへの動的な適応を可能にする。

今後、多くの有望な技術がさらなる研究に値する：

• モデルが検索ツールを理解し、相互作用する方法を改善するために、さまざまなキューイング戦略と事前トレーニング/微調整を使用する。
• ワークフロー全体をオーケストレーションするのではなく、特定のユースケースや、複雑な質問への回答やコード生成などのタスクに、プロセスの特定の部分で戦略的に推論モデルを使用する。

現段階では、o3-miniのような推論モデルは、合理的な時間制約の中で、コアな検索タスクのための従来のRAGプロセスを凌駕していない。モデルが進歩し、ツールを使用するための戦略が進化するにつれて、モジュラー推論ベースのRAGシステムは、特に動的で論理集約的なワークフローを必要とするドメインにとって、実行可能な代替手段になるかもしれない。