著者🎨 |スワラケシュ・ムラリー 編纂者：岳陽 Unsplash[2]のtravelnow.or.crylater[1]による写真 ユーザーがLLMに毎回完璧な質問をすると考えているなら、それは大きな間違いです。ユーザーのクエリを直接実行するのではなく、最適化してみてはいかがでしょうか？これがクエリ変換技術と呼ばれるものです。 当社がこれまでに作成したすべての文書（PowerPointプレゼンテーション、プロジェクト提案書、進捗報告書、納品書など）を検索できるアプリケーションを開発しました。過去にも同様の試みが何度も失敗してきたため、これは画期的な成果です。RAGのおかげで、今回は非常にうまくいきました。 プロジェクトのデモンストレーション段階では、私たち全員がこのアプリケーションに大きな熱意を示しました。当初は少数の従業員にのみ導入を勧めましたが、実際に目にした印象はそれほど刺激的なものではありませんでした。 当初、このアプリは人々の働き方を完全に変えるだろうと考えられていましたが、ほとんどのユーザーは、まるでアプリが単なる子供のおもちゃであるかのように、数回試しただけで使用をやめてしまいました。 ログデータではアプリのパフォーマンスは良好でしたが、実際にアプリを使用したユーザーと意見交換を行い、問題を特定しました。彼らのフィードバックに基づき、クエリ変換技術を用いてユーザー入力の曖昧さを排除する方法を検討し始めました。 具体的な例を見てみましょう。 あるユーザーは、クライアント「XYZ」へのファッション関連事業の買収に関するアドバイスに興味を示しました。彼の質問は、「XYZのパートナー企業は、これまでにどのようなファッション関連企業を買収してきましたか？」というものでした。アプリケーションは関連するPowerPointプレゼンテーションを取得し、12社以上の企業リストを生成しました。しかし、このリストはユーザーの期待とは大きく異なっていました。例えば、XYZは実際には7つのファッションブランドを買収していましたが、リストには4社しか記載されていませんでした。このユーザーはテスターでもあり、実際の買収件数を把握していました。 人々がこのツールを放棄したのも無理はありません。幸いなことに、段階的に全ユーザーに展開するという当社の戦略により、失った信頼を取り戻すチャンスはまだ残っています。 この問題に対処するため、アプリケーションに一連の改良を実施しました。重要なアップデートの一つは、クエリ翻訳技術です。 本論文では、詳細な技術的分析には立ち入ることなく、私たちが用いる様々なクエリ翻訳技術の概要を説明することを目的としています。例えば、これらの技術は、few-shot promptingやchain of thoughtsといったプロンプト技術と組み合わせることで、結果を最適化することができます。ただし、これらの技術の技術的な詳細については、後続の論文[3]で詳しく説明します。 次に、これらの手法を一つずつ検証していきます。その前に、簡単なRAGの例を見てみましょう。 01 基本的なRAGの例RAG（Retrieval-Augmented Generation：検索拡張生成）アプリケーションは通常、少なくとも1つのデータベース（通常はベクトルストアと言語モデル）を備えています。RAGの中核となる概念は非常にシンプルです。大規模言語モデル（LLM）が既存の知識を用いてユーザーの質問に答える前に、まずデータベース内で関連するコンテキスト情報を検索し、より正確な回答を生成します。 下の画像は、RAG アプリケーションの基本的な例を示しています。 基本的な RAG アプリケーション ワークフロー — 画像は著者によるものです。 基本的なRAG（検索強化生成）アプリケーションでは、大規模言語モデル（LLM）とのやり取りは一度だけ行われます。LLMは、OpenAIのGPTモデル[4]、Cohereモデル[5]、あるいはローカルにデプロイしたモデルなどです。 以下のコードは、上図に示した基本的なRAGワークフローの実装方法を示しています。このコードを基に、この記事で紹介する他の手法をさらに詳しく見ていきます。 上記のコードでは、Webベースのローダーを使用してDjangoの公式ドキュメントページを取得し、そのコンテンツをChromaベクターデータベースに保存しています。この処理は、Webドキュメント、ローカルテキストドキュメント、PDFドキュメントなど、さまざまな種類のデータリソースに適用できます。 この例では、高度な検索技術を使用する代わりに、リトリーバーを最終的なRAG（検索強化生成）プロセスに直接統合しました。後ほど、単一のリトリーバーではなく、リトリーバーチェーンを使用します。以下のセクションでは、リトリーバーチェーンの構築方法に焦点を当てます。 02 ステップバックプロンプト
ステップバックプロンプティングは基本的なRAGプロセスと非常に似ていますが、ユーザーが送信した質問を処理する際に、ユーザーの最初の質問を直接照会するのではなく、より広範な質問を用いてデータベースから関連文書を取得します。 具体的な質問と比較して、より広範な質問はより多くの文脈情報を捉えます。そのため、大規模言語モデル（LLM）は、全体的な文脈と矛盾することなく、この情報に基づいてより有用な情報をユーザーに提供できます。 このアプローチは、最初のクエリが具体的かつ詳細すぎるが、全体的な視点が欠けている場合に非常に役立ちます。 ステップバックを促すワークフロー — 画像は著者によるものです。 ステップバックプロンプトのプロセスは次のとおりです。言語モデルは最初にユーザーによるクエリ入力を拡張し、次にベクター データベースから関連ドキュメントを取得して必要なコンテキストを提供し、ユーザーが最初に提示した質問に答えます。 以下は、ステップバックプロンプトのコード実装です。前述の基本的なRAGワークフローで検索エンジンを直接渡す方法とは異なり、ここでは異なるアプローチを採用していることに注意してください。 ステップバックプロンプトは、より広範な文脈情報を必要とするアプリケーションに非常に役立ちます。これにより、LLMは関連する質問に対して一貫した回答を提供できます。 03 HyDE（仮想文書埋め込み）
HyDE（ハイブリッド・ドキュメント・エンベディング）は、最近人気が高まり、広く採用されている文書検索技術です。その核となる考え方は、大規模言語モデル（LLM）によって学習された事前知識を用いて文書を作成し、それらの文書を用いてベクターデータベースから関連する文脈情報を取得または抽出することです。 HyDEは、ユーザーが問題を平易な言葉で説明する一方で、ベクターデータベース内の情報は高度に専門的であるような状況に特に適しています。さらに、LLMによって生成されるテキスト情報にはより多くのキーワードやキーフレーズが含まれるため、取得される関連情報はより正確になります。 たとえば、「Django のパフォーマンスを向上させる 10 の方法」のようなクエリに対して、HyDE はコストの影響、キャッシュ戦略、データ圧縮などを網羅した包括的な回答を提供できます。 HyDE ドキュメント検索プロセス — 画像は著者によるものです。 以下のコードスニペットは、上の画像に示したコード実装です。今回は、HyDEを使用して取得チェーンを構築するコードスニペットのみを提供しました。 04 マルチクエリ
マルチクエリ技術は、距離ベースの類似度検索で発生する可能性のある問題に対処するのに役立ちます。ほとんどのベクターデータベースは、ベクター化された文書を検索する際に、コサイン類似度を指標として使用します。この手法は、文書間の類似度が十分に高い限り、一般的に良好なパフォーマンスを発揮します。しかし、類似度が低すぎて距離ベースの類似度指標を用いて関連性を効果的に識別できない場合、検索プロセスは期待どおりの結果を得られない可能性があります。 マルチクエリアプローチでは、大規模言語モデル（LLM）を用いて、同じクエリを複数のバージョンに変換します。例えば、「Djangoアプリを高速化する方法」というクエリは、「Djangoベースのウェブアプリのパフォーマンスを向上させる方法」という別のバージョンに変換されます。これらのクエリは連携して、ベクターデータベースからより関連性の高いドキュメントを取得します。 これらの文書をRAG-LLMに渡して最終的な回答を生成する前に、取得した文書の重複を除去する必要があります。これは、複数のクエリで同じ文書が取得される可能性があるためです。すべての文書を渡すと重複が発生し、LLMのトークンしきい値を超え、最終的な回答の品質に影響を与える可能性があります。 マルチクエリ検索ワークフロー — 著者による画像。 以下のコードスニペットは、ドキュメントから重複を削除する追加機能を実装しています。残りの部分は他のメソッドと一貫性を保っています。 05 RAGフュージョン情報の検索と回答の生成のプロセスでは、ユーザーの質問に関連性の高いドキュメントを優先して活用することが重要です。これらのドキュメントは、正確で有用な回答を生成するために役立つ情報を提供するからです。 RAG融合とマルチクエリは、文書検索において多くの類似点を持っています。ここでは、大規模言語モデル（LLM）を用いて、初期クエリの複数の異なるバージョンを生成します。そして、これらの異なるバージョンのクエリを個別に使用して対応する文書を取得し、それらをマージします。 ただし、ドキュメントをマージおよび重複排除する際には、関連性に基づいて並べ替えも行います。以下は、RAG-fusionワークフローの図です。 RAG 融合ワークフロー — 画像は著者によるものです。 単純に重複排除を行うのではなく、ランキングシステムを用いてドキュメントをソートします。相互融合ランキング（RRF）は、非常に巧妙なドキュメントランキングアルゴリズムです。 クエリの複数のバージョンで同じ文書が取得され、その文書が最も関連性の高い場合、RRFアルゴリズムはその文書を上位にランク付けします。一方、ある文書がクエリの1つのバージョンにのみ出現し、かつ関連性が低い場合、RRFはその文書を下位にランク付けします。このようにして、より関連性の高い情報を取得し、優先順位を付けることができます。 06 分解複雑な問題を扱う場合、大規模言語モデル (LLM) を使用すると、問題を複数の部分に分割し、徐々に答えを構築することができます。 場合によっては、単に答えを提供するだけでは最善の戦略とは言えません。複雑な課題を効率的に解決するには、問題をいくつかの部分に分割し、それぞれの部分に一つずつ答えていくことが効果的です。 これはLLM特有のテクニックではないですよね？ はい、クエリを分解する過程で、最初の問題を複数のサブ問題に分解しようとします。これらのサブ問題への答えを見つけることで、最初の問題を解決するための手がかりが得られます。 RAG でのクエリ分解 — 画像は著者によるものです。 図に示すように、各サブ質問に関連する文書を取得し、個別に回答します。その後、これらの質問と回答のペアをRAG-LLMに渡します。これにより、LLMは複雑な問題を解決するためのより詳細な情報を得ることができます。 07 最終的な考えこのアプリケーションは、デモ版から本番環境への導入に至るまで、多くの最適化プロセスを経てきました。このプロセスにおいて避けられないステップの一つが、クエリ変換技術の活用でした。 私たちが解決する問題は複雑さの度合いが様々です。ユーザークエリが不完全であることは当たり前のことであることを考慮する必要があります。また、検索プロセスにおける欠陥にも対処する必要があります。これらはすべて考慮すべき問題です。 最適なクエリ変換手法を選択するための唯一の正しい方法は存在しません。実際のアプリケーションでは、望ましい出力結果を得るために複数の手法を組み合わせる必要がある場合があります。 読んでくれてありがとう！ このブログを楽しんで、新しいことを学んでいただければ幸いです。 トゥワラケシュ・ムラリー データサイエンスジャーナリスト＆独立コンサルタント https://www.linkedin.com/in/thuwarakesh/ 終わり 🔗記事内のリンク🔗[1] https://unsplash.com/@travelnow_or_crylater?utm_source=medium&utm_medium=referral [2] https://unsplash.com/?utm_source=medium&utm_medium=referral [3] https://towardsdatascience.com/advanced-retrieval-techniques-for-better-rags-c53e1b03c183 [4] https://platform.openai.com/docs/models [5] https://cohere.com/ この記事は、原著者の許可を得てBaihai IDPによって翻訳されました。翻訳の転載をご希望の場合は、お問い合わせください。 オリジナルリンク: https://towardsdatascience.com/5-proven-query-translation-techniques-to-boost-your-rag-performance-47db12efe971 |
