Retrieval Augmented Generation (RAG)は過負荷された用語です。それは世界を約束しますが、RAGパイプラインを開発した後、多くの人々がなぜ期待通りに機能しないのか疑問に思っています。
ほとんどのツールと同様に、RAGは使いやすいがマスターするのは難しいです。実際のところ、RAGには文書をベクトルDBに入れてLLMを追加する以上のことがあります。それでうまくいくこともありますが、常にうまくいくわけではありません。
この電子書籍は、箱から出したままのRAGがうまく機能しない場合に何をすべきかを伝えることを目指しています。この最初の章では、サブ最適なRAGパイプラインに対する通常最も簡単で迅速に実装できる解決策について見ていきます。つまり、_rerankers_について学んでいきます。
この章のビデオコンパニオン。
リコール vs. コンテキストウィンドウ
解決策に取り組む前に、問題について話しましょう。RAGでは、多くのテキスト文書を対象に 意味検索 を行っています — これらは数万から数十億の文書になります。
大規模な検索時間を短縮するために、通常、ベクトル検索を使用します。つまり、テキストをベクトルに変換し、すべてをベクトル空間に配置し、コサイン類似度のような類似度メトリックを使用してクエリベクトルに近いかどうかを比較します。
ベクトル検索を行うためには、ベクトルが必要です。これらのベクトルは、通常768次元または1536次元のベクトルにテキストの「意味」を圧縮したものです。この情報を単一のベクトルに圧縮するため、情報の一部が失われます。
この情報の損失のため、たとえば上位3つのベクトル検索ドキュメントでも関連情報が見落とされることがよくあります。残念ながら、検索では上位_kのカットオフ以下に関連情報が返されることがあります。
下位の位置に関連情報がある場合、LLMがより良い応答を形成するのに役立つでしょう。最も簡単なアプローチは、返されるドキュメントの数を増やすこと（top_kを増やすこと）で、それらをすべてLLMに渡すことです。