> [!abstract] 概要（abstract 日本語訳） > 大規模企業ではオンコールエンジニア（OCE）がサービスの可用性と信頼性の確保に不可欠である。しかしインシデントが増量・複雑化する中、従来の手動オンコールプロセスはますます不十分になっている。大規模言語モデル（LLM）の近年の進歩は推論とマルチエージェント協調における顕著な能力を示しており、自動化に向けた新たな機会をもたらす。我々は OncallX を提案する。これは実世界の産業シナリオ向けに設計されたエンド・ツー・エンドの自動化オンコールシステムであり、LLM とマルチエージェント協調を統合してインテリジェントかつ効率的なインシデント管理を実現する。OncallX はまず外部知識ベースと多ターン対話インタラクションを活用してユーザークエリを強化する。続いて複数の専門エージェントが木探索ベースのメカニズムを通じて協調し、効果的な応答と解決策を生成する。インシデントを自動解決できない場合、OncallX はそれを最適なチームに正確に割り当てる。トップクラスのグローバル動画配信サービスプロバイダの実本番環境で実施した包括的な実験は、OncallX がインシデントに効率的に対応しチケットを正確にトリアージすることを示しており、自動化指標と人手評価の両方で既存手法を大幅に上回る。さらに OncallX は 2 か月間の本番デプロイに成功し、その間に平均インシデント対応時間をわずか 21 秒・平均トリアージ時間を 4 秒に大幅短縮するという、オペレーショナルエクセレンスの革新的な改善をもたらした。 ## 論文情報 - **タイトル**: LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation - **著者**: Ruowei Fu（南開大）, Yang Zhang（ByteDance）, Zeyu Che（南開大）, Xin Wu（ByteDance）, Zhenyu Zhong（南開大）, Zhiqiang Ren（ByteDance）, Shenglin Zhang（南開大、責任著者）, Feng Wang（ByteDance）, Yongqian Sun（南開大）, Xiaozhou Liu（ByteDance）, Kexin Liu（南開大）, Yu Zhang（ByteDance） - **所属**: Nankai University / ByteDance Inc. - **媒体**: ASE 2025（Automated Software Engineering） - **連絡先**: [email protected]（Shenglin Zhang） ## 概要 [[OncallX]] は、LLM を中核にマルチエージェント協調でオンコール業務を自動化するシステムである。対象は大規模企業のシステムテクノロジー＆エンジニアリング（STE）チームで、カーネル障害・仮想化問題・OS 関連インシデントを日次で大量に処理する。手動オンコールでは平均対応 0.58 人日・トリアージ 200 秒かかっていたが、OncallX デプロイ後に対応 21 秒・トリアージ 4 秒まで短縮した。（Source: §V-E RQ4） ## 問題設定 **入力**: オンコールエンジニアに寄せられるユーザークエリ（短く曖昧な技術用語を含む）またはシステムアラートのインシデントチケット（タイトル・説明・優先度・ディスカッション等のフィールドを持つ）。 **出力**: (1) インシデント対応 — 正確で実行可能な解決策、(2) チケットトリアージ — 適切な担当チームへの割り当て。 **前提条件**: 動的に増減するチケットカテゴリを扱うため、追加の分類器訓練を不要とする fine-tuning-free 設計が要求される。 **データ**: 1,285 チケット（数ヶ月分）のうち 70 件をインシデント対応テストセット、8,662 チケットのうち 145 件をトリアージテストセットとして使用。 **3 つのコアチャレンジ**: - Challenge 1: 曖昧なオンコールクエリに対する LLM の理解強化 - Challenge 2: 複雑なインシデントへの LLM 応答精度の向上 - Challenge 3: LLM ベースのチケットトリアージの効率化と精度向上 ## 提案手法 **Figure 1: 人手オンコールワークフローとインシデントチケット例** ![[_attachments/Ruowei__OncallX_to_ASE_25/fig01-on-call-workflow.png]] (Figure 1. (a) 人手オンコールワークフロー: アラート/障害報告 → OCE 対応 → チームトリアージの 3 段階。(b) インシデントチケット例: 問題種別・説明・優先度・起票者・パラメータ・ディスカッションを記録。Source: §II-A) **Figure 3: OncallX フレームワーク全体像** ![[_attachments/Ruowei__OncallX_to_ASE_25/fig03-oncallx-framework.png]] (Figure 3. 左上から右下へ 3 モジュール: (1) ユーザー意図強化（ドメイン語抽出→知識検索→ClarifyAgent 多ターン対話）、(2) オンコール QA（OCEAgent が木探索プランナーとして専門エージェント群を協調）、(3) チケットトリアージ（KG で候補カテゴリを絞り TriageAgent が割り当て）。Source: §IV-A) ### アーキテクチャ: 3 モジュール構成 **Module 1: ユーザー意図強化モジュール（ClarifyAgent）** ドメイン語抽出 LLM がクエリから専門用語（"GWPAsan"・"kdump"・"clang11" 等）を抽出し、キュレートされた知識ベース（公式ドキュメント・過去インシデント報告・専門家知見）を RAG で参照して入力を補強する。続いて ClarifyAgent が意図不明確と判断した場合に多ターン対話でユーザーに追加情報を引き出す。解決済みチケットが自動アーカイブされることで知識ベースは動的に更新される。（Source: §IV-B） **Module 2: オンコール QA モジュール（OCEAgent + 専門エージェント群）** OCEAgent が中央プランナーとして機能し、KernelAgent・VirtualAgent・CompileAgent・NetworkAgent・OSAgent・FirmwareAgent 等のドメイン専門エージェントを木探索で協調させる。各エージェントはドメインツール（コンパイル知識ベース参照・IP クエリツール等）を装備し、ロール記述で動作境界を定義。木探索の 3 ステップは Step1 Planning・Step2 Execution・Step3 Integration からなり、反射（リフレクション）機構により行き詰まりで以前の意思決定ポイントへバックトラックする。探索空間は事前定義の深さ・幅制限で有界とする。（Source: §IV-C） **Module 3: チケットトリアージモジュール（TriageAgent + KG）** 2 段階の戦略でノイズとカテゴリ空間爆発に対処する。(a) **ノイズ除去**: TriageAgent が生のディスカッションを LLM で要約し、タイトル + 要約をトリアージ入力とする。(b) **知識グラフ（KG）**: 過去チケットから LLM が エンティティ（"jemalloc"・"velinux" 等）と関係（"belongs to"・"occurs"・"leads to"）を抽出し Neo4j に保存。オンライン時にエンティティを KG でクエリして候補カテゴリを頻度順に top-N に絞る。(c) **多ラウンドトリアージ**: Eq.1 で候補セット推論 → Eq.2 でリフレクション → Eq.3 で KG 不完全時の全カテゴリ参照。（Source: §IV-D） **Figure 5: KG 構築フレームワーク** ![[_attachments/Ruowei__OncallX_to_ASE_25/fig05-kg-construction.png]] (Figure 5. Processed Ticket → LLM（エンティティ抽出 + 関係生成）→ KG 構築 → Knowledge Graph（Neo4j）の処理フロー。ラベルインフォームドプロンプティングと few-shot 設計でエンティティ−関係の品質を向上。Source: §IV-D) ### アルゴリズム詳細 - **ドメイン語抽出**: LLM でクエリから技術用語を特定し、知識ベースを targeted search で参照（RAG）。 - **ClarifyAgent プロンプト**: 「不完全なら追加質問を行え」という context-aware 指示。 - **OCEAgent プロンプト**: 「失敗した場合は give up して再スタートせよ」という reflection-oriented 指示。 - **KG エンティティ抽出**: ラベルインフォームドプロンプティング（チケットカテゴリラベルをウィークスーパービジョン信号として使用）。 - **Few-shot KG 抽出**: 例示（例: RapidJSON → "belongs to" → Compilation/C++）によりトリプル形式を学習。 - **候補スコアリング**: KG 内でエンティティと関連するカテゴリを頻度でランク付け、top-N を最終候補とする。 ## 新規性 **既存手法の課題**: - 個別 LLM: ドメイン固有知識不足・複雑推論限界・コンテキスト管理欠如 - ReAct（単一エージェント）: ツール呼び出しはできるが専門知識の役割分担なし - DeepCT / DeepTriage / COMET: チケットトリアージに特化し、インシデント対応を含むエンド・ツー・エンド設計なし。DeepCT はディスカッションの高ノイズで Attention 機構が歪む。COMET はキーワード類似度に依存し多様なディスカッションの表現差に対応困難。 **OncallX の解決**: - fine-tuning-free: 追加モデル訓練不要でカテゴリ変化に対応 - 知識グラフ制約: LLM のカテゴリ空間を KG で絞り推論複雑度を削減 - ハルシネーション対策: KG バインド + リフレクション + 多ラウンドトリアージの組み合わせ 著者らによれば、OncallX は「マルチエージェント協調フレームワークを中心に組み立てた最初の包括的オンコールシステム」である。（Source: §I Contribution (1)） ## 実験設定 - **ハードウェア**: NVIDIA A6000 GPU × 1 - **バックボーン LLM**: gpt-3.5-turbo-16k / doubao-1.5-pro-32k - **インシデント対応テストセット**: 70 チケット（優先度 low:medium:high = 51:15:4、難易度 simple:medium:complex = 1:3:3） - **トリアージテストセット**: 145 チケット（学習用 8,517 チケット、Q1 2023〜Q4 2024） - **ベースライン（インシデント対応）**: GPT-3.5-Direct / GPT-3.5-ReAct / Doubao-Direct / Doubao-ReAct - **ベースライン（トリアージ）**: MART / LGBM / InvertedIndex / SI / DNN / DeepTriage / DeepCT / COMET - **評価指標（対応）**: 人手評価（Accuracy/Readability 3段階）・GPT-4 評価・Pass Rate - **評価指標（トリアージ）**: ACC@1・ACC@3 ## 実験結果 **Table I: インシデント対応比較** | モデル | 手法 | Pass Rate | Avg.Tokens | |--------|------|-----------|------------| | GPT-3.5 | Direct | 72.46% | 0.30K | | GPT-3.5 | ReAct | 71.01% | 9.00K | | GPT-3.5 | **OncallX** | **78.26%** | 12.51K | | Doubao | Direct | 73.91% | 0.92K | | Doubao | ReAct | 69.57% | 10.57K | | Doubao | **OncallX** | **75.36%** | 9.75K | GPT-3.5-OncallX は Direct 比 +5.8pt、ReAct 比 +7.25pt を達成。人手評価では OncallX（Doubao）が Direct に対し 83.87% 勝率。（Source: Table I, §V-B） **Table II: チケットトリアージ比較** | 手法 | ACC@1 | ACC@3 | |------|-------|-------| | MART | 0.372 | 0.710 | | DeepTriage | 0.359 | 0.641 | | COMET | 0.262 | 0.455 | | **OncallX** | **0.652** | **0.774** | SOTA 比 ACC@1 +28.0pt・ACC@3 +6.4pt。（Source: Table II, §V-C） **Table III: アブレーション（インシデント対応）** | 手法 | Pass Rate | Avg.Tokens | |------|-----------|------------| | OncallX | 75.36% | 9.75K | | − User Intent Enhancement | 65.22% | 19.26K | | − Multi-Agent & Tree-Planner | 62.32% | 10.56K | 意図強化削除で Pass Rate −10.14pt かつトークン倍増。マルチエージェント&木プランナー削除で −13.04pt。（Source: Table III, §V-D-1） **Table IV: アブレーション（チケットトリアージ）** | 手法 | ACC@1 | ACC@3 | |------|-------|-------| | TriageAgent | 0.652 | 0.774 | | − Noise Reduction | 0.579 | 0.729 | | − KG | 0.443 | 0.752 | | − Multi-Round Triage | 0.563 | 0.714 | KG 除去が最大の性能低下（−20.9pt）。（Source: Table IV, §V-D-2） **本番効率（RQ4）**: 人手: 平均 0.58 人日（≈ 4.6 時間）の対応 + 200 秒のトリアージ → OncallX: 21 秒の対応 + 4 秒のトリアージ。789 倍の対応高速化・50 倍のトリアージ高速化。（Source: §V-E） ## 考察 **Figure 8: ケーススタディ ワークフロー例** ![[_attachments/Ruowei__OncallX_to_ASE_25/fig08-case-study-workflow.png]] (Figure 8. ipmitool 障害事例: ドメイン語抽出（ipmitool の説明を KB から取得）→ ClarifyAgent 対話 → OCEAgent が FirmwareAgent を選択 → `get_firmwareknow` ツール呼び出し → Observation（デフォルトでインバンドアクセス無効）→ 最終回答。Source: §V-F) **強み**: - fine-tuning-free 設計により動的なカテゴリ変化に対応可能 - 知識ベース + KG の二重バインドでハルシネーションを抑制 - 木探索 + リフレクションで複雑インシデントでも探索を諦めない設計 **弱点・課題**: 1. 自律エージェントの過大評価: 応答精度は外部知識ベースとツール統合の品質に強く依存する 2. 計算オーバーヘッド: 多ターン通信がレイテンシ・コストを増加させる 3. コンテキスト推論限界: ターン数増加に伴い LLM のコンテキスト保持能力が低下し、「会話履歴圧縮機構」が未解決課題として残る（Source: §VI-A） **外的妥当性の制約**: ByteDance の STE チームのみで評価。他組織・他業務ドメインへの汎化は未検証。ただし論文著者は plug-and-play フレームワーク設計により転移可能と主張する。（Source: §VI-B） ## 強み / 弱点・課題 **Strengths** - 産業規模の実本番デプロイ（2 か月間）による定量的検証 - エンド・ツー・エンド設計でオンコールライフサイクル全体をカバー - fine-tuning-free で動的なカテゴリ変化に対応 **Weaknesses / Limitations** - STE チームのみの評価（単一組織・単一業務ドメイン） - コンテキスト推論限界は LLM の根本制約であり設計で回避不能 - 知識ベース品質への強依存は外部維持コストを生む