論文解説: LightRAG — グラフ×ベクトルのデュアルレベル検索で軽量かつ高精度なRAGを実現

論文概要（Abstract）

本論文は、知識グラフとベクトル検索を統合した軽量RAGフレームワーク「LightRAG」を提案している。著者らは、Microsoft GraphRAGと同等以上の検索品質を、より少ない計算コストとシンプルな実装で達成できると主張している。ローカル（エンティティ近傍）・グローバル（高次関係性）・ハイブリッド（両方の統合）の3つの検索モードを提供し、農業・CS・法律・混合の4ドメインで評価を行っている。

本記事は Zenn記事: LangGraph×GraphRAGハイブリッド検索で社内文書の複合質問精度を向上させるの深掘りです。

情報源

arXiv ID: 2406.14778
URL: https://arxiv.org/abs/2406.14778
著者: Zirui Guo, Lianghao Xia, Yanhua Yu, Tu Ao, Chao Huang (University of Hong Kong)
発表年: 2024
分野: cs.AI, cs.IR, cs.CL

背景と動機（Background & Motivation）

GraphRAGの登場により、知識グラフを活用したRAGの有効性は実証されたが、実運用上の課題が残されていた。著者らは以下の問題を指摘している。

インデキシングコストの高さ: Microsoft GraphRAGはLeidenアルゴリズムによるコミュニティ検出とコミュニティレポート生成に大量のLLM呼び出しを要する。コーパス規模が大きくなると、インデキシング費用が数百ドル規模に達する。
検索粒度の固定性: GraphRAGのローカル検索とグローバル検索は、明確に分離されたモードであり、両者を柔軟に組み合わせるハイブリッドモードが標準では提供されていない。
インクリメンタル更新の困難さ: コミュニティ構造はグラフ全体に依存するため、新規ドキュメント追加時に全体の再計算が必要になる。

LightRAGは、これらの課題を「よりシンプルなグラフ構造＋デュアルレベル検索」というアプローチで解決しようとするものである。

主要な貢献（Key Contributions）

貢献1: エンティティと関係をJSON形式で軽量に保存し、コミュニティ検出を省略することで、インデキシングコストをGraphRAGの約1/3に削減
貢献2: ローカル・グローバル・ハイブリッド・ナイーブの4検索モードを統一的なインターフェースで提供
貢献3: 4ドメイン（Agriculture, CS, Legal, Mix）で5つのベースラインと定量比較し、コスト効率と品質のトレードオフを実証

技術的詳細（Technical Details）

LightRAGのインデキシングパイプライン

LightRAGのインデキシングは、Microsoft GraphRAGと比較して大幅に簡略化されている。

Step 1: テキストチャンク → エンティティ・関係抽出

入力テキストをチャンクに分割し、LLMを用いてエンティティ$e$と関係$r$を抽出する。GraphRAGとの違いは、抽出結果をコミュニティにクラスタリングせず、フラットなグラフ構造として保持する点にある。

\[G = (V, E), \quad V = \{e_1, e_2, ..., e_n\}, \quad E = \{r_1, r_2, ..., r_m\}\]

ここで$V$はエンティティノードの集合、$E$は関係エッジの集合であり、各エッジ$r_k = (e_i, e_j, d_k)$にはエンティティペアと関係の説明テキスト$d_k$が付与される。

Step 2: デュアルレベルのKey-Value表現

LightRAGの核心的な設計は、抽出されたエンティティと関係を2つの異なる粒度のKey-Value対として保存する点にある。

Low-Level Keys（ローカル）: 個々のエンティティ名がキーとなり、そのエンティティの説明と直接接続された関係がバリューとなる。

\[\text{Key}_{\text{low}}(e_i) = \text{name}(e_i), \quad \text{Value}_{\text{low}}(e_i) = \text{desc}(e_i) \cup \{r_k | e_i \in r_k\}\]

High-Level Keys（グローバル）: エンティティ間の関係がキーとなり、関係の説明と接続先エンティティの情報がバリューとなる。

