話題のGraphRAG その可能性と課題を理解する 進化するRAGの世界 - GraphRAGと評価指標の最新動向 https://www.alpha.co.jp/ 2024年 10月 31日 株式会社アルファシステムズ 鏡味 秀行

自己紹介 2 • 鏡味 秀行 （かがみ ひでゆき） • 株式会社アルファシステムズ 経営企画本部 AI推進室 室長 • 組織ミッション: AIソリューションによる顧 客の価値向上、社内のAIの普及 • 10/27 JJUG CCC 2024 Fallで登壇 “LangChain4jを使った生成AIシステム設 計パターン - Javaで構築する最新アーキテ クチャ”

目次 3 • GraphRAGとは？ • MicrosoftのGraphRAGの仕組み • GraphRAGの実用性、ユースケース、課題 • GraphRAGの最新動向、今後の展開予想

応用 応用 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 実装+応用 どうなる？

ナレッジグラフ（Knowledge Graph：KG） 5 ナレッジグラフ

ナレッジグラフ（Knowledge Graph：KG） 6 • エンティティ（ノード）とリレーション（エッジ）の集合で意味を示すもの。 「日本の首都は東京です」 「日本の首都は東京です。関東圏に位置し人口は約1400万人です。」 首都 東京 日本 首都 1400万 人口 関東 地方 ま た は 地方:関東 人口:1400万 プロパティ 東京 エンティティ エンティティ リレーション 日本 東京 日本 首都 • グラフにプロパティを付与することもある（プロパティグラフ） • 特に主語・述語・目的語の関係性を持つものは「トリプル(Triplet)」と呼ばれる

グラフデータベース（Graph Database：GraphGB） 7 ナレッジグラフ グラフデータベース 実装

グラフデータベース（Graph Database：GraphGB） データをナレッジグラフの構造として扱い、問い合わせにより付加価値を持つ情報を取り出す GraphDB データ クエリ レスポンス 変換 グラフデータ 人/コード 格納 結果（パス探索結果/ネットワーク分析結果/ 関係性/クラスタリング/部分グラフ/etc…） 構造/非構造 エンティティ/リレーション抽出 グラフ用クエリ言語や グラフ操作API 8

グラフデータベース（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万 人口 関東 地方 大阪 近畿 地方

GraphRAG 10 ナレッジグラフ グラフデータベース 実装 Naive RAG RAG 実装 RAG RAG Advanced RAG 応用 応用 GraphRAG

GraphRAG: 従来のRAGの応用、という見方 11 GraphRAGは、RAGにナレッジグラフ技術を適用したもの • インデックス作成時: ドキュメントからエンティティ/リレーションを抽出して保存 テキストチャンク /埋め込み GraphRAG • 情報取得時: クエリに関係するエンティティ/リレーションを取り出し、要約して回答 データ NaiveRAG データ エンティティ/リレーション テキストチャンク GraphRAG クエリ NaiveRAG クエリ LLM 要約 LLM 要約

GraphRAG: 何が優れているか 12 Graphを使って質問から関係する回答を辿れる • 文章上の距離が離れていても、関係が近ければ隣に • グラフ上多少離れてもマルチホップで取り出せる（先ほどの「日本」と「1400万」） • 質問を回答に近づけていける仕組みの一つ 〇〇 △△ ■■ 〇〇 △△ ■■

GraphRAG： Graph DatabaseをLLMで拡張、という見方 • クエリとレスポンスにLLMが介在する • グラフデータ格納（インデクシング）でLLMが介在する GraphDB データ クエリ レスポンス 変換 グラフデータ 格納 質問 回答 LLMにより様々な形式を解釈 LLMによるエンティティ/ リレーションの抽出 自然言語をグラフ用 クエリ言語に LLM 注:LLM適用がすべての箇所で必須ではないです LLM LLM 非構造のケース多め 13

