LEANNとは｜密ベクトルを全件保存せず作り直すローカルRAG索引の仕組みと使い方

手元の文書やメールをまとめて検索させようとすると、ローカルRAGでは検索精度より先に保存容量が効いてくる。文書を分割して全件をベクトル化するため、プロジェクトが公開しているベンチでは、6,000万件規模で従来型の索引が201GBに達する例もある。LEANNは、この保存量を削るために「全件分の高精度な密ベクトルを索引に持たない」という選択をしたベクトル索引だ。UC Berkeley の Sky Computing Lab が公開しており、MLSys 2026 の Best Research Paper Award を受賞した論文の実装にあたる。

この記事でわかること

ローカルRAGが「保存」で詰まる理由（すべての埋め込みベクトルをベクトルDBに置く代償）
LEANNが全件分の高精度な密ベクトルを索引内に持たず、必要な分だけ再計算する仕組み
公称でどれだけ保存量が減るのか（プロジェクトが公開しているベンチ値）
容量を減らす代わりに何を払うのか（検索時の再計算コストというトレードオフ）
対応バックエンド・インデックスできるデータ・インストールと基本操作
既存のローカルRAG手法（量子化埋め込み・全ベクトル保存）とどう棲み分けるか

先に結論

全件分の高精度な密ベクトルを索引内に保存せず、検索時に必要な分だけ作り直すローカルRAG向けの索引
公称で保存量を約97%削減。論文は索引の保存量を生データ容量の5%未満に抑えたまま、上位3件の再現率90%を報告している
代償は検索時の再計算。索引構築時と同じ埋め込みモデルまたはAPIを、検索時にも呼び出せる状態が要る
検索時間は環境差が大きい（論文の測定でRTX 4090が約1〜7秒、M1 Ultraが約5〜45秒）
埋め込みもLLMもローカルのバックエンドを選べば端末内で完結できる。ライセンスはMIT

ローカルRAGは「保存」で詰まる
LEANNの仕組み：密ベクトルを持たず「作り直す」
どれだけ減るのか（公称値）
容量の代わりに払うもの
何をインデックスできるか
ローカル完結とプライバシー
導入と基本操作
向く場面・向かない場面と、既存手法との棲み分け
よくある疑問
まとめ
参考資料

ローカルRAGは「保存」で詰まる

手元の文書やメールを検索して答えさせるローカルRAGは、ふつう次の流れで動く。文書を細かく分割し、埋め込みモデルで各断片をベクトルに変換し、そのベクトルをベクトルDBに保存しておく。質問が来たら質問文もベクトル化し、近いベクトルを探して該当断片をLLMに渡す。基本的な組み立て方はローカルRAGとは（Ollama・ChromaDB・Gemma）やOllamaでローカルRAGパイプラインを構築する方法で扱っている。

この構成のコストは二つに分かれる。ひとつは変換のコスト（断片ごとの埋め込み推論）、もうひとつが保存のコスト（作ったベクトルを全件ぶん索引として保存しておく）。従来型のグラフ探索は毎回すべてのベクトルを読むわけではなく、探索で訪れた一部を参照するが、その参照先を正確なベクトルとして事前に保存しておく点が効いてくる。個人の文書が数千件のうちは後者は問題にならない。だが対象がメールの全履歴、ブラウザの閲覧履歴、チャットのログにまで広がると、ベクトルの総量が生データを上回る規模まで膨らむことがある。埋め込みは1件あたり数百〜数千次元の浮動小数点で、これを件数ぶん保存するためだ。

具体的な数字で見ると、埋め込みの保存量はおおまかに「次元数 × 件数 × 1要素のバイト数」で決まる。たとえば768次元の埋め込みを単精度（1要素4バイト）で持つと、1件あたり約3KBになる。これが100万件なら約3GB、1,000万件なら約30GBに達する。元のテキストは軽いのに、ベクトルにした途端に生データと同等かそれ以上の容量を占めるのはこのためだ。次元数の大きいモデルを使うほど、また件数が増えるほど、この保存量は素直に膨らんでいく。量子化は1要素のバイト数を削る方向、LEANNは高精度な密ベクトルを持たず、必要な分を検索時に再計算する方向、というのが両者の狙いの違いになる。

