連Claude 3.5都敗下陣來，大語言模型能否定位軟件服務的故障根因？

論文的第一作者是香港中文大學（深圳）數據科學學院三年級博士生徐俊傑龍，指導老師為香港中文大學（深圳）數據科學學院的賀品嘉教授和微軟主管研究員何世林博士。賀品嘉老師團隊的研究重點是軟件工程、LLM for DevOps、大模型安全。

大型語言模型（LLM）近期在軟件工程領域取得了顯著進展，催生了 MetaGPT、SWE-agent、OpenDevin、Copilot 和 Cursor 等大量研究成果與實際應用，深刻影響著軟件開發的方法論和實踐。現有研究主要聚焦於軟件開發生命週期（SDLC）的早期階段的任務，如代碼生成（LiveCodeBench）, 程序修復（SWE-Bench），測試生成（SWT-Bench）等等。然而，這些研究往往忽視了軟件部署後的運維階段。在實際生產環境中，線上軟件的故障可能導致服務提供商遭受數十億美元的損失，這凸顯了在根因分析（RCA）領域開發更有效解決方案的迫切需求。

為了探索 LLM 在這一領域的可行性，學術界和工業界的許多研究者已經開始進行相關研究。然而，受限於運維數據的隱私性以及企業系統的差異性，目前基於 LLM 的根因分析研究缺乏統一且清晰的任務建模，也沒有公開的評估數據和通用的評估指標。這使得公平地評估 LLM 在根因分析方面的能力變得困難，進而阻礙了該領域的發展。

為瞭解決這一問題，微軟 DKI 團隊、香港中文大學（深圳）賀品嘉教授團隊與清華大學裴丹教授共同提出了當前首個公開的、用於評估 LLM 根因分析能力的基準評估集 ——OpenRCA。本文已被 ICLR 2025 接收。

OpenRCA 為基於 LLM 的 RCA 任務製定了清晰的任務建模和對應的評估方法，並提供了一組公開且經過人工對齊的故障記錄和大量的運維可觀測數據。這為未來基於 LLM 的 RCA 方法的探索奠定了基礎。

• 論文標題：OpenRCA: Can Large Language Models Locate the Root Cause of Software Failures?

• 論文地址：https://openreview.net/pdf?id=M4qNIzQYpd

• 開源代碼：https://github.com/microsoft/OpenRCA

• 評測榜單：https://microsoft.github.io/OpenRCA/

研究者發現，當前主流的 LLM 在直接解決 OpenRCA 問題時面臨顯著挑戰。例如，Claude 3.5 在提供了 oracle KPI 的情況下，僅解決了 5.37% 的 OpenRCA 任務。當使用隨機均勻抽樣策略提取可能相關的數據時，這一結果進一步下降到 3.88%。為了為解決 OpenRCA 任務指明可能的方向，研究者進一步開發了 RCA-agent，以作為一個更有效的基線方法。在使用 RCA-agent 後，Claude 3.5 的準確率提升至 11.34%，但依然離解決好 OpenRCA 問題有著較大的差距。

評估基準

任務建模

OpenRCA 將基於 LLM 的根因分析任務定義為目標驅動的形式：模型或智能體將接收由自然語言組成的查詢指令，執行不同目標的根因分析任務。根據查詢指令，模型或智能體需要通過檢索和分析當前系統中保存的運維可觀測數據（包括指標、日誌、調用鏈），從中推理並識別出三種根因的組成元素（故障時間、故障組件和故障原因）中的一個或多個元素，並最終以 JSON 結構輸出。當輸出中的所有元素與標籤一致時，該樣本被視為正例；否則，視為反例。OpenRCA 通過計算樣本的平均預測正確率來評估方法的能力。

評估數據

為了確保所使用的軟件故障記錄和運維數據的質量，OpenRCA 將往年 AIOps 挑戰賽系列中提供的大量來自企業系統的匿名運維數據集合作為數據源。為保障數據質量的可靠性，研究者進行了包括四個步驟在內的人工數據處理和標籤對齊。具體來說，研究者排除了無法用於根因定位的系統觀測數據，這些數據通常僅能用於粗粒度異常檢測，而缺乏詳細的故障記錄，例如故障原因等信息。接著，研究者整理了這些系統的數據，對不同系統間的樣本數量進行了均衡化處理，並標準化了不同系統數據的目錄結構，以便於模型的檢索。最重要的是，為保證問題的可解性，研究者手動驗證了剩餘數據中的故障是否可以通過相數據人工定位到故障根因。研究者去除了滿足以下任一條件的數據記錄：（1）無法數據中識別根因；（2）故障期間數據缺失；（3）從數據推斷出的根因與標籤不一致。最終，研究者根據不同的根因定位目標，使用 LLM 為每個故障案例生成了相應的查詢指令，並將其對應的根因元素作為標籤，構建了 335 個根因定位問題。

