Zenn
Open11

LightRAGをGeminiAPIで動かす

LLM
RAG
lightrag
みとみと

RAGについて調べているところに、良さそうなツイート。
触ってみなければ！

いつも有益な情報ありがとうございます。

みとみと

なんJプロンプト (Claude 3.5 Sonnet)

1 ：AI研究者@量子コンピュータ：2024/12/13 20:15：ID:abc123
LightRAGとかいう新しい検索システムについて語ろうや
従来のRAGシステムの問題点を解決した神システムらしいで

2 ：機械学習エンジニア：2024/12/13 20:17：ID:def456
＞＞1
ワイも論文読んだで！主な特徴は以下の3つや：

  1. グラフベースのインデックス作成で文書間の関係性を保持
  2. 低レベル・高レベルの2段階検索
  3. 増分更新対応で新しいデータにも強い

従来のRAGは文書をバラバラに保存してて関係性が失われてたんや

3 ：情報検索の研究者：2024/12/13 20:19：ID:ghi789
＞＞2
その通りや！特に従来システムの2つの問題点を解決してるんや：

  1. フラットなデータ表現による関係性の欠如
  2. コンテキスト認識の不足

例えば「電気自動車が都市の大気質と公共交通インフラにどう影響するか？」みたいな質問に対して、従来システムは断片的な回答しかできへんかったんや

4 ：自然言語処理の初心者：2024/12/13 20:21：ID:jkl012
＞＞3
ちょっと待って！その例がよく分からんのやけど、なんで従来システムやと断片的になるん？

5 ：情報検索の研究者：2024/12/13 20:23：ID:ghi789
＞＞4
ええ質問や！従来システムやと、「電気自動車」「大気汚染」「公共交通の課題」について別々に情報を取得するだけなんや。でもLightRAGやと、グラフ構造のおかげでこれらの要素の関連性も含めて包括的な回答ができるんや！
例えば、電気自動車の普及→大気質の改善→公共交通への影響、みたいな因果関係も理解できるわけや

6 ：データサイエンティスト：2024/12/13 20:25：ID:mno345
実験結果もめっちゃ良かったで！従来手法と比べて検索精度も応答時間も改善されとる。特にLegalデータセットでの性能向上が顕著やった。
ちなみに実装もシンプルで、既存のベクトルDBとLLMを使うだけや。これは実用化も期待できるで！

みとみと

Google Gemini API で動かしたかったので、forkしてコード追加してみた。

みとみと

example/lightrag_gemini_demoy.py を動かす。

git clone git@github.com:mito99/LightRAG.git
cd LightRAG

uv venv
source .venv/bin/activate
uv pip install -e .
uv pip install -r ./requirements.txt

echo  "GOOGLE_API_KEY=<APIKEY>" > .env

python examples/lightrag_gemini_demoy.py
みとみと

登録時にGeminiAPIが並列的に呼び出されるので、
APIリソース制限で落ちる場合は、同時実行数を調整すると良い。

lightlag/llm_geminy.py
# グローバルなレートリミッターインスタンスを作成
rate_limiter = GeminiRateLimiter(max_concurrent_calls=5)  # 同時実行数を5に制限
みとみと

lightrag_gemini_demoy.py の実行結果

検索クエリ:
桃太郎の仲間教えて

データ:
https://ja.wikipedia.org/wiki/桃太郎

naive 検索

INFO:lightrag:Truncate 13 to 3 chunks

桃太郎の仲間は、犬、猿、雉です。
物語によって多少の違いはありますが、一般的にこの三匹が桃太郎と共に鬼ヶ島へ赴き、
鬼退治を手伝います。

naive searchの実行時間: 1.1438秒

local 検索

INFO:lightrag:kw_prompt result:
{  "high_level_keywords": ["桃太郎", "仲間", "登場人物"],
    "low_level_keywords": ["犬", "猿", "雉", "鬼"]}
INFO:lightrag:Local query uses 60 entites, 37 relations, 3 text units

桃太郎の物語における仲間は、犬、猿、雉の三体です。
これらの動物は、桃太郎が鬼ヶ島へ向かう際に仲間として加わり、鬼退治に協力します。
物語のバージョンによって、これらの動物の役割や性格描写は多少異なる場合がありますが、
基本的には桃太郎を助ける重要な役割を担っています。
例えば、犬は忠実さと力強さを、猿は知恵と機敏さを、
雉は情報収集能力や迅速な行動力を象徴していると言えるでしょう。

local searchの実行時間: 15.3892秒

global 検索

INFO:lightrag:kw_prompt result:
{  "high_level_keywords": ["桃太郎", "仲間", "登場人物"],
    "low_level_keywords": ["犬", "猿", "雉", "鬼"]}
INFO:lightrag:Global query uses 91 entites, 60 relations, 3 text units

桃太郎の物語には、桃太郎と行動を共にする仲間が登場します。
これらの仲間は、物語のバージョンによって異なりますが、最も一般的なバージョンでは、
犬、猿、雉の3匹が桃太郎に仕えています。
これらの動物たちは、桃太郎が鬼ヶ島へ向かう冒険の途中で加わり、
それぞれ独自の能力で桃太郎を助けます。