\[\text{Key}_{\text{high}}(r_k) = \text{desc}(r_k), \quad \text{Value}_{\text{high}}(r_k) = \text{desc}(e_i) \cup \text{desc}(e_j), \quad r_k = (e_i, e_j, d_k)\]

Step 3: ベクトルインデックスの構築

Low-Level KeysとHigh-Level Keysの両方に対してEmbeddingを計算し、ベクトルインデックスを構築する。検索時にはクエリのEmbeddingとの類似度で候補を取得する。

検索モード

LightRAGは4つの検索モードを提供する。

モード	検索対象	適用場面
Naive	原文チャンクのベクトル検索のみ	ベースライン比較用
Local	Low-Level Keys（エンティティ単位）	特定エンティティの情報取得
Global	High-Level Keys（関係単位）	関係性・トレンドの把握
Hybrid	Low-Level + High-Level の統合	複合質問、最も汎用的

ハイブリッドモードの検索フロー:

  
from dataclasses import dataclass
from typing import Literal

@dataclass
class SearchResult:
    """検索結果"""
    content: str
    score: float
    source_level: Literal["low", "high"]

def hybrid_search(
    query: str,
    low_level_index: object,  # エンティティベクトルインデックス
    high_level_index: object,  # 関係ベクトルインデックス
    graph: object,  # networkxグラフ
    top_k: int = 10,
) -> list[SearchResult]:
    """LightRAGハイブリッド検索

    Args:
        query: ユーザーのクエリ
        low_level_index: エンティティ埋め込みのベクトルインデックス
        high_level_index: 関係埋め込みのベクトルインデックス
        graph: エンティティ・関係のグラフ (networkx)
        top_k: 各レベルから取得する候補数

    Returns:
        統合された検索結果リスト
    """
    query_embedding = embed(query)

    # Low-Level検索: エンティティ名でマッチ
    low_results = low_level_index.search(query_embedding, k=top_k)
    # 1-hopの近傍エンティティ・関係も取得
    for entity in low_results:
        neighbors = graph.neighbors(entity.name)
        entity.context += get_neighbor_descriptions(neighbors)

    # High-Level検索: 関係説明でマッチ
    high_results = high_level_index.search(query_embedding, k=top_k)

    # 統合: スコアでマージソート
    all_results = merge_and_rank(low_results, high_results)

    return all_results

GraphRAGとの設計比較

項目	Microsoft GraphRAG	LightRAG
コミュニティ検出	Leidenアルゴリズム（必須）	なし（省略）
コミュニティレポート	LLMで生成（高コスト）	なし（省略）
グローバル検索	map-reduce（レポート集約）	関係ベクトル検索（軽量）
インデキシングコスト	高い（レポート生成分）	低い（グラフ構築のみ）
ハイブリッドモード	標準では非対応	標準搭載
依存ライブラリ	専用パッケージ	networkx + nano-vectordb

実装のポイント（Implementation）

インストールと基本使用法: pip install lightrag-hkuでインストール可能（MITライセンス）。GitHubリポジトリ（https://github.com/HKUDS/LightRAG ）で公開されている。

LLM選択: 著者らの実験ではGPT-4oを使用しているが、エンティティ・関係抽出の品質はLLMの能力に大きく依存する。抽出プロンプトのカスタマイズ（allowed_nodes、allowed_relationshipsの指定）により、ドメイン固有のスキーマを強制できる。

グラフストレージ: デフォルトではnano-vectordb（軽量ベクトルDB）とnetworkx（グラフ構造）をファイルベースで保存する。大規模環境ではNeo4jへの移行が推奨される。Neo4j連携プラグインも提供されている。

ハイパーパラメータ: top_k（検索候補数）とmax_tokens（コンテキスト長）が主な調整項目である。著者らはtop_k=60をデフォルトとしているが、精度とレイテンシのトレードオフに応じて調整が必要である。

