turbovec とは？ローカル RAG のメモリを節約する Rust 製ベクトルインデックス

RyanCodrai/turbovec は、今日の GitHub Trending で目立っているプロジェクトの一つです。Rust で書かれたベクトルインデックスで、Python バインディングも提供し、ローカルのベクトル検索をより省メモリ、高速、RAG に組み込みやすいものにすることを目指しています。

README の位置づけは明確です。Google Research の TurboQuant アルゴリズムを使い、ベクトルを圧縮したまま検索します。10 million 件の文書コーパスを float32 で保存すると約 31 GB のメモリが必要になる一方、turbovec では約 4 GB まで圧縮でき、一部のテストでは FAISS より高速だとしています。

この種のプロジェクトが重要なのは、ローカル RAG のボトルネックが「モデルを呼べるか」ではなく、ベクトルインデックスのメモリ、遅延、フィルタリング、デプロイ方式になることが多いからです。個人 PC、NAS、小型サーバー、プライベート環境では、インデックスをメモリに載せられるかどうかが体験を大きく左右します。

解決する問題

多くの RAG システムは最初、embedding を float32 で保存し、メモリ上のインデックスやデータベースで検索する単純な方式から始めます。始めやすい一方、データ量が増えるとメモリ負荷がすぐに目立ちます。

1536 次元の embedding を例にすると、float32 のベクトル一つは 1536 × 4 bytes、つまり 6144 bytes です。100 万件で数 GB、1000 万件では普通のマシンにとってかなり重い規模になります。

turbovec は圧縮ベクトルインデックスの路線を取ります。ベクトルを正規化し、ランダム回転を適用し、低 bit 量子化と SIMD 検索カーネルで近似検索を行います。README によると、1536 次元ベクトルは 2-bit モードで 6144 bytes から 384 bytes へ圧縮でき、16 倍の圧縮になります。

主な特徴

特徴	説明
Rust コア	検索コアを Rust で実装し、性能とローカルデプロイを重視
Python バインディング	`pip install turbovec` で Python RAG プロジェクトから利用可能
学習ステップなし	README では、ベクトル追加後すぐにインデックス化でき、別途 codebook 学習が不要とされる
オンライン書き込み	コーパスが増えても `add` を続けられ、毎回全インデックスを再構築しなくてよい
検索時フィルタ	`search()` が allowlist に対応し、候補 ID 内で dense rerank が可能
ローカル実行	ホステッドなベクトルデータベースに依存せず、データをローカルや LAN に置ける
フレームワーク連携	README では LangChain、LlamaIndex、Haystack、Agno などの統合が挙げられている

これは伝統的な意味での完全なベクトルデータベースではありません。アプリケーションに埋め込める高性能ベクトルインデックスライブラリに近いものです。文書分割、embedding 生成、メタデータ、権限、永続化戦略、アプリケーションロジックは自分で扱う必要があります。

Python での簡単な使い方

README の最小例はシンプルです。

1

pip install turbovec

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


from turbovec import TurboQuantIndex

index = TurboQuantIndex(dim=1536, bit_width=4)
index.add(vectors)
index.add(more_vectors)

scores, indices = index.search(query, k=10)

index.write("my_index.tv")
loaded = TurboQuantIndex.load("my_index.tv")

削除後も外部 ID を安定させたい場合は、IdMapIndex を使えます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import numpy as np
from turbovec import IdMapIndex

index = IdMapIndex(dim=1536, bit_width=4)
index.add_with_ids(vectors, np.array([1001, 1002, 1003], dtype=np.uint64))

scores, ids = index.search(query, k=10)
index.remove(1002)

index.write("my_index.tvim")
loaded = IdMapIndex.load("my_index.tvim")

これは実運用で重要です。文書 ID は通常、データベース、ファイルシステム、オブジェクトストレージから来るため、ベクトルインデックス内部の連番とは限りません。

フィルタ付き検索が実用的な理由