保存量を抑える方向は、大きく二つある。ひとつはベクトル1本を小さくするアプローチで、埋め込みを低ビットに量子化する。三値（−1・0・+1）まで落とす手法は三値（BitNet系）に量子化したテキスト埋め込みモデルで扱った。もうひとつが本稿の高精度な密ベクトルを保存しないアプローチで、これがLEANNの立ち位置になる。前者は圧縮したベクトルをそのまま距離計算に使い、後者は正確な密ベクトルを保存せず検索時に再計算する。方向が違う手法なので、後述するように使い分けも考えられる。

LEANNの仕組み：密ベクトルを持たず「作り直す」

LEANN（Low-Storage Overhead Vector Index）は、全件分の高精度な密ベクトルを索引内に保存しない。論文版が索引本体として保存するのは、断片どうしの近さを表す剪定した近傍グラフと、各ベクトルをPQ（積量子化）で高圧縮した小さなコードの二つだ。これとは別に、再計算のもとになるテキストや画像のデータは保持する。検索では、まずPQコードで近似的な距離を計算して有望そうな候補を絞り、そのうえで選ばれた一部のノードだけ、埋め込みモデルで厳密な埋め込みを計算し直す（二段構成）。全ベクトルを高精度のまま置いておくのではなく、粗いPQで当たりをつけてから必要な分だけ精算する、という発想だ。

論文では、これを支える技術として次の三つが挙げられている。

グラフベースの選択的再計算：高精度な密埋め込みを保存する代わりに、剪定したグラフとPQコードを保存し、探索で絞り込んだ一部のノードだけ埋め込みを必要時に再計算する
高次数を残す剪定（high-degree preserving pruning）：冗長な接続を削りつつ、多くのノードとつながる「ハブ」ノードは残す。探索の通り道になりやすい要所を保つことで、グラフを小さくしても検索の質を落としにくくする
二段階の探索：有望なノードを優先してたどりつつ、再計算をまとめて実行（動的バッチ処理）してGPUを効率よく使う

保存量が減る理由はここにある。従来型は高精度な密ベクトルを件数ぶん抱えるが、LEANNが持つのは剪定したグラフと、ベクトルを大幅に圧縮したPQコードで、いずれも密ベクトル本体よりはるかに軽い。件数が増えれば保存量も増えるが、1件あたりに残すデータが小さいため総量を大きく抑えられる。高精度な埋め込みは「保存する対象」から「必要なときに作り直す対象」へ移る。

ここまでは論文が示す方式で、公開実装ではバックエンドを選べる。既定のHNSWは再計算を重視して保存削減を最大化する構成、DiskANNはPQコードを使った探索で速度を優先する構成として提供されている（詳細は後述）。どちらを選ぶかで、保存量と検索速度のバランスが変わる。

どれだけ減るのか（公称値）

プロジェクトのREADMEは、従来のベクトルDBに比べて保存量を約97%削減し、精度は落とさないとしている。公開されているベンチの内訳は次のとおり。いずれもLEANN側が公表している値で、当サイトの実測ではない。なおREADMEにはこのほかにも削減例があり、データセットによっては91〜95%（97%は削減幅が大きい側の例）となっている。

データ	規模	従来型の保存量	LEANNの保存量
Wikipedia	約6,000万件	201GB	6GB
メール	約78万チャンク	2.4GB	79MB
チャット履歴	約40万メッセージ	1.8GB	64MB

「精度を落とさない」はプロジェクト側の主張で、READMEでは「従来の重い方式と同じ検索品質を保ったまま保存量を97%削る」と表現されている。置き換えているのは保存量であって精度ではない、というのが設計の要点だ。論文はこれを、比較対象のHNSWとLEANNを上位3件の再現率が約90%になる条件にそろえて評価し、その条件下でLEANNの下流QA精度がHNSWと同程度だった、という形で示している（索引の保存量は生データ容量の5%未満）。つまり90%はLEANN固有の上限ではなく、比較のために設定した目標値で、あらゆるデータや設定で保証される値でもない。要件が厳しい用途では、自分のデータで再現率を確かめる前提で捉えたい。

検索の速さは、プロジェクトページが「上位3件を2秒未満」と要約している。ただしこれはプロジェクトページ上の要約値で、論文が載せる詳細な測定とは差がある。論文の表では、RTX 4090・32GB RAM・WSL2環境で約1.1〜7.1秒、AWS EC2のApple M1 Ultra・128GB RAM環境で約5.2〜44.8秒と、データセット・探索条件・埋め込みモデル・ハードウェアによる差が大きい。従来型のように事前保存した正確なベクトルを参照するのではなく、探索時に一部のノードを再計算するぶん、実際の速度は後述する埋め込みモデルの重さとGPUの有無に左右される。

