LightRAGは知識グラフベースのデュアルレベル検索を実装したRAGフレームワークだ。GitHubスター33,000超を獲得し、自然言語処理の主要国際会議EMNLP2025に採択された。従来のベクトル検索中心のRAGが抱える「文脈の断片化」「高次概念の把握困難」という課題に対し、ドキュメントからエンティティと関係性を自動抽出して知識グラフを構築し、エンティティ単位とコミュニティ単位の2段階検索で回答精度を高める。PostgreSQL・MongoDB・Neo4j対応、Web UI・REST API・Docker完備と、プロダクション運用に必要な機能が揃っている。
LightRAGのアーキテクチャ：知識グラフ×デュアルレベル検索の仕組み
LightRAGの中核は、ドキュメントのインデキシング時にLLMを使ってエンティティ（人物、組織、技術、概念など）と関係性を抽出し、知識グラフを自動構築する点にある。従来のRAGがドキュメントをチャンクに分割してベクトル化するだけなのに対し、LightRAGはチャンクからさらに構造化された知識を抽出する。
この知識グラフに対して、2つのレベルで検索を実行する。
- 低レベル検索（Low-level Retrieval）: 特定のエンティティとその直接的な関係性にフォーカスし、「PostgreSQLのWAL設定方法」のような具体的な質問に精密に回答する
- 高レベル検索（High-level Retrieval）: エンティティのコミュニティ構造（関連するエンティティ群のクラスタ）を活用し、「データベースの可用性戦略」のような抽象的・包括的な質問にも対応する
PDF / テキスト / 画像"] -->|チャンク分割| B["テキストチャンク"] B -->|LLMで抽出| C["エンティティ抽出
人物・組織・技術・概念"] B -->|LLMで抽出| D["関係性抽出
エンティティ間の関連"] C --> E["知識グラフ構築
ノード + エッジ"] D --> E B -->|埋め込み生成| F["ベクトルインデックス"] E --> G["コミュニティ検出
関連エンティティのクラスタ化"] H["ユーザーの質問"] --> I["クエリ解析"] I --> J["低レベル検索
エンティティ + 関係性"] I --> K["高レベル検索
コミュニティ構造"] I --> F J --> L["検索結果の統合
+ リランキング"] K --> L F --> L L --> M["LLM回答生成
引用付き"]
この二層構造によって、LightRAGは具体的な事実の検索と抽象的な概念の把握を同時に行える。ベンチマーク評価では、農業・計算機科学・法律・混合ドメインの4分野でNaiveRAG、GraphRAG、RQ-RAG、HyDEを上回る結果を示している。
従来のベクトル検索型RAGでは「Aとは何か」という直接的な質問には対応できても、「AとBの関係性はどうなっているか」「Cに影響を与える要因を包括的に列挙せよ」のような関係性や網羅性が求められる質問には弱かった。LightRAGの知識グラフは、このような質問に対してエンティティ間のエッジ情報とコミュニティの階層構造を活用して回答を生成する。
知識グラフの構築はインデキシング時に一度だけ実行され、新しいドキュメントが追加された場合はインクリメンタルに更新される。既存のグラフ構造を破壊せず、新たなエンティティと関係性をマージする設計のため、運用中のナレッジベースを動的に拡張できる。重複するエンティティが異なるドキュメントに出現した場合は、自動的にdeduplication（重複排除）が行われ、グラフの肥大化を防ぐ。
インストールとセットアップ：3つの導入方法
LightRAGは用途に応じて3つの方法で導入できる。
方法1：PyPIからのインストール（推奨）
最も手軽な方法で、Web UI付きのサーバーとして起動できる。
# uvを使ったインストール（Web UI + REST API付き）
uv tool install "lightrag-hku[api]"
# pipの場合
pip install "lightrag-hku[api]"
# サーバー起動
lightrag-server
lightrag-serverを実行すると、デフォルトでhttp://localhost:9621にWeb UIが立ち上がる。ブラウザからドキュメントのアップロード、知識グラフの可視化、RAGクエリの実行が可能だ。
方法2：ソースからのインストール
開発や拡張を行う場合はソースからインストールする。
git clone https://github.com/HKUDS/LightRAG.git
cd LightRAG
# uvによる依存解決と仮想環境の作成
uv sync
source .venv/bin/activate
# 開発モードで起動
make dev
lightrag-server
方法3：Dockerでのデプロイ
本番環境やチームでの共有利用にはDockerが適している。
git clone https://github.com/HKUDS/LightRAG.git
cd LightRAG
# 環境変数ファイルの作成
cp env.example .env
# Docker Composeで起動
docker compose up -d
.envファイルで設定すべき主要項目は以下の通り。
# LLM設定（OpenAIの場合）
LLM_MODEL=gpt-4o
LLM_API_KEY=sk-xxxxxxxxxxxxxxxx
# 埋め込みモデル設定
EMBEDDING_MODEL=text-embedding-3-large
EMBEDDING_API_KEY=sk-xxxxxxxxxxxxxxxx
# ストレージバックエンド（PostgreSQL推奨）
LIGHTRAG_STORAGE=postgresql
POSTGRES_HOST=localhost
POSTGRES_PORT=5432
POSTGRES_USER=lightrag
POSTGRES_PASSWORD=your_secure_password
POSTGRES_DATABASE=lightrag
環境変数の設定にはセットアップウィザードも利用できる。
make env-base # LLM・埋め込み・リランカーの設定
make env-storage # ストレージバックエンドの設定
make env-server # サーバーポート・認証・SSLの設定
make env-security-check # セキュリティ監査
MCPサーバーの構築ガイドで解説しているように、AIツールのセットアップでは環境変数の管理が重要になる。LightRAGもこの原則に従い、.envファイルで全設定を一元管理する設計になっている。
Python APIによるRAGパイプラインの構築
LightRAGのPython APIは非同期（asyncio）ベースで設計されている。ドキュメントの投入からクエリの実行まで、コードから完全に制御できる。
基本的な使い方
import asyncio
import os
from lightrag import LightRAG, QueryParam
# 作業ディレクトリの設定
WORKING_DIR = "./lightrag_data"
os.makedirs(WORKING_DIR, exist_ok=True)
async def main():
# LightRAGインスタンスの初期化
rag = LightRAG(
working_dir=WORKING_DIR,
llm_model_name="gpt-4o",
embedding_model_name="text-embedding-3-large",
)
# ドキュメントの投入
with open("knowledge_base.txt", "r") as f:
content = f.read()
await rag.ainsert(content)
# naive検索（ベクトル類似度のみ）
result_naive = await rag.aquery(
"LLMの推論最適化手法は？",
param=QueryParam(mode="naive")
)
print("--- Naive ---")
print(result_naive)
# hybrid検索（エンティティ + コミュニティ）
result_hybrid = await rag.aquery(
"LLMの推論最適化手法は？",
param=QueryParam(mode="hybrid")
)
print("--- Hybrid ---")
print(result_hybrid)
# mix検索（最高精度、リランキング付き）
result_mix = await rag.aquery(
"LLMの推論最適化手法は？",
param=QueryParam(mode="mix")
)
print("--- Mix ---")
print(result_mix)
asyncio.run(main())
ainsert()でドキュメントを投入すると、LLMによるエンティティ・関係性の抽出と知識グラフの構築が自動的に実行される。aquery()のmodeパラメータで検索戦略を切り替えられる。
PostgreSQLバックエンドでの初期化
本番環境ではファイルベースのストレージではなくPostgreSQLを使用する。PostgreSQLバックエンドはベクトルインデックス・知識グラフ・ドキュメントストアをすべて1つのデータベースで管理できるall-in-oneソリューションだ。
from lightrag import LightRAG
rag = LightRAG(
working_dir="./lightrag_data",
llm_model_name="gpt-4o",
embedding_model_name="text-embedding-3-large",
# PostgreSQLバックエンド設定
kv_storage="PostgreSQLStorage",
vector_storage="PostgreSQLStorage",
graph_storage="PostgreSQLStorage",
doc_status_storage="PostgreSQLStorage",
# 接続情報は環境変数から自動取得
# POSTGRES_HOST, POSTGRES_PORT, POSTGRES_USER,
# POSTGRES_PASSWORD, POSTGRES_DATABASE
)
Neo4jを知識グラフのストレージとして使う場合は、graph_storage="Neo4JStorage"に変更するだけで切り替え可能だ。ベクトル検索はPostgreSQLのpgvector拡張を使いつつ、グラフ探索はNeo4jの高速なトラバーサルを活用するハイブリッド構成も組める。
Ollama（ローカルLLM）での利用
外部APIを使わずにローカル環境でLLMを動かす場合は、Ollamaと組み合わせて利用できる。
from lightrag import LightRAG
rag = LightRAG(
working_dir="./lightrag_data",
llm_model_name="qwen2.5:32b", # Ollamaで動作するモデル
llm_model_func_name="ollama_model_complete",
embedding_model_name="bge-m3",
embedding_func_name="ollama_embedding",
)
LLMは32Bパラメータ以上、コンテキスト長は64KB以上が推奨される。インデキシング時にはreasoning model（推論特化モデル）の使用を避けることが公式に推奨されている。推論モデルはトークン消費が大きく、エンティティ抽出タスクには過剰なためだ。
Web UI・REST API・マルチモーダル対応
知識グラフの可視化とWeb UI
LightRAGのWeb UIはlightrag-serverコマンドで起動する。デフォルトではhttp://localhost:9621でアクセスできる。
Web UIが提供する主な機能は以下の通り。
- ドキュメント管理: テキスト・PDF・画像のアップロードとインデキシング状態の監視
- 知識グラフ可視化: ノード（エンティティ）とエッジ（関係性）をインタラクティブに探索。重力レイアウトの切り替えに対応
- サブグラフフィルタリング: 特定のエンティティを起点にしたサブグラフの抽出と表示
- RAGクエリ: 5つの検索モード（naive / local / global / hybrid / mix）を切り替えながら対話的にクエリを実行
- Ollama互換チャット: ローカルLLMと組み合わせたチャットインターフェース
知識グラフの可視化は、ドキュメント間の関係性を直感的に把握するのに有用だ。大量の技術文書を投入した場合、手動では発見困難な概念間のつながりがグラフ上で可視化される。
REST APIによる外部連携
REST APIも同時に提供されるため、外部アプリケーションからのHTTP経由での利用も可能だ。
# ドキュメントの投入（REST API経由）
curl -X POST http://localhost:9621/documents/text \
-H "Content-Type: application/json" \
-d '{
"text": "LightRAGは知識グラフベースのRAGフレームワークです...",
"description": "LightRAG概要ドキュメント"
}'
# クエリの実行
curl -X POST http://localhost:9621/query \
-H "Content-Type: application/json" \
-d '{
"query": "LightRAGのアーキテクチャを説明してください",
"mode": "mix"
}'
マルチモーダル対応：PDF・画像・テーブルの統合処理
LightRAGはRAG-Anythingとの統合により、テキスト以外のデータソースにも対応している。PDF内の画像、数式、テーブルを構造化データとして抽出し、知識グラフに組み込むことができる。
対応するデータ形式は以下の通り。
| データ形式 | 処理方法 | 知識グラフへの反映 |
|---|---|---|
| プレーンテキスト | 直接チャンク分割 | エンティティ・関係性を抽出 |
| テキスト抽出 + レイアウト解析 | テキスト・テーブル・画像を分離して処理 | |
| 画像 | マルチモーダルLLMで記述生成 | 画像の内容をテキスト化してグラフに統合 |
| テーブル | 構造化データとして抽出 | 行・列の関係性をエンティティ化 |
| 数式 | LaTeX形式で抽出 | 数式の意味をテキスト記述に変換 |
技術論文のPDFを投入した場合、本文テキストだけでなく図表のキャプション、テーブルの数値データ、数式の意味も知識グラフに取り込まれる。これにより、「この論文で使われている損失関数は何か」のような、図表に記載された情報への質問にも対応可能になる。
AIエージェントフレームワーク比較2026で取り上げたように、エージェントが外部知識を参照する際のRAG精度は最終的な回答品質に直結する。LightRAGのマルチモーダル対応は、エージェントのナレッジベースとしても活用できる。
LightRAGのエコシステムには関連プロジェクトとしてVideoRAG（長尺動画に対するRAG）とMiniRAG（軽量化された簡易版LightRAG）も存在する。VideoRAGは動画コンテンツからフレームとトランスクリプトを抽出して知識グラフに組み込む。MiniRAGはリソースが限られた環境向けに機能を絞った実装で、エッジデバイスや小規模プロジェクトでの利用を想定している。
LightRAG vs GraphRAG vs NaiveRAGの比較
知識グラフを活用するRAGフレームワークとして、LightRAGとMicrosoftのGraphRAG、そして従来型のNaiveRAG（ベクトル検索のみ）を比較する。
| 比較項目 | LightRAG | GraphRAG (Microsoft) | NaiveRAG |
|---|---|---|---|
| 検索方式 | デュアルレベル（エンティティ + コミュニティ） | グラフベース（コミュニティサマリ中心） | ベクトル類似度のみ |
| 知識グラフ構築 | LLMで自動抽出 + インクリメンタル更新 | LLMで自動抽出（バッチ処理） | なし |
| インデキシングコスト | 中（GraphRAGより軽量） | 高（大量のLLMコール） | 低（埋め込み生成のみ） |
| 検索モード | 5種類（naive / local / global / hybrid / mix） | 2種類（local / global） | 1種類（ベクトル検索） |
| リランキング | 対応（mixモード） | 非対応 | ツール依存 |
| インクリメンタル更新 | 対応（グラフマージ） | 非対応（再構築が必要） | 対応 |
| ストレージ対応 | PostgreSQL / MongoDB / Neo4j / OpenSearch | Azure / ローカル | ベクトルDB各種 |
| Web UI | あり（知識グラフ可視化付き） | なし（CLIベース） | ツール依存 |
| Docker対応 | あり | あり | ツール依存 |
| マルチモーダル | 対応（RAG-Anything連携） | テキストのみ | テキストのみ |
| ベンチマーク（網羅性） | 67.6%（農業ドメイン） | 32.4%（農業ドメイン） | ベースライン |
| ライセンス | MIT | MIT | ツール依存 |
| GitHubスター | 33,400+ | 24,000+ | — |
| 学術採択 | EMNLP2025 | — | — |
ベンチマーク結果は公式論文（EMNLP2025採択）に基づく。農業・計算機科学・法律・混合ドメインの4分野で、網羅性（Comprehensiveness）・多様性（Diversity）・エンパワーメント（Empowerment）・総合品質（Overall）の4指標すべてでLightRAGがGraphRAGを上回っている。
特にインクリメンタル更新の有無は運用上の大きな差になる。GraphRAGは新しいドキュメントを追加するたびに知識グラフ全体を再構築する必要があるが、LightRAGは既存グラフに新しいエンティティと関係性をマージするだけで済む。ドキュメントが日々追加される環境では、この差がインデキシングコストと運用負荷に直結する。
また、LightRAGのmixモードはリランカーを統合しており、検索結果の精度を追加のコンポーネントなしで向上させる。GraphRAGやNaiveRAGでリランキングを実現するには、別途Cohere RerankやBAAI/bge-rerankerなどの外部サービスを組み込む必要がある。
運用のベストプラクティスとチューニング
LightRAGを本番環境で運用する際に押さえておくべき設定とチューニングのポイントを整理する。
LLMと埋め込みモデルの選定
LightRAGのパフォーマンスはLLMと埋め込みモデルの選定に大きく依存する。
# 推奨設定例（.env）
# インデキシング用LLM（エンティティ抽出）
# 32B以上、64KBコンテキスト推奨
# reasoning modelは避ける（トークン消費が過大）
LLM_MODEL=gpt-4o
LLM_API_KEY=sk-xxxxxxxx
# クエリ用LLM（回答生成）
# インデキシングより高性能なモデルを使うと回答品質が向上
QUERY_LLM_MODEL=gpt-4o
# 埋め込みモデル
# 多言語対応が必要な場合はBAAI/bge-m3を推奨
# 重要：インデキシングとクエリで同じモデルを使うこと
EMBEDDING_MODEL=text-embedding-3-large
# リランカー（mix検索モードで使用）
# 精度向上に大きく寄与する
RERANKER_MODEL=BAAI/bge-reranker-v2-m3
埋め込みモデルはインデキシング時とクエリ時で必ず同じモデルを使用する必要がある。モデルを変更する場合はベクトルテーブルのクリアと再インデキシングが必要になる。これはベクトルの次元数や意味空間が異なるためで、混在させると検索精度が大幅に劣化する。
ストレージバックエンドの選定
LightRAGは4つのストレージバックエンドに対応している。用途に応じて選択する。
| バックエンド | 特徴 | 適した用途 |
|---|---|---|
| PostgreSQL | ベクトル・KG・ドキュメントをすべて1つのDBで管理。pgvector拡張を使用 | 本番環境の標準構成。運用の簡素化を重視する場合 |
| Neo4j | グラフデータベース。ノードのトラバーサルが高速 | 知識グラフの探索性能を重視する場合。PostgreSQLとの併用も可能 |
| MongoDB | ドキュメント指向DB。スキーマレスで柔軟 | 既存のMongoDBインフラがある環境 |
| OpenSearch | 全文検索 + ベクトル検索の統合基盤 | Elasticsearchエコシステムとの統合が必要な場合 |
PostgreSQLはall-in-oneソリューションとして最も導入が容易で、公式にも推奨されている。Neo4jはグラフ探索に特化しているため、知識グラフのノード間を何ホップもたどるような複雑なクエリが頻繁に発生する場合に有利だ。ファイルベースのJSON/KVストレージも用意されているが、開発・テスト用途に限定される。
インデキシングの最適化
大量のドキュメントを投入する場合は、以下の点に注意する。
- バッチサイズの調整: 一度に大量のドキュメントを投入するとLLMのAPI呼び出しが集中する。数十ファイル単位でバッチ処理を行い、レート制限を回避する
- 重複エンティティの管理: LightRAGはエンティティの重複排除（deduplication）を自動的に行う。同一エンティティが異なるドキュメントに登場した場合、グラフ上でマージされる
- ドキュメントの削除: 削除APIを使用すると、該当ドキュメントに由来するエンティティと関係性が知識グラフから自動的に除去され、グラフが再生成される
トークン使用量の監視
知識グラフの構築にはLLMの呼び出しが必要なため、トークンコストの監視が重要だ。LightRAGはトークン使用量のトラッキング機能を内蔵しており、Langfuseとの連携でコストの可視化も可能だ。
# Langfuseトレーシングの有効化
import os
os.environ["LANGFUSE_PUBLIC_KEY"] = "pk-xxx"
os.environ["LANGFUSE_SECRET_KEY"] = "sk-xxx"
os.environ["LANGFUSE_HOST"] = "https://cloud.langfuse.com"
# RAGASによる品質評価
# インデキシング・クエリ双方のメトリクスを計測
from lightrag import LightRAG
rag = LightRAG(
working_dir="./lightrag_data",
llm_model_name="gpt-4o",
embedding_model_name="text-embedding-3-large",
enable_llm_cache=True, # LLMキャッシュでコスト削減
)
enable_llm_cache=Trueを設定すると、同一のプロンプトに対するLLMの応答がキャッシュされ、再インデキシング時やテスト時のコストを削減できる。
セキュリティ設定
LightRAGのセットアップウィザードにはセキュリティ監査機能が含まれている。
# セキュリティチェックの実行
make env-security-check
本番環境では以下を確認する。
- APIキーが
.envファイルに平文で保存されていないか（シークレット管理ツールの利用を推奨） - Web UIの認証設定が有効になっているか
- PostgreSQLの接続にSSLが使用されているか
- ネットワーク設定でLightRAGサーバーのポートが外部に公開されていないか
まとめ：LightRAGの導入判断チェックリスト
LightRAGは、知識グラフとデュアルレベル検索を組み合わせることで、従来のベクトル検索型RAGを超える検索精度を実現するフレームワークだ。EMNLP2025採択という学術的な裏付けと、33,000超のGitHubスターというコミュニティの支持を得ている。
導入を検討する際のチェックポイントを整理する。
- 知識グラフが必要か: ドキュメント間の関係性や高次概念の把握が求められる場合はLightRAGが効果的。単純なFAQ検索なら従来のベクトル検索RAGで十分
- インデキシングコスト: 知識グラフの構築にはLLMのAPI呼び出しが必要で、ドキュメント量に比例してコストが発生する。ただしGraphRAGより軽量
- LLMの要件: 32Bパラメータ以上、64KBコンテキスト推奨。ローカルLLM（Ollama）でも動作するが、モデルサイズに注意
- ストレージの選定: PostgreSQL（all-in-one）、Neo4j（グラフ探索重視）、MongoDB（ドキュメント指向）から選択
- 運用体制: Web UIがあるため非エンジニアもクエリ実行可能。ただしインデキシング設定やモデル選定にはMLエンジニアの知見が必要
知識グラフベースのRAGは、単なるベクトル検索では拾えなかった文脈や関係性を捉える。LightRAGはその中でも軽量で実用的な選択肢として、プロダクション運用への道が開けている。
