LabHub

ブログ

知識グラフのツール・フレームワーク地図 — 何を、いつ選ぶか

한국어English日本語中文

はじめに — 必要なのはピンではなく地図

知識グラフのツール地形は、この2年で爆発しました。グラフデータベースだけで6つを本気で検討でき、RDFスタックには20年の歴史があり、グラフRAGフレームワークは毎月のように新しく出ます。この種の記事のありがちな失敗は、リンクを30個並べて終わることです。リンク集はもう足りています。

だからこの記事は地図を描きます。カテゴリごとに、何のためのものか、代表ツールを2〜3個、そしていつ何を選ぶかを述べます。このシリーズの実用的な最終編です — なぜグラフRAGかグラフをどう構築するかドメインをどうオントロジーとしてモデリングするかを経て、いよいよ「では何を使うのか」に答えます。

一つ正直な前提を先に。ツールは変わります。この記事を書いている間にも、有名な組み込みグラフDBが一つアーカイブされました。だからツール名よりも選ぶ基準を丁寧に書き残しました。基準のほうが長持ちするからです。

大きな分岐 — プロパティグラフ vs RDFトリプルストア

何を選ぶにせよ、最初の分岐はデータモデルです。二つの家系があります。

プロパティグラフは、ラベル付きのノードとエッジに任意のキー・バリュー属性を付けます。形式スキーマは必須ではなく、開発者フレンドリーで、Cypher(および2024年にISO標準になったGQL)、Gremlin、GSQLで問い合わせます。

// プロパティグラフ (Cypher): 実用的、スキーマは任意
CREATE (a:Person {name: 'Ada'})-[:WORKS_AT]->(c:Company {name: 'AE Ltd'})

RDFトリプルストアは(主語, 述語, 目的語)の三つ組で保存し、グローバルなIRIで実体を識別し、RDFS/OWLで形式オントロジーを定義し、論理推論を回せます。SPARQLで問い合わせ、W3C標準なので組織間の相互運用性が強みです。

# RDF (SPARQL): グローバル識別子、形式的な語彙、推論が可能
SELECT ?person WHERE { ?person a :Person ; :worksAt ?org . }

正直な基準はこうです。大半のLLM・グラフRAGアプリケーションはプロパティグラフが合います。 儀式(ceremony)が少なく、抽出したノイズ混じりのグラフを扱うのに柔軟です。RDFを持ち出すのは形式的な意味が必要なとき — 複数チーム・組織で共有する語彙、論理推論、標準・規制への準拠、データ統合です。オントロジーをどこまで形式化するかはドメインオントロジー編で別途扱いました。

なお、Amazon Neptuneは両方をサポートします(プロパティグラフはopenCypher/Gremlin、RDFはSPARQL)。「すでにAWSにいる」がそれ自体強い理由になります。

グラフデータベース — 何をどこに

6つを実用基準で分けてみます。

組み込み vs サーバーはこう分けます。プロトタイプ・ノートブック・単一ノードなら組み込み(Kùzu)。並行性・エコシステム・本番ならサーバー(Neo4j)。マネージドが欲しければNeptuneまたはAuraDB。

RDF・オントロジースタック — 形式的な意味が必要なとき

RDFの道に入ったなら、ツール構成はだいたいこうなります。

選ぶ基準: プロトタイプ・PythonならRDFLib。オープンソースの本番RDFアプリならJena(+Fuseki)。推論と規模が要るエンタープライズのトリプルストアならGraphDB(またはStardog)。データスチュワードシップの組織ならTopBraid EDG。オントロジーの著述はどこでもProtégé。

グラフRAGフレームワーク — 自作か、バッテリー同梱か

ここは二つの軸で分けると選びやすくなります。(1) バッテリー同梱のパイプラインか、組み立て部品か、(2) バッチのインデックスが重いか、軽いか。

自作 vs バッテリー同梱のコツ: 実体・関係を自分のグラフに入れるだけでよいなら、LangChain/LlamaIndexの抽出器や普通のLLM呼び出しで十分です。Microsoft GraphRAGは、そのコミュニティ要約・グローバル問い合わせの機構が本当に必要なときにだけ元が取れます。

ベクトル + グラフ — 埋め込みの居場所

