RAG (Retrieval Augmented Generation) システムの設計における失敗ポイントと、ケーススタディから得られた教訓を報告されている論文を紹介します。
タイトル：Seven Failure Points When Engineering a Retrieval Augmented Generation System
タイトル：Seven Failure Points When Engineering a Retrieval Augmented Generation System
RAGシステムが失敗する理由
一般的にRAGシステムの精度が低い原因は、検索に起因する部分が大きいと言われています。RAGは、ユーザーのクエリから検索するわけですが、クエリが曖昧だと解釈が難しいですし、一方複雑なクエリも、それはそれで正確に回答するのは難しいです。
また、参照するドキュメントも様々な落とし穴があります。ドキュメントが章ごとに分かれており、内容が正しく、明確な文章で記載されていれば問題ありません。しかし、情報が古かったり、ドキュメントの形式がばらばらだったり、ページ構成が複雑だと、検索で引っ掛けるのが難しくなります。
また、参照するドキュメントも様々な落とし穴があります。ドキュメントが章ごとに分かれており、内容が正しく、明確な文章で記載されていれば問題ありません。しかし、情報が古かったり、ドキュメントの形式がばらばらだったり、ページ構成が複雑だと、検索で引っ掛けるのが難しくなります。
さらに、質問であるクエリと参照ドキュメントは、そもそも別物なので、そのギャップを埋めることが難しい状況です。
本論文でも、FP2～4に、検索に起因する課題が記載されています。「答えが含まれているドキュメントが上位にランクインしない」「検索されたチャンクが文脈に合っていない」「コンテキストにノイズや矛盾する情報が多すぎる」などです。
ケーススタディから得られた教訓
それでは、どのように解決すればよいのでしょうか。本論文では、ケーススタディから、解決策を検討されています。上記画像の一番上の教訓である、「大きなコンテキストにより正確な応答が得られる」という旨の内容はなるほどと思いました。GPT-3.5以前の研究とは対照的です。
モデルのトークン数と性能が上がり、大きなコンテキストが来ても理解できるようになったからでしょう。今後ますますトークン数が増えることが想定されるため、検索エンジンの精度が多少低くともカバーできるようになる可能性があります。
また、上から4つ目の「取得したコンテキストにファイル名とチャンク番号などのメタデータを含めることで検索性能が向上する」というのも、やや手間がかかりますが、実施すべき解決策でしょう。
感想
本論文は、失敗ポイントと教訓を記載されており、実践的な論文と思います。ただし、クエリ周りはベストプラクティスがまだ見つかっておらず、様々試行錯誤が必要になりそうです。
また、RAGシステムは、運用中に未知の入力を受け取るため、継続的なモニタリングとチューニングが必要という部分は重要な点と思いました。設計段階から、運用も意識して構築する必要があることを理解できました。
参考記事
Seven Failure Points When Engineering a Retrieval Augmented Generation System【論文瞬読】RAGシステムの実装に隠れた7つの落とし穴と教訓～実践する上で知っておくべきこと～