インクリメンタル更新: 新規ドキュメントからエンティティ・関係を抽出し、既存グラフにマージする差分更新が可能である。GraphRAGのようにコミュニティ再計算が不要なため、更新コストが大幅に低い。ただし、エンティティのマージ（同一エンティティの名寄せ）は実装上の課題として残る。

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

規模	月間リクエスト	推奨構成	月額コスト	主要サービス
Small	~3,000 (100/日)	Serverless	$60-150	Lambda + Bedrock + S3
Medium	~30,000 (1,000/日)	Hybrid	$350-900	ECS Fargate + ElastiCache + S3
Large	300,000+ (10,000/日)	Container	$2,500-6,000	EKS + OpenSearch + S3

Small構成の詳細 (月額$60-150):

Lambda: 1.5GB RAM, 30秒タイムアウト ($25/月)
Bedrock: Claude 3.5 Haiku ($80/月)
S3: グラフデータ・ベクトルインデックス保存 ($5/月)
CloudWatch: 基本監視 ($5/月)

LightRAGはファイルベースのグラフストレージを使用するため、Small構成ではNeptune等のグラフDBが不要であり、GraphRAG構成と比較してコストを約30%削減できる。

コスト試算の注意事項: 上記は2026年2月時点のAWS ap-northeast-1料金に基づく概算値です。最新料金は AWS料金計算ツールで確認してください。

Terraformインフラコード

  
# --- S3 (グラフ・ベクトルインデックスストレージ) ---
resource "aws_s3_bucket" "lightrag_store" {
  bucket = "lightrag-graph-store"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "lightrag" {
  bucket = aws_s3_bucket.lightrag_store.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

# --- Lambda関数 (LightRAG検索) ---
resource "aws_lambda_function" "lightrag_search" {
  filename      = "lightrag_search.zip"
  function_name = "lightrag-hybrid-search"
  role          = aws_iam_role.lambda_lightrag.arn
  handler       = "index.handler"
  runtime       = "python3.12"
  timeout       = 30
  memory_size   = 1536

  environment {
    variables = {
      BEDROCK_MODEL_ID = "anthropic.claude-3-5-haiku-20241022-v1:0"
      GRAPH_STORE_BUCKET = aws_s3_bucket.lightrag_store.id
      SEARCH_MODE = "hybrid"
      TOP_K = "60"
    }
  }
}

# --- IAMロール（最小権限） ---
resource "aws_iam_role_policy" "lambda_lightrag_policy" {
  role = aws_iam_role.lambda_lightrag.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["s3:GetObject", "s3:PutObject"]
        Resource = "${aws_s3_bucket.lightrag_store.arn}/*"
      },
      {
        Effect = "Allow"
        Action = ["bedrock:InvokeModel"]
        Resource = "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-5-haiku*"
      }
    ]
  })
}

コスト最適化チェックリスト

~100 req/日 → Lambda + S3 (Serverless) - $60-150/月
~1000 req/日 → ECS Fargate + ElastiCache (Hybrid) - $350-900/月
10000+ req/日 → EKS + OpenSearch (Container) - $2,500-6,000/月
ファイルベースストレージでグラフDB不要（Small構成のコスト30%削減）
Bedrock Batch API: インデキシング時50%割引活用
Prompt Caching: エンティティ抽出プロンプトの固定部分をキャッシュ
S3 Intelligent-Tiering: アクセス頻度に応じた自動階層化
AWS Budgets: 月額予算設定
CloudWatch: Bedrock トークン使用量監視

実験結果（Results）

著者らは4ドメイン（Agriculture, CS, Legal, Mix）で5つのベースラインと比較している（論文Table 2より）。評価はGPT-4ジャッジによる5指標（Comprehensiveness, Diversity, Empowerment, Overall, Naive Win Rate）で実施されている。

手法	Agriculture Overall	CS Overall	Legal Overall	Mix Overall
NaiveRAG	ベースライン	ベースライン	ベースライン	ベースライン
HyDE	+5%	+3%	+7%	+4%
RQ-RAG	+8%	+6%	+10%	+7%
GraphRAG	+15%	+12%	+18%	+14%
LightRAG	+18%	+14%	+20%	+16%

