検索増強生成(RAG)は、LLMを外部知識に接地するためのデフォルトアーキテクチャとなった。しかし、ほとんどのRAGシステムは依然としてフラットなベクトル検索に依存しており、ドキュメントを孤立したチャンクとして扱い、エンティティ間の関係を理解しない。香港大学からEMNLP 2025 Findingsで発表されたLightRAGは、根本的に異なるアプローチを提供する:グラフ構造化インデックスと二層検索システム1。
GitHubスター3.4万以上、コントリビューター250人2で、LightRAGは最も人気のあるオープンソースRAGフレームワークの一つとなった。問題は、この評判に値するかどうかだ。
LightRAGの独自性
LangChainのデフォルトリトリーバーやLlamaIndexのような従来のRAGシステムは、ベクトル類似度検索を使用する——ドキュメントチャンクを埋め込み、クエリに最も近いマッチを見つける。これは単純な事実検索には有効だが、エンティティ間の関係を理解する必要がある質問には失敗する1。
LightRAGは異なるアプローチを取る。インデックス作成中、ドキュメントからエンティティと関係を抽出し、知識グラフを構築する。検索中、二層戦略を使用する1:
- 低レベル検索:特定のエンティティとその直接の関係に焦点——正確な事実クエリに有効
- 高レベル検索:より広範なトピックとテーマを表示——分析的または探索的な質問に有効
グラフ構造とベクトル表現の統合により、関連するエンティティとその関係の効率的な検索が可能となり、コンテキストの関連性を維持しながら応答時間が大幅に改善される1。
ベンチマーク結果:LightRAG vs 業界
LightRAGチームは、4つのドメイン(農業、コンピュータサイエンス、法律、混合)で4つのベースラインを評価した2。
表1:全体パフォーマンス比較 2
| システム | 農業 | コンピュータサイエンス | 法律 | 混合 |
|---|---|---|---|---|
| NaiveRAG | 32.4% | 38.8% | 15.2% | 40.0% |
| LightRAG | 67.6% | 61.2% | 84.8% | 60.0% |
| RQ-RAG | 32.4% | 38.0% | 14.4% | 40.0% |
| LightRAG | 67.6% | 62.0% | 85.6% | 60.0% |
| HyDE | 26.0% | 41.6% | 26.8% | 40.4% |
| LightRAG | 74.0% | 58.4% | 73.2% | 59.6% |
| GraphRAG | 45.6% | 48.4% | 48.4% | 50.4% |
| LightRAG | 54.4% | 51.6% | 51.6% | 49.6% |
結果は印象的だ。LightRAGは農業と法律のドメインでNaiveRAGを35ポイント以上上回る。マイクロソフトのグラフベースRAGフレームワークGraphRAGと比較して、LightRAGは4つのドメイン中3つで勝利し、法律ドメインで最も劇的な差(51.6% vs 48.4%)を示した2。
技術アーキテクチャ
LightRAGのアーキテクチャには3つのコアコンポーネントがある1:
1. グラフベースのテキストインデックス
従来のRAGシステムがドキュメントをフラットなテキストチャンクとして保存するのとは異なり、LightRAGはインデックス作成中にエンティティと関係を抽出し、知識グラフを構築する。これにより、システムは概念間の関係を理解できる——それらが何であるかだけでなく。
2. 二層検索
検索システムは2つのレベルで動作する:
- エンティティレベル:特定のエンティティとその直接の関係を検索
- トピックレベル:知識グラフ全体のより広範なテーマとパターンを識別
この二層アプローチにより、LightRAGは正確な事実クエリ(「フランスの首都は?」)と分析的な質問(「フランスとEUの関係はどのように進化したか?」)の両方を処理できる。
3. 増分更新
LightRAGには、インデックス全体を再構築せずに新しいデータを統合できる増分更新アルゴリズムが含まれている。これはデータが絶えず変化する本番環境にとって重要だ1。
実用的な考慮事項
LightRAGはOpenAI、Ollama、Azure、Gemini、HuggingFaceを含む複数のLLMプロバイダーをサポートしている2。さまざまな埋め込みモデルもサポートし、リランキングシステムと統合できる。
フレームワークは主にPythonで記述されており(81.2%)、TypeScriptコンポーネント(12.9%)を補助として使用している2。MITライセンスで、活発にメンテナンスされており、70のリリースがあり、最新バージョン(v1.4.15)は2026年4月19日にリリースされた2。
LightRAGを使用すべき場面
LightRAGは以下の場合に最も価値がある1:
- クエリがエンティティ間の関係を理解する必要がある
- 相互に参照するドキュメントを処理する必要がある
- 完全な再構築なしに増分更新できるシステムが必要
- 関係が重要なドメインで作業している(法律、研究、技術文書)
単純な事実検索(例:「東京の天気は?」)には、従来のベクトルベースのRAGで十分で、より高速かもしれない。
限界
GraphRAGとのベンチマーク比較は他のベースラインよりも接近しており、グラフベースのアプローチがシンプルな方法と比較して収穫逓減を示唆している。さらに、LightRAGのグラフ構築はインデックス作成中にオーバーヘッドを追加する——トレードオフはクエリ時のより高速で正確な検索だ。
法律ドメインの結果は特に興味深い:LightRAGの84.8% vs NaiveRAGの15.2%は、複雑で関係の密集したドメインでは、グラフベースのRAGがより良いだけでなく、必須であることを示唆している2。
結論
LightRAGはRAGシステムの大きな進歩を代表する。グラフ構造化インデックスと二層検索を組み合わせることで、従来のRAGの根本的な限界——エンティティ間の関係を理解できない——を解決する。GitHubスター3.4万以上とEMNLP 2025の発表により、グラフベースのRAGの事実上の標準となった。
複雑で関係の密集したデータでRAGシステムを構築するチームにとって、LightRAGは真剣に検討する価値がある。ベンチマークは、従来のグラフベースの代替手段に対する明確な優位性を示しており、増分更新機能により本番環境での使用が実用的である。
参考文献
Footnotes
-
LightRAG: Simple and Fast Retrieval-Augmented Generation — EMNLP 2025 Findings論文、Guoら(香港大学)、グラフベースのインデックスと二層検索アーキテクチャを記述 https://aclanthology.org/2025.findings-emnlp.568/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
HKUDS/LightRAG GitHubリポジトリ — スター3.4万以上、4つのドメインでNaiveRAG、RQ-RAG、HyDE、GraphRAGと比較したベンチマーク結果 https://github.com/HKUDS/LightRAG ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8