編集者注：検索強化生成（RAG）システムは最近大きな注目を集めており、ChatGPTの人気がさらに広範な議論を巻き起こしています。Matt Ambrogiによるこの記事の核心は、基本的な実用的なRAGシステムの構築は驚くほど簡単である一方、それを実稼働レベルにまで引き上げるのは非常に困難で、多大な労力を要するという点です。

この目的のために、著者らは10の戦略を詳述しています。これには、データのクリーニング、様々なインデックスタイプの試行、ブロック分割戦略の最適化、Base Promptの使用、メタデータフィルタリングの使用、クエリルーティングの使用、並べ替えの検討、クエリ変換の使用、埋め込みモデルの微調整、LLMエコシステム関連ツールの使用が含まれます。これらの戦略はすべて、RAGシステムのパフォーマンスをさまざまな程度に向上させることができます。

全体として、この記事は RAG システム開発者にとって非常に参考になるものであり、注意深く読んで実践する価値があります。

著者 | マット・アンブロジ

編纂者：岳陽

01 クイックスタートガイドですが、このセクションだけを読むだけでは不十分です。

検索拡張生成（LAG）は、ChatGPTのような大規模言語モデル（LLM）を、ユーザー（またはシステム）が他の場所から取得した情報で補完するプロセスです。LLMはこの情報を用いて、応答生成を強化します。— Cory Zue

「検索拡張生成とは、ChatGPTのような大規模言語モデル（LLM）へのユーザー入力を、システムが別の場所から取得した追加情報で補完するプロセスです。LLMはその情報を用いて、生成する応答を拡張することができます。」— Cory Zue

大規模言語モデル（LLM）は素晴らしい発明ですが、深刻な問題を抱えがちです。それは、何もないところから情報を捏造してしまう可能性があることです。RAG（Rapid Aspects of Language）は、ユーザーの質問やクエリに回答する際に文脈を提供することで、LLMの実用性を高めます。

LangChain や LlamaIndex などのフレームワークのクイック スタート ガイドを使用すると、わずか 5 行程度のコードを使用して、ドキュメント用のチャットボットなどのシンプルな RAG システムを簡単に構築できます。

しかし、たった5行のコードで構築されたチャットボットは、パフォーマンスがあまり良くありません。RAGはプロトタイプ作成は容易ですが、本番環境への導入は非常に困難であり、ユーザー満足度の達成は困難です。これらの基本的な使用方法でRAGの効果を80%まで高めることはできますが、残りの20%にはさらなる実験が必要になることがよくあります。RAGのベストプラクティスはまだ改良中であり、ユースケースによって異なります。しかし、RAGはLLMを活用する最も効果的な方法の一つである可能性があるため、ベストプラクティスを見つけることは間違いなく価値があります。

この記事では、RAGシステムの品質向上のための戦略をいくつか紹介します。特に、基本構成（使用可能）と本番環境対応（使用可能で使いやすい）のパフォーマンスギャップを縮めたいと考えているRAGシステム開発者向けにカスタマイズされています。原題の「改善」とは、RAGシステムが（1）関連するコンテキストを見つけ、（2）関連する応答を生成できるユーザークエリの割合を増やすことを意味します。この記事は、読者がRAGの仕組みを既に理解していることを前提としています。そうでない場合は、Cory Zueの記事「 RAG（Retrieval Enhancement Generation）テクノロジの説明：垂直ドメインの独自データに基づくチャットボットの実装方法」を読むことをお勧めします。また、この記事では、読者がこれらのRAGツールの構築に使用される一般的なフレームワークであるLangChain[1]とLlamaIndex[2]の基礎知識を持っていることも前提としています。ただし、この記事で説明する内容は、これらのフレームワークとはほとんど関係がありません。

