## Memo
- ![[Pasted image 20250424133153.png]]
- 計画の実行は、エンジニアリングチームが持っている既存の特定のツールに依存する。 一般的に、ログ検索 やホストの再起動など、いくつかのツールがある。このような特殊なツールがなければ、LLexusはSSHのよう な汎用ツールに頼らざるを得ず、生産システムに無制 限にアクセスできるようになる。(a)LLMがそのような アクションを実行するためにSSHセッションを操作する 必要がないことで、LLMの使用コストを削減する。(b) このような決定論的ツールに依存することで、幻覚の範囲を縮小する。ツールが存在しない場合、LLMはどの ようなアクションも実行することができ、通常、エンジニアがそうでない場合のツール出力の分析となる。
- 明確でよく書かれたTSGの重要性: ケーススタディで は、明確でよく書かれたトラブルシューティングガイド( TSG)を持つことの重要な役割が強調された。LLexusが作 成した計画は、TSGの質に直接影響された。TSGの書き方 が不十分であったり、曖昧であったりする場合、生成さ れた計画は効果が低く、改善するためにはより多くの反 復が必要であった。
## Memo with LLM
![[Pasted image 20250424133006.png]]
## 論文情報
- タイトル: LLexus: an AI agent system for incident management
- 著者と所属: Pedro Las-Casas, Alok Gautum Kumbhare, Rodrigo Fonseca, Sharad Agarwal (Microsoft)
- 所属: Microsoft
- 発表年: 記載なし（論文のフッターから2024年と推測）
## 論文概要
この論文は、クラウドサービスのインシデント管理を効率化するためのAIエージェントシステム「LLexus」を提案しています。LLexusは大規模言語モデル（LLM）エージェントを活用し、トラブルシューティングガイド（TSG）を実行可能な計画に変換し、インシデント発生時に自動実行することで、解決時間の短縮を目指しています。
## 詳細解説
### 問題設定
クラウドサービスの運用において、パフォーマンス低下や障害が発生した場合、エンジニアはトラブルシューティングガイド（TSG）を参照して対応します。しかし、TSGには以下の問題があります：
1. TSGは長文（平均815語、最大5500語以上）であり、緊急時に読解するのに時間がかかる
2. TSGの可読性が低い（Flesh-Kincaid Grade Levelで最大20年の教育が必要な難解さ）
3. 暗黙知に依存している部分が多い
4. 品質にばらつきがある（不完全な情報、リンク切れ、誤情報など）
5. 頻繁に更新される（平均19日ごとに更新）
これらの問題により、TSGの自動化は困難でした。また、単純にLLMにTSGを与えてインシデント解決を試みる方法は、以下の理由で信頼性が低いです：
1. TSGの品質問題
2. LLMの出力の不確実性とハルシネーション（誤った情報の生成）
3. インシデントが増えるとLLM呼び出しのコストが高騰する
### 提案手法
LLexusは以下の2つの主要コンポーネントで構成されています：
1. **Plan Extractor（プランナー）**：オフラインコンポーネント
- TSGを分析し、実行可能な計画を生成
- TSGが作成または更新された時に作動
- 入力としてTSGと利用可能なツールのセットを必要とする
- マルチステップの計画生成プロセスを採用（Tool Selection → Plan Schema Extractor → Step Details Extractor）
- 各ステップで検証（Validation）を行う
- 人間のエンジニアとの対話的なプロセスでTSGを改善
2. **Plan Executor（エグゼキューター）**：オンラインコンポーネント
- プランナーによって生成された計画を実行
- インシデント発生時に作動
- インシデントに関連する計画を取得し、必要な情報を収集
- 計画に記述された各ステップを実行
- 結果をインシデントログに記録
生成される計画はフローチャート形式で、以下の3種類のステップで構成されます：
1. **アクションステップ**：ツールを実行するステップ
2. **条件ステップ**：決定を行うステップ（分岐点）
3. **イベントステップ**：外部アクションや時間待ちのステップ
また、計画で使用できるツールは以下の2種類です：
1. **スクリプトツール**：LLMなしで実行できる従来のプログラム
- 取得ツール：外部ソースからデータを取得
- アクションツール：システム上でアクションを実行
2. **セマンティックツール**：LLMの理解と生成能力に依存
- 例：ログ分析、関連情報の抽出、判断の支援
### 新規性
LLexusの主な新規性は以下の点にあります：
1. **計画の事前生成アプローチ**：
- インシデント発生時ではなくTSG作成/更新時に計画を生成
- LLM利用コストの削減とエラーリスクの軽減
- インシデント発生時の迅速な対応（MTTM削減）
2. **反復的な計画生成プロセス**：
- 詳細な計画を生成しつつLLMのハルシネーションを制限
- エンジニアによる計画の監査とTSGの改善
3. **TSGを真実の源とする方針**：
- 計画に問題がある場合、計画ではなくTSGを編集
- 人間とLLexus両方にとってTSGの一貫した改善
4. **既存ツールの活用**：
- エンジニアチームが持つ特定のツールに依存
- 汎用ツール（SSH等）よりも特定ツールを使うことでシステムへのアクセス制限とハルシネーション軽減
従来の研究では、TSGからプログラムを直接抽出するか、TSGをコードとして記述する方法が提案されていましたが、LLexusはLLMを活用してTSGから計画を生成し、その計画を決定論的に実行する新しいアプローチを取っています。
### 実験設定
論文では、3つのケーススタディでLLexusの有効性を検証しています：
1. **Azure Service Fabricのアップグレード失敗**：
- 比較的シンプルな公開TSGを使用
- 直線的な計画が1回の試行で生成された
2. **Azure Service Fabricのバックアップポリシー問題**：
- 条件ステップとイベントステップを含む複雑な公開TSG
- 計画生成に2回の反復が必要だった
3. **Microsoft内部サービスのネットワークリンク問題**：
- 品質の低い内部TSG
- 複数回の反復を経てTSGを改善し、完全な計画を生成
また、計画生成のコスト分析も行っています：
- GPT-4-turboモデルを使用
- 入力トークン：$0.01/1,000トークン
- 完了トークン：$0.03/1,000トークン
### 実験結果
ケーススタディの結果：
1. **Azure Service Fabricのアップグレード失敗**：
- 5ステップの計画が生成された
- 計画生成コスト：$0.60
- ステップ詳細抽出（$0.25）と検証（$0.26）が最もコストがかかった
2. **Azure Service Fabricのバックアップポリシー問題**：
- 条件分岐とイベントステップを含む計画が生成された
- TSG更新後、エスカレーションステップが削除され、調査クローズステップが追加された
- 同じTSGから10回計画を生成した結果、構造は同じだが説明の表現が異なる計画が生成された
3. **ネットワークリンク問題**：
- 初期の低品質TSGから不完全な計画（12ステップ）が生成
- TSG改善後、完全な計画（21ステップ）が生成された
- TSGの品質向上がLLexusの効果に直接影響することを示した
コスト分析の結果：
- 計画生成コスト：$0.60〜$1.71（TSGの複雑さと検証失敗回数に依存）
- オンラインアプローチ（インシデント発生時に計画生成）と比較すると、インシデント数が増えるほどLLexusが費用対効果が高くなる
- 数回のインシデント処理後にコスト的に有利になることがグラフで示されている
論文では、LLexusがTSGの品質向上と実行可能な計画の生成の両方に効果があることが示されています。特に、TSGの品質が高いほど、生成される計画の質も高くなり、検証失敗も少なくなるため、コスト効率も向上することが明らかになりました。
## Abstract
クラウド上でソフトウェアサービスを運用する場合、複数の分散コンポーネントの応答性を維持する複雑さは、エンジニアリングチームにとって大きな課題となる。エンジニアは、パフォーマンスやサービス停止のインシデントを軽減する方法をナビゲートするために、トラブルシューティングガイド(TSG)を頻繁に参照する。しかし、TSGの有効性は、その長さ、暗黙的な部族知識への依存、およびコンテンツの品質のばらつきによって妨げられることが多い。本稿では、TSGの実行を自動化するエージェントベースのAIシステムであるLLexusを紹介する。
LLexusは、プランニングフェーズにおいて、Large Language Model ([[LLM]]) エージェントを使用してTSGを正確な実行可能なプランに変換する。 これらのプランは、インシデントが発生した際に実行される。 LLexusは主に、インタラクティブなプランナーと実行者で構成される。 プランナーは、エンジニアがTSGをフローチャートで表した詳細なプランに改良するのを支援し、タスクと判断ポイントを明確にする。その後、実行部がこれらの計画を自律的に実行し、機器の交換など物理的な行動を必要とするタスクのみ、人間の支援を必要とする。一連のユースケースを通じて、我々は LLexus の実現可能性と予備的な有効性を示し、インシデント管理プロセスの合理化の可能性を提示する。
主な調査結果では、TSGの読みやすさを向上させるLLexusの能力が強調されている。計画段階でLLMを使用することで、LLM関連のコストと実行時の潜在的なエラーの影響の両方を確実に削減できる。