著者 | フロリアン・ジューン 編纂者：岳陽 この記事は、人生でよくあるシナリオ、つまり持ち込み試験を取り上げます。このような試験に直面した場合、私たちは通常、以下の3つの対処法から選ぶことができます。
最初の方法は、このシリーズの第 8 回の記事で紹介したセルフ RAG テクニックに似ていますが、2 番目の方法は従来の RAG テクニックです。 最後に、この記事では 3 番目の方法、つまり Corrective Retrieval Augmented Generation (CRAG) を紹介します。 01 CRAGテクノロジーはなぜ生まれたのか？図1：これらの例は、非効率的な検索者が多くの無関係な情報を簡単に持ち込み、生成者が正確な知識を獲得するのを妨げ、さらには誤った方向に導く可能性があることを示しています。出典：Corrective Retrieval Augmented Generation[1] 図1は、従来のRAG手法の問題点を示しています。従来のRAG手法の多くは、文書の内容とユーザーの質問との関連性を無視し、取得した文書を単純につなぎ合わせています。このアプローチでは、無関係な情報が含まれてしまう可能性があり、モデルが正確な知識を獲得できず、誤解を招く可能性があり、結果として錯覚問題を引き起こします。 さらに、従来のRAG手法の多くは、取得したドキュメント全体を大規模モデルに渡します。しかし、これらのドキュメントに含まれるコンテンツの大部分は、実際にはモデルのレスポンス生成プロセスには寄与しないため、大規模モデルに無差別に渡すべきではありません。 02 CRAGのコアコンセプトCRAG は、特定のユーザー要求に対して取得されたドキュメントの全体的な品質を評価するために使用できる軽量の検索評価メカニズムを考案し、Web 検索テクノロジを創造的に利用して検索結果の精度を高めています。 CRAGは優れた互換性を備え、プラグアンドプレイで、様々なRAGベースの戦略システムに容易に統合できます。全体的なフレームワークを図2に示します。 図2：RAGアーキテクチャにおけるCRAG（赤い破線で囲まれた部分）の位置付け。CRAGは巧みに検索評価モジュールを導入しており、検索された文書とユーザーのニーズとの関連性を評価し、それに応じて信頼度を推定することで、{正解、不正解、不確実}という3つの異なる知識検索戦略をトリガーします。これらの戦略のうち、「x」はユーザーのクエリ要求を表します。この図は著者によるオリジナルであり、CRAG部分（赤い破線で囲まれた部分）は「Corrective Retrieval Augmented Generation」[1]から引用したものです。 図 2 に示すように、CRAG は検索評価ツールを導入することで従来の RAG 方式を改良し、取得したドキュメントとクエリ コマンドの関連性をより正確に測定できるようになりました。 考えられる結果は 3 つあります。
最後に、処理された情報は大規模言語モデル（LLM）に転送され、最終的なモデル応答が生成されます。図3はこのプロセスを詳細に示しています。 図 3: 記事「Corrective Retrieval Augmented Generation」から抜粋した評価と治療の手順。 ウェブ検索は、ユーザーの生の入力を直接使用して検索を実行するわけではないことに注意してください。代わりに、この技術はまずプロンプトを作成し、次にいくつかの例を提示します。そして、それらはGPT-3.5 Turboに送信され、より正確な検索クエリを取得します。 処理フローの全体について基本的な理解を得た後、CRAG システムの 2 つのコア モジュール (検索評価モジュールと知識改良アルゴリズム) に焦点を当てて詳細に検討します。 2.1 検索評価器図 4 に示すように、検索評価機能は後続のステップの有効性に大きな影響を与え、システム全体のパフォーマンスに重大な影響を及ぼします。 図4：CRAGの知識修正プロセス。出典：Corrective Retrieval Augmented Generation[1] CRAGは、検索評価器として、細かく調整されたT5-largeモデルを使用しています。大規模言語モデルの時代において、T5-large[2]は軽量言語モデルとしても認識されています。 システムは通常、特定のユーザークエリごとに約10件の参照を抽出します。次に、ユーザークエリを各参照と個別に組み合わせてモデル入力を作成し、それらの関連性を評価します。モデルの微調整フェーズでは、肯定的なサンプルには「1」、否定的なサンプルには「-1」のラベルが付けられます。モデル推論フェーズでは、評価者が各ドキュメントの関連性スコアを-1から1までの値で計算します。 これらの相関スコアは、特定の閾値に基づいて3つのカテゴリーに分類されます。この分類には、2つの異なる閾値境界を定義する必要があります。CRAGシステムは閾値設定において高い柔軟性を備えており、特定の実験データに基づいて調整することができます。
2.2 知識洗練アルゴリズムCRAG は、図 4 に示すように、取得したドキュメントに対して革新的な「セグメンテーションと再統合」戦略を採用し、最も重要な知識情報を深く掘り下げます。 最初のステップでは、一連のヒューリスティックルールを用いて各文書を複数のきめ細かな知識ポイントに分解し、より正確な情報を抽出します。取得した文書に1つか2つの文しか含まれていない場合は、独立した情報単位として扱います。一方、長い文書の場合は、全体の長さに基づいて、複数の文からなる複数の小さな単位に柔軟に分割されます。これにより、各小さな単位が独立した完全な情報を確実に包含します。 次に、検索・評価メカニズムを用いて、各サブ知識ポイントの関連度スコアを計算し、関連度スコアの低いものを除外します。残った関連性の高い知識ポイントは、内部知識ベースを形成するために再編成されます。 03 コードの説明CRAGは、LangchainとLlamaIndexの両方のプラットフォームでサポートおよび実装されているオープンソース技術です。詳細な分析のモデルとして、LlamaIndexの実装を使用します。 3.1 環境設定インストール後、LlamaIndex と Tavily の対応するバージョンは次のとおりです。 3.2 テストコードテストコードは以下の通りです。初回実行時にはCorrectiveRAGPackをダウンロードする必要があります。 YOUR_TAVILYAI_API_KEYは、このウェブサイト[3]から申請できます。 テストコードの実行結果は次のとおりです (ほとんどのデバッグ情報は削除されています)。 テストコードを理解するには、corrective_rag.run() メソッドの実装の詳細を詳しく調べる必要があります。詳しく見てみましょう。 3.3 CorrectiveRAGPackクラスのコンストラクタまず、コンストラクタを見てみましょう。そのソースコード[4]は次のようになります。 システムのデフォルト設定ではgpt-4モデルが使用されていることにご注意ください。gpt-4を使用する権限がない場合は、手動でgpt-3.5-turboまたは他の大規模モデルAPIに変更できます。 3.4 クラス CorrectiveRAGPack::run()関数run()[5]のソースコードを以下に示します。 上記のコードは、標準の CRAG プロセスとは 3 つの重要な点で異なります。
ただし、LlamaIndex は代替の方法論 (langchain にも同様のプラクティスがあります) を導入し、このようなタスクの処理に関する別の考え方を提供します。 3.5 LLMを使用して取得した情報を評価する具体的なコード[6]は以下のとおりです。 LLM[7]を呼び出すためのプロンプトを以下に示します。 CRAG の論文によると、ChatGPT は検索コンテンツの関連性の評価において T5-Large モデルよりもパフォーマンスが劣ります。 実際のプロジェクトでは、初期知識精緻化アルゴリズムを最大限に活用できます。対応するコード実装はこちらのリンク[8]でご覧いただけます。 3.6 検索クエリを書き換えるウェブ検索機能は、ユーザーが入力したクエリを直接使用しません。代わりに、「few-shot」戦略を採用し、ガイドとなるサジェストワードを慎重に構築し、GPT-3.5 Turboモデルに送信して、より適切な検索リクエストを生成します。このガイドとなるサジェストワードの構築方法は以下の通りです。 04 CRAGに関する著者の洞察と考察4.1 CRAGと自己RAGの違い
図5：4つの主要データセットの関連テストセットにおける包括的な評価結果。これらの結果は、異なるLLM分類に従って示されています。太字の値は、すべての手法とLLMの中で最高のパフォーマンスを表します。一方、灰色の太字の値は、特定のLLMの中で最高のパフォーマンスを表します。アスタリスク（*）でマークされた結果はCRAG再検証によって得られたもので、その他の結果は関連する研究文献から直接引用したものです。出典：*Corrective Retrieval Augmented Generation* 4.2 検索評価ツールのさらなる改良検索評価器は、評価スコア分類モデルと見なすことができます。クエリと文書間の関連性を評価する役割を担っており、その機能はRAGシステムの再ランキングモデルに似ています。 これらの関連性判断モデルの実用性を向上させるために、より現実世界のシナリオに近い機能を統合することができます。例えば、科学研究論文向けのRAG（Research and Answering）シナリオでは専門用語が多数登場しますが、観光業界向けのRAGシナリオでは、日常会話形式のユーザーからの質問が多くなります。 検索評価器の学習データにシーン特徴を組み込むことで、文書の関連性を評価する能力を効果的に強化できます。さらに、図6に示すように、ユーザーの意図や編集距離といった要素を補助特徴として導入することも可能です。 図6：CRAGシステムにおける検索推定器の学習効率は、追加の機能を統合することでさらに向上します。画像は著者提供。 さらに、T5-Large モデルの成功から判断すると、軽量モデルも良好な結果を達成しているようで、これは間違いなく、小規模なチームや企業における CRAG テクノロジーの推進と応用に希望をもたらすでしょう。 4.3 検索評価器の採点基準と閾値設定前述の通り、データの種類によって閾値は異なります。「不確実」および「不正確」カテゴリの閾値は概ね-0.9に近づく点に注目すべきです。これは、取得された情報の大部分が依然としてクエリと何らかの関連性を持っていることを示しています。したがって、取得した知識を完全に捨て去り、Web検索のみに頼るのは賢明ではないかもしれません。 実際の適用シナリオでは、特定の問題状況と実際のニーズに合わせて柔軟に調整する必要があります。 05 結論この記事は、鮮明な例から始まり、CRAG の中核となるプロセスを徐々に概説し、コード分析を補足し、個人的な洞察と詳細な思考を織り交ぜています。 結論として、プラグアンドプレイ プラグインとしての CRAG は、RAG のパフォーマンスを大幅に向上させ、RAG 改善のための軽量なソリューションを提供します。 RAG テクノロジーにご興味がございましたら、このシリーズの他の記事をお読みください。 読んでくれてありがとう！ フロリアン・ジューン AI研究者。LLM、RAG、エージェント、ドキュメントAI、データ構造に焦点を当てています。最新の記事はニュースレターをご覧ください： https://florianjune.substack.com/ 終わり 参考文献[1] https://arxiv.org/pdf/2401.15884.pdf [2] https://huggingface.co/google-t5/t5-large [3] https://app.tavily.com/sign-in [4] https://github.com/run-llama/llama_index/blob/v0.10.29/llama-index-packs/llama-index-packs-corrective-rag/llama_index/packs/corrective_rag/base.py#L47 [5] https://github.com/run-llama/llama_index/blob/v0.10.29/llama-index-packs/llama-index-packs-corrective-rag/llama_index/packs/corrective_rag/base.py#L106 [6] https://github.com/run-llama/llama_index/blob/v0.10.29/llama-index-packs/llama-index-packs-corrective-rag/llama_index/packs/corrective_rag/base.py#L71 [7] https://github.com/run-llama/llama_index/blob/v0.10.29/llama-index-packs/llama-index-packs-corrective-rag/llama_index/packs/corrective_rag/base.py#L13 [8] https://github.com/HuskyInSalt/CRAG/blob/main/scripts/internal_knowledge_preparation.py#L58 オリジナルリンク: https://ai.gopubby.com/advanced-rag-10-corrective-retrieval-augmented-generation-crag-3f5a140796f9 |
