RAGはどこで力尽きるか ―GraphRAGが解いた3つの弱点
連載「AIエージェント時代のオントロジー」第2回
こんな経験はありませんか？
社内文書をAIで検索できるようにした。デモは上々だった。ところが本番に出すと、妙な弱さが露呈する・・・・
「A製品の後継の、そのまた後継は?」に、なぜか答えられない。
「今年の問い合わせ、全体としてどんな傾向?」と聞くと、たまたま検索に引っかかった数件だけを見て、さも全体を語るように答えてしまう。
これはAIの出来が悪いのでも、作った人の腕が悪いのでもありません。いま広く使われている検索のやり方——RAGと呼ばれる仕組み——の「かたち」そのものに、はじめから組み込まれた弱点なのです。
今回は、その弱点を3つに整理します。そして、Microsoftが公開したGraphRAGという手法が、それをどう乗り越えたかを、なるべく専門用語に頼らずに見ていきます。前回(Palantir回)の結論、「組織の知識は、バラバラの文書ではなく“構造”として持て」の、これがその技術的な裏づけになります。
まず、RAGとは「似た付箋を数枚拾う」仕組み
RAG(検索拡張生成)を、身近なたとえで説明します。
大量の社内文書を、まず小さな断片に切り分けます。マニュアルの一段落、メールの一通、報告書の一節——付箋(ふせん)くらいの大きさのメモが、何万枚もできると思ってください。
質問が来ると、AIはこの付箋の山から「質問と“似ている”付箋」を数枚だけ拾い上げ、それを読んで答えを作ります。ここでいう「似ている」は、AIが文章の意味の近さを数値で測って判断しています(この数値化した意味の指紋を、専門的には「ベクトル」と呼びますが、名前は覚えなくて大丈夫です)。
知識をAIの“頭の中”ではなく“外の付箋”に置いておくので、内容を差し替えれば答えも更新できるし、「この付箋を根拠にしました」と示せる。方向性としては、とても正しい。
問題は2点です。拾うのが「付箋(=断片)」であること。そして拾い方が「似ているかどうか」だけであること。ここから、3つの弱点が芽を出します。
弱点1:「〜の、そのまた〜」という多段の問いに弱い
「HK-100の系譜(けいふ)の、いちばん新しい機種を持っている顧客は誰?」
人間なら、台帳を2〜3回めくれば済む問いです。HK-100の後継はHK-200、その後継はHK-300、じゃあHK-300を買った顧客は……と、関係をたどっていくだけ。
ところがRAGは、これが極端に苦手です。答えに必要な事実——「100の後継は200」「200の後継は300」「300の持ち主は田中さん」——は、それぞれ別々の付箋にバラバラに書かれているからです。しかも、この3枚が3枚とも「元の質問文と似ている」とはかぎらない。むしろ似ていないことのほうが多い。
RAGには「1枚目の付箋を手がかりに、2枚目、3枚目へとたどる」という動きがありません。似た付箋を一度に拾って終わり。だから、鎖のようにつながった問いの、最初の輪で止まってしまうのです。
弱点2:「全体としてどうか」を見渡す問いに弱い
「今年の修理報告、全体でいちばん多い故障の傾向は?」
この問いには、そもそも「似ている付箋」が存在しません。答えは、どれか1枚の付箋の中にあるのではなく、何百枚もの付箋を集計した“上”に浮かび上がるものだからです。
数枚だけ拾って答えるRAGにこれを聞くのは、分厚い本を10ページだけ読んだ人に、本全体の書評を頼むようなもの。たまたま開いたページの話は詳しく語れても、「全体として何が言えるか」は原理的に答えられないのです。
弱点3:根拠の“粒”が粗い
RAGが示せる根拠は、「この文書のこのあたりです」まで。「この一つの事実が、どのシステムの、いつの時点のデータに由来するか」までは指させません。
ふだんは気になりませんが、監査やコンプライアンスが関わる仕事——「その判断の根拠を、一つひとつ遡って示せますか?」と問われる場面——では、この粗さが効いてきます。
ここまでを一言でまとめると、RAGは「関係をたどれない」「全体を見渡せない」「根拠が大ざっぱ」。3つとも、原因は同じ。付箋がただ山積みになっているだけで、付箋どうしのつながりが記録されていないからです。
では、そのつながりを、はじめから地図として描いておいたらどうなるか。ここからが本題です。
その前に ――「ナレッジグラフ」を絵で理解する
GraphRAGの「Graph(グラフ)」は、折れ線グラフや棒グラフのグラフではありません。ここでのグラフは、**点と線でできた“関係の地図”**のことです。
いちばん近いイメージは、ドラマの冒頭に出てくる登場人物の相関図です。「田中さん」「HK-300」「保守契約」といった登場人物(点)があり、その間を「所有している」「後継である」「対象にしている」といった線が結んでいる。あるいは、駅と路線でできた鉄道の路線図を思い浮かべても構いません。
この「点と線の地図」を、知識について作ったものがナレッジグラフです。付箋の山と決定的に違うのは、つながりそのものが、線として最初から描かれていること。だから「たどる」ことができる。弱点1が生まれた根っこを、地図はそもそも持っていないのです。
GraphRAG ――付箋の山を、相関図に組み替える
2024年にMicrosoftが公開したGraphRAGは、この発想を製品の形にしたものです。やっていることは、大きく三段階。物語として追ってみましょう。
① AIが文書を読んで、相関図を描く
まず、AIがすべての文書を読み込み、そこに出てくる登場人物(人・製品・組織・契約……)と、その間の関係を抜き出して、一枚の大きな相関図(=ナレッジグラフ)を自動で描き上げます。バラバラだった付箋が、線でつながれた地図に組み替わる、と考えてください。
② 相関図を「ご近所」に分けて、あらすじを先に書いておく
大きな相関図は、そのままでは広すぎて全体を見渡せません。そこでAIは、関係の濃い者どうしを“ご近所”ごとにまとめます(この“ご近所”を専門的にはコミュニティと呼びます)。「エンジン系トラブルのご近所」「田中農園まわりのご近所」といった具合です。
そして、ご近所ごとに“あらすじ”をあらかじめ書いておく。「このご近所では、こういう故障が、こういう頻度で起きている」と。全体を見渡す問いへの答えを、質問が来る前に下ごしらえしておくわけです。
③ 問いに応じて、二つの調べ方を使い分ける
準備ができたら、問いの種類によって調べ方を変えます。
特定の人・モノについての問い——「田中さんの機械のことで」——には、その登場人物を起点に、相関図の線をたどって関係者を集めて答える。これが弱点1(たどれない)への回答です。
全体を見渡す問い——「今年の傾向は?」——には、②で用意しておいたご近所のあらすじを束ねて答える。これが弱点2(見渡せない)への回答です。
付箋の類似検索ではどうしてもできなかった「たどる」と「見渡す」を、地図という構造が肩代わりしている。これがGraphRAGの正体です。
正直な注記:タダではない
いいことばかりではありません。①と②では、AIに全部の文書を読ませて相関図とあらすじを作らせるので、準備の手間とコストは決して安くない。文書が頻繁に入れ替わる現場では、地図を描き直す段取りも要ります。
つまりGraphRAGは、なんにでも効く魔法ではなく、「関係をたどる」「全体を見渡す」「根拠を細かく示す」——この3つが本当に必要な仕事にこそ効く道具です。逆に言えば、単純な一問一答で足りるなら、素朴なRAGで十分なこともあります。
その先へ ――「AIが自己流で描いた相関図」でいいのか?
ここで一歩、視点を上げます。
GraphRAGの相関図は、AIが文書から自己流で描いたものでした。便利ですが、弱点もあります。同じ「田中農園」が、表記のゆれで別人として二つの点に割れてしまう。「所有する」と「使っている」の線引きが、文書ごとにブレる。地図の正確さが、AIの読み取りの正確さに、まるごと乗っかってしまうのです。
では——もし、AIに描かせるのではなく、あらかじめきちんと設計された地図を持っていたら?
「うちにとって“顧客”とは何を指すのか」を関係者みんなで合意して定義し、「保守契約は必ず1つの機械と結びつく」といったルールで検算され、「この事実はどの台帳の何月時点のものか」まで出所を記録した——そんな、いわば組織公認の台帳としての地図です。
そういう地図を持っているなら、AIの使い方はもっと賢くなります。しかも、最強のやり方はもはや「検索」ですらありません。
たとえ話:司書とカード目録
図書館を想像してください。あなたが曖昧な言葉で「戦後すぐの、東北の農業の本ってある?」と尋ねると、司書はその意図をくみ取り、正確な検索カードに翻訳して、目録という台帳から該当の本を、確実に、抜け漏れなく引き出してくれます。司書は本の中身をうろ覚えで語ったりしません。探すのは目録に任せ、自分は“翻訳”と“案内”に徹するからこそ、間違えないのです。
設計された地図に対しては、AIをこの司書のように働かせられます。人間の曖昧な問いを、AIが正確な“検索カード”(専門的には SPARQL(スパークル) という問い合わせ言葉ですが、名前は覚えなくて結構です)に翻訳する。そして、事実を実際に引き出して組み合わせる作業は、台帳側のきっちりした仕組みに任せる。
こうすると何が嬉しいか。答えの“事実の部分”が、必ず台帳から来ていることが、仕組みとして保証されるのです。AIは意図をくみ取ることと、結果をやさしい日本語に直すことだけを担当し、事実をでっち上げる余地がない。前回の「AIが存在しない型番を自信満々に答える」問題を、“気合い”や“確率”ではなく、工程の設計で塞いでしまう——これが、この連載がめざす地点です。
で、その「設計された地図」はどう作るの?
もっともな疑問です。そして、それこそがこの連載の本編そのものです。
さらに嬉しいことに、その地図を設計するスキルは、いまやAI自身が強力に手伝ってくれる時代になりました。かつて専門家が何ヶ月もかけていた作業を、AIが下書きしてくれる。だから、身構える必要はありません。
次回はそれを、実際に手を動かして体感してもらいます。「LLMと90分でオントロジーを作る」——たった3通の修理報告書から、AIとの対話だけで、検証済みの小さなナレッジグラフ(あの“相関図”の、あなた専用の一枚)を作るハンズオンです。文系の方こそ、ぜひ一緒に手を動かしてみてください。作ってみると、驚くほど腑に落ちます。
前回:[Palantirの「オントロジー」は、標準技術で再現できるか]
感想・リクエストは #AI時代のオントロジー でぜひ。マガジンをフォローすると毎週火曜の更新が届きます。
#GraphRAG #RAG #LLM #AI #AI時代のオントロジー
