Amazon Web Services ブログ
RAG の精度を向上させる Advanced RAG on AWS の道標
生成 AI の進化と共に、大規模言語モデル (LLM) を活用したアプリケーション開発が急速に広がっています。その中で、検索拡張生成 (Retrieval-Augmented Generation; RAG) は、LLM に対して最新の情報や特定のドメイン知識を組み込むための重要な技術として注目を集めています。
RAG は、その名の通り、外部知識ベースから関連情報を検索し、それを LLM の入力に組み込むことで、より正確で最新の情報に基づいた回答を生成する手法です。この手法には以下のような重要な利点があります。
- 最新情報の反映: LLM の学習データの制限を超えて、最新の情報を回答に反映させることができる。
- ドメイン特化: 特定の分野や組織固有の情報を容易に組み込むことができ、専門的な質問にも対応可能になる。
- 根拠の明確化: 生成された回答の情報源を追跡しやすくなり、回答の信頼性が向上する。
- ハルシネーション (幻覚) の低減: 外部知識に基づいて回答を生成するため、LLM が誤った情報を創作するリスクを軽減できる。
基本的な RAG システム (Naive RAG / Baseline RAG) でも多くの場合で十分な性能を発揮しますが、より複雑な質問や高度な応用では、さらなる改善が必要となります。Advanced RAG は、この基本的な RAG を様々な手法で拡張し、以下のような課題に対応するために開発されています。
- 複雑なクエリへの対応: 多岐にわたる情報や複数の文書にまたがる知識を必要とする質問に適切に回答する。
- 検索精度の向上: より関連性の高い情報を正確に抽出し、回答の質を向上する。
- コンテキストの理解: 質問の意図や背景をより深く理解し、適切な情報を検索・生成する。
前回の記事「Amazon Kendra と Amazon Bedrock で構成した RAG システムに対する Advanced RAG 手法の精度寄与検証」では Amazon Bedrock を用いたクエリ拡張と検索結果の関連度評価という手法に絞って実装方法と検証結果を紹介しました。本記事では、AWS のサービスを活用したさまざまな Advanced RAG の実装方法や、精度を向上させるための様々なテクニックを紹介します。これらの手法を理解し適用することで、より高度で信頼性の高い AI アプリケーションの開発が可能になります。
RAG の基本構成
RAG の基本的な仕組みを理解することは、Advanced RAG の技術を効果的に適用するための第一歩です。ここでは、RAG のデータフローと、その中で特に重要となる検索精度の課題について説明します。
RAG システムは大きく分けて、データ準備 (データ取り込み) フェーズと利用 (検索 + テキスト生成) フェーズの 2 つのフェーズで構成されています。
- データ準備 (データ取り込み) フェーズ
- ドキュメント収集: RAG で使用する知識ベースとなる文書を収集する。
- テキスト分割: 長い文書を適切な長さのチャンク (断片) に分割する。
- ベクトル化: 各チャンクを埋め込みモデルを使ってベクトル表現に変換する。
- インデックス化: 変換されたベクトルをベクトルデータベースに格納する。
- 利用 (検索 + テキスト生成) フェーズ
- クエリベクトル化: ユーザーからの質問文を埋め込みモデルでベクトル化する。
- 類似度検索: ベクトルデータベースから質問に類似したチャンクを検索する。
- コンテキスト構築: 検索結果を元に、LLM への入力コンテキストを構築する。
- 回答生成: LLM を使用して、構築されたコンテキストに基づいて回答を生成する。
RAG システムの性能は、大きく検索の精度に依存します。以下のような問題が検索精度に影響を与え、結果として生成される回答の質を左右します。
- 不適切なチャンク選択:
- 質問に関連性の低いチャンクが選択されると、的外れな回答が生成される可能性がある。
- 必要な情報が複数のチャンクに分散している場合、全ての関連情報を適切に取得できないことがある。
- コンテキストの欠落:
- チャンクサイズが小さすぎると、重要なコンテキスト情報が失われる可能性がある。
- 逆に大きすぎると、ノイズとなる情報も含まれてしまい、回答の精度が下がる可能性がある。
- 意味的類似性の限界:
- 単純なベクトル類似度だけでは、文脈や意図を完全に捉えきれない場合がある。
- 例えば、否定表現や条件付きの文章の意味を正確に理解することが難しい場合がある。
- 多様な表現への対応:
- 同じ概念や事実が異なる表現で記述されている場合、適切に関連付けることが困難な場合がある。
これらの課題に対処するために、Advanced RAG ではさまざまな手法が提案されています。以降のセクションでは、これらの改善テクニックについて詳しく見ていきます。
Advanced RAG の概要
Advanced RAG は、基本的な RAG システムの性能を向上させるための一連の技術や手法の総称です。Advanced RAG の手法は、RAG のパイプライン内のどの部分を改善するかによって分類することができます。主な改善領域には、データ準備段階、クエリ処理、検索段階、検索結果の後処理、そして回答生成があります。
データ準備段階では、チャンクサイズの最適化や高度なドキュメントパース技術、メタデータの抽出などが行われます。クエリ処理の改善には、クエリ拡張や分解、意図分類などの技術が含まれます。検索段階では、ハイブリッド検索やグラフベースの知識表現 (Graph RAG) などが活用されます。検索結果の後処理では、リランキングやフィルタリング、Small-to-Big Retrieval (階層チャンク) などの手法が用いられます。回答生成の改善には、プロンプトエンジニアリングや複数ステップの推論、自己一貫性チェックなどが活用されます。
これらのアプローチは、単独で使用することも、複数を組み合わせて使用することも可能です。実際の適用においては、タスクの性質、データの特性、要求される精度や応答時間などを考慮して、最適な手法を選択することが重要です。
他にも、エージェントとして RAG を実行したり、基盤モデルのファインチューニングを行うアプローチもありますが、相応のコストが発生します。まずはチャンクサイズ調整、ドキュメントパースの改善、メタデータによるフィルタ、ハイブリッド検索といった手軽に利用できる手法から試すのをおすすめします。
Advanced RAG の適用における重要な注意点
高度な技術を採用する前に、まず基本に立ち返ることが重要です。Advanced RAG や GraphRAG といった複雑な手法を闇雲に適用する前に、現在の RAG システムの性能を適切に評価し、具体的な問題点を特定することが必要です。
効果的な RAG 改善のアプローチとして、まず RAG システムの性能を正確に測定するための評価フレームワークを構築しましょう。この評価システムには、ユーザーのクエリ (質問)、検索結果、そして最終的な LLM の回答を含めるとよいでしょう。オフライン評価やユーザによるオンライン評価等の評価指標を測定するためには OSS の RAGAS や Amazon Science が公開している RAGChecker のようなライブラリがよく利用されます。
そして、この評価システムを用いて、回答の質が悪いパターンを収集し、分析します。各ステップでどこに問題があるのかを特定し、なぜそのような結果になったのかを深く掘り下げます。例えば、クエリの加工が適切でないのか、検索結果の関連性が低いのか、それとも LLM の回答生成に問題があるのかを見極めます。開発者は「有給休暇を取得する方法を教えてください。」のようなチャット形式で質問される想定でいても、ユーザーのクエリが「有休」のような単一のワードのみ入力されるかもしれません。この場合、「有給休暇」が「有休」と省略されており、類義語への対応が必要かもしれません。また、有休の取得なのか、取り消しなのか、ユーザーが何を知りたいのかが曖昧です。
問題の根本原因が特定できたら、それに基づいて最適な改善策を検討します。ここで重要なのは、必ずしも高度なテクニックを必要としない解決策も考慮に入れることです。プロンプトエンジニアリングやシンプルな手法で十分な場合も多々あります。
実装した改善策の効果を継続的に評価し、必要に応じて調整を加えていくことが大切です。この過程を繰り返すことで、システムの段階的な改善を図ることができます。
このアプローチを採用することで、不必要に複雑な解決策を避け、効率的かつ効果的に RAG システムの性能を向上させることができます。Advanced RAG の技術は確かに強力ですが、それらを適用する前に、まず基本的な評価と分析のプロセスを確立することが、長期的な成功への鍵となります。
基本的な RAG 改善テクニック: まずはここから
RAG システムの性能を向上させるための基本的なテクニックには、チャンクサイズの調整、ドキュメントパースの改善、メタデータによるフィルタリング、ハイブリッド検索などがあります。これらのテクニックは比較的実装が容易で、多くの場合、大きな効果が期待できます。
チャンクサイズの調整
チャンクサイズはベクトル検索の基礎的な調整項目ですが、RAG システムの性能に大きな影響を与える重要な要素です。小さすぎるチャンクは検索の精度を上げる一方で、文脈の欠落を招く可能性があります。逆に、大きすぎるチャンクは関連性の低い情報を含んでしまう可能性があります。
最適なチャンクサイズは、扱うデータの性質や質問の種類によって異なります。一般的には、256 から 1024 トークン程度の範囲で調整することが多いですが、実際のタスクに応じて実験的に最適な値を見つけることが重要です。
チャンクサイズの調整によって、検索精度、回答の関連性、処理時間のバランスを取ることができます。例えば、LlamaIndex のブログ記事 “Evaluating the Ideal Chunk Size for a RAG System using LlamaIndex” の実験では、チャンクサイズを 1024 程度に増やすことで、レスポンスタイムは若干増加するものの、回答の忠実性 (Faithfulness) や関連性 (Relevancy) が向上したと報告されています。
ドキュメントパースの改善
ドキュメントパースの改善は、特に PDF や複雑なフォーマットの文書を扱う際に重要です。単純なテキスト抽出では、レイアウト情報や図表の内容が失われてしまう可能性があります。
例えば PDF にはヘッダー、フッター、ページ番号などのノイズが含まれることがあるので、これを除去したり、本文としてではなくメタデータとして扱ったりすることで、本文の内容を正確に抽出することができます。また、表や図表の内容をテキスト形式に変換することで、検索可能な情報を増やすことができます。
例えば、Amazon Bedrock Knowledge Bases の高度なパース機能では、Anthropic の Claude 3 というマルチモーダルなモデルを使用して、図や表を Markdown などのテキスト形式に変換することができます。これにより、視覚的な情報も含めた総合的な検索が可能になります。
メタデータによるフィルタリング
メタデータを活用したフィルタリングは、検索結果の精度を大幅に向上させる効果的な手法です。メタデータには、ドキュメントのタイトル、作成日時、著者、カテゴリなどが含まれます。
例えば、時系列データを扱う場合、ユーザーの質問に含まれる時間情報を元に、特定の期間のデータのみを検索対象とすることができます。これにより、不適切な時期の情報が回答に混入することを防ぎ、より正確な回答を生成することができます。
また、質問自体を LLM を使ってカテゴリ分類し、そのカテゴリに関連するドキュメントのみを検索対象とする方法も効果的です。これにより、検索空間を絞り込み、より関連性の高い情報を抽出することが可能になります。
Amazon Bedrock Knowledge Bases のメタデータフィルタリングの機能に関してはブログ記事「Knowledge Bases for Amazon Bedrock がメタデータフィルタリングをサポートし検索精度向上」を参照してください。
ハイブリッド検索
ハイブリッド検索は、キーワード検索とベクトル検索のそれぞれの長所を組み合わせた手法です。キーワード検索は特定の単語や句を含むドキュメントを正確に抽出できる一方、ベクトル検索は意味的な類似性を捉えることができます。ハイブリッド検索では、キーワード検索とベクトル検索の両方の検索を並行して行い、結果をスコアリングして統合します。
Amazon Bedrock Knowledge Bases に統合されている Amazon OpenSearch Serverless は、ネイティブにハイブリッド検索をサポートしており、簡単な設定で高度な検索機能を実現できます。これにより、キーワードの正確性とベクトル検索の柔軟性を両立させ、より適切な検索結果を得ることができます。詳しくはブログ記事「Knowledge Bases for Amazon Bedrock がハイブリッド検索をサポート」を参照してください。
これらの基本的な RAG 改善テクニックを適切に組み合わせることで、RAG システムの性能を大幅に向上させることが可能です。次のセクションでは、さらに高度な改善テクニックについて説明していきます。
高度な RAG 改善テクニック
基本的な改善テクニックを適用した後、さらなる性能向上を目指す場合、より高度な RAG 改善テクニックを検討することができます。ここでは、リランキング、クエリ書き換え、Small-to-Big Retrieval という3つの重要な手法について解説します。
リランキング
リランキングは、初期の検索結果をさらに精緻化する手法です。通常の検索エンジンが返す結果の順序を、より高度なモデルを使用して再評価し、最も関連性の高い情報を上位に配置します。
この手法の利点は、初期検索の広範な結果を維持しつつ、最終的な順序をより洗練させることができる点です。例えば、ある質問に対して検索結果 A, B, C, D が得られたとすると、リランキングモデルはこれらの結果とクエリとの関連性を詳細に分析し、最も適切な順序に並べ替えます。
リランキングモデルには、Cohere が提供する多言語対応のモデルが広く使用されています。このモデルは、Amazon SageMaker JumpStart を通じて簡単にデプロイし、利用することができます。詳しくはブログ記事 “Improve RAG performance using Cohere Rerank” を参照してください。また、オープンソースのモデルを自前でホストしたり、LLM を使用してリランキングを行うこともできます。
クエリ書き換え
クエリ書き換えは、ユーザーの入力した質問を、検索システムにとってより最適な形に変換する技術です。この手法は、ユーザーの意図をより正確に捉え、関連性の高い情報を効果的に検索するのに役立ちます。クエリ書き換えには、主に以下のようなアプローチがあります。
- クエリの簡略化: 複雑な質問を核心的なキーワードに絞り込む。例えば、「RAG を使った検索で、検索の精度を上げるための方法をいくつか教えてください」というクエリを「RAG の精度向上」に簡略化する。
- クエリの拡張: 元のクエリに関連する用語や同義語を追加し、検索範囲を広げる。例えば、「大規模言語モデル」というキーワードに対して「Large Language Model」、「LLM」、「生成 AI」といった関連用語を追加する。
- クエリの分解: 複雑な質問を複数の簡単な質問に分解する。例えば、「クリーンエネルギーの世界的な普及における主要な障害と、それらを克服するための国際的な努力は何か?」という質問を、「クリーンエネルギーの定義は何か」「クリーンエネルギー普及の主な障害は何か」「どの国際組織がクリーンエネルギー普及を推進しているか」といった複数の質問に分解する。
Amazon Bedrock で提供されている Cohere Command R や Command R+ というモデルでは (1) のクエリ簡略化を行うことができます。モデルを利用する際に search_query_only オプションを True にすることで、検索クエリとして適したテキストが返ります。詳しくは開発者ドキュメント “Cohere Command R and Command R+ models” を参照してください。
Amazon Bedrock Knowledge Bases では、クエリ分解 (query decomposition) の機能が提供されており、複雑な質問を効果的に処理することができます。クエリ分解に関してはブログ記事 “Amazon Bedrock Knowledge Bases now supports advanced parsing, chunking, and query reformulation giving greater control of accuracy in RAG based applications” で説明されています。
Small-to-Big Retrieval (階層チャンク)
Small-to-Big Retrieval (階層チャンク; hierarchical chunking) は、検索の精度と文脈の理解のバランスを取るための手法です。この方法では、初期検索には小さなチャンクを使用し、その後、選択されたチャンクの周辺情報も含めてLLMに提供します。具体的なプロセスは以下の通りです。
- 小さなチャンクを使用して初期検索を行い、最も関連性の高い部分を特定する。
- 選択されたチャンクの前後の文脈 (より大きなチャンク) を取得する。
- LLM に対して、初期検索で見つかった小さなチャンクと、その周辺の大きなチャンクの両方を提供する。
この手法により、検索の精度を保ちつつ、より広い文脈情報を LLM に与えることができます。結果として、より正確で文脈に即した回答を生成することが可能になります。Amazon Bedrock Knowledge Bases では、この Small-to-Big Retrieval (階層チャンク) がネイティブにサポートされており、簡単に実装することができます。詳しくはブログ記事 “Amazon Bedrock Knowledge Bases now supports advanced parsing, chunking, and query reformulation giving greater control of accuracy in RAG based applications” を参照してください。
これらの高度な RAG 改善テクニックを適切に組み合わせることで、RAG システムの性能をさらに向上させ、より高品質な回答を生成することが可能になります。ただし、これらの手法を導入する際は、処理時間やリソース消費とのトレードオフを考慮し、適切なバランスを取ることが重要です。
GraphRAG
RAG の技術は日々進化しており、その中でも特に注目を集めているのが GraphRAG です。この新しいアプローチは、従来の RAG の限界を克服し、より複雑な質問に対応することを目指しています。
GraphRAG の概要と利点
GraphRAG は、従来のベクトルデータベースの代わりに、ナレッジグラフを使用してドキュメントの知識を表現する手法です。ナレッジグラフは、情報をノードとエッジの形で構造化して表現し、データ間の関係性をより明確に捉えることができます。GraphRAG の主な利点は以下の通りです。
- 複雑な関係性の表現: ナレッジグラフを用いることで、文書間や概念間の複雑な関係性を明示的に表現できる。これにより、単純なキーワードマッチングやベクトル類似度では捉えきれない情報の関連性を考慮した検索が可能になる。
- 多段階の推論: グラフ構造を活用することで、直接的な関連がない情報同士をつなぎ合わせる多段階の推論が可能になる。これは、複数の文書にまたがる情報を必要とする複雑な質問に特に有効となる。
- 説明可能性の向上: 回答生成の過程で使用された情報の関係性を、グラフ上のパスとして視覚化できるため、回答の根拠をより明確に示すことができる。
- コンテキストの保持: グラフ構造によって情報の階層性や文脈を保持できるため、より広い文脈を考慮した回答生成が可能になる。
複雑な質問や多岐にわたる情報を必要とするユースケースでは、GraphRAG は非常に強力なソリューションとなる可能性があります。特に、企業の内部文書や専門分野の文献など、深い文脈理解が必要な領域での活用が期待されています。
GraphRAG の実装には、大きく分けて 2 つのステップがあります。まず、入力文書からナレッジグラフを構築し、次にこのグラフを用いて質問に答えます。グラフの構築には最近では LLM を活用する手法が注目されており、質問応答の過程では、グラフ上での多段階の推論やグラフの階層 (コミュニティ) ごとの要約などの情報が用いられます。
AWS 上での GraphRAG 実装
AWS のサービスを活用して GraphRAG を実装する場合、以下のような構成が考えられます。
- グラフデータベース: Amazon Neptune を使用してナレッジグラフを格納する。Neptune は高性能なグラフデータベースサービスで、大規模なグラフデータの管理と高速なクエリ処理が可能。
- グラフ構築: AWS Lambda や Amazon SageMaker 上で LlamaIndex などのオープンソースライブラリを使用し、入力文書からナレッジグラフを構築する。この過程で Amazon Bedrock の LLM を活用して、テキストからエンティティや関係性を抽出する。
- グラフ処理: Amazon Neptune の機能を活用して、グラフ上での検索や推論を行う。複雑なパターンマッチングやパス探索などの操作が可能。
- 回答生成: グラフからの検索結果を基に、Amazon Bedrock の LLM を使用して最終的な回答を生成する。この際、グラフの構造情報を活用して、より文脈に即した回答を生成することができる。
GraphRAG の実装には、従来の RAG と比べてより多くの計算リソースと複雑な処理が必要となります。そのため、性能とコストのバランスを慎重に検討する必要があります。また、グラフの構築と保守には専門知識が必要となる場合があります。
GraphRAG は比較的新しい技術であり、今後さらなる研究と改善が進むことが予想されます。AWS のサービスも継続的に進化しているため、最新の機能や事例を常にチェックし、自身のユースケースに最適な実装方法を検討することが重要です。
まとめ
本ブログでは、RAG の基本から、GraphRAG まで、Advanced RAG と呼ばれる手法を幅広く解説しました。チャンクサイズの調整、ドキュメントパースの改善、メタデータによるフィルタリング、ハイブリッド検索といった基本的な改善テクニックから、リランキング、クエリ書き換え、Small-to-Big Retrieval などの高度な手法、さらには GraphRAG のような最新のトレンドまで、様々なアプローチを紹介しました。
これらの手法を適用する際に最も重要なのは、RAG システムの評価の仕組みを確立することです。ユーザーの入力、検索結果、最終的な LLM の回答を含む評価システムを構築し、各改善策の効果を客観的に測定することが、効果的な RAG 改善の鍵となります。新しい技術を導入する際は、必ず評価システムを通じてその効果を検証し、段階的なアプローチを取りましょう。
著者について
本橋 和貴 (Kazuki Motohashi / @kmotohas) は、AWS Japan の機械学習スペシャリストソリューションアーキテクトです。AWS の AI/ML サービスのお客様に対する技術的な支援を行いながら市場開拓を推進しています。好きなサービスは Amazon Bedrock と Amazon SageMaker です。週末は子供と屋内遊園地で遊ぶのが習慣になっています。博士 (理学)。