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

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

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

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

OpenRCA 為基于 LLM 的 RCA 任務制定了清晰的任務建模和對應的評估方法，并提供了一組公開且經(jīng)過人工對齊的故障記錄和大量的運維可觀測數(shù)據(jù)。這為未來基于 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/

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

評估基準

任務建模

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

評估數(shù)據(jù)

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

基線方法

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

Sampling-based Prompting

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

• Balanced Sampling：采用分層抽樣策略，即從每類 KPI 中隨機選取一個，循環(huán)進行，直到達到模型的 token 上限。該方法簡單實用，確保 KPI 類型的分布均衡。為保證可重復性，研究者對每種配置測試三次，并報告中位數(shù)結果。
• Oracle Sampling：為研究抽樣方法的性能上限，研究者引入了 oracle 策略，即使用在基準構建中已經(jīng)被工程師驗證能夠有效定位根因的 KPI 集合作為固定的輸入。雖然這種方法在在實際場景中并不現(xiàn)實，但能體現(xiàn)采樣的能力上限。

RCA-agent

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

• Controller：負責決策與流程控制，引導模型完成異常檢測 → 故障識別 → 根因定位的分析流程。每個步驟都會要求 Executor 完成單一原子化的任務，并根據(jù)返回結果來決策下一步。
• Executor：根據(jù)控制器指令生成并執(zhí)行 Python 代碼，并返回結果。其包含 LLM 代碼生成器與 Python 執(zhí)行環(huán)境。所有代碼與變量均緩存于內存中，直至整個任務完成。

主要實驗

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

• 基于智能體的方法的能力上限比提示詞方法更好。
• 當前模型在解決 OpenRCA 問題上仍面臨挑戰(zhàn)。

表 1 基線方法的準確率對

圖 2 模型在各個系統(tǒng)上的準確率分布

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

圖 3：交互鏈條長度的分布；圖 4：正確率隨交互鏈條長度的分布；表 2：模型代碼執(zhí)行有錯時的正確率

使用指南

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

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

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

結語

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

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