よくある誤解は、ベクトルかグラフかを二者択一で見ることです。現代のデフォルトはハイブリッドです。

ベクトル検索は曖昧な意味的想起(「こういう文章」)を、グラフ走査は精密な多段の関係(「XとYはどうつながるか」「Zが影響するすべて」)を担います。定石はこうです — ノードやチャンクを埋め込み、ベクトル検索で入口を見つけ、そこからグラフを走査してつながった文脈を引き込む。neo4j-graphrag のVectorCypherRetrieverがまさにこの形です。

そして最近のグラフDBの多く(Neo4j, Kùzu, Memgraph, Neptune Analytics, GraphDB, TopBraid)はベクトルインデックスを内蔵します。そのため別のベクトルDBが必ずしも要りません。埋め込みはグラフを構築するのにも使われます — 似たノードをつなぐ実体解決(entity resolution)がその例で、TopBraid EDG 8.0のベクトルDBやtxtaiのセマンティックグラフがそれを行います。

グラフを使うべきでないとき

正直な反対側の錘を置きます。問いが単一ホップの類似度で解けるなら(「Xに関する文書を探す」「このポリシーを要約して」)、普通のベクトルRAGのほうが単純で、安く、速く、十分です。グラフは抽出パイプライン、ストア、スキーマ、走査ロジックを足し — そのどれもが間違え得ます。

グラフが元を取るのは、次の4つのいずれかが必要なときだけです: 多段の推論、関係を意識した検索、コーパス全体のグローバルな統合、説明可能な出所の追跡。このうちどれが要るのか名指しできないなら、たぶんベクトルRAGが答えです。検索の基礎をまず固める話はプロダクションRAGパターンにまとめました。

もう一つ — ゴミのような抽出の上に建てたグラフは、グラフが無いより悪いです。構築の品質がすべてを左右します(構築編を参照)。

決定フロー

一枚に圧縮するとこうです。

1. 問いに関係が必要か?
   (多段、「XとYはどうつながるか」、コーパス全体の主題)
   いいえ -> 普通のベクトルRAG。ここで止まる。グラフを建てるな。
   はい   -> 続ける。

2. 形式的な意味が必要か?
   (論理推論、組織間で共有する語彙、標準・規制)
   はい   -> RDFスタック: Protege(OWL)で著述、Jena/GraphDBに保存、SPARQLで問い合わせ。
   いいえ -> プロパティグラフ (下記)。

3. グラフDBを選ぶ:
   ローカル / ノートブック / 単一ノード -> Kuzu (注: 2025年にリポジトリがアーカイブ、コミュニティフォーク)
   本番サーバー、最大のエコシステム     -> Neo4j
   リアルタイム / ストリーミング更新    -> Memgraph
   AWSのマネージド                      -> Amazon Neptune
   グラフ + 文書を一つのストアに        -> ArangoDB
   超大規模の並列ディープリンク分析     -> TigerGraph

4. グラフRAG層を選ぶ:
   「コーパス全体の主題」の統合         -> Microsoft GraphRAG (コストはLazyGraphRAGで)
   Neo4jにコミット、1st-partyが欲しい   -> neo4j-graphrag
   すでにフレームワークの中             -> LlamaIndex PropertyGraphIndex / LangChain
   持続するエージェントメモリ           -> Cognee
   軽量 / ローカル / トピック探索       -> txtai セマンティックグラフ

おわりに

地図であってピンではありません。ツールは揺れます — Kùzuが今年の証拠です。揺れないのは問いです。プロパティかRDFかは流行ではなく意味論の問いであり、グラフかベクトルかはハイプではなく関係の問いです。まずその二つに答えてから、ツールを選んでください。

これでシリーズの実用的な終点に着きました。なぜグラフRAGかで理由を、構築で建て方を、ドメインオントロジーでモデリングを、そしてこの記事でツールを扱いました。グラフが過剰なときのためのプロダクションRAGパターンを傍らに置けば、地図は十分です。

最も正直な最後の一行: 最良のグラフプロジェクトはたいてい、問いに答える最小のものであり — ときにそれはグラフが一切無いことです。

参考資料

コメント

まだコメントはありません。

ログインするとコメントできます