導入

こんにちは、株式会社ナレッジセンスの須藤英寿です。普段はエンジニアとして、LLMを使用したチャットのサービスを提供しており、とりわけRAGシステムの改善は日々の課題になっています。

今回は、メモリの制約が厳しい環境における効率的なRAGシステムを実現したEdgeRAGを紹介いたします。

サマリー

RAGは、大容量の情報にアクセスするための優れた手法で、様々な手法が開発されています。その一方でデータの保管には大量のメモリを消費してしまい、例えばモバイルの環境ではRAGをそのまま運用することが難しいです。

今回紹介するEdgeRAGはメモリに乗せるベクトルデータを賢く選択することでメモリの消費を抑えつつ、大規模なデータセットにおいて従来の手法の3倍程度の速度を実現しています。

問題意識

メモリが少ない環境におけるベクトルDBの問題

RAGを構築する上でベクトルDBは欠かせない存在となっています。ベクトルDBは、チャンクごとのEmbeddingをすべてメモリ上に乗せることでデータの追加や検索を高速にしています。しかしEmbeddingは性質上かなり大きなデータとなるため、ベクトルDBの使用メモリは保存したいデータそのものより大きくなる傾向にあります(こちらの記事も似た問題に触れているのでぜひ確認してみてください)

このため、大容量のメモリを確保できないモバイル端末上で動かすRAGは頻繁にストレージへの書き込みが発生することになり検索速度が発揮できない問題を抱えています。

手法

EdgeRAGは、Two-level Inverted File(IVF)という手法を応用することで実現しています。

Two-level Inverted File

この手法は名前の通り二段階構成で検索の仕組みを実現しています。大まかに説明すると

• 1段階目で、ベクトルデータのグループのうち類似したデータが含まれている可能性の高いものを選択
• 2段階目で、そのグループ内でさらに類似したベクトルデータを検索する

という手順で最も類似したベクトルデータを検索します。

EdgeRAG

EdgeRAGはTwo-level Inverted Fileの手順に加えて以下のような工夫により使用するメモリを大幅に削減しています。

• 一部のEmbeddingは検索時に動的に生成することでメモリを消費しないようにする
• 生成コストの高いグループは事前に計算しておき必要に応じてメモリに乗せる

成果

こちらのグラフは、データベースのサイズと検索にかかった時間を記録した物となっています。その端末の許容するメモリの上限を超えたラインから検索にかかる時間が爆発的に増えていることがわかります。

こちらのグラフは、データセットと手法の組み合わせごとに使用したメモリ量と検索にかかっている時間が記録されています。データ量が少ないうちは相対的に遅いですが、データ量が増えるに従って速さの差が顕著になり最大でもととなるIVFと比較して4倍程度の速さになっていることがわかります。

まとめ

メモリが制限されている環境における高速なベクトルDBの検索手法EdgeRAGについて紹介しました。スマホなどの環境では他のアプリケーションとの兼ね合いで使用可能なメモリは大幅に制限されるはずなのでそういった環境では特に有用な手法になりそうに感じました。一方で現在のベクトルDBではANNなどの若干の正確性と引き換えに大幅な高速化が実現できる手法や、以前紹介したBinary Embeddingといった手法と比較した場合の結果も合わせて比べられているとより有用性が際立っていたかと思います。

RAGの精度を向上させるための手法に関する論文は数多く見られますが、こうした制限のある環境における検索速度や精度に言及した論文はあまりないように感じます。こうした論文も増えてくるとより広い範囲に適用できる汎用的な技術になっていくはずなので、注目していきたいと思います。