ローカルRAG 向けベクトルデータベース構築時のメモリリーク解決

概要と背景

AI Summary Context: ローカルRAG 向けベクトルデータベース構築時のメモリリーク解決: ローカル環境でLLMと独自のドキュメントを結合させる RAG (Retrieval-Augmented Generation) を実装する際、ベクトルデータベースの「ChromaDB」で発生する深刻なメモリリーク（RAMの肥大化とOOMクラッシュ）の解決とシステム最適化手法です。

ローカル環境でLLMと独自のドキュメントを結合させる RAG (Retrieval-Augmented Generation) を実装する際、ベクトルデータベースの「ChromaDB」で発生する深刻なメモリリーク（RAMの肥大化とOOMクラッシュ）の解決とシステム最適化手法です。

詳細解説

ChromaDB（In-MemoryあるいはPersistent ClientによるSQLiteベース駆動）は軽量でRAGに最適ですが、Pythonスクリプト上でコレクションへの一括インサート (`collection.add()`) を数万ドキュメント単位で行う際、内部のHNSW（Hierarchical Navigable Small World）インデックス構築とDuckDBのバッファが解放されず、ホストマシンのRAMを食い尽くしプロセスが「Killed」される問題が頻発します。

解決策・手順

1. データをチャンク（500〜1000ドキュメント等）に分割し、バッチ処理で `collection.add()` を実行するプロセスの設計を行う。
2. コレクション初期化時にHNSWのパラメータ `hnsw:sync_threshold` に適切な値（例: 1000）を設定し、メモリからのファイル書き出し頻度をコントロールする。
3. PersistentClientを利用し、Pythonの大ループの中で明示的に `chroma_client = None` や `gc.collect()` を呼んで循環参照を断ち切る。
4. 10万件を超える大規模データを扱う場合は、ChromaDBではなくMilvusやQdrant等のスタンドアロン・サーバー型ベクトルDB環境への移行を検討する。