検索強化生成システム（RAG）のケーススタディから学ぶ教訓と失敗
3つの要点
✔️ 検索強化生成システムに関して、3つのケーススタディから学んだ教訓と7つの失敗点を紹介
✔️ 実務者向けの参考資料を提供し、検索強化生成システムの研究ロードマップを提示
✔️ ケーススタディの共有によって、ソフトウェアエンジニアリングのコミュニティへの貢献
Seven Failure Points When Engineering a Retrieval Augmented Generation System
written by Scott Barnett, Stefanus Kurniawan, Srikanth Thudumu, Zach Brannelly, Mohamed Abdelrazek
(Submitted on 11 Jan 2024)
Comments: Published on arxiv.
Subjects: Software Engineering (cs.SE); Artificial Intelligence (cs.AI)
code：
本記事で使用している画像は論文中のもの、紹介スライドのもの、またはそれを参考に作成したものを使用しております。
概要
検索強化生成（RAG）を使ってアプリケーションにセマンティック検索を実装することが増えています。検索強化生成システムは、ユーザーのクエリに合うドキュメントを見つけ、それをChatGPTなどの大規模言語モデル（LLM）に渡して正しい回答を生成する仕組みです。この方法は、大規模言語モデルによる誤った情報（ハルシネーション、幻覚）を減らし、回答に出典を関連づけ、ドキュメントにメタデータを付ける手間を省くことができます。
しかし、検索強化生成システムにも情報検索システムに特有の制約や大規模言語モデルに依存する問題があります。この論文では、研究、教育、バイオメディカルの3つの分野でのケーススタディを通じて、検索強化生成システムの失敗例を報告しています。著者らが研究から学んだ教訓を共有し、検索強化生成システムを設計する際に考慮すべき7つのポイントを提示しています。
この論文の重要なポイントは、検索強化生成システムの検証は実際に運用してみないとわからないこと、その堅牢性は初めから設計されるのではなく、進化していくものだということです。また、ソフトウェアエンジニアリングのコミュニティ向けに、検索強化生成システムに関する今後の研究方向を示しています。
大規模言語モデルの進展により、ソフトウェアエンジニアは新たなHCIソリューションを構築し、複雑なタスクを完了し、ドキュメントを要約し、質問に答え、新しいコンテンツを生成することができます。しかし、大規模言語モデルのみで企業内の最新情報や専門知識を網羅する限界があります。この問題を解決するための方法として、大規模言語モデルをファインチューニングするか、検索強化生成システムを使用するかの2つの選択肢があります。ファインチューニングは、ドメイン固有のデータで大規模言語モデルを再学習する必要があり、管理が大変になります。一方、検索強化生成システムは既存の知識を使って回答を生成するため、管理の手間を減らすことができます。
検索強化生成システムは、情報検索と生成の両方の機能を組み合わせ、ユーザーのクエリに対して文脈的に関連する正確で最新の情報を提供することができます。これにより、ナレッジグラフの構築やデータのキュレーションが不要となり、開発時間を短縮することができます。
ソフトウェアエンジニアが検索強化生成システムを構築する際には、ドメイン知識を適切に前処理し、適切なデータストアに保存し、クエリとアーティファクトをマッチングする戦略を実装し、大規模言語モデルのAPIを呼び出してユーザークエリと文脈のドキュメントを渡すことが求められます。新しい検索強化生成システムの構築方法は常に進化していますが、特定のアプリケーションにどのように適用されるかを見極める必要があります。
この論文では、3つのケーススタディから学んだ教訓と7つの失敗点を紹介しています。これにより、実務者向けの参考資料を提供し、検索強化生成システムの研究ロードマップを提示しています。また、この論文は、ソフトウェアエンジニアリングのコミュニティは、大規模言語モデルを活用して堅牢なシステムを実現する方法についての知識を提供する責任があると考えており、この研究が検索強化生成システムの構築における堅牢性に対する重要な一歩となることを期待して、作成されています。
検索強化生成（RAG）の概要
大規模言語モデルであるChatGPT、Claude、Bardなどが急速に普及する中、これらを質問応答システムとして利用するケーススタディがよく見られます。これらのモデルは非常に高い性能を示すものの、大きな課題があるとされています。1つは、幻覚（ハルシネーション）と呼ばれ、大規模言語モデルが一見すると正しそうだが、間違った回答を生成することです。もう1つは、出力内容を制御または更新する方法がない（プロンプトエンジニアリングを除く）ことです。検索強化生成システムは、これらの課題を克服するために設計された手法です。
最初にインデックスプロセスがあります。検索強化生成システムでは、自然言語のクエリを数値ベクトル（埋め込み）に変換し、これを使ってドキュメントをセマンティックに検索します。ドキュメントは小さいチャンクに分割され、それぞれが埋め込みに変換されてデータベースにインデックスされます。このプロセスで、ソフトウェアエンジニアはチャンクのサイズを適切に設定する必要があります。チャンクが小さすぎると特定の質問に答えられず、大きすぎるとノイズが混じる可能性があります。
異なる種類のドキュメントには異なるチャンク分割と処理が必要です。例えば、動画コンテンツは音声をテキストに変換するトランスクリプションが必要です。また、使用する埋め込みモデルの選択も重要とされており、これによりすべてのチャンクを再インデックスする必要が生じる場合があります。埋め込みは、セマンティックに正しい応答を検索する能力に基づいて選ばれます。
次にクエリプロセスです。これは、検索の実行時に行われます。自然言語の質問はまず一般的なクエリに変換され、埋め込みが計算されてデータベースから関連ドキュメントを検索します。上位k件の類似ドキュメントがコサイン類似度などの手法を用いて検索されます。これにより、クエリにセマンティックに近いチャンクが回答を含む可能性が高くなります。
検索されたドキュメントは再びランク付けされ、回答を含むチャンクが上位に位置するように調整されます。次の段階では、大規模言語モデルのトークン制限やレート制限を考慮してチャンクを処理されます。例えば、OpenAIのサービスには、プロンプトに含めるテキストの量に制限があり、システムの待ち時間も制約されています。
検索強化生成システムの最後には、生成されたテキストから回答が抽出されます。リーダー（Reader）は、プロンプトからノイズを取り除き、フォーマット指示に従ってクエリに対する出力を生成します。検索強化生成システムの実装には、質問と回答を処理するために複数のプロンプトをカスタマイズする必要があります。
リアルタイムにドキュメントから質問に回答するために大規模言語モデルを使用することは、新たなアプリケーション領域を切り開く可能性があります。しかし、検索強化生成システムはテストが困難であり、データが存在しないため、合成データの生成や最小限のテストでシステムを試験運用する必要があります。
ケーススタディ
この研究では、検索強化生成システムを実装する際に直面する課題を明らかにするため、3つのケーススタディを検証しています。各ケーススタディの概要は下表にまとめられているとおりです。
1つ目のケーススタディは、Cognitive Reviewerです。これは、科学文書の分析を支援するために設計された検索強化生成システムです。研究者は質問や目的を指定し、それに関連する研究論文をアップロードします。システムは、指定された目的をもとに文書をランク付けし、研究者が手動でレビューできるようにしています。また、研究者はすべての文書に対して直接質問をすることもできます。Cognitive Reviewerは、ディーキン大学の博士課程の学生によって文献レビューの支援に使用されています。このシステムは、実行時にインデックスプロセスを行い、アップロードされた文書を処理するための堅牢なデータ処理パイプラインに依存しています。また、ランク付けアルゴリズムを使用して文書を並べ替えています。
2つ目のケーススタディは、AI Tutorです。これは学生がユニットに関する質問を行い、学習コンテンツから回答を得るための検索強化生成システムです。学生は回答元のリストにアクセスして回答を確認することができます。AI Tutorは、ディーキン大学の学習管理システムに統合されており、PDF文書、動画、テキスト文書などのすべてのコンテンツをインデックス化します。動画はディープラーニングモデルWhisperを使用して文字起こしされ、チャンク化されます。AI Tutorは2023年8月から11月までに開発され、2023年10月末に200人の学生を対象としたユニットでパイロットテストが行われました。このパイプラインには、クエリを一般化するリライター（Rewriter）が含まれており、ユーザーとAI Tutorの過去の対話から文脈を読み取るチャットインターフェースを実装しました。リライターは、この文脈を考慮してクエリを書き直し、曖昧な要求を解消しています。
3つ目のケーススタディは、バイオメディカルの質問応答です。上述のケーススタディでは内容の少ない文書に焦点を当てましたが、より大規模な問題を探るためにBioASQデータセットを使用して検索強化生成システムを作成しています。このデータセットには、質問、文書へのリンク、回答が含まれています。質問に対する回答は、はい/いいえ、テキスト要約、ファクトイド、リストのいずれかになっています。BioASQデータセットから4,017のオープンアクセスの文書をダウンロードし、合計1000の質問を用意しています。すべての文書がインデックス化され、検索強化生成システムに対して質問が行われます。
生成された質問は、OpenAIによって実装されたOpenEvals技術を使用して評価されています。40の問題を手動で検査し、OpenEvalsが不正確とフラグを立てたすべての問題も検査しています。このドメインでは、自動評価は人間の評価者よりも悲観的であることが分かりました。しかし、この発見には妥当性の脅威があり、それはBioASQが特定のドメインに特化したデータセットであり、レビュアーが専門家でなかったためとしています。つまり、大規模言語モデルは非専門家よりも多くの知識を持っている可能性があるとしています。
検索強化生成システムの失敗例
この論文では、上述の3つのケーススタディから、検索強化生成システムにおける以下の7つの失敗点を特定しています。これらは、検索強化生成システムを開発する際に発生する主な問題点としています。
1つ目は、コンテンツの欠如（FP1）です。システムが利用可能なドキュメントから回答できない質問を受けた場合に発生します。理想的には、「申し訳ありませんが、わかりません」などと断りの応答が望ましいですが、関連する質問に対して誤った回答を生成する可能性があります。
2つ目は、上位ランクのドキュメントの見落とし（FP2）です。回答がドキュメント内に存在するが、十分に高いランク付けがされていないためにユーザーに返されない場合です。理論上はすべてのドキュメントがランク付けされますが、実際には性能に基づいて選ばれた上位K件のみが返されてしまいます。
3つ目は、文脈に含まれない（FP3）です。回答が含まれるドキュメントが取得されたが、回答を生成する文脈に含まれていない場合です。多くのドキュメントが返された際に、統合プロセスで回答が適切に取得されないことが原因です。
4つ目は、抽出されない（FP4）です。文脈に回答が存在しているが、大規模言語モデルが正しい回答を抽出できなかった場合です。これは、文脈にノイズや矛盾した情報が多すぎる時に発生します。
5つ目は、フォーマットの間違い（FP5）です。質問が表やリストなど特定の形式での情報抽出を要求している場合に、大規模言語モデルが指示を無視することです。
6つ目は、特異性の欠如（FP6）です。回答が返されても、ユーザーのニーズに対して特異性が足りない、または過剰である場合です。特に、教育コンテンツが含まれるべき質問に対して単なる回答だけが返される場合や、ユーザーが質問の仕方に確信が持てず一般的すぎる場合に発生します。
最後、7つ目は、不完全な回答（FP7）です。不完全な回答は誤りではありませんが、抽出可能な情報の一部が欠落している場合です。例えば、「ドキュメントA、B、Cでカバーされている主要なポイントは何ですか？」という質問に対しては、個別に尋ねる方が良いものです。
以上の失敗例は、検索強化生成システムの設計と実装時に注意すべき重要なポイントです。
教訓と今後の研究方向
この論文では、3つのケーススタディから得られた教訓をもとに、検索強化生成システムをエンジニアリングする際の考慮事項と、今後の研究課題をまとめています。
1つ目は、チャンク化と埋め込みに関してです。ドキュメントのチャンク化は一見簡単そうに見えますが、その質は検索プロセスに多大な影響を与えます。特に、チャンクの埋め込みが類似性やユーザークエリとのマッチングに影響します。チャンク化には、句読点や段落の終わりなどを利用するヒューリスティックベースと、テキストの意味を基に開始・終了を決定するセマンティックチャンク化の2つの方法があります。これらの方法のトレードオフや、埋め込みや類似性マッチングなどの重要なプロセスへの影響を探る研究が必要です。クエリの関連性や検索精度を指標にした評価フレームワークが、この分野に貢献するとしています。
埋め込みは、表、図、数式などのマルチメディアやマルチモーダルチャンクの生成を含む活発な研究分野です。チャンクの埋め込みは通常、システム開発時や新しいドキュメントがインデックスされた際に一度生成されます。クエリの前処理は検索強化生成システムの性能に大きな影響を与え、特に否定的または曖昧なクエリの処理が重要です。埋め込みの固有の制限に対処するためのアーキテクチャパターンとアプローチに関するさらなる研究が求められるとしています。
2つ目は、微調整に関してです。大規模言語モデルは膨大なトレーニングデータを基にした優れたモデルですが、リリース前に行われる微調整タスクも影響します。しかし、これらのモデルは一般的な目的のためのものであり、特定のドメインの詳細を知らない場合があります。また、知識のカットオフ日が設定されています。微調整と検索強化生成は、それぞれ異なるトレードオフを持つ2つのカスタマイズ方法です。
微調整は、内部データセットをキュレーションし、大規模言語モデルをトレーニングする必要がありますが、データがモデルに組み込まれるため、セキュリティやプライバシーの問題があります。また、基礎モデルの進化や新しいデータの追加に伴い、再度微調整を行う必要があります。一方、検索強化生成システムはデータを必要に応じてチャンク化し、関連するチャンクのみを文脈に使用して大規模言語モデルから回答を生成する実用的な解決策を提供します。これにより、新しいドキュメントで知識を継続的に更新し、ユーザーがアクセスできるチャンクを制御することができます。ただし、チャンクの埋め込み、検索、および文脈的融合の最適な戦略は依然として活発な研究領域です。微調整と検索強化生成のパラダイムを精度、遅延、運用コスト、堅牢性などの要素で体系的に比較する研究が必要としています。
3つ目は、検索強化生成システムのテストと監視に関してです。検索強化生成システムのためのソフトウェアエンジニアリングのベストプラクティスはまだ発展途上です。ソフトウェアテストとテストケース生成は改善の余地がある分野の一つとしています。検索強化生成システムは、インデックスされた非構造化ドキュメントに対してアプリケーション固有の質問と回答を必要としますが、それがしばしば利用できません。最近の研究では、大規模言語モデルを使用して複数のドキュメントから質問を生成することが検討されています。現実的なドメイン関連の質問と回答を生成する方法は依然として未解決の問題です。
適切なテストデータが利用可能になったら、品質トレードオフを支援するための品質指標も必要としています。大規模言語モデルの使用は高価であり、遅延の懸念を引き起こし、新しいリリースごとに性能特性が変わります。この特性は以前に機械学習システムで研究されてきましたが、大規模言語モデルベースのシステム（検索強化生成など）に適用するための必要な適応はまだ行われていません。もう一つのアイデアは、自己適応システムの概念を取り入れて検索強化生成システムを監視し、適応させることとしています。
まとめ
検索強化生成システムは、大規模言語モデルを活用した新しい情報検索手法です。ソフトウェアエンジニアは、セマンティック検索の実装や新しいコード依存タスクを通じて、検索強化生成システムとますます多くの接点を持つようになっています。
この論文では、15,000件のドキュメントと1,000件の質問を含む3つのケーススタディから得られた教訓を示しています。また、検索強化生成システムを実装する際の課題を紹介し、実務者に向けたガイドラインを提供しています。
大規模言語モデルを活用したシステムは、今後もエンジニアや研究者にとって興味深い新たな能力を次々と報告されることが期待されます。この論文は、ソフトウェアエンジニアリングの観点から検索強化生成システムに対する初めての調査を提供しています。
この記事に関するカテゴリー