基線方法

為了評估當前 LLM 解決 OpenRCA 問題的能力，研究者構建了三種基線方法，其中兩個是基於采樣的 Prompting 方法，一個是基於簡單的 ReAct 的 Agentic 方法。

Sampling-based Prompting

運維可觀測數據規模龐大，而 LLM 的上下文窗口有限，因此直接輸入全部數據並不現實。在傳統根因分析中，常見的處理方式是采樣。研究者將所有數據（包括追蹤、日誌和指標）按每分鐘一個值進行下采樣，並對具體的指標類型進一步抽樣以減少 KPI 序列的數量。研究者採用了兩種策略來執行這種抽樣：

• Balanced Sampling：採用分層抽樣策略，即從每類 KPI 中隨機選取一個，循環進行，直到達到模型的 token 上限。該方法簡單實用，確保 KPI 類型的分佈均衡。為保證可重覆性，研究者對每種配置測試三次，並報告中位數結果。

• Oracle Sampling：為研究抽樣方法的性能上限，研究者引入了 oracle 策略，即使用在基準構建中已經被工程師驗證能夠有效定位根因的 KPI 集合作為固定的輸入。雖然這種方法在在實際場景中並不現實，但能體現采樣的能力上限。

RCA-agent

儘管采樣可緩解長上下文的問題，但運維數據中仍包含大量非自然語言（如 GUID、錯誤碼等），LLM 處理此類信息的能力有限。為此，研究者設計了 RCA-agent，一個基於 Python 的代碼生成與執行反饋的輕量 Agent 框架，允許模型使用數據檢索和分析工具以提升模型對複雜數據的理解與操作能力。RCA-agent 由兩部分組成：

• Controller：負責決策與流程控制，引導模型完成異常檢測 → 故障識別 → 根因定位的分析流程。每個步驟都會要求 Executor 完成單一原子化的任務，並根據返回結果來決策下一步。

• Executor：根據控製器指令生成並執行 Python 代碼，並返回結果。其包含 LLM 代碼生成器與 Python 執行環境。所有代碼與變量均緩存於內存中，直至整個任務完成。

主要實驗

為了評測當前大模型解決 OpenRCA 問題的能力，研究者挑選了六個至少具有 128k token 上下文長度的模型，如 Claude 3.5 sonnet, GPT-4o, Gemini 1.5 pro 等。結果顯示：

• 基於智能體的方法的能力上限比提示詞方法更好。

• 當前模型在解決 OpenRCA 問題上仍面臨挑戰。

通過進一步分析，研究者觀察到當前模型傾向於使用更短的交互（6-10 步）來解決問題。然而，交互次數更多的情況下，問題的正確率通常更高。其次，研究者發現模型的代碼生成和代碼糾錯能力會大幅影響其在 RCA-agent 上的表現。在僅考慮那些執行軌跡中出現過代碼運行失敗情況的例子中，Claude 3.5 sonnet 的正確率僅下降了 17.9% (11.34->9.31)。而 Gemini 1.5 pro 則下降了 68.4% (2.69->0.85)。這些發現可能的啟發是，在以基於代碼執行的智能體方法解決 OpenRCA 問題時，需儘可能使用代碼能力更強的模型進行更長鏈條的交互和思考。

使用指南

OpenRCA 數據、文檔、以及相關代碼已開源在倉庫中：https://github.com/microsoft/OpenRCA

要使用 OpenRCA 數據，需要首先將原始數據下載到本地。每個子數據集下都有若幹個以日期命名的運維數據目錄，以及一份原始數據記錄 (record.csv) 和問題清單 (query.csv) 使用者需要讓他們的方法能夠訪問對應的運維數據目錄，來解決問題清單上的問題。最後，使用者可以利用倉庫中的評估腳本 (evaluate.py) 來評估其方法的結果正確性。

如果使用者希望公開他們的評估結果在 OpenRCA 的評測榜單上（https://aka.ms/openrca），可以把他們方法的名稱、原始結果文件、跑分、執行軌跡（如果有）、倉庫連接（如果開源）發送到 openrcanon@gmail.com。我們將在確認結果可信度之後盡快將結果更新在排行榜上。

結語

大模型在軟件工程領域的研究仍然是一片藍海。本文聚焦於提供一個任務定義清晰且數據開放的代理任務數據集，來允許各種不同的大模型 RCA 方法使做公平對比。本文的評測也僅局限於大模型本身的 RCA 能力上。在實際應用中，還有許多可以進一步工程優化的點，如配置定製化工具來避免模型完全自由推理和編碼產生的幻覺問題。希望這篇論文能拋磚引玉，激發更多軟件工程任務上的大模型研究的產生。

本文已被 ICLR 2025 接收，海報將於 4 月 25 日下午 3 點至 5 點半在 Hall 3 + Hall 2B #115 展出。歡迎感興趣的同行們來與作者交流討論。