graph-engineering

グラフエンジニアリング

グラフエンジニアリングとは、エージェントが作業する構造を設計する分野であり、プロンプトを設計するものではありません。次の2つの側面があります。

1. ナレッジグラフ — エージェントが記憶する内容です。ノードはエンティティや事実を表し、エッジは時間情報と出典情報を伴う関係を表します。このファイルの9段階のパイプラインでは、LLM時代のエージェント向けに英訳・適応された内容を取り上げています。内容は、東南大学の大学院向けKG講座をもとにまとめられています （https://github.com/npubird/KnowledgeGraphCourse、Peng Wang教授）。
2. タスクグラフ — エージェントの作業方法です。ノードはジョブ、エッジは実行上の依存関係を表します。並列ファンアウト、個別の検証コンテキスト、停止ルール、人間による承認ゲートなどがあります。メモリの構築ではなく、エージェントのオーケストレーションが目的のリクエストでは、references/task-graphs.mdを参照してください。

基本となる考え方は、ナレッジグラフはトリプルの寄せ集めではなく、スキーマを備えたプロダクトだということです。品質はパイプラインの順序によって決まります。抽出の前にドメインをモデル化し、保存の前に統合し、各段階で評価します。

学習モード

ユーザーがグラフエンジニアリングを構築するのではなく学びたい場合は、実際に教えてください。単に実行するだけではいけません。ルールは次のとおりです。

1. 各段階をユーザー自身のドメインに結び付けます。実際のプロジェクトまたはデータセットを1つ尋ね、すべての段階を通じて一貫した例として使います。
2. 教えながら、視覚的な成果物を作成します。 この分野の概念は形で表せるので、見せましょう。主要な概念ごとに、ユーザーが手元に残せる小さな図を作成します。mermaid図（パイプラインとタスクグラフにはフローチャート、オントロジーの例とサブグラフにはgraph LR）か、インタラクティブにすると役立つ場合は単体で完結するHTMLページを使います。最低限、9段階のパイプライン、ユーザーのドメインから作った3種類のオントロジー、実際のサンプルから抽出したサブグラフ（ノード5～10個）、ユーザー自身のジョブをノードとして使ったダイヤモンドパターンを作成します。
3. パイプラインの順序に沿って、各やりとりで1段階ずつ教えます。次の段階に進む前に、毎回簡単な演習（「あなたのプロジェクトについて、コンピテンシークエスチョンを3つ書いてください」など）を行います。
4. レッスンで作成したものをまとめて、最初の実プロジェクト用のスターターontology.yamlと、図示したタスクグラフを作成して締めくくります。

9 段階のパイプライン

各段階を順番に実行してください。小規模なプロジェクトでは、段階 4〜6 を 1 回の抽出処理にまとめられますが、段階 3（オントロジー）と段階 8（融合）は決して省略しないでください。実世界のグラフで問題が起きるのは、まさにこの段階だからです。

1. スコープと価値の検証 — よりシンプルな構造よりもグラフが適しているかを確認します。「Y を使ったプロジェクトで、X と一緒に働いたのは誰か」のような複数ホップのクエリがある場合、エンティティが複数のドキュメントに繰り返し登場する場合、または関係そのものがデータである場合は、グラフが有効です。検索が 1 ホップで済むなら、テーブルを使って終了してください。

2. 知識表現の選択 — 事実をどのように表現するかを選択します。プロパティグラフ（Neo4j 形式、実用上のデフォルト）、RDF トリプル（相互運用性／標準）、または JSON／SQLite の単純な型付きエッジ（小規模向け）から選びます。時間と来歴をすべての事実にどのように付与するかも、この時点で決めてください。

3. オントロジーのモデリング — 抽出の前に、エンティティ型、関係型（domain／range を含む）、属性を定義します。まずは最小限から始めます。エンティティ型は 5〜15 種類、関係型は 10〜30 種類です。このコースで学ぶルールは 2 つです。すべての関係に正確な動詞名を付けること（RELATED_TO ではなく ACQUIRED）、そして 2 つの型が常に一緒にクエリされるなら統合することです。 詳細と実例：references/modeling.md