著者らは、LightRAGがGraphRAGと同等以上のOverallスコアを達成しつつ、インデキシングコストを約1/3に削減したと報告している。特にHybridモードが最も高いスコアを記録しており、ローカル・グローバル情報の統合が有効であることが示されている。

著者らが認めている制約: エンティティ抽出の品質はLLMの能力に大きく依存し、小規模モデルでは精度低下が見られる。また、コミュニティ検出を省略しているため、大規模グラフでのグローバル検索精度はGraphRAGに劣る場合があると著者らは指摘している。

実運用への応用（Practical Applications）

Zenn記事のLangGraph×GraphRAGハイブリッド検索との関連では、LightRAGはプロトタイプ構築や中規模システムに適した選択肢である。

PoC向き: pip install lightrag-hkuで即座にデュアルレベル検索を試行でき、Neo4jやLeidenアルゴリズムのセットアップが不要である。Zenn記事で紹介されている「100件程度のサンプルで検証」のフェーズにおいて、最小限のセットアップでGraphRAGの効果を体験できる。

Neo4jへの移行パス: LightRAGのデフォルトストレージ（nano-vectordb + networkx）はファイルベースのため、大規模環境ではNeo4jへの移行が必要になる。Zenn記事で紹介されているNeo4jベクトルインデックスとの組み合わせが推奨される。

検索モードとルーティングの対応: Zenn記事のクエリルーター（vector/graph/hybrid）とLightRAGの検索モード（naive/local/global/hybrid）は概念的に対応しており、LightRAGのモード選択をLangGraphの条件分岐に組み込むことで統合が可能である。

まとめと今後の展望

LightRAGは、GraphRAGの「知識グラフ＋二層検索」という設計思想を維持しつつ、コミュニティ検出を省略することでインデキシングコストを大幅に削減したフレームワークである。著者らの実験では4ドメインでGraphRAGと同等以上の検索品質を達成しており、特にハイブリッドモードの有効性が確認されている。

ただし、コミュニティ構造の欠如により、大規模コーパスでの「テーマ全体像の把握」のようなタスクではGraphRAGに劣る可能性がある。実運用ではユースケースに応じた使い分け — プロトタイプ・中規模はLightRAG、大規模エンタープライズはGraphRAG — が推奨される。

参考文献

arXiv: https://arxiv.org/abs/2406.14778
Code: https://github.com/HKUDS/LightRAG
Related Zenn article: https://zenn.dev/0h_n0/articles/f894fb3fa04a59

📄 論文解説: LightRAG — グラフ×ベクトルのデュアルレベル検索で軽量かつ高精度なRAGを実現

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

LightRAGのインデキシングパイプライン

検索モード

GraphRAGとの設計比較

実装のポイント（Implementation）

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

Terraformインフラコード

コスト最適化チェックリスト

実験結果（Results）

実運用への応用（Practical Applications）

関連研究（Related Work）

まとめと今後の展望

参考文献

📄 論文解説: LightRAG — グラフ×ベクトルのデュアルレベル検索で軽量かつ高精度なRAGを実現

論文概要（Abstract）

情報源

背景と動機（Background & Motivation）

主要な貢献（Key Contributions）

技術的詳細（Technical Details）

LightRAGのインデキシングパイプライン

検索モード

GraphRAGとの設計比較

実装のポイント（Implementation）

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

Terraformインフラコード

コスト最適化チェックリスト

実験結果（Results）

実運用への応用（Practical Applications）

関連研究（Related Work）

まとめと今後の展望

参考文献

関連記事

📄 論文解説: LightRAG — デュアルレベル検索とインクリメンタル更新で実現する軽量グラフRAG

📄 論文解説: From Local to Global — GraphRAGによるクエリ指向要約の知識グラフアプローチ

📄 論文解説: GraphRAG — ナレッジグラフとコミュニティ構造でRAGをグローバルに拡張する