『AIで検索を賢く』にRAG即答して外す副業提案、GraphRAG6パターンを質問分類から当てる引き出し設計

取引先から『社内ドキュメントの検索精度を上げたい』と相談されて、ベクトル検索を一発で提案してしまう人は多い。自分も副業でAIを触り始めた頃、RAGを組めば全部解決するとどこかで思っていた時期があった。実際は、質問の種類が変わるだけで同じ仕組みが空振りする。10年以上エンジニアをやってきて、副業で複数のAIエージェントを回している今も、検索設計の話になると毎回立ち止まる。

海外の解説記事で、GraphRAGを6つのアーキテクチャに分けて整理したガイドが出ていた。副業で受託や提案を考えているエンジニアにとって、これは『技術一覧』ではなく『提案の引き出し』として読める内容だった。今日はそこで整理された考え方を、案件を取る側の立場で分解してみる。

『AIで検索精度を上げてほしい』と言われて、何を答えるか
単純な類似検索では、業務データの『つながり』を拾えない
GraphRAGという選択肢が示す、6つの設計パターンの違い
1. 決まった質問に強い方式と、あいまいな質問に強い方式は別物
2. 精度を求めるほど、構築コストと運用の手間が増える構造
技術を知っているだけでは案件にならない、提案の言葉に変える練習
まとめ
参考
【PR】おすすめの書籍
1. あわせて読みたい

『AIで検索精度を上げてほしい』と言われて、何を答えるか

副業で相談を受ける時、いちばん困るのは要件が広すぎる依頼だ。『AIで検索を賢くしたい』『社内資料をChatGPTみたいに使いたい』という粒度で来る。ここで即座に『じゃあRAG組みましょう』と返してしまうと、後で必ずズレる。実際に運用が始まってから、質問に答えられないケースが山ほど出てくるからだ。

典型的なのは、部品の遅延が完成品に与える影響を聞かれた時。『部品Aの入荷遅れが、製品Cの最終組立にどう波及するか』という質問は、意味の近い文書を集めても答えが出ない。関係の連鎖を追わないと結論が出ないタイプの問いだからだ。もう一つ厄介なのが、5年分の売上推移をカテゴリ横断で集計するような質問。バラバラのPDFに散った数字を、期間で束ねて計算するのはベクトル検索の守備範囲外になる。

自分がAIエージェントを組んで動かしていて実感するのは、検索の精度は『何を聞かれるか』で決まるということ。技術選定の前に、想定質問を10個くらいノートに書き出させてもらうと、提案の方向が一気に絞れる。ここを飛ばして技術から入ると、動くけど使われないシステムができあがる。

単純な類似検索では、業務データの『つながり』を拾えない

通常のRAG(Retrieval-Augmented Generation、外部データを検索してLLMに渡す仕組み)は、文書を細かく切って埋め込みベクトルに変換し、質問に近いチャンクを引いてくる仕組みだ。局所的で明示的な質問には強い。ただし、この仕組みが見ているのは『似ている文章片の平坦な世界』でしかない。エンティティ同士の明示的な関係は最初から視界に入っていない。

『サプライヤーBから部品Aが遅延したら製品Cはどうなるか』を例に取ると、通常のRAGはBとAとCの記述が入ったチャンクを別々に引いてくる。それらを並べて渡されたLLMは、関係を推測しようとするが、たいてい途中で外す。ここで必要になるのが、実体と関係を構造として持たせる発想だ。

この発想を持ち込むのが、GraphRAGと呼ばれるアプローチになる。ドキュメントをフラットな塊で扱う代わりに、ナレッジグラフ(Knowledge Graph、実体をノード・関係をエッジで表現するデータ構造)を挟む。ノードには『会社』『人物』『部品』が並び、エッジに『供給する』『所属する』『依存する』といった関係が張られる。LLMの意味理解と、グラフの決定的な関係辿りを組み合わせる考え方だ。

ただ、GraphRAGと一言で言っても中身は一枚岩ではない。冒頭で触れた元記事は、実装現場で分岐する6つのアーキテクチャを整理していた。副業で提案する側から見ると、この分岐こそが会話のフックになる。

GraphRAGという選択肢が示す、6つの設計パターンの違い

元記事が並べた6つのパターンは、大まかに『どこにグラフを効かせるか』で分かれている。全部を暗記する必要はないが、案件の話をする時に『こういう分け方がありますよ』と出せるだけで、提案の解像度がガラッと上がる。以下、代表的な考え方を4つに絞って触れる。