4. エンティティ抽出（NER） — ソースから型付きエンティティを抽出します。手法の選択肢は、クローズドな語彙には正確なルール／辞書を使い、オープンテキストにはプロンプトにオントロジーを含めて LLM で抽出することです。来歴を確保するため、必ずスパンとソースへのポインターを付けて抽出してください。

5. 関係抽出 — 認識済みエンティティ間の型付きエッジを抽出します。domain／range のチェックを行い、LLM が使用できる関係をオントロジーの関係リストに制限します。端点の型に互換性がないエッジは拒否します。この検証を 1 つ行うだけで、幻覚による構造の大半を取り除けます。

6. イベント抽出 — 動的なドメイン（ニュース、ログ、トランザクション）では、静的なエッジだけで表現するのではなく、イベントを第一級ノード（トリガー＋型付き引数＋時間）として抽出します。 段階 4〜6 の抽出手法、プロンプトパターン、失敗要因： references/extraction.md

7. 品質ゲート — 融合の前にサンプルを抽出して評価します。エンティティの適合率（抽出されたエンティティは実在し、正しく型付けされていますか？）、関係の適合率（ソース文は実際にそのエッジを示していますか？）を確認します。出力を修正するのではなく、プロンプト／ルールを修正してから再実行します。先に進む前に、50 件のサンプルで適合率 90% 以上を目指してください。再実行を重ねれば再現率は向上しますが、適合率が低いとグラフに取り返しのつかない悪影響が及びます。

8. ナレッジ融合 — ソース内およびソース間の重複を統合します。同じ実世界のエンティティが異なる表記で登場する場合（「SEU」＝「Southeast University」＝「东南大学」）が該当します。ブロッキング＋マッチング＋統合ポリシーを使用します。これを省略することが、役に立たないグラフが生まれる最大の原因です。 マッチング戦略：references/fusion-and-llm.md

9. LLM への提供（KG × LLM） — エージェントにとってグラフを有用にします。GraphRAG による検索（サブグラフ → コンテキスト）、グラフをメモリとして使用する方法（エージェントが段階 4〜8 を通じて事実を書き戻す）、パスを対象にした LLM による推論などがあります。パターンと注意点： references/fusion-and-llm.md

作業ルール

• 常にスキーマを先に定義します。 オントロジーなしで抽出すると、実際には矢印付きのワードクラウドにすぎない「グラフ」ができあがります。ユーザーがスキーマ設計に難色を示した場合は、サンプルドキュメント 3 件から最小限の 5 型オントロジーを構築し、承認を求めてください。
• すべての事実に来歴を付与します。 各ノード／エッジに source、extracted_at、信頼度を保存します。これは必須です。融合（段階 8）にも信頼性にも不可欠です。
• 一括処理より段階的な処理を優先します。 規模を拡大する前に、10 件のドキュメントからなるパイロットを 9 段階すべてに通します。パイロットを実施すれば、コストの 1% でオントロジーの不足を明らかにできます。
• LLM による抽出はパイプラインではなく、段階の一部を担う仕組みです。 LLM は段階 4〜6 に組み込みます。出力をナレッジグラフにするのは、その周囲にあるスキーマ、検証、融合です。

参考ファイル

• references/curriculum.md — 講義ごとの要約と、元の中国語スライド資料へのリンクを含む、コース全体の翻訳版カリキュラムです。 ユーザーが理論を詳しく知りたい場合、学術的な背景を知りたい場合、または元の資料を見たい場合に参照してください。
• references/modeling.md — 知識表現とオントロジーエンジニアリング（コースの講義 2～3）。ステージ 2～3 で参照してください。
• references/extraction.md — ルールから LLM のプロンプト作成までのエンティティ、関係、イベントの抽出（講義 4～7）。ステージ 4～7 で参照してください。
• references/fusion-and-llm.md — 知識融合と KG × LLM の統合（講義 8～9）。ステージ 8～9 で参照してください。

クレジット

東南大学「知識グラフ」大学院コース（Southeast University の知識グラフ大学院コース）、Peng Wang 教授の内容を要約・翻訳したものです — https://github.com/npubird/KnowledgeGraphCourse. 講義 PDF はすべて中国語です。このスキルは、AI エージェントのワークフロー向けに独自に英語で要約・翻案したものです。