紹介する各戦略の具体的な実装方法については深く掘り下げませんが、読者の皆様に、これらの戦略がいつ、なぜ役立つのかをご理解いただけるよう努めます。この分野の発展は急速に進んでいるため、RAGに関する網羅的かつ最新のベストプラクティスガイドを提供することは不可能です。その代わりに、この記事の目的は、開発者がRAGアプリを試用し、改善する際に考慮すべき事項を概説することです。

02 検索強化生成システムのパフォーマンスを向上させる10の方法

2.1 データのクリーニング

RAG は LLM の機能をデータに接続します。データの内容やレイアウトが整理されていない場合、RAG システムは問題に遭遇します。使用されるデータに矛盾または冗長な情報が含まれている場合、検索システムは正しいコンテキストを見つけるのに苦労します。たとえ正しいコンテキストを見つけることができたとしても、LLM によって実行される生成手順は最適ではない可能性があります。たとえば、会社のヘルプ ドキュメント用のチャットボットを構築しているが、効果がないという場合を考えてみましょう。最初に確認すべきことは、システムに入力されるデータです。トピックは適切に分類されていますか。トピックは 1 か所に集中していますか、それとも複数の場所に分散していますか。人間であるあなたが、一般的なクエリの回答を得るためにどのドキュメントを参照すればよいかを簡単に判断できない場合、検索システムもその判断に失敗します。

このプロセスは、同じトピックのドキュメントを手動でマージするだけのシンプルなものもあれば、よりクリエイティブな方法もあります。私が目にしたもう一つの革新的なアプローチは、LLM（限定言語管理）を用いてすべてのドキュメントの要約を作成するというものです。検索システムはまずこれらの要約を検索し、必要な場合にのみドキュメントの詳細を掘り下げます。一部のフレームワークには、LLMを用いた要約作成と検索のための機能が組み込まれています。

2.2 さまざまなインデックスタイプの探索

インデックスはLlamaIndexとLangChainの中核を成す柱であり、検索システムを支える「列」として機能します。RAGの一般的な標準的なアプローチは、埋め込みと類似性検索です。コンテキストデータはチャンク化され、すべてのコンテンツは埋め込みベクトルに変換されます。クエリを受信すると、コンテキストから類似のフラグメントが検索されます。このアプローチは非常に効果的ですが、あらゆる状況に適しているわけではありません。特定のコンテンツ（オンラインストアの商品など）を検索する必要がある場合は、キーワードベースの検索を検討するとよいでしょう。ただし、これらの手法は必ずしも相互に排他的ではなく、多くのアプリケーションではハイブリッドな検索アプローチが採用されています。例えば、キーワードベースのインデックスは特定のコンテンツを含むクエリに使用し、埋め込みは一般的な顧客サポートに使用されます。

2.3 さまざまな文書分割方法を試す

コンテキスト データをチャンク化することは、RAG システム構築の中心的なステップです。これらの RAG フレームワークはチャンク化プロセスを抽象化するため、プロセスを理解しなくても直接使用できます。ただし、プロセスを理解する必要があり、チャンク サイズを決定することが重要です。RAG アプリに最も効果的な方法を検討する必要があります。一般に、チャンク サイズが小さいほど検索パフォーマンスは向上しますが、生成されたコンテンツのコンテキストの関連性が欠如する可能性があります。チャンク化の方法は多数ありますが、盲目的にチャンク化することは現実的ではありません。PineCone のこの記事 [3] では、参照できる戦略がいくつか紹介されています。こちらは、実験でテストできる一連のテスト問題例です [4]。各質問セットは、小、中、大のチャンク サイズでループで 1 回テストされ、結果は小さいチャンク サイズが最適であることを示しました。

2.4 Base Promptを使ってみる

LlamaIndex で Base Prompt (翻訳者注: 大規模な言語モデルを使用してモデルが対応するテキストまたは回答を生成するようにガイドするために提供される最初のプロンプトまたは指示を指します) を使用する典型的な例は次のとおりです。

以下はコンテキスト情報です。既存の知識に関わらず、コンテキスト情報に基づいて関連するクエリに回答してください。

