GraphRAGでLinkedIn 28.6%短縮

「その件は、前任の佐藤さんに聞かないとわかりません」

このセリフが会議室で出るたびに、私は少しだけ死にたくなります。佐藤さんはもういないからです。SharePointには400ページのドキュメントがあるのに、どれとどれが関連しているかは、佐藤さんの頭の中にしかありませんでした。

LinkedInが同じ問題をGraphRAGで解いていて、しかも数字が公開されています。今日はその中身を、指標定義と実装単位までほどいていきます。

何がどれだけ改善したのか

出典はLinkedInの論文「Retrieval-Augmented Generation with Knowledge Graphs for Customer Service Question Answering」(arXiv 2404.17723、SIGIR 2024で発表)です。6ヶ月の本番運用の結果として、次の3つが報告されています。

• 問題解決時間の中央値: −28.6%
• MRR (Mean Reciprocal Rank): +77.6%
• BLEU: +0.32

一番よく引用されるのは28.6%の方ですが、私はMRR +77.6%の方が実装者としては嬉しい数字だと思っています。MRRは「関連する答えが検索結果の何番目に出るか」の逆数の平均。1位に出れば1.0、2位で0.5、10位で0.1です。これが77.6%改善したということは、探しているチケットが上位に来るようになったという話で、そこが速くなるから解決時間も縮む。因果としてまっすぐです。

BLEUの+0.32は、生成される回答文そのものの品質。回答文とリファレンスがどれくらい単語重複しているかを見る指標なので、これは検索精度ではなくLLMの生成部分の改善です。3つの数字が別々の場所を測っているのを、区別しておくと本文が誤読されにくくなります。

なぜベクトル検索だけでは足りなかったのか

論文の背景セクションが率直で好きです。既存のベクトル検索ベースのRAGは、サポートチケットの解決にはうまく効きませんでした。理由は3つ挙げられています。

1. チケットは長い。埋め込みは長文になるほど「雰囲気の類似度」しか出せなくなる
2. チケットには構造がある。サマリ、説明、優先度、再現手順、解決策といった内部セクションを、ベクトルは潰す
3. チケット間の関係がある。過去の類似障害、前提となる別チケット、連鎖する障害。ベクトルは点同士の類似しか見ない

「雰囲気の近いチケット」を出すだけなら、それはGoogleでできる仕事です。サポート担当者が欲しかったのは「この障害の原因になっているチケット」で、これは類似ではなく関係の情報です。

LinkedInが実際に組んだ構成

論文からの要約は次のとおりです。

要素	何を使った
Parsing / 回答生成	GPT-4
埋め込み	E5
チケット表現	ツリー構造(チケットを根、サマリ・説明・再現手順・解決策などのセクションを子ノードに)
クエリ → グラフクエリ	自然言語質問をグラフDBクエリに変換
検索	サブグラフとして関連事例を取得
生成	サブグラフをコンテキストに回答

ツリー構造でチケットを持つのが肝で、これでチケットの中の階層関係が保存されます。さらにチケット同士も辺で繋がっているので、「このチケットの前提になっているチケット」を辿れる。

流れ全体はこうです:

1. 新しい質問が来る
2. 質問を解析して、KGに投げるクエリに変換する
3. KGから関連するサブグラフを抜く(点だけでなく、点と点をつなぐ辺ごと)
4. 抜いたサブグラフをコンテキストにLLMが回答を作る

3の「辺ごと」がベクトル単独との違いです。ベクトルは似た点を返しますが、点と点の関係は返せません。GraphRAGは関係を含んだまま渡せる。

私の家GraphRAGにどう落ちるか

正直に書くと、家のGraphRAGはまだNeo4jに3ノードしか入っていない段階です。それでもLinkedIn事例から2つは引き継げるものがあると思っています。

1つ目: 情報単位を「ドキュメント」から「関係付きの実体」に変える

私は最初、社内Wikiのページを1つ1つノードにしていました。これはベクトルRAGの発想の延長で、GraphRAGの利点を潰しています。LinkedIn式は「チケット=木」にして、「そのチケットが依存する別チケット」を辺で繋いでいる。私も「1記事=木、章と章の間に辺、関連記事同士に辺」に変えました。

2つ目: 質問→グラフクエリの変換を人任せにしない

LinkedInは自然言語質問をCypher相当のクエリに落とす層を明示的に置いています。ここが薄いと結局ベクトル検索に戻ります。私はまだLLMに「関係を辿るクエリ」を書かせる部分が弱くて、ここが次の宿題です。

まとめ

• LinkedInのGraphRAG事例は3つの数字を報告している。検索精度(MRR +77.6%)、業務効率(解決時間−28.6%)、回答品質(BLEU +0.32)。それぞれ別の場所を測っている
• ベクトル検索単独では、点同士の類似は取れても点と点の関係が取れない。GraphRAGはそこを埋める
• 実装のキモは「情報単位を関係付きの実体にする」ことと、「質問→グラフクエリの変換層を明示的に置く」こと

GraphRAGの実装をもう少し体系的にやりたい方には、私の書いた ナレッジグラフ実務ガイド が近い話をしています。第6章がまさにこのLinkedIn事例の分解で、NTT東日本の4ステップ導入フレームワークとNTTデータの契約リスク評価も同じ章に入っています。