複数のRAGコレクションがホームサーバーのRAMを奪い合うのはなぜですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Do Multiple RAG Collections Compete for RAM on a Home Server?

複数のRAGコレクションは、各コレクションが独自のベクトル、検索グラフ、メタデータインデックス、キャッシュ、アクティブなワーキングセットを保持するため、RAMを奪い合います。

ホームサーバーでは、プライバシー保護や検索結果の整理を目的に、家族の文書、技術マニュアル、写真のメタデータ、仕事のメモ、スマートホームの履歴を別々のRAGコレクションに分けることがあります。元のファイルはディスクに十分収まっていても、検索レイヤーが予想以上に多くのメモリを消費する場合があります。各コレクションは、近似最近傍インデックス、ペイロードフィルター、セグメントメタデータ、最近アクセスされたページ、クエリバッファーなどを読み込むことがあります。さらに、埋め込みサービスやリランキングサービスも、これらのコレクションとは別に常駐モデルを保持します。

コレクションごとに個別の検索構造が作られる

ベクトルコレクションは、単なる埋め込みのフォルダーではありません。検索エンジンは通常、ベクトル値に加えて、すべてのレコードを走査せずに済むよう、近傍グラフなどの近似検索構造を保持します。

Weaviateは、インメモリの近似最近傍インデックスにおける主なメモリ消費要因として、ベクトルとHNSWグラフを挙げています。

そのため、5つのコレクションを作成すると、同じ埋め込みモデルを共有し、1つのデータベースプロセス内で動作している場合でも、独立してアドレス可能なインデックスが5つ存在することになります。分離による検索上のメリットが、増大するワーキングセットを正当化できる場合にのみ、分離はポリシー管理やメンテナンスの改善につながります。

次元数とインデックスのオーバーヘッドが基準値を押し上げる

生のベクトルメモリは、ベクトル数、埋め込みの次元数、コンポーネントあたりのバイト数に応じて増加します。検索可能なインデックスには、これに加えてグラフリンク、識別子、アライメント、メタデータ、アロケーターのオーバーヘッドが発生します。

Milvusは、ベクトルインデックスのメモリ計算式を提示し、HNSWの構成では、インデックス化されていないベクトルだけの場合よりも大幅に多くのメモリが必要になる可能性があると説明しています。

各コレクションを個別に見積もってから、合計してください。ドキュメント数が少ないコレクションでも、高次元の埋め込み、完全精度のコンポーネント、高い再現率を重視したグラフ設定を使用していれば、高コストになる可能性があります。

グラフの接続性はRAMと再現率・速度のトレードオフ

HNSWは各ベクトルを近傍ノードにリンクします。接続数を増やすと探索性能や再現率を向上できますが、保存するエッジごとにメモリを消費し、インデックス構築のコストも高くなります。

Redisは、グラフの接続性が、インデックスサイズと再現率、検索動作のバランスを調整するパラメーターによって制御されることを説明しています。

コレクションごとに必要な要件が異なるにもかかわらず、同じ積極的なデフォルト設定を引き継いでいる場合があります。最も厳しい検索ワークロードに合わせてすべてのインデックスを調整するのではなく、小規模なアーカイブや同時実行数の少ないコレクションには、メモリ使用量の少ないプロファイルを使用してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

メモリマッピングは負荷を共有ページキャッシュへ移す

ベクトルやグラフデータをメモリマッピングによってディスク上に配置すると、プロセスが恒常的に確保する常駐メモリを減らせます。ただし、アクティブなページが空くわけではありません。オペレーティングシステムは、最近アクセスされたインデックスブロックをRAMにキャッシュし続けます。

Qdrantのメモリ比較では、メモリマッピングされたベクトルによって測定上のRAM使用量が減る一方、ストレージ経由でデータを取得するため、レイテンシとのトレードオフが生じることが示されています。

クエリが複数のコレクションを行き来すると、それぞれのホットページがページキャッシュ内で互いに追い出し合う可能性があります。同じ負荷によって、ホームサーバー上の写真アプリ、コンテナ、データベース、ネットワーク共有で使用されるファイルシステムデータがキャッシュから追い出されることもあります。

RAMを超えるサイズのインデックスはストレージI/Oで代償を払う

インデックスが物理メモリを超えていてもクエリは実行できますが、検索経路のより多くの部分をSSDから読み込む必要があります。その結果、ランダムアクセスとキャッシュミスが検索レイテンシの一部になります。

PlanetScaleは、RAMを超えるサイズのインデックスについて説明しており、より小さなナビゲーション構造をメモリに保持しながら、より多くのポスティングやベクトルデータをストレージへ移す方法を紹介しています。

検索頻度が低く、インデックスが高速なSSDストレージ上にある場合、これはホームサーバーに適した妥協案になります。一方、複数のコレクションに同時にクエリが送られる場合や、アプリケーションデータベースやメディア処理と低速なディスクを共有している場合には、適切とは限りません。

重複ストレージと個別サービスが隠れたコピーを生む

同じ埋め込みが、ドキュメントストア、ベクトルインデックス、アプリケーションキャッシュ、バックアップまたはステージング用コレクションに存在することがあります。また、別々のコンテナが、同一の埋め込みモデルやリランキングモデルを異なるプロセスのアドレス空間に読み込むこともあります。

Memgraphのベクトルストレージの重複回避に関する解説は、インデックスのアーキテクチャによって、1つの検索対象レコードに対してメモリ内に保持されるコピー数が変わる理由を示しています。

したがって、コレクション数は予算を決める要素の一つにすぎません。ベクトルの重複、古いインデックスバージョン、一時的な再構築用コレクション、モデルプロセス、キャッシュされた結果を確認してから、原因がベクトルデータベースだけだと判断してください。

アクセスポリシーとワークロードを基準にコレクションを統合する

異なる権限、埋め込み次元数、保持ポリシー、更新スケジュール、障害分離が必要な場合は、コレクションを分けてください。トピックのラベルが異なるだけなら、必ずしも物理的に別のインデックスを用意する必要はありません。

テナント、所有者、ソース、カテゴリなどのメタデータを持つ共有コレクションを使用すれば、1つのインデックスを再利用しながら、フィルターによって意図した範囲内に検索結果を限定できます。ただし、大規模な混在コレクションでは、ランキングやメンテナンスに新たなコストが生じる可能性があるため、統合前にフィルター適用時の再現率をテストしてください。

ZimaSpaceのローカルAIランタイムがメモリを確保し続ける理由に関する解説は、監視結果を理解するのに役立ちます。保持されたページやキャッシュは、リークではなく再利用可能なワーキングステートである場合がありますが、それでもサーバーの他の処理とメモリを奪い合います。