# 知識グラフ ## 定義 知識グラフ(Knowledge Graph, KG)は、実体(エンティティ)と実体間の関係をトリプル(主語・述語・目的語)として有向グラフで表現する知識表現形式である。ノードが実体に、有向エッジが関係に対応し、複雑なドメイン知識を機械可読な構造で統合できる。[[グラフニューラルネットワーク]] と組み合わせることで、グラフ構造の推論・補完・埋め込み学習が可能になる。 AIOps での応用では、分散システムのログ・メトリクス・トレースなど複数のオブザーバビリティデータを単一のグラフ構造に統合し、従来の単一モダリティ解析では捉えられなかったフィールド間・コンポーネント間の依存関係を活用した障害診断・根本原因分析を実現する点で注目される。 ## 横断的知見 ### ログ障害診断への適用 - **ログの複数フィールドを知識グラフで統合することで、単一フィールド手法では捉えられないフィールド間の関係が障害診断の精度向上に寄与する**: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph|LogKG]]([[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]], TSC 2023)は、ログのタイムスタンプ・ログレベル・IP・コンポーネント・タスクID・コンテンツという 6 種のフィールドをすべて知識グラフに統合する。従来の多くの手法(LogCluster 等)は非構造化コンテンツフィールドのみを対象とし、SLOGERT・LEKG 等の既存 KG 手法も構造化フィールドのセマンティクスを十分に活用していなかった。LogKG は RotatE による知識グラフ埋め込み(KGE)でマルチフィールド情報を連続ベクトル空間に統合し、CMCC データセットで精度 1.0 / Macro-F1 1.0、GAIA データセットで精度 0.98 / Macro-F1 0.99 を達成した。既存ベースラインに対して GAIA 精度 +26%・Macro-F1 +15% という大幅な改善を示す。(Source: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) - **KGE モデルの選択はログデータの特性を考慮する必要があり、自然言語ベースの埋め込みモデル(GloVe・Word2Vec)はログに不適である**: LogKG のアブレーション実験では、KGE を GloVe に置換すると GAIA データセットで Macro-F1 が 0.84 まで大幅に低下する。ログデータは自然言語と異なり繰り返しが多く文法規則に従わないため、文脈的語義を学習する言語モデルが苦手とする。RotatE はエンティティと関係を回転変換でモデル化する位相幾何学的アプローチで、ログの構造的パターンに適している。(Source: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) ### エンティティ抽出とアライメントの課題 - **ログからの知識グラフ構築には、1 テンプレートが複数イベントを含む問題と、異なる構文で同一セマンティクスを持つエンティティの統合という 2 つの固有の技術課題がある**: LogKG が定義する CH.1(エンティティ抽出: 1 テンプレートに複数イベント)・CH.2(エンティティアライメント: 異種構文・同一意味)は、一般的な自然言語処理での知識グラフ構築では顕在化しにくいログ固有の問題である。LogKG は CoreNLP による品詞タグ付けと OpenIE によるトリプル抽出を組み合わせ、さらに Sentence-BERT ベースのベクトル化 + OPTICS クラスタリングによるトリプルアライメントでこれらを解決する。言語モデル(MPNet・RoBERTa・MiniLM)やクラスタリングアルゴリズムを変えても最終診断精度が安定しており、アライメント選択に対する頑健性が実証された。(Source: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) ### 障害表現学習との組み合わせ - **KGE だけでは不十分で、障害に特化したログ選別(FOLR)との組み合わせで初めて高精度な障害表現が得られる**: LogKG の FOLR(Failure-Oriented Log Representation)は、障害発生時刻前後 20 分のログを収集し、全障害に頻出して障害種別を弁別しないノイズテンプレートを IFF(Inverse Failure Frequency)閾値でフィルタリングした上で、残りのテンプレートを TF-IFF 重み付き加重和で KGE ベクトルに集約する。FOLR なし(KGE のみ)のアブレーションでは Macro-F1 が 0.08 低下し、「ノイズログを除去してから KGE を適用する」という 2 段の組み合わせが重要だと示す。この「情報を絞ってから推論する」骨格は [[ログ解析]] の設計原理として共通する。(Source: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) ### テスト障害診断への適用 - **マルチソースログのヘテロジニアスな形式差を知識グラフの統合エンティティで吸収できる**: SynthoDiag([[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]], FSE 2024)は、実行ログ(半構造化テキスト)とトレースログ(スパン付き木構造)という異なるフォーマットを同一の知識グラフに統合する。3 種類のエンティティ——属性エンティティ(ログレベル・サービス名等の構造化属性)・パラメータエンティティ(変数部分)・ログエンティティ(コンテンツ原文)——の抽出と、意味類似度ベースのエンティティアライメント(BERT + クラスタリング)により、マルチソース間で同一情報が異なる形式で記録されている問題を解決する。LogKG がログの複数フィールドをグラフで統合するのに対し、SynthoDiag は複数ソースのログを統合するという点で、知識グラフによる統合の適用範囲が「フィールド間」から「ソース間」へと拡張されたことを示す。(Source: [[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]] §3.3) - **知識グラフ埋め込み(KGE)と事前学習言語モデルの組み合わせが異種ソース統合の有効な設計パターンとして確立しつつある**: LogKG が RotatE による KGE と Sentence-BERT の組み合わせで有効性を示し、SynthoDiag が MRotate + Sentence-BERT の組み合わせで同じ設計パターンを採用する。2 つの独立した研究が同じ組み合わせパターン(KGE で構造的関係を捉え + BERT 系で意味的類似を捉える)に収束していることは、ログデータの知識グラフ埋め込み設計の有望な標準パターンとして示唆的。SynthoDiag のアブレーション(図 6c)でも KGE のみ・BERT のみより組み合わせが上回ることが確認された。(Source: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]], [[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]] §3.4, §4.3.3) ### 実務家による「学術的知識グラフ」との自覚的な切り分け - **オブザーバビリティ実務側は「知識グラフ」という語を意図的に避け、より狭い「ドメインの地図」を志向する**: [[AIサンドイッチアーキテクチャ]](*Observability Engineering* 2nd Edition, Chapter 17)の著者 Frank Chen は、オントロジーを説明する冒頭で「私が話しているのは学術者が使う知識グラフではない。組織とりわけオブザーバビリティデータの層に組み込む、ドメインの地図——核となるオブジェクト・関係・ルール——を定義することだ」と明示的に区別する。本ページが蓄積する LogKG・SynthoDiag は academia 発でトリプル・KGE を用いる本格的な知識グラフだが、Chen は同種の考え方(エンティティ+関係+ルール)を採用しつつも、形式的な知識グラフ基盤(RDF/OWL/グラフDB)を導入せず、4エンティティ・3不変条件という極小のスキーマで済ませる。両者は「エンティティと関係で構造化する」という発想を共有しながら、実装の重厚さでは対極に位置し、ドメインの複雑さとチームの成熟度に応じてスペクトラム上のどこを選ぶかという選択問題を可視化する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 17 Ontologies as a Shared Language for Humans and AI]], [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) > [!contradiction] [[Mark Burgess]] の知識管理論との緊張関係 > 本ページはログ障害診断における知識グラフ(KGE)の高い実用的成果(LogKG・SynthoDiag、精度 0.98〜1.0)を蓄積するが、[[Mark Burgess]] は "The Failure of Knowledge Management"(2023)で Topic Maps・RDF・OWL といった同系統の論理的知識表現の取り組みを「ほぼ失敗だった」と断じ、「論理は脆く妥協を許さないが、知識はすべて解釈の問題である」と主張する。両者は矛盾するわけではなく対象範囲が異なる可能性が高い——LogKG・SynthoDiag が扱うログという閉じた・構造の定まったドメインでのパターン照合と、Burgess が批判する人間が汎用的に「何かを知る」ための知識管理は異なる問題設定である。詳細は [[知識のリレーションシップモデル]] を参照。(Source: [[@2023__Medium__The Failure of Knowledge Management]]) ### 一般的なデータモデルとしてのトリプルストア/RDFとの関係 - **本ページが蓄積するAIOps知識グラフ(LogKG・SynthoDiagのKGE)は、DBMS教科書が形式化する「トリプルストア/RDF」という一般モデルの特殊化として位置づけられる**: [[グラフデータモデル]]([[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]])は、知識グラフを支える一般的なデータモデルとして*トリプルストア*((主語, 述語, 目的語)の3つ組でデータを表現するモデル、RDFに基づく実装にDatomic・AllegroGraph等がある)を定義する。LogKG・SynthoDiagはログの複数フィールドやマルチソースログを(実体, 関係, 実体)という構造に落とし込みKGE(RotatE)で埋め込むが、これは本質的にトリプル構造へのデータ変換とその埋め込み学習であり、DDIAが説明する一般的なグラフデータモデルの応用インスタンスとみなせる。DDIAはさらに「検索エンジンは知識グラフを使い、クロールで取得した事実やWikidataのような構造化データ源から組織・人物・場所などの実体間関係を記録する」と述べており、AIOpsのログ障害診断という閉じた・構造の定まったドメイン適用とは別に、知識グラフにはオープンなWeb規模の実体関係記録という応用系統が存在することを示す。両者は同じ理論的基盤(トリプル/RDF)を共有しつつ、応用範囲(閉じたログドメイン対 オープンなWeb由来の実体)が対照的であり、[[知識のリレーションシップモデル]]が論じる「スコープが狭いほど形式的知識表現が機能する」という仮説とも接続する——検索エンジンの汎用知識グラフより、LogKG・SynthoDiagのようなドメイン限定KGの方が高精度な数値目標(F1 0.98以上)を達成しやすいと解釈できる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Graph-Like Data Models", "Triple Stores and SPARQL", [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) - [一般的なデータモデルとしてのトリプルストア/RDFとの関係] 材料科学における合成手順の構造化において、国際標準 PROV-DM (W3C の来歴データモデル) に準拠した PROV-JSONLD 表現を採用することで、複雑な合流・分岐を伴う手順を有向非巡回グラフ(DAG)として機械可読にモデル化できる。閉じたログ解析(LogKG・SynthoDiag)や Web 規模の汎用エンティティ関係記録に加え、実験科学の手順・因果連鎖を標準セマンティクスで統合するデータセット MatPROV (2,367 手順) が構築され、推論モデル (o4-mini) を用いたグラフ抽出で構造 F1 0.835 が実証された。(Source: [[@2025__arXiv__MatPROV - A Provenance Graph Dataset of Material Synthesis Extracted from Scientific Literature]]) - **クラウド文脈知識グラフと LLM の協調による DSL 生成(text-to-PromQL)**: クラウドネイティブ環境において、ノード・サービス・Pod・API などのコンポーネントエンティティとメトリクス・ラベル・ラベル値エンティティを相互に結ぶシステム文脈知識グラフを構築し、質問文から抽出した関係パス(Cypher クエリ変換)と BM25/ベクトル検索を組み合わせることで、LLM の文脈長制約を超えずに高精度(Recall 0.908)で必要な推論パスを絞り込める。(Source: [[@2026__TOSEM__PromCopilot - Simplifying Prometheus Metric Querying in Cloud Native Online Service Systems via Large Language Models]]) ## 未解決の問い - **形式的データモデルと応用実装の対応関係**: LogKG・SynthoDiagのようなAIOps知識グラフは、実装上トリプルストア/RDFの標準ツール(Apache Jena等)や標準クエリ言語(SPARQL)を使っているのか、それとも論文固有の独自中間表現を持つのか——両論文には明記がなく、DDIAが説明する一般モデルとの実装レベルでの対応関係は未検証。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]]) - **ログ知識グラフの動的更新**: LogKG の KG はオフライン訓練時に構築され、新規ログテンプレートが出現した際の動的 KG 拡張の方法が課題として残る。ログシステムのバージョンアップやアーキテクチャ変更に伴うテンプレートのドリフトへの追従はどこまで自動化できるか。(Source: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) - **マルチモーダル統合への拡張**: LogKG はログのみを扱い、メトリクス・分散トレーシングとの統合は将来課題とされる。知識グラフがログ、メトリクス、トレースを単一のグラフ構造で表現できれば、モダリティ間の因果関係も捉えられるが、異種データの統合スキーマ設計と KGE の学習効率が問題になる。[[根本原因分析]] における「ログ単一モダリティの深掘り対マルチモーダル横断」の対比とも接続する。(Source: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) - **KGE モデルの選択基準**: ログデータに RotatE が有効だと示したが、異なるシステム(データセンターファブリック・クラウドネイティブ・組み込みシステム等)でも同じ結論が成り立つか。ログの繰り返し率・フィールド種別・テンプレート数などのデータ特性とモデル選択の関係は体系化されていない。 - **事前知識の自動化**: LogM のような事前知識を要する高精度手法との比較が LogKG では行われていない。知識グラフに事前ドメイン知識(障害モード・システム依存関係)を組み込む場合と、データ駆動で純粋にログから学習する場合で、ラベリングコストと診断精度のトレードオフはどう変わるか。 - **科学実験プロセスの来歴グラフと障害因果グラフの推論共通基盤**: PROV-DM 準拠の材料合成来歴グラフと、AIOps における障害伝播因果グラフ(システムコンポーネント・ログ・メトリクス)は、いずれも有向グラフとしての依存・因果関係を表現する。これら異なるドメインの構造化グラフに対して、共通のグラフニューラルネットワーク(GNN)や知識グラフ埋め込み(KGE)手法を用いた予測・計画モデルの転移可能性は存在するか。(Source: [[@2025__arXiv__MatPROV - A Provenance Graph Dataset of Material Synthesis Extracted from Scientific Literature]]) - 知識グラフ上の関係パス抽出において、LLM が存在しない関係やエンティティを抽出する幻覚(Hallucination)エラーを抑止するために、オントロジー制約付きデコーディングやスキーマ文脈の動的プルーニングは有効か? ## 関連 - ソース: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]] / [[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 17 Ontologies as a Shared Language for Humans and AI]] / [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] / [[@2025__arXiv__MatPROV - A Provenance Graph Dataset of Material Synthesis Extracted from Scientific Literature]] / [[@2026__TOSEM__PromCopilot - Simplifying Prometheus Metric Querying in Cloud Native Online Service Systems via Large Language Models]] - 概念: [[ログ解析]] / [[根本原因分析]] / [[グラフニューラルネットワーク]] / [[AIOps]] / [[異常検知]] / [[テスト障害診断]] / [[ログベース障害診断]] / [[AIサンドイッチアーキテクチャ]] / [[グラフデータモデル]] - エンティティ: [[Yicheng Sui]] / [[Shenglin Zhang]] / [[Dan Pei]] / [[Nankai University]] / [[Tsinghua University]] / [[Frank Chen]] / [[Hirofumi Tsuruta]] / [[Masaya Kumagai]] ## 出典 - [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]](§3 提案手法, §4 実験, §5 本番展開) - [[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]](§3.3 知識グラフ構築, §3.4 ケース埋め込み, §4.3.3 アブレーション) - [[@2026__OReilly__Observability Engineering 2E - Chapter 17 Ontologies as a Shared Language for Humans and AI]]("Ontologies and Their Role in Observability") - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]]("Graph-Like Data Models", "Triple Stores and SPARQL") - [[@2025__arXiv__MatPROV - A Provenance Graph Dataset of Material Synthesis Extracted from Scientific Literature]](PROV-DM準拠の材料合成来歴グラフデータセット MatPROV と LLM 抽出評価)