容量の代わりに払うもの

LEANNの設計は、保存量を計算量に置き換えるトレードオフとして理解すると分かりやすい。従来型は参照するベクトルを事前に保存しておき「読み出す」だけで済むが、LEANNはそれを保存しない代わりに、探索時に必要になった一部のノードの埋め込みを「作り直す」（候補の絞り込みに何を使うかは後述のバックエンドで異なる）。そのため、検索時にも、索引構築時と同じ埋め込みモデルまたはAPIを呼び出せる状態にしておく必要がある。動的バッチ処理でまとめて計算し、GPUがあれば効きやすい、という設計はこの再計算コストを抑えるためのものだ。

再計算がどれだけ効くかは、検索の頻度と埋め込みモデルの重さで変わる。一度の質問で作り直すのは探索経路上の一部のノードだけで、全件を毎回作り直すわけではない。それでも、ベクトルを読み出すだけの従来型に比べれば計算は増える。埋め込みモデルが軽く、GPUで動かせるほどこの差は縮み、逆にCPUだけで重い埋め込みモデルを使う構成では、再計算が検索時間に乗りやすい。保存量を最優先で削りたいのか、検索の反応速度を優先したいのかで、埋め込みモデルの選び方とハード構成の見立てが変わってくる。

READMEが主要なバックエンドとして案内しているのはHNSWとDiskANNだ。既定のHNSWは、密ベクトルを持たず必要時に再計算する方式で、保存削減が最大になる。より速い検索が要るときはDiskANNを選べるが、こちらはPQ（量子化）コードを保存して探索を速める設計のため、保存削減はHNSWより小さくなる。ここで注意したいのは、論文で評価されたHNSWベースのLEANNと、現在のOSSが提供するHNSW・DiskANNバックエンドでは、保存と探索の実装構成が完全には同じでない点だ。そのうえで、保存量を最優先するなら既定のHNSWが基本線になる。ビルドに要る準備は環境ごとに変わる（WindowsはVisual Studio Build Toolsとvcpkg、macOSは13.3以降など）ため、事前に確認したい。

どちらを取るかの整理
・保存容量がボトルネック（大きな個人コーパスを端末に置きたい）→ 再計算コストを払ってでも保存を削るLEANNが向く
・検索を極端な低レイテンシで回したい、対象が数千件と小さい → 全ベクトルを保存する従来型のほうが素直なことが多い
・保存はLEANNで削りつつ、再計算の負荷も下げたい → より小型・軽量な埋め込みモデル（量子化済みモデルなど）を使う余地がある。保存削減はLEANNが受け持ち、モデル側を軽くすれば再計算そのものが速くなる。ただし三値・低ビットの「出力ベクトル」量子化との組み合わせは論文の評価対象ではなく、効果や互換性は個別に検証が要る

何をインデックスできるか

LEANNが掲げるのは「あらゆるものをRAGに」という方針で、個人の端末にたまる多様なデータを索引化の対象にしている。READMEで挙げられているのは次のようなソースだ。

ローカルのファイル（.pdf・.txt・.md など）
Apple Mail のメール、iMessage、WeChat
Chromeのブラウザ閲覧履歴
ChatGPTやClaudeとの会話履歴
Googleの検索履歴、コードベース（ソースコード）
MCPサーバー経由のライブデータ（Slack・Twitter など）

ただしメールやチャット系のコネクタは、対応するアプリや環境に依存するものが含まれる。上の一覧はREADMEの記載に沿ったもので、GmailやOutlookなど一覧にないアプリを使っている場合は、対応状況を導入前に確認したい。含まれないときも、エクスポートしたテキストやPDFをローカルファイルとして取り込めば索引化はできる。

高精度な密ベクトルを持たない設計は、こうした「量は多いが一件あたりは短い」個人データと相性がよい。LEANNでも件数が増えれば保存量は増えるが、各ノードについて高次元の密ベクトルを保存しないため、従来型より1件あたりの保存量を大きく抑えられる。ドキュメント抽出を軸にしたローカルでのPDF・請求書のJSON抽出のような前処理と組み合わせれば、扱えるデータの幅はさらに広がる。

