README-ja.md
<a href="https://pypi.org/project/lightrag-hku/"></a>
</p>
<p>
<a href="https://discord.gg/yF2MmDJyGJ"></a>
<a href="https://github.com/HKUDS/LightRAG/issues/285"></a>
</p>
<p>
<a href="README-zh.md"></a>
<a href="README.md"></a>
<a href="README-ja.md"></a>
</p>
<p>
<a href="https://pepy.tech/projects/lightrag-hku"></a>
<a href="https://hvtracker.net/agents/lightrag/"></a>
</p>
</td>
<td style="vertical-align: middle; padding-left: 12px;">
<a href="https://litewrite.ai">
</a>
</td>
</tr>
Fix、Recursive、Vector、Paragraph。図1: LightRAG インデックス作成フローチャート - 画像出典: Source 図2: LightRAG 検索・クエリフローチャート - 画像出典: Source
</details>💡 パッケージ管理に uv を使用: 本プロジェクトでは、高速かつ信頼性の高い Python パッケージ管理のために uv を使用しています。まず uv をインストールしてください: curl -LsSf https://astral.sh/uv/install.sh | sh（Unix/macOS）または powershell -c "irm https://astral.sh/uv/install.ps1 | iex"（Windows）
注記: お好みであれば pip も使用できますが、より良いパフォーマンスと信頼性の高い依存関係管理のため、uv を推奨します。
📦 オフラインデプロイ: オフライン環境やエアギャップ環境については、すべての依存関係とキャッシュファイルを事前インストールする手順を記したオフラインデプロイガイドを参照してください。
### uv を使って LightRAG サーバーをツールとしてインストール（推奨）
uv tool install "lightrag-hku[api]"
### または pip を使用
# python -m venv .venv
# source .venv/bin/activate # Windows: .venv\Scripts\activate
# pip install "lightrag-hku[api]"
# env ファイルのセットアップ
# env.example ファイルは GitHub リポジトリのルートからダウンロードするか、
# ローカルのソースチェックアウトからコピーして入手してください。
cp env.example .env # .env を自分の LLM・埋め込み設定で更新
# サーバーの起動。デフォルトではすべてのネットワークインターフェース(0.0.0.0)にバインドされます。
# セキュリティ: ネットワークに公開する前に、.env で認証を設定してください
#（LIGHTRAG_API_KEY、または AUTH_ACCOUNTS と TOKEN_SECRET の組み合わせ）。ローカル専用
# アクセスの場合は 127.0.0.1 にバインドしてください。認証がない場合、すべてのエンドポイントが公開されます。
# 注記: Ollama 互換の /api/* ルートは、クライアント互換性のためデフォルトで開放されたままです。
# これらにも認証を要求するには WHITELIST_PATHS=/health を設定してください。
lightrag-server
git clone https://github.com/HKUDS/LightRAG.git
cd LightRAG
# 開発環境のブートストラップ（推奨）
make dev
source .venv/bin/activate # 仮想環境の有効化（Linux/macOS）
# Windows の場合: .venv\Scripts\activate
# make dev はテストツールチェーンに加えて、完全なオフラインスタック
#（API、ストレージバックエンド、プロバイダー統合）をインストールし、フロントエンドをビルドします。
# サーバーを起動する前に、make env-base を実行するか env.example を .env にコピーしてください。
# uv による同等の手動手順
# 注記: uv sync は .venv/ ディレクトリに自動的に仮想環境を作成します
uv sync --extra test --extra offline
source .venv/bin/activate # 仮想環境の有効化（Linux/macOS）
# Windows の場合: .venv\Scripts\activate
### または仮想環境付きで pip を使用
# python -m venv .venv
# source .venv/bin/activate # Windows: .venv\Scripts\activate
# pip install -e ".[test,offline]"
# フロントエンド成果物のビルド
cd lightrag_webui
bun install --frozen-lockfile
bun run build
cd ..
# env ファイルのセットアップ
make env-base # または: cp env.example .env して手動で更新
# API-WebUI サーバーの起動
lightrag-server
git clone https://github.com/HKUDS/LightRAG.git
cd LightRAG
cp env.example .env # .env を自分の LLM・埋め込み設定で更新
# .env で LLM と埋め込みの設定を変更
docker compose up
LightRAG docker イメージの過去バージョンはこちらで確認できます: LightRAG Docker Images
GitHub Actions により公開された公式 GHCR イメージは、GitHub OIDC を用いた Sigstore Cosign で署名されています。検証コマンドについては docs/DockerDeployment.md を参照してください。
Apple Silicon（macOS 26）では、Docker Desktop なしで、同じ Postgres/Neo4j/Milvus ストレージスタックを Apple ネイティブの
containerランタイム上で実行できます。詳細は docs/AppleContainerSetup.md を参照してください。
env.example を手作業で編集する代わりに、対話型のセットアップウィザードを使って設定済みの .env、必要に応じて docker-compose.final.yml を生成できます:
make env-base # 必須の最初のステップ: LLM、埋め込み、リランカー
make env-storage # 任意: ストレージバックエンドとデータベースサービス
make env-server # 任意: サーバーポート、認証、SSL
make env-base-rewrite # 任意: ウィザード管理の compose サービスを強制再生成
make env-storage-rewrite # 任意: ウィザード管理の compose サービスを強制再生成
make env-security-check # 任意: 現在の .env のセキュリティリスクを監査
各ターゲットの詳細な説明については docs/InteractiveSetup.md を参照してください。
Native docx パーサーのオプトイン式エンジンパラメータ smart_heading は、文分割 / NER のヒューリスティック判定に spaCy を使用します。spaCy ランタイムは api extra に含まれています — 追加で必要なのは、バージョン固定された 2 つの言語モデル（zh_core_web_sm / en_core_web_sm 3.8.0、PyPI 未公開の GitHub release wheel）のインストールだけです：
lightrag-download-cache --spacy-install
smart_heading はファイル / ルール単位（例：LIGHTRAG_PARSER=docx:native(smart_heading=true)）でも、.env でグローバルにも有効化できます：
# native エンジンにルーティングされた .docx ファイルはデフォルトで smart_heading が有効になります。
# 個別に無効化するには、明示的な native(smart_heading=false) ルール / ヒントを使用してください。
DOCX_SMART_HEADING=true
グローバルスイッチが有効な場合（または LIGHTRAG_PARSER ルールに native(smart_heading=true) が含まれる場合）、サーバーは起動時にモデルの存在を検証し、欠落していればインストール手順を示して即座に失敗します（fail-fast）。smart_heading を一切使わないデプロイメントにはモデルは不要です。Docker のメインイメージにはモデルが同梱されています（lite イメージには含まれません）。オフライン環境についてはオフラインデプロイメントガイドを参照してください。
Native markdown/textpack パーサーは、埋め込まれた SVG 画像を cairosvg 経由で PNG にラスタライズします。cairosvg は cairo への cffi バインディングです：pip install cairosvg（api extra に含まれる）は常に成功しますが、実際にレンダリングが動作するのは、ネイティブの libcairo 共有ライブラリもホストに存在する場合に限られます — pip/uv はシステムライブラリをインストールできません。欠落している場合、ラスタライズは実行時に失敗し、該当の SVG はスキップされます（ドキュメントの他の部分には影響しません）。サーバーは起動時にこの機能を検証し、欠落していれば目立つ黄色の警告を表示するため、この問題がドキュメント処理時まで気づかれずに隠れてしまうことを防ぎます。
各プラットフォーム向けのシステムパッケージをインストールしてください：
# Debian / Ubuntu（公式 Docker イメージには既に含まれています）
sudo apt-get install -y libcairo2
# RHEL / Fedora
sudo dnf install -y cairo
# macOS（Homebrew）
brew install cairo
# Windows：libcairo-2.dll を同梱する GTK3 ランタイムをインストールしてください
埋め込み SVG を含む markdown/textpack ドキュメントを処理しないデプロイメントでは、この起動時の警告は無視して構いません。
LightRAG は、軽量なナレッジグラフRAGフレームワークであり、Microsoft GraphRAGの効率的な代替手段です。KG（ナレッジグラフ）とベクトル埋め込みを同時に管理する二層アーキテクチャを採用しており、従来のベクトルベースRAGとグラフベースRAGの間にある技術的なギャップを効果的に埋めます。高い拡張性を前提に設計されたLightRAGは、大規模なグラフのインデックス作成および検索における、計算コストの大きさ、応答の遅さ、増分更新コストの高さといった主要課題を解決します。大規模データセットをサポートしながら、30B規模のオープンソース大規模言語モデル（LLM）を用いた場合でも、非常に高いRAG品質を維持できます。
固定長チャンク (F)、再帰文字チャンク (R)、ベクトルセマンティックチャンク (V)、段落セマンティックチャンク (P) の 4 種類の戦略をサポートします。LightRAG 独自の 段落セマンティックチャンク (P) は、チャンク境界をドキュメント本来の意味的な境界（見出し、段落、表）にできる限り合わせます。これにより、見出しと本文の不一致や、長い表を分割した際のヘッダー行の欠落といった問題を軽減します。従来の RAG システムには、ドキュメント内の画像、数式、表などのマルチモーダルコンテンツを効果的に処理する手段が不足しています。v1.5 以降、LightRAG はマルチモーダル処理機能をドキュメント処理パイプラインとクエリフローにシームレスに統合しています。LightRAG はナレッジグラフを通じてマルチモーダルコンテンツと本文を関連付け、クエリへの回答時にその情報を活用することで、より正確で信頼性の高い回答を生成します。この機能により、操作マニュアルや学術論文など、マルチモーダルコンテンツを多く含むドキュメントの RAG 品質を大幅に向上できます。
LightRAG サーバーは、LightRAG の機能を探索するための Web ベース UI だけでなく、包括的な REST API も提供します。LightRAG サーバーの詳細については LightRAG Server を参照してください。
LightRAG のワークフローでは、4つの異なるロールの LLM/VLM を使用します。処理速度と性能のバランスを取るため、ロールごとに能力と速度の異なるモデルを設定することを推奨します。LightRAG はドキュメントからエンティティと関係を抽出する必要があるため、従来の RAG よりも大規模言語モデル（LLM）に高い能力が求められます。クエリ段階では、LLM は LightRAG が取得したエンティティ、関係、テキストチャンクなどの大量の情報を処理するため、ノイズを含む長いコンテキストから高品質な回答を生成できる必要があります。
ロール別の推奨モデル：
EXTRACT）：エンティティ・関係抽出は各テキストチャンクに対して実行されるため、高速でコスト効率に優れた一般的なモデルで十分です。抽出処理の低速化やコスト増加を避けるため、**非思考モデル（reasoning/thinking モードを無効化）**を強く推奨します。海外サービスでは GPT-5.6-luna、Claude Haiku、Gemini-mini、中国国内では DeepSeek-V4-lite、Kimi が選択肢となります。ローカルデプロイでは、最低ラインとして Qwen3-30B-A3B-Instruct を検討できます。QUERY）：長くノイズを含む取得コンテキストから最終回答を生成するため、回答品質を最大限に高められるよう、抽出モデルよりも高性能なモデルを選択してください。このロールでは、思考機能を備えたモデルを使用しても問題ありません。KEYWORD）：軽量かつレイテンシに敏感な処理であるため、クエリの遅延を抑えるには必ず非思考モデルを使用してください。抽出モデルと同等の高速なモデルで十分です。VLM）：画像入力に対応する一般的なマルチモーダルモデルであれば使用できます。ローカルデプロイでは Qwen3.6-35B-A3B を検討できます。許容可能なレイテンシとコストの範囲内で、公開ベンチマークやランキングのスコアが最も高いモデルを優先してください。モデル設定の詳細については、RoleSpecificLLMConfiguration.md を参照してください。
LightRAG は5つのクエリモードをサポートします:
LightRAG のデフォルトのクエリモードは mix です。mix モードを使用すると、一般に最も理想的なクエリ結果が得られます。mix モードは naive よりわずかに時間がかかりますが、その他のクエリモードはレイテンシがおおむね同等です。
埋め込みモデルを選ぶ際は、その多言語サポート能力に注意してください。LightRAG の検索品質は埋め込みモデルへの依存度が限定的であるため、低次元で高速なモデルを選ぶことを推奨します。通常、BAAI/bge-m3 で十分です。最良のパフォーマンスを得るため、埋め込みモデルをローカルにデプロイすることを強く推奨します。
重要な注記: 埋め込みモデルはドキュメントのインデックス作成前に確定する必要があり、クエリ段階でも同じモデルを使用しなければなりません。一度選択すると、埋め込みモデルは一般に変更できません。変更した場合は、すべてのテキストチャンク、エンティティ、関係を再埋め込みする必要があります。LightRAG は現在、再埋め込みツールを提供していません。一部のストレージバックエンド（例: PostgreSQL）では、テーブルの初回作成時にベクトル次元を定義する必要があるため、埋め込みモデルを変更するにはベクトル関連テーブルを削除し、LightRAG が再作成できるようにする必要があります。
クエリ段階で Rerank オプションを有効にすると、クエリ品質が大幅に向上します。ただし、Rerank を有効にすると通常 1～2 秒の遅延が生じます。レイテンシを最小化するため、Rerank モデルをローカルにデプロイすることを強く推奨します。設定の詳細については .env.example ファイルを参照してください。埋め込みモデルとは異なり、Rerank モデルはクエリ段階でいつでも変更できます。
LightRAG のデフォルトのパイプライン設定では、システムが最高の性能を発揮できません。ドキュメント解析の品質はドキュメントのインデックス作成とクエリに大きく影響します。そのため、MinerU 解析エンジンを有効にし、パイプラインの画像分析機能を有効化するようパイプラインを設定することを推奨します。推奨設定:
LIGHTRAG_PARSER=*:native-iteP,*:mineru-iteP,*:legacy-R
VLM_PROCESS_ENABLE=true
VLM_LLM_MODEL=<your_vlm_model_name>
クラウドベースの MinerU サービスには利用量・ファイルサイズ・ページ数の制限があるため、ローカルにデプロイした MinerU を使用することを推奨します。ファイル処理パイプラインの設定の詳細については FileProcessingPipeline.md を参照してください。
大規模なドキュメント処理では、並行性を高める必要があります。ファイルの並行処理に関連する主要な環境変数は以下のとおりです:
MAX_PARALLEL_INSERT は理想的には MAX_ASYNC_LLM の約1/3に設定すべきです。# 設定例
MAX_ASYNC_LLM=8
MAX_PARALLEL_INSERT=3
EMBEDDING_FUNC_MAX_ASYNC=16
EMBEDDING_BATCH_NUM=32
LightRAG は4種類のバックエンドストレージを必要とします:
デフォルトでは、LightRAG のストレージバックエンドはファイル永続化されたインメモリデータベースです。これらのデフォルトストレージは開発・デバッグ用途のみを想定しており、本番環境には適していません。本番環境で、4種類すべてのストレージを単一のバックエンドで扱いたい場合は、PostgreSQL、MongoDB、または OpenSearch を選択できます。あるいは、ベクトルストレージに Milvus や Qdrant、グラフストレージに Neo4j や Memgraph を使用するなど、ベクトルやグラフのストレージに専用データベースを選択することもできます。
ドキュメント挿入段階では、ニーズに応じて以下の環境変数の調整を検討するとよいでしょう:
Chinese、English）。entity/relation が関連付けられるテキストチャンクの最大数を制御します。entity/relation が関連テキストチャンク数の上限を超えた後も、エンティティ/関係の説明を更新し続けるかどうかを制御します（デフォルトでは更新を停止します。その時点でエンティティ関係の説明はすでに十分豊富であり、さらなる更新はほとんど価値を加えないためです。更新をスキップすることで知識ベースの構築を大幅に高速化できます）。entity/relation が関連付けられるソースファイルの最大数を制御します。この上限を超えると、新しいファイル名はベクトルストレージに書き込まれなくなります。エンティティ・関係抽出中の LLM タイムアウトは、通常3つの原因のいずれかに起因します。原因を特定し、対応する対策を適用してください（パラメータは併用できます）:
*_LLM_TIMEOUT（グローバルの LLM_TIMEOUT、または抽出フェーズ用のロール別 EXTRACT_LLM_TIMEOUT）でタイムアウトを延長してください。実際の実行タイムアウトは設定値の2倍になるため、EXTRACT_LLM_TIMEOUT=300 は最大600秒を許容します。OPENAI_LLM_MAX_TOKENS または OPENAI_LLM_MAX_COMPLETION_TOKENS で出力長を制限してください（正しいパラメータ名は LLM プロバイダーによって異なります。env.example を参照）。目安として max_output_tokens < LLM_TIMEOUT × tokens_per_second（例: 9000 < 240s × 50 tps）が有用です。P）チャンク戦略（例: LIGHTRAG_PARSER=...-iteP）を使用している場合、CHUNK_P_DROP_REFERENCES=true を設定すると、チャンク化の前に一致する参考文献ブロックを自動的に削除します。これにより、参考文献が大量の低価値なエンティティ・関係を生成すること（タイムアウトの一般的な原因）を防ぎます。ファイル名のヒント paper.[-P(drop_rf=true)].pdf でファイルごとに有効化することもできます。関連する検出パラメータ（CHUNK_P_REFERENCES_TAIL_N、CHUNK_P_REFERENCES_HEADINGS）は env.example に記載されています。ドキュメントクエリ段階では、ニーズに応じて以下の環境変数の調整を検討するとよいでしょう:
entities、relations、text chunks の3つの部分から構成されます。エンティティと関係の長さは独立して制御でき、テキストチャンクの長さは総長からエンティティと関係の長さを差し引いて決まります。⚠️ プロジェクトへの統合には、LightRAG サーバーが提供する REST API の使用を強く推奨します。 LightRAG SDK は主に組み込みアプリケーションや学術研究・評価目的を想定しています。
cd LightRAG
# 注記: uv sync は .venv/ ディレクトリに自動的に仮想環境を作成します
uv sync
source .venv/bin/activate # 仮想環境の有効化（Linux/macOS）
# Windows の場合: .venv\Scripts\activate
# または: pip install -e .
uv pip install lightrag-hku
# または: pip install lightrag-hku
LightRAG コアを使い始めるには、examples フォルダにあるサンプルコードを参照してください。さらに、ローカルセットアップ手順を案内するデモ動画も用意されています。すでに OpenAI API キーをお持ちであれば、すぐにデモを実行できます:
### デモコードはプロジェクトフォルダ内で実行してください
cd LightRAG
### OpenAI 用の API-KEY を指定
export OPENAI_API_KEY="sk-...your_opeai_key..."
### Charles Dickens 著「A Christmas Carol」のデモドキュメントをダウンロード
curl https://raw.githubusercontent.com/gusye1234/nano-graphrag/main/tests/mock_data.txt > ./book.txt
### デモコードを実行
python examples/lightrag_openai_demo.py
ストリーミング応答の実装例については、examples/lightrag_openai_compatible_demo.py を参照してください。実行前に、サンプルコードの LLM と埋め込みの設定を適宜変更してください。
注記1: デモプログラムを実行する際は、テストスクリプトによって異なる埋め込みモデルが使用される場合があることに注意してください。別の埋め込みモデルに切り替える場合は、データディレクトリ（./dickens）をクリアする必要があります。そうしないとプログラムでエラーが発生する可能性があります。LLM キャッシュを保持したい場合は、データディレクトリをクリアする際に kv_store_llm_response_cache.json ファイルを残すことができます。
注記2: 公式にサポートされているサンプルコードは lightrag_openai_demo.py と lightrag_openai_compatible_demo.py のみです。その他のサンプルファイルはコミュニティによる貢献であり、完全なテストと最適化を経ていません。
SDK の利用に関する詳細な手順については、docs/ProgramingWithCore.md を参照してください。一部の LightRAG 機能は REST API では公開されておらず、SDK 経由でのみアクセス可能です。これらの機能は通常、実験的なものであり、将来のバージョンと互換性がない場合があります。
LightRAG は、農業、コンピュータサイエンス、法律、混合ドメインにわたって、NaiveRAG、RQ-RAG、HyDE、GraphRAG を一貫して上回ります。完全な評価方法論、プロンプト、再現手順については、docs/Reproduce.md を参照してください。
全体性能テーブル
| Agriculture | CS | Legal | Mix | |||||
|---|---|---|---|---|---|---|---|---|
| NaiveRAG | LightRAG | NaiveRAG | LightRAG | NaiveRAG | LightRAG | NaiveRAG | LightRAG | |
| Comprehensiveness | 32.4% | 67.6% | 38.4% | 61.6% | 16.4% | 83.6% | 38.8% | 61.2% |
| Diversity | 23.6% | 76.4% | 38.0% | 62.0% | 13.6% | 86.4% | 32.4% | 67.6% |
| Empowerment | 32.4% | 67.6% | 38.8% | 61.2% | 16.4% | 83.6% | 42.8% | 57.2% |
| Overall | 32.4% | 67.6% | 38.8% | 61.2% | 15.2% | 84.8% | 40.0% | 60.0% |
| RQ-RAG | LightRAG | RQ-RAG | LightRAG | RQ-RAG | LightRAG | RQ-RAG | LightRAG | |
| Comprehensiveness | 31.6% | 68.4% | 38.8% | 61.2% | 15.2% | 84.8% | 39.2% | 60.8% |
| Diversity | 29.2% | 70.8% | 39.2% | 60.8% | 11.6% | 88.4% | 30.8% | 69.2% |
| Empowerment | 31.6% | 68.4% | 36.4% | 63.6% | 15.2% | 84.8% | 42.4% | 57.6% |
| Overall | 32.4% | 67.6% | 38.0% | 62.0% | 14.4% | 85.6% | 40.0% | 60.0% |
| HyDE | LightRAG | HyDE | LightRAG | HyDE | LightRAG | HyDE | LightRAG | |
| Comprehensiveness | 26.0% | 74.0% | 41.6% | 58.4% | 26.8% | 73.2% | 40.4% | 59.6% |
| Diversity | 24.0% | 76.0% | 38.8% | 61.2% | 20.0% | 80.0% | 32.4% | 67.6% |
| Empowerment | 25.2% | 74.8% | 40.8% | 59.2% | 26.0% | 74.0% | 46.0% | 54.0% |
| Overall | 24.8% | 75.2% | 41.6% | 58.4% | 26.4% | 73.6% | 42.4% | 57.6% |
| GraphRAG | LightRAG | GraphRAG | LightRAG | GraphRAG | LightRAG | GraphRAG | LightRAG | |
| Comprehensiveness | 45.6% | 54.4% | 48.4% | 51.6% | 48.4% | 51.6% | 50.4% | 49.6% |
| Diversity | 22.8% | 77.2% | 40.8% | 59.2% | 26.4% | 73.6% | 36.0% | 64.0% |
| Empowerment | 41.2% | 58.8% | 45.2% | 54.8% | 43.6% | 56.4% | 50.8% | 49.2% |
| Overall | 45.2% | 54.8% | 48.0% | 52.0% | 47.2% | 52.8% | 50.4% | 49.6% |
docs/）🇨🇳 が付いた項目は、同じフォルダに中国語版（*-zh.md）も用意されています。
デプロイとセットアップ
| ドキュメント | 内容 |
|---|---|
| InteractiveSetup.md | make env-* セットアップウィザード：.env およびウィザード管理下の docker-compose.final.yml の生成 |
| DockerDeployment.md | Docker / Docker Compose によるデプロイ、イメージの種類、公式 GHCR イメージの Cosign 検証 |
| AppleContainerSetup.md | Apple ネイティブの container ランタイムで Postgres / Neo4j / Milvus のストレージスタックを動かす方法（Apple Silicon、Docker Desktop 不要） |
| OfflineDeployment.md | オフライン／閉域環境でのインストール：依存関係、tiktoken キャッシュ、spaCy モデルの事前導入 |
| MultiSiteDeployment.md | 1 台のリバースプロキシ配下で複数の独立インスタンスを運用し、WebUI のビルド成果物を共有する（LIGHTRAG_API_PREFIX） |
| FrontendBuildGuide.md | WebUI のビルドと配布の仕組み（Bun / Node）、およびビルドが必要になるインストール形態 |
サーバーと API
| ドキュメント | 内容 |
|---|---|
| LightRAG-API-Server.md 🇨🇳 | サーバー完全ガイド：起動、設定、認証、REST エンドポイント、WebUI の使い方 |
ドキュメント処理
| ドキュメント | 内容 |
|---|---|
| FileProcessingPipeline.md 🇨🇳 | パイプライン仕様：LIGHTRAG_PARSER のルーティング規則、エンジン別パラメータ、マルチモーダル解析、ドキュメント状態のライフサイクル |
| ParserServiceDeployment.md 🇨🇳 | 外部解析サービス MinerU / docling-serve の自前ホスティング（Docker、GPU、モデル重み） |
| ParagraphSemanticChunking.md 🇨🇳 | Paragraph semantic (P) チャンク戦略：見出し／段落／表の境界に合わせた分割、参考文献の除外 |
| LightRAGSidecarFormat.md 🇨🇳 | マルチモーダル対応パーサーエンジンが必ず出力すべき sidecar（*.parsed/）交換フォーマットの仕様 |
| ThirdPartyParser.md 🇨🇳 | 独自パーサーエンジンの開発と登録 |
| ParserDebugCLI.md 🇨🇳 | python -m lightrag.parser.cli — サーバーなしで単一ファイルをオフライン解析し、結果を確認する |
モデルとストレージ
| ドキュメント | 内容 |
|---|---|
| RoleSpecificLLMConfiguration.md 🇨🇳 | ロール別（EXTRACT / QUERY / KEYWORD / VLM）の LLM・VLM 設定 |
| AsymmetricEmbedding.md | クエリ／文書の非対称 embedding（EMBEDDING_ASYMMETRIC）とモデルごとのプレフィックス |
| MilvusConfigurationGuide.md | vector_db_storage_cls_kwargs を通じた Milvus インデックスパラメータのチューニング |
SDK と開発
| ドキュメント | 内容 |
|---|---|
| ProgramingWithCore.md | LightRAG を Python SDK として使う方法（REST では公開されていない機能を含む） |
| Reproduce.md | 論文で報告した評価結果の再現手順 |
| UV_LOCK_GUIDE.md | uv.lock を更新すべきタイミングと方法 |
lightrag/tools/）ストレージを扱うツールはサーバーと同じように .env と環境変数を読み込むため、プロジェクトルートから同一の設定で実行してください。いくつかのツールはストレージをその場で書き換えます。サーバー（および他の書き込み側）を先に停止する必要があるかは各ガイドを確認してください。rebuild_vdb は停止が必須です。
rebuild_vdb.py — lightrag-rebuild-vdb — README_REBUILD_VDB.md
すべてのベクトルストレージを破棄し、権威データ（グラフのノード／エッジ、text_chunks KV ストア）から再構築します。ベクトル書き込み失敗後の復旧、および embedding モデルや次元数を変更した後の再構築に使用します。読み取り専用の整合性チェックモードもあります。
clean_llm_query_cache.py — lightrag-clean-llmqc — README_CLEAN_LLM_QUERY_CACHE.md
クエリモードの LLM キャッシュ（mix:*、hybrid:*、local:*、global:*、naive:*）を削除し、コストの高い抽出キャッシュは保持します。
migrate_llm_cache.py — python -m lightrag.tools.migrate_llm_cache — README_MIGRATE_LLM_CACHE.md
default モードのキャッシュ（抽出・要約・マルチモーダル解析）を KV ストレージバックエンド間で移行し、workspace の分離を保ちます。
kg_integrity_repair.py — python -m lightrag.tools.kg_integrity_repair [--apply] — README_KG_INTEGRITY_REPAIR.md
グラフ全体を監査し、full_entities / full_relations の復旧アンカーから参照されていない寄与を検出、帰属不能な孤立オブジェクトを報告し、必要に応じてアンカーを補完して削除・再処理から再発見できるようにします。
source_conflict_repair.py — python -m lightrag.tools.source_conflict_repair list / ... repair — README_SOURCE_CONFLICT_REPAIR.md
同一の正規 source key を主張するドキュメントを一覧表示し、運用者が選ばなかった候補を重複としてマークします。ツールが勝者を自動で決めることはなく、内容を削除することもありません。
download_cache.py — lightrag-download-cache [--spacy-install] — OfflineDeployment.md
オフラインデプロイおよび docx の smart_heading エンジンパラメータに必要な tiktoken エンコーディングとバージョン固定済み spaCy モデルを事前ダウンロードします。
hash_password.py — lightrag-hash-password [--username USER] — LightRAG-API-Server.md
AUTH_ACCOUNTS にそのまま貼り付けられる bcrypt 値を生成します。
check_initialization.py — python -m lightrag.tools.check_initialization --demo — ProgramingWithCore.md
SDK 用の診断ツール：LightRAG インスタンスが完全に初期化されているかを検証し、よくある「await rag.initialize_storages() の呼び忘れ」を検出します。
エコシステムと拡張機能
<div align="center"> <table> <tr> <td align="center"> <a href="https://github.com/HKUDS/RAG-Anything"> <div style="width: 100px; height: 100px; background: linear-gradient(135deg, rgba(0, 217, 255, 0.1) 0%, rgba(0, 217, 255, 0.05) 100%); border-radius: 15px; border: 1px solid rgba(0, 217, 255, 0.2); display: flex; align-items: center; justify-content: center; margin-bottom: 10px;"> <span style="font-size: 32px;">📸</span> </div> <b>RAG-Anything</b> <sub>マルチモーダル RAG</sub>
</a>
</td>
<td align="center">
<a href="https://github.com/HKUDS/VideoRAG">
<div style="width: 100px; height: 100px; background: linear-gradient(135deg, rgba(0, 217, 255, 0.1) 0%, rgba(0, 217, 255, 0.05) 100%); border-radius: 15px; border: 1px solid rgba(0, 217, 255, 0.2); display: flex; align-items: center; justify-content: center; margin-bottom: 10px;">
<span style="font-size: 32px;">🎥</span>
</div>
<b>VideoRAG</b>
<sub>極めて長いコンテキストの動画 RAG</sub>
</a>
</td>
<td align="center">
<a href="https://github.com/HKUDS/MiniRAG">
<div style="width: 100px; height: 100px; background: linear-gradient(135deg, rgba(0, 217, 255, 0.1) 0%, rgba(0, 217, 255, 0.05) 100%); border-radius: 15px; border: 1px solid rgba(0, 217, 255, 0.2); display: flex; align-items: center; justify-content: center; margin-bottom: 10px;">
<span style="font-size: 32px;">✨</span>
</div>
<b>MiniRAG</b>
<sub>極めてシンプルな RAG</sub>
</a>
</td>
</tr>
プルリクエストを送信する前に、<a href=".github/CONTRIBUTING.md"><strong>貢献ガイド</strong></a>をお読みください。
</div> <div align="center"> 貴重な貢献をいただいたすべてのコントリビューターに感謝します。 </div> <div align="center"> <a href="https://github.com/HKUDS/LightRAG/graphs/contributors"> </a> </div>@article{guo2024lightrag,
title={LightRAG: Simple and Fast Retrieval-Augmented Generation},
author={Zirui Guo and Lianghao Xia and Yanhua Yu and Tu Ao and Chao Huang},
year={2024},
eprint={2410.05779},
archivePrefix={arXiv},
primaryClass={cs.IR}
}
</a>
<a href="https://github.com/HKUDS/LightRAG/issues" style="text-decoration: none;">
</a>
<a href="https://github.com/HKUDS/LightRAG/discussions" style="text-decoration: none;">
</a>