Upgrade to Pro — share decks privately, control downloads, hide ads and more …

話題のGraphRAG、その可能性と課題を理解する

 話題のGraphRAG、その可能性と課題を理解する

10/31のFindy社様主催のイベント「進化するRAGの世界 - GraphRAGと評価指標の最新動向」の登壇資料です。
https://findy.connpass.com/event/331660/

本資料の著作権は株式会社アルファシステムズに帰属します
https://www.alpha.co.jp/

鏡味秀行

October 30, 2024
Tweet

More Decks by 鏡味秀行

Other Decks in Technology

Transcript

  1. 自己紹介 2 • 鏡味 秀行 (かがみ ひでゆき) • 株式会社アルファシステムズ 経営企画本部

    AI推進室 室長 • 組織ミッション: AIソリューションによる顧 客の価値向上、社内のAIの普及 • 10/27 JJUG CCC 2024 Fallで登壇 “LangChain4jを使った生成AIシステム設 計パターン - Javaで構築する最新アーキテ クチャ”
  2. 応用 応用 GraphRAG Journey (GraphRAGの理解への道) 4 GraphRAG ナレッジグラフ グラフデータベース 実装

    Naive RAG RAG 実装 RAG RAG Advanced RAG e.g. Neo4j+LangChain 発展 e.g. Neo4j+LangChain e.g. Neo4j+LangChain 概念 焦点 流れ 注:本セッション内のみ整理の名称および概念あり MS GraphRAG 実装+応用 どうなる?
  3. ナレッジグラフ(Knowledge Graph:KG) 6 • エンティティ(ノード)とリレーション(エッジ)の集合で意味を示すもの。 「日本の首都は東京です」 「日本の首都は東京です。関東圏に位置し人口は約1400万人です。」 首都 東京 日本

    首都 1400万 人口 関東 地方 ま た は 地方:関東 人口:1400万 プロパティ 東京 エンティティ エンティティ リレーション 日本 東京 日本 首都 • グラフにプロパティを付与することもある(プロパティグラフ) • 特に主語・述語・目的語の関係性を持つものは「トリプル(Triplet)」と呼ばれる
  4. グラフデータベース(Graph Database:GraphGB) データをナレッジグラフの構造として扱い、問い合わせにより付加価値を持つ情報を取り出す GraphDB データ クエリ レスポンス 変換 グラフデータ 人/コード

    格納 結果(パス探索結果/ネットワーク分析結果/ 関係性/クラスタリング/部分グラフ/etc…) 構造/非構造 エンティティ/リレーション抽出 グラフ用クエリ言語や グラフ操作API 8
  5. グラフデータベース(Graph Database:GraphGB) 9 MATCH (country:Node {name: '日本'})-[:首都]->(city:Node)-[:地方]->(region:Node) RETURN city.name AS

    首都, region.name AS 地方 グラフを探索するクエリ言語: Cypher(openCyper), PGQL, SQL/PGQ • グラフ構造をパターンマッチングして情報を抽出できる • 例)日本の首都である都市のパターンマッチング ⇒ `東京`, `関東` 東京 日本 首都 1400万 人口 関東 地方 大阪 近畿 地方
  6. GraphRAG: 従来のRAGの応用、という見方 11 GraphRAGは、RAGにナレッジグラフ技術を適用したもの • インデックス作成時: ドキュメントからエンティティ/リレーションを抽出して保存 テキストチャンク /埋め込み GraphRAG

    • 情報取得時: クエリに関係するエンティティ/リレーションを取り出し、要約して回答 データ NaiveRAG データ エンティティ/リレーション テキストチャンク GraphRAG クエリ NaiveRAG クエリ LLM 要約 LLM 要約
  7. GraphRAG: Graph DatabaseをLLMで拡張、という見方 • クエリとレスポンスにLLMが介在する • グラフデータ格納(インデクシング)でLLMが介在する GraphDB データ クエリ

    レスポンス 変換 グラフデータ 格納 質問 回答 LLMにより様々な形式を解釈 LLMによるエンティティ/ リレーションの抽出 自然言語をグラフ用 クエリ言語に LLM 注:LLM適用がすべての箇所で必須ではないです LLM LLM 非構造のケース多め 13
  8. GraphRAG:LLMによるエンティティ/リレーションの抽出 14 プロンプトにエンティティとリレーションを抽出する指示を詳細に記述 -目標- この活動に関連する可能性のあるテキスト文書とエンティティタイプのリストが与えられた場合、テキストか らそれらのタイプのすべてのエンティティと、特定されたエンティティ間のすべての関係を特定する。 -手順- 1. すべてのエンティティを特定する。特定された各エンティティごとに、以下の情報を抽出する: -

    entity_name: 大文字で表記されたエンティティの名前 - entity_type: 次のいずれかのタイプ:[historical_figure, event, battle, political_maneuver, dynasty, title, region, policy, cultural_development, alliance] - entity_description: エンティティの属性と活動の包括的な説明 各エンティティを("entity"|<entity_name>|<entity_type>|<entity_description>)の形式で表記する 例: MicrosoftのGraphRAG ‘graphrag/prompt_tune/templateentity_extraction.py’ より デフォルトプロンプトを「歴史上の人物用」にチューニングしたもの (このあとにリレーションの抽出やFew-Shotのサンプルが続く)
  9. MS GraphRAGの特徴①:ベクトル検索を併用: インデクシング 17 • テキストチャンク化と埋め込みの機能を持つ • ドキュメントとテキストチャンクと埋め込みも グラフとして持つ •

    エンティティやリレーションに説明文と埋め込み を付与してベクターDBに保存 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 突然の「本能寺の変」で、 本能寺に滞在していた信 長は自害に追い込まれる。 この事件の背景には、信 長の苛烈な性格や光 Graph Databaseの 観点から秀への遠征命 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 突然の「本能寺の変」で、 本能寺に滞在していた信 長は自害に追い込まれる。 この事件の背景には、信 長の苛烈な性格や光 戦国時代から安土桃山時代に かけての武将、大名。通説で は美濃国の明智氏の支流の人 物で、俗に美濃の明智荘の明 智城の出身と言われているが、 他の説もある。このため前歴 不明。越前国の一乗谷に本拠 を持つ朝倉義景を頼り、長崎 称念寺の門前に十年ほど暮ら し、このころに医学の知識を 身に付ける。その後、足利義 昭に仕え、さらに織田信長に 17 (図の出典:https://graphr.ag/ ) ↑おススメ!のまとめサイト
  10. 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ

    の革新的な政策と過酷な 統治で反感を買っていた。 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 突然の「本能寺の変」で、 本能寺に滞在していた信 長は自害に追い込まれる。 この事件の背景には、信 長の苛烈な性格や光 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 突然の「本能寺の変」で、 本能寺に滞在していた信 長は自害に追い込まれる。 この事件の背景には、信 長の苛烈な性格や光 Graph Databaseの 観点から秀への遠征命 戦国時代から安土桃山時代に かけての武将、大名。通説で は美濃国の明智氏の支流の人 物で、俗に美濃の明智荘の明 智城の出身と言われているが、 他の説もある。このため前歴 不明。越前国の一乗谷に本拠 を持つ朝倉義景を頼り、長崎 称念寺の門前に十年ほど暮ら し、このころに医学の知識を 身に付ける。その後、足利義 昭に仕え、さらに織田信長に MS GraphRAGの特徴①:ベクトル検索を併用: クエリ処理 18 • ローカルサーチというタイプの検索 • グラフクエリを使わずベクターDBを使い質問にマッチするエン ティティを抽出 • グラフを使い近隣の関連情報を辿って情報抽出 • 関連情報:ノード/エンティティ/ コミュニティ(後述)/主張など • LLMが要約して回答
  11. MS GraphRAGの特徴①:ベクトル検索を併用: クエリ処理 20 # graphrag/query/context_builder/entity_extraction.py def map_query_to_entities( # クエリからエンティティの抽出

    # クエリから意味的に近い「エンティティの説明」を、ベクトル類似性で抽出 search_results = text_embedding_vectorstore.similarity_search_by_text( text=query, text_embedder=lambda t: text_embedder.embed(t), ) # search_results には、entityのキーが入っている • ローカル検索処理でクエリからエンティティ抽出
  12. MS GraphRAGの特徴②:コミュニティ 21 • 階層 Leiden クラスタリング (Hierarchical Leiden Clustering)

    アルゴリズムを使い、エ ンティティが多くのリレーションを持つ/持たない状況を見て、グルーピングする。 • グルーピングされたまとまりをコミュニティという。 • コミュニティを見渡せば、全体の概要が把握できる。 クラスタリングで作られたコミュニティ(四角の枠)
  13. 1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 突然の「本能寺の変」で、 本能寺に滞在していた信 長は自害に追い込まれる。 この事件の背景には、信

    長の苛烈な性格や この事件の背景には、信 長の苛烈な性格や光秀へ の遠征命令が影響してい たと考えられる。信長の 死後、豊臣秀吉が素早く 光秀を討ち、信長の遺領 を引き継ぐことで、彼の 後を継いで天下統一を進 めることになる。本能寺 の変は日本史の流れを大 きく変えた。 戦国時代から安土桃山時代に かけての武将、大名。通説で は美濃国の明智氏の支流の人 物で、俗に美濃の明智荘の明 智城の出身と言われているが、 他の説もある。このため前歴 不明。越前国の一乗谷に本拠 を持つ朝倉義景を頼り、長崎 称念寺の門前に十年ほど暮ら し、このころに医学の知識を 身に付ける。その後、足利義 昭に仕え、さらに織田信長に 仕えるようになった。 22 • コミュニティ作成時、説明する文章(コ ミュニティ・レポート)をLLMに作らせ る。 • 全体的かつ主要情報は、コミュニティ・ レポートに集約し、グラフ全体の概略を 回答できる • グローバルサーチにより質問と関連のあ るコミュニティ・レポートを抽出し要約 して回答 (図の出典:https://graphr.ag/ ) MS GraphRAGの特徴②:コミュニティ:インデクシング・クエリ処理
  14. GraphRAG/MS GraphRAGの実用性・ユースケース 24 関係性の発見、体系的な理解の補助を行う業務 • グラフ構造を活かした探索 (GraphRAG/MS GraphRAG) • 文書同士の参照関係を持つもの

    • 関連情報の水平展開やドリルダウン探索を行いながら調査する作業 • グローバル探索とローカル探索を活かした探索 (MS GraphRAG) • 例えば、初学者の専門分野理解のサポート。 • 全体把握と部分把握を往復して理解する作業 ユースケースは、従来の GraphDB の活用事例にヒントあり • Neo4j社の事例集など • White Paper:Optimized Graph Algorithms in Neo4j
  15. GraphRAGの課題と克服 25 GraphRAGの課題 ≒ GraphDBの課題 ≒ RDBと比べてどうか? 課題1:エコシステムや教育の普及が進んでいない → SQL/PGQやGQLなどグラフクエリの国際標準化が進んできている

    • OracleやPostgreSQLなどへの実装が進展しエコシステムが整う • ハイブリッド環境も整備。単一種のDBでメンテ性を維持しながらGraphRAGを構築できる • Neo4j の VectorDB 拡張 • OracleやPosgreSQLなどRDBの GraphDB・VectorDB 拡張
  16. 今後の発展の方向性の予想 29 発展の方向性として2軸: 1. GraphDBを軸にRAGを導入:既にGraphDBで運用中、または今後適用が有効なプロダク トに、LLMをシームレスに統合してさらに価値を上げる 2. RAGを軸にGraphDBを導入:LLMの外部能力をより一層強化させる手段として導入 ナレッジグラフ グラフデータベース

    実装 Naive RAG RAG 実装 応用 応用 GraphRAG 1. GraphDBを軸に発展 2. RAGを軸に発展 • スキーマ制約強め • 構造データ傾向 • 分析系クエリ傾向 • スキーマ自由度高め • 非構造データ傾向 • 探索系クエリ傾向
  17. 周辺情報・プロダクト 31 • MS GraphRAG使用・派生系 • kotaemon: MS GraphRAGを内包したUIは希少。All-in-One RAGツールとしても有望。

    • nano-graphrag: MS GraphRAGからインスパイア。小さく高速。Neo4対応 • LightRAG: nano-graphragの派生。シンプルでコスト減 • GraphRAGを持つRAG系 • R2R: 内部にGraphRAGを持つハイブリットRAGエンジン • トリプル抽出用にチューニングした専用LLM(Triplex)による安価で高速性が売り • HybridRAG: VectorDBをGraphDB補完。インデクシングはMS GraphRAGより工夫