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

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

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

為了解決這一問題，微軟 DKI 團(tuán)隊(duì)、香港中文大學(xué)（深圳）賀品嘉教授團(tuán)隊(duì)與清華大學(xué)裴丹教授共同提出了當(dāng)前首個(gè)公開的、用于評(píng)估 LLM 根因分析能力的基準(zhǔn)評(píng)估集 ——OpenRCA。本文已被 ICLR 2025 接收。

OpenRCA 為基于 LLM 的 RCA 任務(wù)制定了清晰的任務(wù)建模和對(duì)應(yīng)的評(píng)估方法，并提供了一組公開且經(jīng)過人工對(duì)齊的故障記錄和大量的運(yùn)維可觀測(cè)數(shù)據(jù)。這為未來基于 LLM 的 RCA 方法的探索奠定了基礎(chǔ)。

• 論文標(biāo)題：OpenRCA: Can Large Language Models Locate the Root Cause of Software Failures?
• 論文地址：https://openreview.net/pdf?id=M4qNIzQYpd
• 開源代碼：https://github.com/microsoft/OpenRCA
• 評(píng)測(cè)榜單：https://microsoft.github.io/OpenRCA/

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

評(píng)估基準(zhǔn)

任務(wù)建模

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

評(píng)估數(shù)據(jù)

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

基線方法

為了評(píng)估當(dāng)前 LLM 解決 OpenRCA 問題的能力，研究者構(gòu)建了三種基線方法，其中兩個(gè)是基于采樣的 Prompting 方法，一個(gè)是基于簡單的 ReAct 的 Agentic 方法。

Sampling-based Prompting

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

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

RCA-agent

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

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

主要實(shí)驗(yàn)

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

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

表 1 基線方法的準(zhǔn)確率對(duì)

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

通過進(jìn)一步分析，研究者觀察到當(dāng)前模型傾向于使用更短的交互（6-10 步）來解決問題。然而，交互次數(shù)更多的情況下，問題的正確率通常更高。其次，研究者發(fā)現(xiàn)模型的代碼生成和代碼糾錯(cuò)能力會(huì)大幅影響其在 RCA-agent 上的表現(xiàn)。在僅考慮那些執(zhí)行軌跡中出現(xiàn)過代碼運(yù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 問題時(shí)，需盡可能使用代碼能力更強(qiáng)的模型進(jìn)行更長鏈條的交互和思考。

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

使用指南

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

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

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

結(jié)語

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

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