ローカル完結とプライバシー

LEANNは埋め込みとLLMのバックエンドを差し替えられる。対応が挙げられているのは次のとおり。

役割	対応バックエンド（READMEより）
埋め込み	facebook/contriever、text-embedding-3-small、Qwen3、nomic-embed-text、Jina AI ほか（OpenAI互換API経由も可）
生成（LLM）	OpenAI、Ollama、Hugging Face、Anthropic、OpenRouter、Gemini、Groq ほか（OpenAI互換APIに対応）
グラフ	HNSW（既定）、DiskANN

上表は代表例で、READMEはこのほかにも OpenRouter・Gemini・Groq・DeepSeek・Mistral など多くのプロバイダを挙げている。埋め込みに nomic-embed-text や Qwen3、生成に Ollama を選べば、データを外部に送らず端末内でRAGを完結できる構成になる。READMEが掲げる「100%プライベート」という位置づけはこの選択が前提で、クラウドの埋め込みや生成APIを選べば当然その限りではない。Ollamaを使ったローカル構成そのものはOllamaでローカルRAGパイプラインを構築する方法と共通の土台なので、そこにLEANNを索引として組み込む、という読み方ができる。

導入と基本操作

PyPIから導入できる。パッケージ管理に uv を使う場合は次のとおり。

uv pip install leann

ソースからビルドする場合は、リポジトリを取得して uv sync --extra diskann を実行する。動作要件はPython 3.10以上（PyPIに対応版として3.10〜3.13が明示されている）。ただし0.3.7時点でWindows向けのビルド済みバックエンドはCPython 3.11以降しか配布されていないため、Windowsでビルドを避けたいならPython 3.11以上を選ぶ。READMEにはmacOS、Ubuntu／Debian、Arch Linux、RHEL系Linux、Windows向けのソースビルド手順が掲載されている（論文のRTX 4090評価はWSL2上で行われた）。ソースからビルドする場合、Linux／macOSでは libomp・boost・protobuf・zeromq・pkg-config などの依存が必要で、DiskANNのビルドには macOS 13.3以降が要る、といった条件がある。PyPIではトップレベルの leann に加え、HNSW・DiskANN のバックエンド用ビルド済みwheelが macOS・Linux・Windows（win_amd64）向けに配布されている（0.3.7時点）ので、通常はビルドせずに導入できる。

コマンドラインからは、索引の作成・検索・対話の三つが基本になる。

leann build my-docs --docs ./your_documents
leann search my-docs "調べたいこと"
leann ask my-docs --interactive

PythonのAPIも用意されている。ビルダーで索引を作り、検索や対話のクラスから利用する形だ。検索と対話は LeannSearcher・LeannChat から呼べる（使い方はCLIの leann search・leann ask と同じ発想で、上のビルダーで作った索引を指定する）。

from leann import LeannBuilder, LeannSearcher, LeannChat

builder = LeannBuilder(backend_name="hnsw")
builder.add_text("インデックスしたいテキスト")
builder.build_index(INDEX_PATH)

索引を作る段階では、剪定したグラフを構築して保存する。埋め込みを全件保存しないぶん、この構築時と、検索時の再計算に処理が寄る。手元のマシンで初回のビルドにどれくらいかかるかは、データ量と選んだ埋め込みモデル、GPUの有無で変わるため、小さなデータで試してから対象を広げるのが無難だ。

データが増えたり入れ替わったりしたときは索引を更新する。論文版のLEANNは、既存グラフへの追加、soft deletion（論理削除）、追加要求をまとめるバッチ更新を備え、更新のたびに索引全体を作り直さない設計で、更新最適化により最大63.3倍の高速化を報告している。ただし現行OSSで実際に使える増分更新の手順や対応範囲は、利用経路とバージョンで異なる（たとえばCLIの leann watch はファイル変更を検出してチェックポイントを保存する機能で、差分をそのまま索引へ増分適用すると明記されているわけではない）ため、導入時に確認したい。まずは一部のフォルダやメールだけを索引化し、検索の質と速度、更新の手間を確かめてから範囲を広げると、想定と実際のずれに早く気づける。

向く場面・向かない場面と、既存手法との棲み分け

LEANNが効くのは、保存容量が制約になっているケースだ。メールやチャット、ブラウザ履歴のような大きな個人コーパスを、外部に出さず端末内で検索したい。従来型のベクトルDBだと保存量が現実的でなくなる規模で、再計算のコストを払ってでも容量を削る価値が出る。

