ナレッジグラフ4つの型を6軸で比較する

ナレッジグラフを作ろうとすると、まず Neo4j と RDF のどちらかという記事に当たります。その分岐の1つ手前に、決まっていることがあります。何をグラフにするかです。

多くの場合、答えは構造化データかコードのどちらかです。 元データが既に構造を持っているなら、抽出という工程がまるごと要りません。コードベースも同じで、構文解析器が構造を返すので LLM は不要です。文書は効果が一番大きい代わりに、取り込みにコストが乗ります。そして4つ目の個人のメモ。技術的には一番簡単で、続かないという理由で一番よく死にます。

この4つを混ぜて設計すると、だいたい更新のところで詰まります。同じ仕事をさせたときにどう割れるのかを、6軸で並べます。

揃える課題

比較を成立させるために、4つの型に同じ問いを投げます。

「A と B はどう繋がっているか」に答えさせる。

ベクトル検索で解ける問いをわざわざグラフにしても意味がないので、対象は、2つ以上のものを繋がないと答えが出ない問いに絞ります。

どれも「似た文書を上位8件返す」では答えになりません。関係を辿る必要があります。

4つの型

構造化データのグラフ。 元データが既にレコードと参照を持っているものです。ゲームのレシピ、依存パッケージの一覧、API の定義、データベースのスキーマ。抽出という工程が存在しないので、読み替えるだけでグラフになります。4つのうち最も速く、最も決定的です。

コードグラフ。 関数・クラス・ファイルをノードにして、呼び出しと依存で繋ぎます。構文解析で取れるので LLM が要らず、更新も git の差分から機械的に組み直せます。

文書グラフ。 社内 wiki、設計文書、議事録をノードにして、人・システム・決定で繋ぎます。作るのが一番大変で、効いたときの効果も一番大きい型です。取り込みに LLM を使うので、ドキュメントの量がそのままコストになります。

個人グラフ。 自分のメモ、読書ノート、学習記録を繋ぎます。ツールは Neo4j でも Obsidian でも足ります。技術的な難所はほとんどありません。難所は運用のほうで、参照しなくなった瞬間に更新が止まり、止まった瞬間に価値がゼロになります。

マトリクス

6つの軸

表の列に並べた6つが、この比較の物差しです。

構築コストは、最初にグラフを作るまでの手間です。文書は非構造化テキストからエンティティと関係を取り出す工程があり、そこに LLM の API コストが乗ります。コードは構文解析器が構造を返すのでこの工程が要りません。構造化データに至っては、元データの参照をそのままエッジに読み替えるだけです。

更新の自動化が、実は一番効く軸です。作るのは一度きりですが、更新は永久に続きます。構造化データとコードは元データの差分から組み直せるので CI に乗ります。文書グラフは「どの文書が変わったか」を検知する仕組みを別に作ることになります。

腐りやすさは、更新の自動化の裏返しです。更新が止まったグラフは、間違った答えを自信を持って返すようになります。空のグラフより、古いグラフのほうが危険です。

多ホップの効きは、グラフにする価値そのものです。1ホップで答えが出る問いなら、ベクトル検索とリランカーで足ります。2ホップ以上を辿らないと答えられない問いがどれだけあるかで、投資の是非が決まります。ここは段数の実測で測りました。

説明可能性は、なぜその答えなのかを経路として提示できるかどうかです。監査の要る業務や規制業界では、精度よりここが採用条件になります。ベクトル検索は「似ている文書」までしか示せません。

必要な道具は、そのまま着手の障壁です。個人グラフは既存のメモアプリで始められます。

自分ならどれか

4行目は、そもそもグラフが要らない可能性があります。 自分の問いが1ホップで閉じているなら、リランカーを足すほうが安上がりです。

5行目も注意が要ります。個人グラフは着手が軽いぶん、続けられるかどうかの見積もりを先にするほうが確実です。参照しない日が2週間続いたら、そのグラフは既に死んでいます。

最初に作るなら構造化データから

4つのうちどれを本命にするかとは別に、最初の1つは構造化データで作るのを勧めます。

そこにしか無いものが1つあります。答え合わせができることです。元データが構造を持っているなら、グラフが正しく組めたかどうかを機械で検算できます。文書グラフでは、抽出が正しかったかを人が読んで判断するしかありません。

グラフDB の操作も、多ホップのクエリの書き方も、更新の設計も、答え合わせのできる題材で一度通しておくほうが速く身につきます。作り方は次の章で扱います。