「コンテキスト情報は以下にあります。事前知識ではなく、コンテキスト情報に基づいてクエリに回答してください。」

上記のプロンプトを他のプロンプトに置き換えたり、RAGを変更して、コンテキスト内に高品質の関連情報が見つからない場合にLLMが自身の知識に頼れるようにすることも可能です。プロンプトを変更することで、モデルの様々な種類の質問に対する受け入れや応答に影響を与えることができます。例えば、主観的な質問に特定の方法で回答するように指示することができます。少なくとも、LLMが何をしているのかを知らせるためにプロンプ​​トを変更することは非常に役立ちます。例えば、以下のようになります。

あなたはカスタマーサポート担当者です。質問に回答する際には正確な情報を提供し、質問者の問題解決を可能な限り支援することが目標です。丁寧な対応を心がけつつ、冗長にならないようにしてください。以下にコンテキスト情報を示します。既存の知識にとらわれず、コンテキスト情報に基づいて適切な質問にご回答ください。

「あなたはカスタマーサポート担当者です。事実に基づいた情報のみを提供しながら、できる限り役立つ情報を提供するよう努めてください。フレンドリーな対応を心がけますが、おしゃべりになりすぎないようにご注意ください。コンテキスト情報は以下に記載されています。事前知識ではなく、コンテキスト情報に基づいて質問に答えてください。」

2.5 メタデータフィルタリングを試す

検索効率を向上する非常に効果的な戦略の 1 つは、データ ブロックにメタデータを追加し、それを使用して結果の処理に役立てることです。日付は、時間でフィルタリングできるため、一般的なメタデータ タグです [5]。ユーザーがメール履歴をクエリできるアプリケーションを開発しているとします。この場合、最新のメールの方が関連性が高い可能性がありますが、埋め込みの観点からは、これらのメールがユーザーのクエリに最も類似しているかどうかはわかりません。このことから、RAG を構築するときに念頭に置くべき一般的な概念、つまり類似度 ≠ 関連性が導き出されます。各メールの日付をそのメタデータに追加して、検索プロセス中に最新の日付のコンテキストを優先することができます。LlamaIndex には、これを実現するのに役立つ Node Post-Processors という組み込みツールがあります。

2.6 クエリルーティングの使用

複数のインデックスを持つことは、一般的に非常に便利です。クエリが到着すると、適切なインデックスにルーティングできます。例えば、あるインデックスは要約的な質問に対応し、別のインデックスは具体的な質問に対応し、さらに別のインデックスは正確な回答を得るために時間的な要素を考慮する質問に対応します。これらすべての動作に対して単一のインデックスを最適化しようとすると、最終的にはすべての動作に悪影響を与えます。代わりに、クエリを適切なインデックスにルーティングすることができます。別のユースケースとして、セクション2.2で説明したように、一部のクエリをキーワードベースのインデックスに誘導することもできます。

インデックスを構築したら、テキスト内の各インデックスの目的を定義するだけです。その後、クエリ実行時にLLMが適切なインデックスを選択します。

2.7 研究の並べ替え

リランキングは、類似性と関連性の不一致に対処するためのアプローチの一つです。リランキングでは、検索システムは通常通りコンテキストの最上位ノードを取得し、関連性に基づいて並べ替えます。この目的では、Cohere Rereanker[6]が一般的に用いられます。RAGの専門家がこの戦略を推奨しているのをよく見かけます。いずれにせよ、RAGを用いてシステムを構築する場合は、リランキングを試してみて、システムの改善効果を確認してみることをお勧めします。

2.8 クエリ変換の使用を検討する

前のセクションでは、ユーザーのクエリを基本プロンプトに入力して RAG システムを最適化する方法を紹介しましたが、さらに変更を加えることも可能です。

• 言い換え：RAGシステムがクエリの適切なコンテキストを見つけられない場合、LLMはクエリを言い換えて再送信できます。埋め込み空間では、人間には同一に見える2つの質問が、必ずしも非常に似ているとは限りません。

