究極のGraphRAG環境を構築:LightRAGとMemgraphによる次世代情報検索基盤

リード

AIエージェントやLLM(大規模言語モデル)の進化に伴い、外部知識を効率的かつ正確に検索・活用するRAG(Retrieval-Augmented Generation)技術の重要性がますます高まっています。しかし、従来のベクトル類似度のみに依存したRAGでは、「文脈の断絶」や「関係性の見落とし」といった課題が浮き彫りになりつつあります。そこで現在、最も熱い視線を集めているのが、知識グラフ(Knowledge Graph)とベクトル検索を融合させた「GraphRAG」です。

本記事では、香港大学(HKU)の研究チームらが開発した高速かつエンティティベースの検索基盤「LightRAG」と、インメモリで高速動作しページランク等のアルゴリズムを内蔵するグラフデータベース「Memgraph」を組み合わせた、究極のセルフホスト型GraphRAG環境の構築方法を解説します。4つのレイヤーすべてをデータベース化(DB化)することで、堅牢性とスケーラビリティを確保し、継続的な情報収集から高度な知識抽出までを自動化する次世代の検索基盤の全貌に迫ります。

背景:なぜ今、GraphRAGなのか?そして「完全DB化」の必要性

従来のRAGシステムは、ドキュメントを一定のサイズ(チャンク)に分割し、それぞれをベクトル化してVectorDBに保存する手法が主流でした。しかし、この手法には致命的な欠点があります。例えば「A社はB社を買収した」「B社のCEOはC氏である」という別々のドキュメントがあった場合、ユーザーが「A社の買収に関連する重要人物は?」と質問しても、単なるベクトル類似度検索では「C氏」という回答を導き出すことが困難です。

GraphRAGは、ドキュメントから「エンティティ(人物、組織、場所など)」と「リレーションシップ(関係性)」を抽出し、知識グラフとして構造化します。これにより、情報のつながりや階層構造をLLMが把握できるようになり、複雑な推論や全体像の要約(Global Search)が劇的に精度向上します。

LightRAGは、このGraphRAGのアプローチを極めて軽量かつ高速に実現するソリューションです。しかし、LightRAGの初期の運用形態や手軽なチュートリアルでは、グラフやベクトルデータをファイルベース(例:nano-vectordbやJSONファイル)でローカルに保存することが多く、データ量の増加に伴うパフォーマンス低下や、コンテナ再起動時のファイル破損リスクが課題となっていました。

そこで我々は、LightRAGが扱う4つの主要なデータストレージレイヤー(Graph、Vector、KV、DocStatus)をすべて専用の外部データベースに委譲する「完全DB化」アーキテクチャを採用しました。これにより、エンタープライズ規模のデータ投入にも耐えうる堅牢なローカルGraphRAGスタックが実現します。

詳細セクション1:LightRAG + Memgraph 環境構築の手順