turbovec の実用的な点の一つは、検索時の allowlist フィルタです。

多くの RAG では「全コーパスから最も似た 10 件を探す」だけではありません。まず業務条件で範囲を絞り、その候補集合の中でベクトル類似度による順位付けをします。たとえば：

あるユーザーがアクセスできる文書だけを検索する。
あるテナントのデータだけを検索する。
直近 30 日の内容だけを検索する。
SQL/BM25 で候補を出し、ベクトル検索で rerank する。
特定のプロジェクト、タグ、ナレッジベース内を検索する。

README の考え方では、外部システムがまず候補 ID を取り出し、それを allowlist として search() に渡します。turbovec は SIMD kernel の内部でフィルタを処理し、全量検索してから不許可の結果を捨てる方式を避けます。

これは権限が厳しい場面や候補範囲が小さい場面に向いています。

FAISS との関係

FAISS は今でもベクトル検索分野で非常に成熟した基盤ライブラリです。turbovec の README も主に FAISS の IndexPQ / IndexPQFastScan と比較しています。

プロジェクトは、OpenAI の 1536 次元および 3072 次元 embedding のテストで、TurboQuant が R@1 で FAISS より 0.4 から 3.4 ポイント高く、ARM では FAISS FastScan より 12% から 20% 速いとしています。x86 の 4-bit 設定では 1% から 6% 速く、一部の 2-bit マルチスレッド設定ではやや遅いとされています。

これらの数字は選定の手がかりにはなりますが、そのまま本番環境の結論にはできません。ベクトル分布、次元数、bit 幅、CPU 命令セット、クエリバッチ、候補フィルタ比率、リコール目標によって結果は変わります。使うなら、自分の embedding とクエリログで benchmark を取るべきです。

向いているユーザー

turbovec は次のような場面に向いています。

ローカル RAG インデックスがメモリを食い始めている。
ナレッジベースを個人 PC、NAS、社内サーバーに置きたい。
文書 embedding をホステッドなベクトルデータベースに入れたくない。
クエリにテナント、権限、時間窓などのフィルタが必要。
主な技術スタックは Python だが、検索性能は Rust/C++ に近づけたい。
LangChain、LlamaIndex、Haystack などを使いながら、より軽いローカルベクトルストアにしたい。

データ量が小さい場合や、すでに成熟したベクトルデータベースを使っていて運用コストが許容できる場合、turbovec の効果はすぐには見えないかもしれません。これはメモリ、プライバシー、遅延がどれも重要な RAG 向けのツールです。

使う前の注意点

第一に、圧縮検索は通常、メモリとリコールの間でトレードオフがあります。2-bit、4-bit の設定は圧縮率と精度に影響するため、圧縮倍率だけを見てはいけません。

第二に、README の benchmark は参考になりますが、本番のリコール要件は自分で検証する必要があります。特に日本語や中国語の知識ベース、コード embedding、多言語 embedding、短文、長文 chunk ではベクトル分布が変わる可能性があります。

第三に、turbovec はインデックスライブラリであり、完全な RAG プラットフォームではありません。文書解析、増分同期、権限管理、クエリ書き換え、回答生成、引用追跡は自分で実装する必要があります。

第四に、ローカルデプロイはプライバシー面では有利ですが、バックアップ、監視、アップグレード、インデックス再構築も自分で管理することになります。

まとめ

turbovec の価値は、ローカルベクトル検索を実用方向へ一歩進めている点にあります。メモリ使用量を下げ、Python/Rust プロジェクトに組み込みやすく、検索時フィルタを持ち、ホステッドサービスへの依存を減らします。

FAISS やベクトルデータベースを置き換えるとは限りませんが、ローカル RAG 技術スタックの新しい選択肢として有力です。個人ナレッジベース、企業内 QA、NAS 上の文書検索、オフライン RAG 環境では、この種の軽量で高性能なインデックスがますます重要になります。

参考： GitHub Trending、RyanCodrai/turbovec