• HyDE ：HyDE[7]は、クエリを受け取り、仮説的な応答を生成し、その両方を同時に埋め込み検索に用いる戦略です。この手法はRAGシステムのパフォーマンスを大幅に向上させることが研究で示されています。

• サブクエリ：複雑なクエリを分解すると、LLMのパフォーマンスが向上することがよくあります。クエリを複数の質問に分割することで、これをRAGシステムに組み込むことができます。

LLamaIndexのドキュメントでは、これらのタイプのクエリ変換について説明しています[8]。

2.9 埋め込みモデルの微調整

RAGの標準的な検索メカニズムは、埋め込みベクトルの類似性に基づいています。データは分解され、インデックスに埋め込まれます。クエリを受信すると、クエリも埋め込みベクトルに変換され、インデックス内の埋め込みベクトルと比較されます。では、テキストを埋め込みベクトルに変換するのは何でしょうか？通常は、OpenAIのtext-embedding-ada-002などの事前学習済みモデルが用いられます。

問題は、事前学習済みモデルが特定の分野における類似性の概念をうまく捉えられない可能性があることです。例えば、法律文書を扱っているとします。埋め込みでは、「したがって」や「合意」といった一般的な用語ではなく、「知的財産」や「契約違反」といった分野特有の用語に基づいて類似性を判断するようにしたいと考えるでしょう。

この問題は、埋め込みモデルを微調整することで解決できます。これにより、検索性能指標が5～10%向上する可能性があります。微調整には多少の追加作業が必要ですが、RAGシステムの検索性能を大幅に向上させることができます。LlamaIndexはトレーニングセットの生成に役立つため、このプロセスは想像以上に簡単です。詳細については、Jerry LiuによるLlamaIndexを用いた埋め込みモデルの微調整方法に関する記事[9]、または微調整プロセスについて説明した記事[10]を参照してください。

2.10 LLMエコシステム関連の開発ツールの使用開始

RAGシステムの構築にLlamaIndexまたはLangChainを既にご利用いただいているかもしれません。どちらのフレームワークにも便利なデバッグツールが搭載されており、コールバック関数の定義、使用されているコンテキストの確認、検索結果の元となるドキュメントの確認などが可能です。

これらのフレームワークの組み込みツールが不十分だと感じる場合、RAGシステムの仕組みをより深く理解するのに役立つツールのエコシステムも成長を続けています。Arize AIには、取得されたコンテキストがどのように、そしてなぜ取得されたのかを調査するのに役立つ組み込みツール[11]があります。Rivet [12]は、複雑なエージェントの構築を支援する視覚的なインターフェースを提供するツールで、リーガルテック企業のIroncladがオープンソース化しました。新しいツールが絶えずリリースされており、どれが自分のワークフローに役立つか試してみる価値があります。（訳注：BaiHai Technologyの大規模モデルプラットフォームであるIDP LMも、ドメイン固有の大規模モデルの構築をゼロコードで微調整するのに役立ちます。）

03 結論

RAG システムの構築は、実行するのは非常に簡単ですが、うまく機能させるのは非常に難しいため、イライラすることがあります。上記の戦略が、読者のインスピレーションとなり、このギャップを可能な限り埋めるのに役立つことを願っています。これらのアイデアは 1 回限りの解決策ではなく、実践は試行錯誤のプロセスです。この記事では、システムのパフォーマンスを評価する方法については詳しく説明していません。評価プロセスは現在、科学よりも芸術ですが、継続的に評価できるシステムを構築することが非常に重要です。これは、実装されている戦略が機能しているかどうかを判断する唯一の方法です。以前、RAG システムを評価する方法に関する記事を書きました [13]。詳細については、LlamaIndex Evals [14]、LangChain Evals [15]、および非常に有望な新しいフレームワークである RAGAS [15] について学んでください。

おめでとうございます！成功しました！

読んでくれてありがとう！

終わり