香港中文大学（深圳）数据科学学院三年级博士生徐俊杰龙是论文的第一作者。指导老师有香港中文大学（深圳）数据科学学院的贺品嘉教授以及微软主管研究员何世林博士。贺品嘉老师的团队研究重点包括软件工程、LLM for DevOps、大模型安全。
大型语言模型（LLM）近期在软件工程领域取得了显着的进展。它催生了metaGPT 等大量研究成果，也催生了SWE-agent 等实际应用。同时，还催生了OpenDevin、Copilot 和Cursor 等。这些成果和应用深刻影响着软件开发的方法论和实践。现有研究主要把注意力集中在软件开发生命周期（SDLC）的早期阶段的任务上，像代码生成（LiveCodeBench），程序修复（SWE-Bench），测试生成（SWT-Bench）等。但是，这些研究通常没有关注到软件部署之后的运维阶段。在实际的生产环境里，线上的软件如果出现故障，有可能让服务提供商蒙受数十亿美元的损失，这把在根因分析（RCA）领域开发更有效的解决方案这件事的迫切需求凸显出来了。
学术界和工业界的许多研究者为了探索LLM 在这一领域的可行性，已经开始进行相关研究。但是，由于运维数据的隐私性以及企业系统的差异性，目前基于LLM 的根因分析研究存在不足，既没有统一且清晰的任务建模，也没有公开的评估数据和通用的评估指标。这使得评估LLM 在根因分析方面的能力变得困难，这种评估难以做到公平，进而对该领域的发展造成了阻碍。
为解决此问题，微软DKI 团队、香港中文大学（深圳）的贺品嘉教授团队以及清华大学的裴丹教授共同提出了当前首个公开的基准评估集——OpenRCA，该评估集用于评估LLM 的根因分析能力。并且，本文已被ICLR 2025 接收。
OpenRCA 制定了清晰的任务建模以及对应的评估方法，用于基于LLM 的RCA 任务。同时，它还提供了一组公开的故障记录，这些记录经过了人工对齐，并且有大量的运维可观测数据。这为未来对基于LLM 的RCA 方法的探索奠定了基础。
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 挑战赛系列中提供的大量来自企业系统的匿名运维数据集合当作数据源，目的是确保所使用的软件故障记录和运维数据的质量。为了保障数据质量的可靠性，研究者进行了人工数据处理和标签对齐，这其中包含四个步骤。具体而言，研究者将无法用于根因定位的系统观测数据予以排除。这些数据一般仅能用于粗粒度的异常检测，并且缺少详细的故障记录，像故障原因这类信息都没有。随后，研究者对这些系统的数据进行了整理，对不同系统间的样本数量进行了均衡处理，同时也标准化了不同系统数据的目录结构，这样做是为了便于模型的检索。最重要的是，为确保问题可解，研究者手动去验证剩余数据中的故障能否通过相数据人工定位到故障根因。研究者去除了满足以下这些条件的数据记录：其一，无法在数据中识别根因；其二，故障期间数据缺失；其三，从数据推断出的根因与标签不一致。研究者首先根据不同的根因确定目标，接着使用LLM 为每个故障案例生成相应的查询指令，然后把对应的根因元素当作标签，最终构建了335 个根因定位问题。
基线方法
研究者构建了三种基线方法，目的是评估当前LLM 解决OpenRCA 问题的能力。其中有两个基线方法是基于采样的prompting 方法，还有一个基线方法是基于简单的ReAct 的Agentic 方法。
Sampling-based prompting
运维的可观测数据规模是很大的，然而LLM 的上下文窗口是有限的，所以直接输入全部数据是不现实的。在传统的根因分析里，常见的处理办法是进行采样。研究者把所有的数据（包含追踪、日志和指标）按照每分钟一个值来进行下采样，并且对具体的指标类型进一步进行抽样，以此来减少KPI 序列的数量。研究者运用了两种策略来执行这种抽样：
RCA-agent
采样能够缓解长上下文的问题，然而运维数据中存在大量非自然语言，像GUID、错误码等。 LLM 处理这类信息的能力是有限的。基于此，研究者设计了RCA-agent，这是一个基于Python 的代码生成与执行反馈的轻量Agent 框架，它允许模型利用数据检索和分析工具，从而提升模型对复杂数据的理解和操作能力。 RCA-agent 由两部分组成：
主要实验
研究者为了评测当前大模型解决OpenRCA 问题的能力，挑选了六个模型，这些模型至少具有128k token 的上下文长度，像Claude 3.5 sonnet、GPT-4o、Gemini 1.5 pro 等。结果表明：
表1 基线方法的准确率对
图2 模型在各个系统上的准确率分布
研究者进一步分析后观察到，当前模型在解决问题时倾向于采用更短的交互，这种交互的步数为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 问题时，要尽量使用代码能力较为强大的模型，并且进行更长的链条式的交互以及思考。
图3 展示了交互链条长度的分布情况；图4 呈现了正确率随交互链条长度的分布情况；表2 列出了模型代码执行有错时的正确率。
使用指南
OpenRCA 数据、文档、以及相关代码已开源在仓库中：
使用OpenRCA 数据时，首先要将原始数据下载到本地。在每个子数据集下，存在着若干个以日期来命名的运维数据目录，同时还有一份原始数据记录（record.csv）以及一份问题清单（query.csv）。使用者需让自己的方法能够访问到相应的运维数据目录，以便解决问题清单上的问题。使用者可以利用仓库中的评估脚本。这个评估脚本是evaluate.py。使用者利用它来评估其方法的结果正确性。
如果使用者期望公开他们的评估结果于OpenRCA 的评测榜单，那么可以把他们方法的名称、原始结果文件、跑分、执行轨迹（若有）以及仓库连接（若开源）发送至openrcanon@gmail.com。我们会在确认结果的可信度之后，尽快把结果更新到排行榜上。
结语
大模型在软件工程领域的研究处于一片尚未充分开发的状态。本文着重于给出一个任务定义明确并且数据开放的代理任务数据集，以便各种不同的大模型RCA 方法能够进行公平对比。本文的评测也只是针对大模型自身的RCA 能力进行的。在实际应用里，存在着许多能够进一步进行工程优化的方面。例如，可以配置定制化的工具，以此来避免模型完全自由地进行推理以及编码所导致的幻觉问题。希望这篇论文能够起到抛砖引玉的作用，从而激发在更多软件工程任务上关于大模型研究的产生。
本文来自微信公众号“机器之心”，36氪经授权发布。