1つ目は、Text-to-Cypher型と呼ばれる方式。自然言語の質問を、グラフDB用のクエリ言語(Neo4jで言うCypher)にLLMが翻訳して、DBに直接投げる形だ。返ってきた結果は決定的で、集計や平均といった数値処理も得意になる。ただし、スキーマ(ノードとエッジの定義)を厳密に渡してやる必要があり、質問者もある程度データ構造を知っている前提になる。人事DBやサプライチェーンのように、業務が構造化されていて用語のブレが少ない現場に効く。

2つ目は、Parallel Hybrid型。ベクトルDBとグラフDBを両方持って、質問が来たら同時に叩く。ベクトル側は意味の近い文書チャンクを、グラフ側は関係のサブグラフを引いてきて、両方の結果をLLMに渡す。『戦略的な優先事項は?』のようなあいまいな部分はベクトルで、『Tier2サプライヤーは誰か』のような明示的な部分はグラフで拾う。実装の手間は倍になるが、質問の性質を選ばずに戦える。

3つ目・4つ目・5つ目・6つ目は、ルーティング型やグラフ拡張検索など、片方をもう片方の入り口や補強に使う形になる。共通しているのは、意味検索と構造検索のどちらか一方だけでは足りないという前提だ。

決まった質問に強い方式と、あいまいな質問に強い方式は別物

提案の現場で意識するのは、想定される質問が『事実照会型』か『探索型』かという分岐だ。事実照会型は、答えが一意に決まる質問。『Xさんの直属の部下は誰か』『2024年の売上合計はいくらか』のようなもの。ここはText-to-Cypher型のような決定論的な方式が強い。ハルシネーションが起きにくく、集計もぶれない。

一方の探索型は、答えが幅を持つ質問。『最近のクレーム傾向はどう変わっているか』『主要顧客の関心はどこに向かっているか』のようなもの。ここはベクトル検索の意味的な広がりが必要で、グラフだけでは拾いきれない。両方が混ざる案件なら、Parallel Hybrid型のように併用する方向に倒す。

この分岐を提案書の最初のページに置いておくだけで、要件定義の会話が短くなる。『御社の質問は事実照会が7割・探索が3割ですね、なので方式Aで組みますが探索側を補強するために方式Bを一部混ぜます』と話せる。技術を語るのではなく、業務の質問を分類してから技術を当てる順番だ。

精度を求めるほど、構築コストと運用の手間が増える構造

GraphRAGは万能ではない。というより、通常のRAGより明らかに重い。まずナレッジグラフを作る段階で、LLMに固有表現抽出と関係抽出をやらせる必要がある。ドキュメント量が多いと、この抽出だけで無視できない計算量になる。しかも抽出結果は事前にオントロジー(どんな種類のノードとエッジを許すかの設計図)を決めておかないとブレる。ここは人間の設計仕事が残る。

運用段階でも手間は続く。ドキュメントが更新されたら、対応するノードとエッジをどう洗い替えるか。ソース文書のIDをノードに紐づけておかないと、古い情報が残り続ける。逆に、あるノードが数百のチャンクに登場する場合、チャンクIDを全部プロパティに突っ込むと配列が肥大化する。元記事はこの点を明示的に非推奨としていた。設計判断が細かい。

提案の時にこの重さを隠すと、後でつらい。自分の副業では、初期見積もりに『抽出パイプラインの試作』と『オントロジー設計』を独立した工程として立てるようにしている。ここを工数化しないと、後半で全部溶ける。技術に興奮して工数を軽く見せると、赤字案件が生まれる。

技術を知っているだけでは案件にならない、提案の言葉に変える練習

GraphRAGの6パターンを覚えても、それだけでは1円にもならない。副業で通帳が動くのは、この知識を『相手の業務課題』の言葉に翻訳できた時だけだ。自分がAIエージェントを組んで感じているのは、技術選定の話に持ち込む前に、質問カタログと運用体制の話を先に済ませておかないと提案が空振りするということだ。

翻訳の練習として、手元で3つの質問を書けるようにしておくと役に立つ。1つ目、想定される質問を10個挙げてもらえますか。2つ目、そのうち答えが一意に決まるものと、幅がある回答でよいものはどれくらいの比率ですか。3つ目、ドキュメントの更新頻度と、更新時に検索結果もすぐ反映してほしいかどうかは決まっていますか。この3つを聞くだけで、通常のRAGで足りるのか、GraphRAG系のどれかに倒すべきかが半分見える。

『AIで検索を賢く』という漠然とした依頼を、こうやって因数分解できる人が副業単価を上げられる。技術の名前を並べて『できます』と言う人ではなく、業務の質問を分類してから技術を当てる人が信頼される。GraphRAGの6パターンは、そのための語彙として持っておく。動かせるかより、選び分けの理由を説明できるかの方が、案件では効いてくる。地味だけど。