kg-gen 評価: 任意のテキストから知識グラフを抽出する Python ライブラリ
[NeurIPS '25] Knowledge Graph Generation from Any Text
ひと目でわかる
- これは何？
- kg-gen は LiteLLM 経由で任意のモデルを呼び出し、平文や会話ログからエンティティと関係を抽出する。チャンク処理とクラスタリングで大規模テキストにも対応するが、抽出精度はモデルとプロンプトに依存する。
- 誰に向いている？
- RAG 用のグラフ構築や合成データ生成を目的とし、モデルを自分で選べる点を重視するチームには向く。逆に、ライセンスが未記載である点を看過できない場合や、抽出結果の再現性を厳密に保証したい用途には向かない。
- 商用利用できる？
- 許可なしにはできません。GitHub はこのリポジトリにライセンスファイルを見つけていません。ライセンスがなければ、原則としてすべての権利が留保され、コードを読むことはできても再利用はできません。使う前に README を確認するか、作者に問い合わせてください。
- 今もメンテナンスされている？
- されています。最後のコミットは 175 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
kg-gen が埋める隙間: テキストをグラフ構造に変換する工程
平文から知識グラフを作る作業は、これまでエンティティ抽出器と関係抽出器を別々に用意し、その出力を突き合わせる工程が多かった。kg-gen はこの工程を generate メソッド一発にまとめる。README が挙げる用途は RAG の補助、モデル訓練・テスト用の合成グラフデータ、テキストの構造化、そしてソーステキスト内の概念間の関係分析である。対象読者は、LLM を使ってグラフを組み立てたいが、抽出パイプラインの実装に時間を割きたくない Python 開発者だ。会話形式のメッセージ配列をそのまま渡せる点は、チャットログの解析で効く。
抽出の実体: LiteLLM と DSPy の役割分担
kg-gen 自身はモデルを持たない。モデル呼び出しは LiteLLM が経由し、構造化出力の生成には DSPy を使うと README は説明している。つまりグラフの品質は、選んだモデルと DSPy 側のプロンプトに委ねられる。モデル文字列は LiteLLM の形式に従い、README の例では openai/gpt-5、gemini/gemini-2.5-flash、ollama_chat/deepseek-r1:14b が示されている。ローカルモデルを指定すれば API キーなしで動かせる。base_url を渡せば独自の API エンドポイントも指定できる。この設計の帰結として、kg-gen は抽出アルゴリズムそのものを提供しているのではなく、抽出の手順と後処理を提供していると理解したほうが正確だ。
チャンクとクラスタリング: 長文と表記ゆれへの対処
長いテキストは chunk_size で分割して処理する。README の例では chunk_size=5000 を指定している。分割すると同じ概念が別々のチャンクで別表記として抽出されるため、cluster=True を渡すとエンティティとエッジをまとめる。README の出力例では、AI と artificial intelligence、ML と machine learning、NN と neural nets がそれぞれ一つのクラスタに統合され、エッジ側も is type of と is a kind of のような表記ゆれがまとめられている。ここで注意したいのは、クラスタリングが別名の統合であって、矛盾する関係の解消ではないことだ。同じチャンク境界をまたいだ関係が落ちる可能性については、README に記述がない。
複数グラフの集約と可視化
aggregate メソッドは複数のグラフを一つにまとめる。README の例では、Linda と Joe の関係を含むテキストと、Joseph を Joe の別名として扱うテキストを別々に処理し、その後 aggregate で統合し、cluster で Joe と Joseph を同一エンティティに寄せている。この二段構えの設計は、文書を分割して並列に処理したい場合に都合がよい。可視化は KGGen.visualize(graph, output_path, open_in_browser=True) で行い、リポジトリのテストを実行すると tests/test_basic.html が生成される。ただし可視化は確認用の出力であり、グラフの正しさを検証する仕組みではない。
導入コマンドと設定キー
パッケージとして使う場合は pip install kg-gen を実行し、from kg_gen import KGGen でインポートする。KGGen の初期化では model、temperature、api_key を指定でき、README の例では model="openai/gpt-4o"、temperature=0.0 が既定値として示されている。api_key は環境変数かローカルモデル利用時には省略できる。リポジトリから開発用に入れる場合はクローン後に pip install -e '.[dev]' を実行し、python tests/test_basic.py で動作確認する。MCP サーバーとして使う場合は pip install kg-gen の後に kggen mcp を実行する。MCP は Claude Desktop や独自の MCP クライアントから利用できると README は説明している。
制約と向かないケース
第一に、ライセンスがリポジトリ情報から確認できない。採用判断の前に必ずリポジトリのライセンス表記を確認する必要がある。第二に、抽出結果はモデル依存であり、temperature=0.0 を指定しても完全な再現性が保証されるわけではない。同じテキストを再処理したときの差分を検証する手段は README に示されていない。第三に、クラスタリングは表記ゆれの統合であり、誤った統合を防ぐ仕組みは記述されていない。第四に、チャンク分割を跨ぐ関係の扱いが不明瞭である。大量の文書を一括処理して厳密なグラフを得たい用途よりも、まず構造の概観を得たい用途のほうが現実的だ。
代替手段との比較: ルールベース抽出との違い
spaCy のようなルールベースの固有表現抽出器と依存関係解析を組み合わせる方法は、モデル呼び出しが不要で、決定的な出力が得られ、ライセンスも明示されている。ただし抽出できる関係は事前に定義したパターンに限られ、README の例にある is brother of や is subset of のような多様な関係表現を網羅するには辞書と規則を書き続ける必要がある。kg-gen はこの規則整備を LLM に置き換える。代償は、モデルのコスト、レイテンシ、そして出力の非決定性だ。規則で書ける範囲が明確なドメインならルールベースのほうが安く安定する。逆に、関係の種類が多く事前に列挙できないテキストを扱うなら kg-gen のほうが現実的である。
保守コストとライセンスの確認事項
依存先は LiteLLM と DSPy であり、どちらも活発に更新される。LiteLLM のプロバイダ形式や DSPy の API が変われば、kg-gen 側の更新を待つか自分で追随する必要がある。モデル名を固定している場合、プロバイダ側のモデル廃止がそのまま動作不良につながる。ライセンスについては、リポジトリ情報に記載がないため、pip install kg-gen で導入する前に PyPI とリポジトリの両方で確認することを勧める。ここでは法的助言はできない。使用モデルのプロバイダ規約も別途確認が必要だ。
編集部の結論
RAG 用のグラフ構築や合成データ生成を目的とし、モデルを自分で選べる点を重視するチームには向く。逆に、ライセンスが未記載である点を看過できない場合や、抽出結果の再現性を厳密に保証したい用途には向かない。導入前に確認すべきは、リポジトリのライセンス表記、使用モデルのプロバイダ規約、そして tests/test_basic.py を自分の環境で実行したときの出力が README の例と一致するかどうかである。
コミュニティノート