グラフベースRCA - yuuk1's Digital Garden

# グラフベースRCA ## 定義グラフベース RCA(Graph-based Root Cause Analysis)は、システムコンポーネント間の依存関係・アラーム・イベントをグラフ G = (V, E) として表現し、グラフ上のスコアリングや伝播アルゴリズムによって根本原因となるコンポーネントを特定する手法群の総称。先行研究(MonitorRank, CloudRanger, AutoMAP 等)がサービス間の依存グラフ上でランダムウォークを用いてきた流れの一環として位置づけられる([[根本原因分析]] §横断的知見参照)。 Grano([[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]])はこの系譜において、**論理・物理の二層トポロジを統合した異常グラフ**と、**アラームの IDF スコアリング + 信頼度スコア伝播**という独自のアルゴリズムを提案した点で位置づけられる。 ## 横断的知見 - **論理・物理 2 層のトポロジ統合が偽陽性低減に寄与する**: Grano は Keyspace/Shard/Replica(論理)と Zone/Rack/Host/Pod(物理)の両階層をノードとして統合した異常グラフを構築することで、「どのコンポーネントが根本原因に近いか」を物理的なインフラ上での実際の影響伝播を踏まえて評価できるようにした。先行研究の多くがサービス依存グラフ上のサービスノードのみを扱うのに対し、物理層を含めることで「同一ホスト上の別コンポーネントが根本原因」という障害クラスへの対応が可能になる。(Source: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] §2.1, §3 Step 1) - **IDF(逆頻度)型アラームスコアリングが「全体的なノイズアラーム」の影響を構造的に下げる**: Grano の Alarm Edge Score は $s_{e(a,c)} = \sigma_{e(a,c)} \log(|C|/|C_a|)$ と定義され、多くのコンポーネントで発火しているアラームほど個々のコンポーネントへの関連度が低いと評価する。これは情報検索の TF-IDF と同じ直観をグラフの辺スコアリングに移植したものであり、広域的なスパイク(例: メンテナンス起因の大規模アラーム)が RCA スコアに与える影響を抑制する設計として機能する。(Source: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] §3 Step 2) - **MonitorRank・CloudRanger のランダムウォーク系と Grano のスコア伝播系は「グラフ上の拡散」という設計を共有しながら、伝播のダイナミクスが異なる**: MonitorRank(Kim+ SIGMETRICS 2013)は異常コンポーネントとの相関に比例した遷移確率のパーソナライズドランダムウォークを採用し、CloudRanger(Wang+ CCGrid 2018)は PC アルゴリズム因果グラフ + 二次ランダムウォークで拡張した。Grano はランダムウォークでなく決定論的なスコア伝播($p_c$ 計算)を採用しており、各ノードが「隣接ノードの平均スコアを γ 倍して受け取る」という乗算型伝播で連結成分末端(Zone・Keyspace)まで伝播させる。(Source: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] §3 Step 4; [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]]; [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]]) - **クラウドインフラ(物理デバイス層)向けグラフ RCA は「歴史的障害知識 + 現在の物理接続性」の時空間統合が鍵**: BSODiag(Duan+ arXiv 2025)は Alibaba Cloud クラウドインフラ(IDC・クラウドネットワーク・クラウドサーバーの 3 ドメイン)向けのイベント原因グラフ方式。Grano が「論理・物理 2 層トポロジ + IDF スコアリング」を採用したのに対し、BSODiag は (1) 歴史的障害データから Apriori で掘り出した **障害知識グラフ $G_f$**(信頼度スコア)と (2) CMDB から取得した **現在のデバイス物理接続性**(距離スコア)を組み合わせた時空間相関強度 $w_{ij} = \exp(p_{ij}.\text{conf}) \cdot \text{dist}(e_i, e_j)$ を辺重みとして定義する。これにより「過去に高頻度で共起した障害ペア」と「現在の物理的隣接性」の両方を根拠として根本原因を推定できる。アブレーション実験で両方の除去が性能低下を引き起こすことが確認された(図7)。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §IV-B〜C, §V-D) - **インスタンスレベル RCA には「サービス・インスタンス・ホスト」の 3 層異種グラフが必要で、サービスグラフのみでは不十分**: MicroIRC([[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]])の HWT(Heterogeneous Weighted Topology)は、サービスノード・インスタンスノード・ホストノードの 3 種を統合した重み付き異種グラフを構築し、パーソナライズドランダムウォークを実行する。既存手法(MicroRCA・CloudRanger・MonitorRank)がサービスノードのみのグラフ上でランダムウォークを行うのに対し、MicroIRC はインスタンスノードにサービスメトリクスとの最大相関値(MC)を辺重みとして付与し、同一サービスの複数インスタンス間を識別する。データセット C・D では HWT の使用により、インスタンス+ホストのみのトポロジ(データセット A・B)に対して大幅な精度向上を示した。(Source: [[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]] §3.2.2) - **パーソナライズドランダムウォーク + 機械学習モデルの 2 段階設計が新種障害への頑健性と精度を両立させる**: MicroIRC は (1) HWT 上のパーソナライズドランダムウォークで候補セットを生成し、(2) 候補セットと時系列メトリクスを GraphSage ベースの MetricSage に入力して最終スコアを算出するという 2 段構成を採用する。DejaVu(GAT による特徴適合+失敗依存グラフ)が新種障害 10% 混入で精度 -28% となるのに対し、MicroIRC は訓練障害種別割合を 0.4 まで減らしても安定した性能を維持する。ランダムウォーク段が「既存トポロジ構造の活用」、MetricSage 段が「リアルタイムメトリクスの学習」を担当することで、各段の役割分離が頑健性の源泉となっている。(Source: [[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]] §4.7) - **マルチアトリビュート・パーソナライズドランダムウォーク(MAPR)は「時刻優先度 × アウタージとの距離」で初期スコアを定義する**: BSODiag の MAPR は Grano の決定論的スコア伝播と MonitorRank の確率的ランダムウォークの中間的アプローチで、ノードのパーソナライズスコアを $u_i = \exp(-t) \cdot \text{dist}(e_i, e_o)$ で初期化する。$\exp(-t)$ は時刻が早い障害に高スコアを与え、$\text{dist}(e_i, e_o)$ はアウタージノードとの物理的近さを加味する。2 つのドメイン知識(「根本原因は早く発生する」「根本原因は影響範囲が広い」)をランダムウォーク初期条件に組み込んだ設計。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §IV-C2) - **グラフベース RCA の対象は「サービス間の依存グラフ」から「エージェント単体の意思決定グラフ」へも拡張されつつある**: 本ページが扱ってきた Grano・MonitorRank・CloudRanger・BSODiag・MicroIRC はいずれもマイクロサービス/クラウドインフラの**コンポーネント間**依存グラフ上で伝播やランダムウォークを行う。一方 [[エージェント修復]](AgentTether)の Critical Transition Graph は、単一 LLM エージェント**内部**の意思決定単位(Transition Unit)を時間的エッジと依存エッジ(共有アーティファクト・エラーシグネチャ)で結んだグラフであり、対象の粒度が「サービス」から「意思決定ステップ」に変わる。ただし設計原理は共通で、AgentTether も「原因は症状より上流にあり、直近性ヒューリスティックでは特定できない」という本ページ横断的知見の IDF スコアリング(広域アラームの過小評価防止)と同型の課題——「多数の後続ステップが 1 つの根本原因を共通の起点として持つ(many-to-many 伝播)」——に直面し、依存エッジに沿った逆方向の帰属探索で対処する。グラフ RCA という設計パターンが、インフラのトポロジからエージェントの内部軌跡まで、粒度を変えて繰り返し発見されていることを示す。(Source: [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] §II Q1, §III-C-1) - **LagRCA(FSE Companion '26)は物理トポロジとメトリクス相関の乖離をマルチラグ因果グラフのスケルトン/強度分離で解消する——Grano/BSODiag のスコア伝播型グラフとは異なる「グラフ構築」段階での対処**: 本ページの GRANO・BSODiag・MicroIRC はいずれもグラフ上のスコア伝播/ランダムウォークで根本原因を特定するのに対し、LagRCA は D1 の実インシデント分析で強相関ペア(|ρ|>0.7)の 56.12%が直接呼び出し関係を持たず、逆にトレース隣接ペアの 42.86%超が弱相関(|ρ|<0.3)に留まることを定量化した上で、離散スケルトン M(トポロジ整合性)と連続強度 W(時変相互作用)を A^(τ)=M^(τ)⊙W^(τ) として分離学習する。これは「グラフをどう伝播させるか」ではなく「グラフをどう構築するか」の段階でトポロジ―メトリクス乖離に対処する設計であり、本ページが集約してきたグラフベース RCA 手法群のもう一つの対処点(伝播アルゴリズム設計 vs グラフ構築設計)を示す。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]]) - **カーネルパニック RCA(LogSage)は「サービス依存グラフ」でも「物理インフラグラフ」でもない第 3 の粒度——障害ケース間の類似度グラフ——を扱い、GraphSAGE によるノード表現学習と能動学習を組み合わせる点で本ページの既存事例と異なる**: 本ページが扱ってきた GRANO・MonitorRank・CloudRanger・BSODiag・MicroIRC はいずれも「サービス」「デバイス」「インスタンス」というシステムコンポーネントをノードとするグラフ上で伝播・ランダムウォークを実行するのに対し、LogSage([[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]], FCS 2025)の GARCA モジュールは、**個々の障害ケース(カーネルパニックインシデント)**をノードとし、ログ専用ドメイン特化埋め込み([[BigLog]])のコサイン類似度が閾値 τ=0.6 を超える場合に辺を張るグラフを構築する。これは「システムのトポロジ」ではなく「過去の障害事例の類似性」をグラフ化する設計であり、GraphSAGE(K=2 層の近傍集約)でノード埋め込みを学習した後、分類器で根本原因カテゴリを予測する。新規ケースはオンライン推論時にコサイン類似度上位 k=10 の履歴ノードと接続され、履歴グラフの再学習なしに一時挿入される。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §3.2.1, §3.3) - **能動学習によるエントロピーベースのノードサンプリングは、本ページのグラフ RCA 手法群に「ラベリングコストを削減しながらグラフ表現を学習する」という新しい設計軸を加える**: LogSage の GARCA は、GRANO の IDF スコアリングや MicroIRC の HWT 構築のような「グラフ構造の設計」に注力するのとは異なる軸で、「どのノードにラベルを問い合わせるか」を軽量分類器の予測エントロピー $H(v)=-\sum_c p_v^{(c)}\log p_v^{(c)}$ に基づき能動的に選択する。初期 1% のランダムラベルから 5 ラウンドの能動学習で最終ラベル比率 6% に到達し性能がほぼ頭打ちになる。グラフ構築(誰と誰をつなぐか)とグラフ学習(どのノードにラベルを与えるか)という 2 つの設計軸が、本ページの既存手法(構造設計中心)と LogSage(ラベリング戦略中心)で異なる重心を持つことを示す。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] §3.2.2, §4.5.2) - **ネットワークドメインのグラフベース RCA は、経路尤度最大化(単純な経験的時間ラグ条件付き確率の積)という本ページ他手法にない推論様式を持ち込み、LagRCA のニューラルラグアテンションと対極の設計選択を示す**: 本ページの既存事例(GRANO・BSODiag・MicroIRC・LagRCA)はいずれもマイクロサービス/クラウドインフラのコンポーネント間グラフを対象とするが、[[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]](Chraim+, AWS)はクラウド**ネットワーク**層(185層×26カテゴリ)を対象とする初のネットワークドメイン事例である。根本原因推論では、候補 r から影響変数 y への全経路についてエッジごとの時間ラグ条件付き確率 P(A=1|B=1,Δt) の積(経路尤度)を計算し最大値でスコアリングする——これは GRANO の乗算型スコア伝播や MicroIRC のパーソナライズドランダムウォークとも異なる「経路そのものを尤度として評価する」設計であり、LagRCA が離散スケルトン×連続強度の低ランクニューラルパラメータ化でラグを学習する([[遅延認識時空間因果推論]])のに対し、本手法は1分ビンの経験的頻度カウントのみでラグ確率を推定する非パラメトリックな対極設計である。800件超の本番運用で完全一致率74.3%を達成しており、ニューラルモデルなしでも産業スケールのラグ対応 RCA が成立することを示す。(Source: [[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]], [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]]) - **同じ AWS 発のネットワークドメイン事例でも、経路尤度最大化(Chraim+)と古典グラフアルゴリズムのカスケード(Neptune Analytics)という 2 つの異なる設計が並立している**: [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]](NTT DOCOMO 実装事例)は、Amazon Neptune 上のネットワーク依存グラフに対し、グラフ分解(WCC/SCC)→クラスタリング(ラベルプロパゲーション)→中心性計算という 3 段カスケードで根本原因ノードをランク付けする。これは Chraim+ の時間ラグ条件付き確率の経路尤度最大化とも、GRANO の IDF スコア伝播とも異なる第 4 の設計軸——「汎用グラフアルゴリズムの直列カスケード」——であり、時間ラグや辺重みのドメイン知識を明示的にモデル化せず、グラフ構造(連結性・コミュニティ・中心性)のみから候補を絞り込む点で最もシンプルな部類に位置づけられる。加えて、この設計はエージェント型 AI(13 種の専門エージェント)による前後処理(既知パターン照合・KPI 異常相関・AST-GNN 予測ドリフト統合)と組み合わされており、グラフ分析単体でなく「グラフ分析結果をエージェントが解釈・検証する」ハイブリッド構成を取る。NTT DOCOMO の商用ネットワーク(トランスポート+4G/5G RAN)で 15 秒の MTTD を達成しており、Chraim+ の完全一致率 74.3%(800 件超)とは評価軸(検出速度 vs 特定精度)が異なるため直接比較はできないが、いずれも「ネットワークドメインのグラフ RCA はマイクロサービス RCA の手法をそのまま輸入せず、ドメイン固有の設計(時間ラグ・トポロジーカスケード)を要する」という共通の示唆を持つ。(Source: [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]], [[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]]) ## 未解決の問い - **Neptune Analytics のカスケード型(WCC/SCC→クラスタリング→中心性)と Chraim+ の経路尤度型、どちらがネットワークドメインで精度・レイテンシに優れるか未比較**: 両者とも AWS 発のネットワーク RCA だが、評価データセット・指標(MTTD vs 完全一致率)が異なり、同一データでの直接比較が存在しない。時間ラグを明示的にモデル化しないカスケード型が、Chraim+ が定量化した「強相関ペアの過半数が直接呼び出し関係を持たない」問題にどこまで頑健かは未検証。(Source: [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]], [[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]]) - **経験的頻度ベースの時間ラグ条件付き確率(Chraim+)とニューラル学習ベースのラグ条件付きアテンション(LagRCA)の精度比較は未実施**: 両手法とも「時間ラグを明示的にモデル化する」という設計目標を共有するが、対象ドメイン(ネットワーク vs マイクロサービス)・評価データ・学習有無が異なるため直接比較できない。同一データセットでの比較により、ラグモデリングにニューラル学習が必要か、単純な経験的頻度で十分かが明らかになる可能性がある。(Source: [[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]], [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]]) - **LogSage のケース類似度グラフ(GARCA)と本ページのシステムトポロジグラフ(GRANO・MicroIRC 等)を統合できるか**: LogSage は障害ケース間の類似度でグラフを構築するが、システムのサービス依存グラフや物理接続グラフの情報は使用しない。同一システムで発生した複数のカーネルパニックケースがサービス依存トポロジ上でも近接している場合、ケース類似度グラフとトポロジグラフの両方を統合すれば精度は向上するか、それとも 2 つのグラフ表現は独立に機能する方が良いか未検証である。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]]) - **LagRCA のスケルトン/強度分離とグラフ伝播型手法(GRANO・BSODiag のランダムウォーク)の組み合わせは未検証**: LagRCA が学習するマルチラグ因果グラフ A^(τ) を、GRANO の RCR スコア伝播や BSODiag の MAPR の入力グラフとして使った場合の効果は測定されていない。「グラフ構築の質」と「グラフ上の伝播アルゴリズムの質」を独立変数として組み合わせ評価する研究が必要。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]]) - Grano の RCR スコア伝播は「接続コンポーネントの平均スコアの γ 倍」という単純な集約を採用しているが、物理・論理の 2 層トポロジが混在するとき、層をまたぐ辺の重み付けはどう設計すべきか。異なる粒度の階層を同一グラフに混在させると「Zone ノードが常に高スコアを受け取る」という構造バイアスが生じないか。 - IDF スコアリングは「よく発火するアラームは重要度が低い」という仮定に依存するが、本番障害において広域的に発火するアラームが実際の根本原因を示すケース(例: 共通インフラ障害)は IDF によって過小評価される可能性がある。この「広域アラームが根本原因」というケースにどう対処するか。 - Grano は first-level の検知モデルとして密度ベースクラスタリング・加法分解予測・指数平滑化の 3 種を採用しているが、それぞれの検知精度がグラフ層の RCR 精度にどの程度影響するか。BARO が「異常検知時刻のずれへの非感度設計」で頑強性を得た([[根本原因分析]] §横断的知見)ことと対比して、Grano は第 1 段階の偽陽性をどこまで IDF とスコア伝播で吸収できるか。 - Grano は 2019 年時点でグラフデータベースに依存した設計をとるが、数千のホスト・数百万のメトリクスで異常グラフがどの程度まで拡大するか。グラフ構築と伝播アルゴリズムの計算コストのスケーラビリティは定量評価されていない。 - BSODiag の障害知識グラフは Apriori ベースの頻度マイニングに依存しているが、障害パターンが進化するクラウド環境で知識グラフを継続的に更新するための増分学習機構はどう設計するか。新規障害種別(初見パターン)は知識グラフにない場合どう扱うか。 - グラフ RCA の適用範囲をマイクロサービス(論理依存グラフ)とクラウドインフラ(物理接続グラフ)の両方にまたがって統合するとき、グラフの結合方法と伝播ルールをどう標準化するか。 - MicroIRC の HWT では MC(最大相関値)を辺重みとして使用するが、メトリクス間の相関と実際の障害因果関係の乖離(「相関 ≠ 因果」問題)が辺重みの歪みを生じさせるリスクをどう軽減するか。 - MicroIRC の MetricSage + パーソナライズドランダムウォーク 2 段構成は、大規模マイクロサービスシステムではランダムウォーク段が 90% 以上の処理時間を占めボトルネックになる。サービストポロジのスケールに合わせてランダムウォークの計算量を削減する方法はあるか(例: 部分グラフの事前剪定、近似ランダムウォーク)。 ## 関連 - 親概念: [[根本原因分析]] - 兄弟概念: [[サービス依存グラフ]] / [[因果推論ベースRCA]] / [[クラウドインフラ障害診断]] / [[エージェント修復]] / [[ログ解析]] - 関連ソース: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] / [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]] / [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]] / [[@2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Applications Automatically]] / [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] / [[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]] / [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] / [[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]] / [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]] - 関連 structures: `structures/` の MOC(例: AIOps.MOC.md) ## 出典 - [[@2025__AWS Database Blog__Beyond Correlation - Finding Root-Causes using a network digital twin graph and agentic AI]](Neptune Analytics のグラフ分解/クラスタリング/中心性カスケード、NTT DOCOMO 実装での 15 秒 MTTD) - [[@2026__arXiv__Graphical Causal Reasoning for Root Cause Analysis in Cloud Networks]](Chraim, Janzing, Evans, AWS — クラウドネットワーク層を対象とする初のグラフベース RCA 事例。経路尤度最大化(エッジ時間ラグ条件付き確率の積)による根本原因スコアリング) - [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]](§2 システムアーキテクチャ、§3 グラフベース RCR の 5 ステップ) - [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]](MonitorRank の伝播設計) - [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]](PC アルゴリズム + 二次ランダムウォーク) - [[@2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Applications Automatically]](3 種ランダムウォーク) - [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]](§IV-B 時空間障害相関、§IV-C MAPR・PPI) - [[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]](§3.2.2 HWT 構築、§3.2.3 パーソナライズドランダムウォーク + MetricSage 細分割、§4.5〜4.7 実験比較) - [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]](§3.2.1 GARCA グラフ構築(BigLog 埋め込み・コサイン類似度)、§3.2.2 GraphSAGE + 能動学習、§3.3 オンライン推論での一時ノード挿入)