しかし、すべての桃太郎の物語でこれらの動物が登場するわけではありません。
いくつかのバージョンでは、異なる動物や、人間仲間が登場する場合もあります。
例えば、いくつかの地域や解釈では、桃太郎の仲間として、
他の動物や人物が挙げられる場合があります。
また、現代の桃太郎をテーマにした作品では、より現代的な解釈で仲間が登場することもあります。
したがって、桃太郎の仲間は、物語のバージョンによって多様性があると言えるでしょう。

global searchの実行時間: 3.5648秒

hybrid 検索

INFO:lightrag:kw_prompt result:
{  "high_level_keywords": ["桃太郎", "仲間", "登場人物"],
    "low_level_keywords": ["犬", "猿", "雉", "鬼"]}
INFO:lightrag:Local query uses 60 entites, 37 relations, 3 text units
INFO:lightrag:Global query uses 91 entites, 60 relations, 3 text units

桃太郎の仲間は、犬、猿、雉の3匹です。
これらの動物は、桃太郎が鬼ヶ島へ向かう際に仲間となり、鬼退治を手伝います。
ただし、これは「標準型」と呼ばれる、明治時代以降教科書や絵本を通じて広く普及した桃太郎物語に
おける構成です。
民間の語り伝えや、異なるバリエーションの桃太郎物語では、
仲間の構成や役割が異なる場合があります。
例えば、一部の地域では、桃太郎が仲間を募集する描写がなく、最初から犬、猿、雉と
共に冒険を始める話もあります。
また、仲間の動物の種類や数も、物語によって異なっている可能性があります。

hybrid searchの実行時間: 3.4157秒

local検索より、global と hybrid 検索が早いのはキャッシュのせいかな。

みとみと

検索モードについて1 (naive検索)

ベクトル検索を用いて意味的に関連性の高いテキストチャンクを検索し、それらをコンテキストとしてLLMに渡すことで回答を生成する、シンプルなRAG検索と言えます。キーワードに依存せず、ローカルな範囲での検索に特化している点が特徴です。

どのような場合に適しているか:

  • 特定のドキュメントやデータセット内での情報検索
  • キーワードが不明確な場合や、意味的な関連性を重視したい場合
  • 高度なコンテキスト処理や推論が不要な場合
  • シンプルなRAGの実装を試したい場合

どのような場合に不向きか:

  • グローバルな知識や関係性を考慮した検索が必要な場合
  • 複雑なクエリや推論が必要な場合
    検索結果の精度や多様性が求められる場合
みとみと

検索モードについて2 (local検索)

知識グラフを活用してエンティティとその関係性を考慮した検索を行い、関連性の高いテキストチャンクをコンテキストとしてLLMに渡すことで回答を生成する、より高度なRAG検索と言えます。ベクトル検索とグラフ探索を組み合わせることで、naive検索 よりも複雑な質問に対応できます。

どのような場合に適しているか:

  • 特定のドキュメントやデータセット内で、エンティティとその関係性を考慮した情報検索が必要な場合
  • クエリに直接含まれていない情報でも、関連性の高い情報を取得したい場合
  • コンテキストを絞り込み、より正確な回答を生成したい場合
  • naive検索 では対応できない、より複雑な質問に対応したい場合

どのような場合に不向きか:

  • グローバルな知識や関係性を考慮した検索が必要な場合
  • 知識グラフに存在しないエンティティや関係性に関する質問
  • 知識グラフの構築が不十分な場合
みとみと

検索モードについて3 (global検索)

知識グラフにおける関係性（エッジ）を重視した検索を行い、関連性の高いエンティティやテキストチャンクをコンテキストとしてLLMに渡すことで回答を生成する、より高度なRAG検索と言えます。ベクトル検索とグラフ探索を組み合わせることで、local検索 よりも広い範囲での関連性を考慮した検索が可能です。

どのような場合に適しているか:

  • 特定のドキュメントやデータセット内で、エンティティ間の関係性を重視した情報検索が必要な場合
  • クエリに直接含まれていない情報でも、関係性の強い情報を取得したい場合
  • よりグローバルな視点での検索を行いたい場合
  • local検索では対応できない、より広い範囲での関連性を考慮した質問に対応したい場合

どのような場合に不向きか:

  • 特定のエンティティに関する詳細な情報を知りたい場合
  • 知識グラフにおける関係性が不十分な場合
  • 関係性よりもエンティティ自体が重要な場合
みとみと

検索モードについて4 (hybrid検索)

知識グラフを活用してエンティティと関係性の両方を考慮した検索を行い、関連性の高い情報を統合してコンテキストとしてLLMに渡すことで回答を生成する、最も高度なRAG検索と言えます。ベクトル検索とグラフ探索を組み合わせることで、local検索 や global検索よりも複雑な質問に対応できます。

どのような場合に適しているか:

  • 特定のドキュメントやデータセット内で、エンティティと関係性の両方を考慮した情報検索が必要な場合
  • クエリに直接含まれていない情報でも、エンティティと関係性の両方の観点から、より関連性の高い情報を取得したい場合
  • より柔軟な検索を行いたい場合
  • local検索や global検索では対応できない、より複雑な質問に対応したい場合
  • 可能な限り最高の検索精度を求めたい場合

どのような場合に不向きか:

  • 特定のエンティティに焦点を当てた検索が必要な場合（local モードの方が適している場合がある）
  • 特定の関係性に焦点を当てた検索が必要な場合（global モードの方が適している場合がある）
  • 知識グラフの構築が不十分な場合
  • 計算コストを抑えたい場合（hybrid モードは最も計算コストが高い）