GraphRAG：LLMによるエンティティ/リレーションの抽出 14 プロンプトにエンティティとリレーションを抽出する指示を詳細に記述 －目標－ この活動に関連する可能性のあるテキスト文書とエンティティタイプのリストが与えられた場合、テキストか らそれらのタイプのすべてのエンティティと、特定されたエンティティ間のすべての関係を特定する。 -手順- 1. すべてのエンティティを特定する。特定された各エンティティごとに、以下の情報を抽出する： - entity_name: 大文字で表記されたエンティティの名前 - entity_type: 次のいずれかのタイプ：[historical_figure, event, battle, political_maneuver, dynasty, title, region, policy, cultural_development, alliance] - entity_description: エンティティの属性と活動の包括的な説明 各エンティティを("entity"|||)の形式で表記する 例: MicrosoftのGraphRAG ‘graphrag/prompt_tune/templateentity_extraction.py’ より デフォルトプロンプトを「歴史上の人物用」にチューニングしたもの （このあとにリレーションの抽出やFew-Shotのサンプルが続く）

MicrosoftのGraphRAG 15 ナレッジグラフ グラフデータベース 実装 Naive RAG RAG 実装 RAG RAG Advanced RAG MS GraphRAG 応用 応用 GraphRAG 実装+応用

MicrosoftのGraphRAG 16 MicrosoftのGraphRAG（以下’MS GraphRAG’とし、従前の’GraphRAG’と区別します） は、GraphRAGの技術をベースにLLMの能力で機能を強化したもの 一般的なGraphRAGと比べての特徴 1. グラフクエリ言語使わず、意味的なヒットでエンティティを取れる • 自然言語の質問⇒Cypherクエリの変換なく 2. 全体を見渡した回答ができる • 「このドキュメントの概要を教えてください」-> 「全体は…」 これらの実現のための要素： ①ベクトル検索の併用 ②コミュニティー

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

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

MS GraphRAGの特徴①：ベクトル検索を併用： クエリ処理 19 • エンティティ（’ create_final_entities.parquet’)の中身

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のキーが入っている • ローカル検索処理でクエリからエンティティ抽出

MS GraphRAGの特徴②：コミュニティ 21 • 階層 Leiden クラスタリング (Hierarchical Leiden Clustering) アルゴリズムを使い、エ ンティティが多くのリレーションを持つ/持たない状況を見て、グルーピングする。 • グルーピングされたまとまりをコミュニティという。 • コミュニティを見渡せば、全体の概要が把握できる。 クラスタリングで作られたコミュニティ（四角の枠）

1582年6月2日、織田信 長は重臣の明智光秀に よって討たれる。信長は 天下統一を進める中、そ の革新的な政策と過酷な 統治で反感を買っていた。 突然の「本能寺の変」で、 本能寺に滞在していた信 長は自害に追い込まれる。 この事件の背景には、信 長の苛烈な性格や この事件の背景には、信 長の苛烈な性格や光秀へ の遠征命令が影響してい たと考えられる。信長の 死後、豊臣秀吉が素早く 光秀を討ち、信長の遺領 を引き継ぐことで、彼の 後を継いで天下統一を進 めることになる。本能寺 の変は日本史の流れを大 きく変えた。 戦国時代から安土桃山時代に かけての武将、大名。通説で は美濃国の明智氏の支流の人 物で、俗に美濃の明智荘の明 智城の出身と言われているが、 他の説もある。このため前歴 不明。越前国の一乗谷に本拠 を持つ朝倉義景を頼り、長崎 称念寺の門前に十年ほど暮ら し、このころに医学の知識を 身に付ける。その後、足利義 昭に仕え、さらに織田信長に 仕えるようになった。 22 • コミュニティ作成時、説明する文章（コ ミュニティ・レポート）をLLMに作らせ る。 • 全体的かつ主要情報は、コミュニティ・ レポートに集約し、グラフ全体の概略を 回答できる • グローバルサーチにより質問と関連のあ るコミュニティ・レポートを抽出し要約 して回答 （図の出典：https://graphr.ag/ ） MS GraphRAGの特徴②：コミュニティ：インデクシング・クエリ処理

GraphRAGの実用性、ユースケース、今後の課題 23 e.g. Neo4j+LangChain e.g. Neo4j+LangChain e.g. Neo4j+LangChain MS GraphRAG GraphRAG 実装+応用

GraphRAG/MS GraphRAGの実用性・ユースケース 24 関係性の発見、体系的な理解の補助を行う業務 • グラフ構造を活かした探索 (GraphRAG/MS GraphRAG) • 文書同士の参照関係を持つもの • 関連情報の水平展開やドリルダウン探索を行いながら調査する作業 • グローバル探索とローカル探索を活かした探索 (MS GraphRAG) • 例えば、初学者の専門分野理解のサポート。 • 全体把握と部分把握を往復して理解する作業 ユースケースは、従来の GraphDB の活用事例にヒントあり • Neo4j社の事例集など • White Paper:Optimized Graph Algorithms in Neo4j

