生産性のためのハンズオンRAG (Japanese Edition)

第3章 RAGスタックのスケーリング

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第2章では、RAGスタックの基本構成要素であるドキュメントの解析、チャンキング、埋め込みモデル、ベクトル検索、およびユーザへのレスポンスを最終的に生成するためのLLMの使用について学んだ。この知識があれば、中小規模のデータセットで十分に機能するエンドツーエンドのRAGアプリケーションの構築を行い、RAGが実際にどのように機能するかを自ら体験できるようになるはずだ。

本章では、遅延やレスポンス品質を犠牲にすることなく、RAGスタックをエンタープライズ規模に拡張するためのより高度なテクニックについて取り上げる。これには、データ取り込み、高度な検索技術、ガードレール、RAGのハルシネーションへの対処などが含まれる。厳密にはスケーリングの一部ではないが、本番環境でのスケーリングに伴い、セキュリティとデータプライバシーが重要になるため、これらについては第4章の 「データセキュリティとプライバシー」で扱う。

本章の締めくくりとして、RAGアプリケーションにおいてあまり議論されないが極めて重要な側面、すなわち、フロントエンドがバックエンドと同等の品質となるよう優れたユーザ体験を構築する方法について述べる。

大規模なRAG

RAGアプリケーションの規模が拡大すると、状況は比較的急速に複雑化する。より多くのドキュメントやクエリ、複数のドキュメント形式への対応、高品質なレスポンスを維持するための高度な検索メカニズムの統合、ハルシネーションの緩和、ガードレールなど、対処すべき課題は多岐にわたる。

このセクションでは、大規模なRAG運用に伴う様々な課題と、その対処法について掘り下げていく。

文書の量と複雑さ

RAGのスケールアップにおける最も基本的な構成要素は、単に文書数を増やすことだ。1つや10個の文書向けのRAGスタックを構築するのは比較的容易だが、数十万、あるいは数百万の文書を扱うとなると、複雑さが増加する。これほど多くの文書があると、インデックス作成や高速（低遅延）な検索の継続的なサポートは決して容易ではない。

ドキュメントのサイズも、スケールアップ時に課題となり得る。小さなドキュメントは解析やチャンク化が容易だが、一部のPDFファイルは非常に大容量になることがある。例えば、2002年発行のこの『連邦官報』は5,000ページに及ぶため、その解析にはかなりの時間がかかり、結果として膨大な数のチャンクが生成されることになる。

スケールとは、ユーザからのクエリ数が膨大になることも意味する。秒間クエリ数（QPS） が増加するにつれ、低遅延を維持するために、RAGスタック全体の水平スケーリング、レート制限、キャッシュの導入が必要になる可能性がある（第4章の「高遅延」のセクションを参照）。

ドキュメント数とチャンク数の両方が増加するにつれ、別の問題が生じる。それは、検索精度が低下する可能性があるということだ。その理由は単純である。利用可能なチャンクが単に増えすぎているため、上位k件の結果の中から最も関連性の高いチャンクを検索することが著しく困難になり、LLMの生成ステップにおいてノイズがシグナルを圧倒するリスクが高まるからだ。 単純なベクトル類似性検索では、最適なパッセージを常に正しくランク付けすることが一貫性がない場合があり、この章の後半で説明する「高度な検索」で見られるように、より優れた検索テクニック（ハイブリッド検索や再ランク付けなど）が必要となる。 ...