この究極のGraphRAGスタックは、Proxmox上のDocker Compose環境で稼働し、5つのコンテナで構成されます。LLMおよびEmbeddingの推論APIは、ローカルネットワーク内のLiteLLM Proxy(http://localhost:4000/v1)経由で供給し、完全にクローズドかつ無料(cost_tier: local)で運用できる設計です。

1. アーキテクチャとコンテナ構成

lightrag-netという専用Dockerネットワーク上で、以下の5つのサービスが連携します。

  1. memgraph (memgraph/memgraph-mage:latest):

グラフDBの中核。GraphRAGの要となるエンティティ関係の保存と、PageRankやCommunity Detectionといった組み込みアルゴリズムの実行を担当します。

  1. memgraph-lab (memgraph/lab:latest):

構築された知識グラフを視覚的に確認・分析するためのWeb UIツール。

  1. lightrag (ghcr.io/hkuds/lightrag:latest):

GraphRAGのオーケストレーションとAPI/WebUIを提供するサーバー。Gunicorn+Uvicornモードで並列処理を行い、クエリのブロックを防ぎます。

  1. lightrag-pg (pgvector/pgvector:pg16):

PostgreSQL。ドキュメントの生テキストやメタデータを保存するKV(Key-Value)ストレージと、インデックスの処理状態を管理するDocStatusストレージを担います。

  1. qdrant (qdrant/qdrant:latest):

高速なベクトルDB。エンティティやチャンクのベクトル表現(Embedding)を保存し、類似度検索を担当します。

2. ストレージバックエンドの完全DB化設定

LightRAG側の設定(環境変数や初期化スクリプト)で、ストレージクラスを明示的に指定します。

  • Graph: MemgraphStorage を使用し、bolt://memgraph:7687 へ接続。
  • Vector: QdrantVectorDBStorage を使用し、http://qdrant:6333 へ接続。
  • KV & DocStatus: ともに PGKVStorage / PGDocStatusStorage を使用し、lightrag-pg:5432 へ接続。

すべてのデータは ./data/ 配下にバインドマウントされ、永続化されます。専用SSD(例: /mnt/litemem/data/)を割り当てることで、I/Oボトルネックを解消できます。

3. LLM / Embedding の接続設定

ローカル推論を活用するため、OpenAI互換のAPIエンドポイントを提供するLiteLLM Proxyを指定します。

  • LLMモデル: lightrag-local(タイムアウト設定 LLM_TIMEOUT=3600 モデルの切り替えをlitellmだけで行えるようAliasにしています)
  • Embeddingモデル: lmstudio-text-embedding-nomic-embed-text-v1.5(次元数 `EMBEDDING_DIM=768`)

4. 起動と依存関係の制御

起動順序は非常に重要です。LightRAGサーバーが起動する前に、3つのデータベースが完全にリクエストを受け付けられる状態である必要があります。Docker Composeの depends_onservice_healthy を駆使し、PostgreSQL(pg_isready)、Qdrant(/dev/tcp)、Memgraph(socket接続)のヘルスチェックを通過した後にLightRAGを起動するよう制御します。

docker compose up -d
# MemgraphのTTL(Time To Live)設定の初期化
docker compose exec memgraph mgconsole < memgraph/ttl-init.cypher

詳細セクション2:LightRAGの活用方法とMCP連携

構築したLightRAG環境は、それ単体で人間がWebUIから検索するだけでなく、AIエージェントが自律的に知識を引き出すための「外部脳」として機能します。ここで威力を発揮するのが、Model Context Protocol(MCP)を用いたツール連携です。

AIエージェント(例:ClaudeやGeminiベースの自律エージェント)は、直接DBを叩くのではなく、MCPサーバーを介してLightRAGの知識にアクセスします。

MCPを利用したLightRAGからのデータ取得例

私たちの環境では、my-mcp-proxyというMCPサーバー内に、lightrag_querylightrag_list_labelsといったツールが定義されています。

例えば、エージェントが「最近のAIトレンドについて、全体的な要約と関連する主要企業を教えて」というタスクを実行する場合、以下のようにMCPツールを呼び出します。

手法1:自然言語による検索(lightrag_query)

最も基本的な方法は、自然言語のクエリを投げる手法です。

{
  "tool": "mcp__my-mcp-proxy__lightrag_query",
  "arguments": {
    "query": "最近のAIトレンドと関連する主要企業",
    "mode": "global",
  "top_k": 5
  }
}
  • mode: global(グラフ全体のコミュニティ要約を活用した広範な回答生成)、local(特定のエンティティや関係性に焦点を当てた詳細な回答)、hybrid(ベクトルとグラフのハイブリッド)を使い分けます。

手法2:ラベルを活用した精度の高い知識抽出(lightrag_list_labels)

グラフ上の特定のカテゴリやタグを起点に検索を行う場合、登録済みのラベルを活用するのが有効です。まず lightrag_list_labels ツールを呼び出して知識グラフ内に存在するラベル(例:"OpenAI", "LLM" 等)の全体像を把握します。そこから得た正確なラベルをキーワードとして lightrag_query へ問い合わせることで、ハルシネーションの少ない確実な情報を引き出すことができます。

OpenAPIを通じた直接アクセスと検証

開発時やデバッグ時には、MCPを介さずに直接APIエンドポイントを確認することも可能です。ブラウザから http://localhost:9621 にアクセスすれば、LightRAG ServerのOpenAPIドキュメント(Swagger UI等)が表示され、提供されているすべてのエンドポイント(/query, /query/data 等)を手軽にテスト・検証できます。

エージェントはこれらの結果を受け取り、GraphRAGによって構造化・集約された高品質な情報を元に、ブログ記事の執筆やレポート作成を自律的に進行します。MCPを介することで、LightRAGはあらゆるLLMアプリケーションに組み込み可能なプラットフォームへと昇華します。

詳細セクション3:継続的なデータ投入(Ingestion)アーキテクチャ

知識グラフは、鮮度の高い情報を絶えず供給し続けることでその価値を最大化します。本環境では、自動化されたバッチ処理によって、24時間365日、様々なソースからデータがLightRAGに流れ込み、グラフが成長し続けるアーキテクチャを構築しています。

具体的には、以下の4つのデータ投入パイプラインが稼働しています。

  1. 1時間に1度のニュースRSS自動取得

国内の主要なテクノロジーメディアやニュースサイトのRSSフィードを1時間おきに巡回します。新着記事のテキストを抽出し、LightRAGに投入(Insert)します。これにより、最新の国内トレンドがいち早く知識グラフに反映されます。

  1. 1時間に1度の専用ディレクトリファイルアップロード

社内文書や、ユーザーが手動で収集したPDF、Markdown、テキストファイルなどを保存する特定のウォッチ・ディレクトリを用意します。1時間に1度、このディレクトリ内の新規ファイルがスキャンされ、自動的にLightRAGへ取り込まれます。

  1. 8時間に1度の海外ニュースRSS取得

グローバルな視点を維持するため、TechCrunchやThe Vergeなどの海外有力メディアのRSSを8時間ごとに取得します。英語の情報も同様にエンティティ化され、国内ニュースのエンティティとグラフ上で結びつくことで、多角的な分析が可能になります。

  1. 20分に1度のローカルGoToSocialからのPost取得

Fediverse(分散型SNS)の一角であるローカルのGoToSocialインスタンスと連携します。20分という高頻度で、指定したアカウントやタイムラインの投稿(Post)を取得・アップロードします。これにより、ニュースサイトには現れないリアルタイムな有識者の考察や生のリアクションが知識グラフに織り込まれます。

運用上の工夫:TTLと孤立ノードの管理

これほど大量のデータが継続的に投入されると、グラフが肥大化しノードのノイズが増加します。そのため、同梱の運用スクリプト(memgraph_ttl_manager.py)により、データの種類(ニュース、SNS投稿など)に応じてTTL(有効期限)を設定し、古い情報を自動的に忘却する仕組みを導入しています。また、不要になった「孤立ノード」を回収するリサイクラーも定期実行し、常に最適化されたクリーンな知識グラフを維持しています。

※memgraphの有料版では、memgraphの機能としてttlが利用可能です。
無料版を使用しているため、スクリプトでttlを実現する運用にしています。

影響・今後

LightRAGとMemgraphを組み合わせた「完全DB化」スタックの構築は、個人のリサーチ基盤や企業の社内ナレッジベースに革命的な影響をもたらします。ファイルベースの不安定さから解放され、Dockerコンテナによる可用性と、専用DBの恩恵を受けた高速なクエリ処理が実現しました。

今後は、LightRAG自体のバージョンアップ(1.4から1.5への移行など)によるマルチバックエンドのバックアップ戦略の強化や、Memgraphの最新バージョンへのシームレスなアップグレード手法の確立が課題となります。また、エッジAIやより強力なローカルLLM(例:DeepSeek-V3やQwenなど)の登場により、外部APIに一切依存せず、推論から知識構築までを完全にローカルで完結させる「究極のプライベートAI」の実現がさらに加速するでしょう。

まとめ

本記事では、LightRAGを中心とし、Memgraph(グラフ)、Qdrant(ベクトル)、PostgreSQL(KV/DocStatus)をバックエンドに据えた強力なGraphRAG環境の構築方法について解説しました。単なるストレージのDB化にとどまらず、MCPを経由したAIエージェントからのシームレスなアクセス、そしてRSSやSNSからの多角的な継続的データ投入(Ingestion)パイプラインを組み合わせることで、生きた知識が成長し続けるシステムが完成します。

情報の洪水の中で「点」と「点」をつなぎ合わせ、「線」や「面」としてのインサイトを導き出すGraphRAG。その究極の形態を、ぜひ皆さんの環境でも構築してみてください。


参考ソース

  • llm-wiki: tools/lightrag-memgraph.md (LightRAG + Memgraph GraphRAGスタックの構成)
  • llm-wiki: decisions/adr-042-lightrag-storage-db-migration.md (LightRAG ストレージのDB化)

関連記事