逆に、対象が数千件と小さければ、全ベクトルを保存する従来型のほうが構成も検索も素直だ。データが頻繁に入れ替わる場合は索引の作り直しと再計算の負荷を見ておきたいし、検索を極端な低レイテンシで回したい用途では、読み出すだけの従来型と比べて再計算の分が乗る点が効いてくる。

既存のローカルRAG手法との関係は次のように整理できる。

アプローチ	保存量の削り方	LEANNとの関係
全ベクトル保存（ChromaDB等）	削らない（全件保存）	容量が破綻する規模での代替になる
量子化埋め込み（三値・低ビット出力）	出力ベクトル1本を小さくする	方向が別。LEANNとの併用効果は論文では未検証
LEANN	正確な密ベクトルを保存せず、構成に応じてPQまたは再計算で探索	本稿の対象

入門的な全保存構成はローカルRAGとは（Ollama・ChromaDB・Gemma）、パイプラインの組み方はOllamaでローカルRAGパイプラインを構築する方法、ベクトル側を軽くする方向は三値に量子化したテキスト埋め込みモデルで扱っている。LEANNはこのうち「索引の作り方そのものを変える」選択肢にあたる。

よくある疑問

精度は本当に落ちないのか。 プロジェクトのいう「精度を落とさない」は「同じ再現率にそろえたとき、従来型HNSWと同程度の下流精度だった」という意味で、置き換えるのは保存量であって精度ではない。論文は上位3件の再現率が約90%になる条件で両者を比較している（索引の保存量は生データ容量の5%未満）。この90%は比較のための設定値であって、LEANN固有の上限でも、どんな設定でも保証される値でもない。取りこぼしが許されない用途では自分のデータで確認する前提で捉えたい。

検索は遅くならないのか。 プロジェクトページは「上位3件を2秒未満」と要約しているが、論文の詳細な測定ではRTX 4090（32GB RAM・WSL2）で約1.1〜7.1秒、AWS EC2のM1 Ultra（128GB RAM）で約5.2〜44.8秒と幅が大きい。探索時に一部のノードを再計算するぶん、実際の速度は埋め込みモデルの重さとGPUの有無で変わり、軽い埋め込みモデルをGPUで動かせるほど有利になる。

Windowsでも使えるのか。 Windowsはネイティブに対応している。既定のHNSWはREADMEで各環境の既定として案内されている。PyPIにはWindows（win_amd64）向けのビルド済みパッケージも配布されているため（0.3.7時点、HNSW・DiskANNの両バックエンド）、uv pip install leann で導入できる。ソースからビルドする場合に Visual Studio Build Tools と vcpkg が要る、という関係だ。「macOS 13.3以降」はmacOSでDiskANNをビルドする場合の条件で、Windowsでの利用可否を左右するものではない。

いまのChromaDBなどの構成から乗り換えるべきか。 保存量が問題になっていないなら急ぐ必要はない。全ベクトルを保存する構成が容量的に苦しくなってきた、あるいは端末内で大きな個人データを扱いたい、という段階で検討する対象と考えるのが素直だ。

まとめ

LEANNは、全件分の高精度な密ベクトルを索引内に保存せず、探索時に必要になったノードだけ埋め込みを再計算するローカルRAG向けの索引だ。密ベクトルを抱える従来型の保存コストを、検索時の再計算コストに置き換えることで、公称で約97%の保存量削減をうたう。論文は索引の保存量を生データ容量の5%未満に抑えたまま、比較のためにそろえた上位3件の再現率90%を報告している。検索の速さはプロジェクトページが2秒未満と要約するが、論文の詳細表ではRTX 4090で約1〜7秒、Macでは約5〜45秒と条件差が大きい。

効くのは、大きな個人データを端末内で検索したいが保存量が制約になる場面。埋め込みもLLMもローカルのバックエンドを選べば端末内で完結でき、ライセンスはMITで導入も uv 一行から試せる。一方で、小さなデータや低レイテンシ重視、頻繁な更新では従来型が素直なことも多い。単独の量子化索引が圧縮したベクトルをそのまま距離計算に使うのに対し、LEANNは検索時の再計算に寄せる。どちらが向くかは、自分のデータ規模と更新頻度で決まる。