GraphRAGの課題と克服 25 GraphRAGの課題 ≒ GraphDBの課題 ≒ RDBと比べてどうか？ 課題１：エコシステムや教育の普及が進んでいない → SQL/PGQやGQLなどグラフクエリの国際標準化が進んできている • OracleやPostgreSQLなどへの実装が進展しエコシステムが整う • ハイブリッド環境も整備。単一種のDBでメンテ性を維持しながらGraphRAGを構築できる • Neo4j の VectorDB 拡張 • OracleやPosgreSQLなどRDBの GraphDB・VectorDB 拡張

GraphRAGの課題と克服 26 課題2：グラフ構築の自由度が高すぎて設計が大変 → スキーマの自由度過ぎる問題について秩序を与えて使い勝手を良くする案 • 構成原則、オントロジーなどの適用 • Microsoft GraphRAGをシステム開発プロジェクトへ適用する - 設計書とソースコードの ナレッジグラフ化 - アルファテックブログ

MS GraphRAGの課題 27 • アプリケーション・ライブラリとしての完成度 • Graph特有の問題: エンティティ重複解消、差分更新などの対応 • ライブラリとしてのポータビリティ • RAGパイプラインの拡張性、理解の難しさ • トークンコスト • Githubの活性度 • Cypherグラフクエリ使えない

GraphRAGの最新動向、今後の展開予想 28 e.g. Neo4j+LangChain 発展 e.g. Neo4j+LangChain e.g. Neo4j+LangChain MS GraphRAG どうなる? GraphRAG 実装+応用

今後の発展の方向性の予想 29 発展の方向性として2軸： 1. GraphDBを軸にRAGを導入：既にGraphDBで運用中、または今後適用が有効なプロダク トに、LLMをシームレスに統合してさらに価値を上げる 2. RAGを軸にGraphDBを導入：LLMの外部能力をより一層強化させる手段として導入 ナレッジグラフ グラフデータベース 実装 Naive RAG RAG 実装 応用 応用 GraphRAG 1. GraphDBを軸に発展 2. RAGを軸に発展 • スキーマ制約強め • 構造データ傾向 • 分析系クエリ傾向 • スキーマ自由度高め • 非構造データ傾向 • 探索系クエリ傾向

今後の発展の予想（願望） 30 以下を容易に組み合わせたり拡張したりして、GraphRAGを独自に性能向上でき、さまざまな ユースケースに柔軟に適応できるベースラインのGraphRAGのリファレンス実装（欲しい…） インデクシングの工夫による性能向上 • スキーマ定義の工夫によるLLMのエンティティ抽出精度向上 • RAGパイプラインのカスタマイズ クエリの工夫による性能向上 • LLMによるコンテキスト情報の付与 • ベクター検索とのハイブリッドによる問い合わせ方法の多様化 • グラフクエリ言語への柔軟な対応 MATCH (country:Node {name: '日本'})-[:首都]- >(city:Node)-[:地方]->(region:Node) RETURN city.name AS 首都, region.name AS 地方

周辺情報・プロダクト 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より工夫

まとめ 32 • GraphRAGの理解はベースとなるナレッジグラフの理解から • LLMによりナレッジグラフやGraphDBが次の応用ステージへ • GraphRAGの進化←LLMの進化+グラフ技術や環境の進化のシナジーに期待

アルファテックブログ のGraphRAGに関する記事 33 今後も順次、情報展開していきます

34 〒211-0053 神奈川県川崎市中原区上小田中6丁目6番1号 株式会社アルファシステムズ 経営企画本部 AI推進室 [email protected] *本書は著作権法と不正競争防止法上の保護を受けています。本書の一部あるいは全部について、株式会社アルファシステムズから文書による承諾を得ずに、いかなる方法においても無断で 複写、複製、ノウハウの使用、企業秘密の展開等をすることは禁じられています。 常に発展する技術者集団 無限 可能性 挑戦 新卒、第二新卒、SE経験者の方々、ぜひこちらまで！ 採用情報 AIに関するご相談はこちら→