DevOps-Eval:蚂蚁集团联合北京大学发布首个面向DevOps领域的大语言模型评测基准!🚀

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 大语言模型在各类NLP下游任务上取得了显著进展。然而在DevOps领域,由于缺乏专门用于大型语言模型的评测基准,在有效评估和比较该领域大语言模型的能力方面存在严重不足。为弥补这一不足,蚂蚁集团联合北京大学发布了首个面向DevOps领域的大模型评测基准DevOps-Eval,以帮助开发者跟踪DevOps领域大模型的进展,并了解各个DevOps领域大模型的优势与不足。

eval.png

1. 背景

大语言模型在各类NLP下游任务上取得了显著进展。然而在DevOps领域,由于缺乏专门用于大型语言模型的评测基准,在有效评估和比较该领域大语言模型的能力方面存在严重不足。

为弥补这一不足,蚂蚁集团联合北京大学发布了首个面向DevOps领域的大模型评测基准DevOps-Eval,以帮助开发者跟踪DevOps领域大模型的进展,并了解各个DevOps领域大模型的优势与不足。

DevOps-Eval根据DevOps全流程进行划分,包含计划、编码、构建、测试、发布、部署、运维和监控这8个类别,包含4850道选择题。此外,DevOps-Eval还特别对运维/监控类别做了细分,添加日志解析、时序异常检测、时序分类和根因分析等常见的AIOps任务。由于DevOps-Eval根据场景对评测样本做了详尽的细分,因此除了DevOps领域大模型,也方便对特定领域大模型进行评测,如AIOps领域等。

目前,我们已发布了第一期的评测榜单,首批评测大模型包含OpsGpt、Qwen、Baichuan、Internlm等开源大语言模型;同时,DevOps-Eval相关论文也在紧锣密鼓地撰写中。我们欢迎相关从业者一起来共建DevOps-Eval项目,持续丰富DevOps领域评测题目或大模型,我们也会定期更新题库和评测榜单

GitHub 地址:https://github.com/codefuse-ai/codefuse-devops-eval

HuggingFace 地址:https://huggingface.co/datasets/codefuse-admin/devopseval-exam


2. 评测数据

2.1. 数据来源

DevOps-Eval最终生成的样本格式都为单项选择题,采用此类格式的原因是单项选择题客观性高,不但能够提高样本收集效率,并且方便进行自动化评测。因此,我们收集样本的策略是尽可能获得选择题原题,或者通过某些手段生成或转换为选择题。经过统计,该项目的数据来源可以分为以下5大类:

  1. 选择题类试题:直接为选择题形式的公开试题,例如计算机通识类考试试题、DevOps专业考试试题等;
  2. 问答类试题:此类试题以问答题的形式出现,且已按照DevOps场景进行了有效划分,来源如超级码客、devops-exercises等,我们再在问答题基础上通过ChatGPT生成答案并转换为选择题;
  3. 开源数据集:基于开源数据集构造AIOps相关样本,例如基于LOGPAI的数据构造日志解析相关的选择题样本,基于TraceRCA的数据构造根因分析相关选择题样本;
  4. ChatGPT生成:某些细分场景缺乏现成的试题,我们使用场景关键词通过ChatGPT直接生成相应的选择题;
  5. 数据仿真生成:通过数据仿真的手段生成数据,例如时序异常检测、时序分类等试题。


2.2. 数据类别

DevOps-Eval根据DevOps全流程进行划分,共分为8个大类和53个子类,包含4850道选择题。其中,AIOps场景有4个,共计2200个中英文题目。每个子类分为dev数据集和test数据集。其中,dev数据集包含5个带有标签和解析的样例,用于few-shot评测;test数据集仅包含标签,用于模型评测。图2.1给出了DevOps-Eval数据的具体细分类别。若要进一步了解各个类别包含的具体内容,可以参考Github中更为具体的样本明细脑图。image.png

图2.1 数据细分类别


2.3. 数据样例

2.3.1. DevOps

以下样本来自于CODE大类下的versionControl子类,主要考察git相关知识。

编号

4

问题

如何找到Git特定提交中已更改的文件列表?

A

使用命令 `git diff --name-only SHA`

B

使用命令 `git log --name-only SHA`

C

使用命令 `git commit --name-only SHA`

D

使用命令 `git clone --name-only SHA`

答案

A

解析

分析原因:git diff --name-only SHA命令会显示与SHA参数对应的提交中已修改的文件列表。参数--name-only让命令只输出文件名,而忽略其他信息。其它选项中的命令并不能实现此功能。


2.3.2. AIOps

  • 日志解析

编号

0

问题

下面是一些运行日志

0 04:21:15,429 WARN Cannot open channel to 2 at election address /10.10.34.12:3888

1 19:18:56,377 WARN ******* GOODBYE /10.10.34.11:52703 ********

2 19:13:46,128 WARN ******* GOODBYE /10.10.34.11:52308 ********

3 19:16:26,268 WARN ******* GOODBYE /10.10.34.11:52502 ********

4 09:11:16,012 WARN Cannot open channel to 3 at election address /10.10.34.13:3888

5 16:37:13,837 WARN Cannot open channel to 2 at election address /10.10.34.12:3888

6 09:09:16,008 WARN Cannot open channel to 3 at election address /10.10.34.13:3888

7 15:27:03,681 WARN Cannot open channel to 3 at election address /10.10.34.13:3888

日志最前面三部分别为序号、时间戳和日志Level,在不考虑这三部分内容的情况下,此处我们设定日志的变量用'<*>'代替,token与token之间用空格分隔,那么请问上述日志的日志模版具体是什么?

A

Notification time out: <*> 和 Connection broken for id <*>, my id = <*>, error =

B

Send worker leaving thread 和 Connection broken for id <*>, my id = <*>, error =

C

Received connection request /<*>:<*> 和 Interrupting SendWorker

D

Cannot open channel to <*> at election address /<*>:<*> 和 ******* GOODBYE /<*>:<*> ********

答案

D

解析

根据日志中的内容,选项D是最符合日志模板的。日志中包含了"Cannot open channel to &lt;*&gt; at election address /&lt;*&gt;:&lt;*&gt;"和"******* GOODBYE /&lt;*&gt;:&lt;*&gt; ********"这两个固定的模板片段,它们都在选项D中出现了。同时,其他选项中的模板片段与日志中的内容不匹配。因此,选项D是最符合日志模板的。

  • 时序异常检测

编号

问题

A

B

C

D

答案

解析

0

分析如下时间序列[50,62,74,84,92,97,99,98,94,87,77,65,265,40,28,17,8,3,0,0,4,10,20,31,43,56,68,79,89,95,99,99,96,91,82,71,59,46,34,22,12,5,1,0,2,7,15,25,37,49]请找出其中明显异常点的下标。所谓的异常点一般指的是明显与数据整体趋势不符的点。

46

0

37

12

D

根据分析,题目中的时间序列在12点出的值265要明显大于周围数据,存在着突增现象,因此选择D是正确的。

上述日志解析样例为给定日志给出具体模版,此外还有给定日志给出模版个数,给定日志模版判断哪些日志由给定模版生成。此外限于篇幅,此处不再展示时序分类和根因分析样例,具体可以查看HuggingFace数据集。


2.4. 数据下载

  • 方法一: 直接下载(也可以用浏览器打开下面的链接)
wget https://huggingface.co/datasets/codefuse-admin/devopseval-exam/resolve/main/devopseval-exam.zip
# 然后可以使用 pandas加载数据:
import os
File_Dir="devopseval-exam"
test_df=pd.read_csv(os.path.join(File_Dir,"test","UnitTesting.csv"))
  • 方法二:使用Hugging Face datasets库函数
from datasets import load_dataset
dataset=load_dataset(r"DevOps-Eval/devopseval-exam",name="UnitTesting")
print(dataset['val'][0])


3. 评测设置

3.1. 评测模型

一期我们选取了比较热门的不同参数大小、不同机构发布的通用大模型和运维领域大模型,具体细节如下表。后续我们也会评测更多其他的大模型。

模型类别

模型名称

参数量

通用大模型

Qwen-7B

7B

Qwen-7B-Chat

7B

Qwen-14B

14B

Qwen-14B-Chat

14B

Baichuan2-7B

7B

Baichuan2-13B

13B

Internlm-7B

7B

运维领域大模型

DevOps-Model-7B

7B

DevOps-Model-7B-Chat

7B

DevOps-Model-14B

14B

DevOps-Model-14B-Chat

14B


3.2. 评测方式

DevOps-Eval包含Zero-shot和Few-shot两种评测方式。其中针对DevOps题目,我们主要评测Zero-shot和Five-shot的结果。而针对AIOps题目,由于题目的token长度较长(如上面展示的日志解析样例,包含多行日志),Five-shot后的题干长度会超过2k个token。而大部分模型的训练的上下文就是2k,所以针对AIOps的题目,我们主要评测Zero-shot和One-shot的结果。

Base模型和Chat模型获取预测结果的方式如下:

  • Base模型:我们将问题输入大模型后,基于模型预测下一个Token的得分,获得分别对应A,B,C,D四个选项的得分,将得分最高的选项作为模型对于这道题预测结果;
  • Chat模型:我们先将问题转换为Chat模型对齐训练时使用的prompt,比如Qwen采用的是chatml的格式,Baichuan2是一种自定义的格式,采用模型对齐训练的格式能够使得模型更好地发挥其能力。当转换好后输入大模型,然后用和Base模型相同的方式获取预测结果。


4. 评测结果

4.1. 🏆 DevOps全流程评测榜单

4.1.1. 0-shot评测结果

如下图所示,0-shot评测结果中DevOpsPal-14B-Chat平均分最高,达到了80.34分,Internlm-7B-Base评分较低,为66.91分。从总体上来看,各模型的分数区分度不大。

image.png


4.1.2. 5-shot评测结果

如下图所示,5-shot的结果要稍好于0-shot,其中DevOpsPal-14B-Chat平均分依然最高,达到了81.77分,Internlm-7B-Base评分较低,为69.17分。从总体上来看,各模型的分数区分度也并不大,说明样本集难度偏低,后期需要区分下样本难度等级。

image.png


4.2. 🔥 AIOps场景评测榜单

4.2.1. 0-shot评测结果

从0-shot结果来看Qwen-14B-Base平均分最高,达到了49.27分,Internlm-7B—Chat评分较低,为32.0分。从总体上来看,各模型在AIOps类别的区分度明显变大。

image.png

4.2.2. 1-shot评测结果

1-shot的结果要稍好于0-shot,其中DevOpsPal-14B—Chat平均分最高,达到了53.91分,Internlm-7B—Chat依然评分较低,为32.73分。在不同细分类别的表现,根因分析得分相对较高,可能跟根因分析题目做了简化相对较为简单有关,而时序异常检测整体表现都不太好,当前大模型对时序类数据的处理依然有待提升。

image.png


5. 未来展望

未来我们将持续对DevOps-Eval项目进行优化,主要优化方向包括以下几点:

1)不断丰富评测数据集:

  • 当前DevOps全流程评测数据主要为中文,后续将增加英文题目;
  • 当前不同类别之间的数据量存在较大差异,需要持续补充数据集,平衡各类别的数据量;
  • 当前评测数据主要以知识类为主,后续将增加更多任务类题目,且题型将不局限于选择题,增加问答等形式;
  • 从DevOps全流程评测结果可以看出,当前评测模型之间得分差异较小,说明当前DevOps全流程的评测数据难度的区分度一般,需要对数据集增加难度分级;

2)重点关注AIOps领域:

  • AIOps一直是运维领域的研究热点,大模型与AIOps能碰撞出什么火花也是当前行业内最关心的话题。目前DevOps-Eval已涵盖4类常见的AIOps任务,后续将继续增加,直至覆盖运维领域的所有智能化任务;

3)持续增加评测模型:

  • 一期主要评测了一些主流的、规模不是很大的开源模型,后续将覆盖更多的模型,并重点跟踪评测面向DevOps和AIOps领域的大模型。

希望大家一起来共建DevOps-Eval,期待在大家的努力下,建立更准确、更全面的DevOps领域大模型评测体系,推动DevOps领域大模型技术的不断发展与创新。


6. 关于DevOpsGPT

DevOpsGPT是我们发起的一个针对DevOps领域大模型相关的开源项目,主要分为三个模块。本文介绍的DevOps-Eval是其中的评测模块,其目标是构建DevOps 领域LLM行业标准评测。此外,还有DevOps-Model、DevOps-ChatBot两个模块,分别为DevOps领域专属大模型和DevOps领域智能助手。我们的目标是在DevOps领域,包含开发、测试、运维、监控等场景,真正地结合大模型来提升效率、成本节约。我们期望相关从业者一起贡献自己的才智,来让“天下没有难做的coder”,我们也会定期分享对于 LLM4DevOps 领域的经验&尝试。

欢迎使用&讨论&共建
(1)ChatBot - 开箱即用的 DevOps 智能助手:https://github.com/codefuse-ai/codefuse-chatbot
(2)Eval - DevOps 领域 LLM 行业标准评测:https://github.com/codefuse-ai/codefuse-devops-eval
(3)Model - DevOps 领域专属大模型:https://github.com/codefuse-ai/CodeFuse-DevOps-Model

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
运维 Devops 调度
DevOps-ChatBot:DevOps开源端到端智能AI助手
随着ChatGPT等通用大模型以及各类垂直领域大模型的出现,各个领域的产品交互模式、用户信息获取模式都在逐步发生改变。但通用大模型自身存在的生成内容不可靠、信息内容不及时、领域任务不完善的问题始终存在,面向DevOps这个对于事实的准确性、信息的及时性、问题的复杂性、数据的安全性要求都比较高的领域,大模型该如何赋能?为此,我们发起并开源DevOps-ChatBot端到端AI智能助手,专为软件开发的全生命周期而设计:通过DevOps垂类知识库 + 知识图谱增强 + SandBox执行环境等技术来保障生成内容的准确性、及时性并让用户交互修改代码编译执行,确保答案的可靠性;通过静态分析技术 + RA
903 1
DevOps-ChatBot:DevOps开源端到端智能AI助手
|
9月前
|
存储 算法 测试技术
CodeFuse-AAIS:改进低智能体框架助力高效程序修复
本文提出了一种基于低智能体框架的自适应自动化程序修复(APR)解决方案——AAIS。该方案结合了智能体的自适应性和低智能体的高效控制流,通过引入交互式缺陷定位和多模型辅助生成,显著提升了程序修复的准确性和多样性。实验结果表明,AAIS在SWE-Bench基准测试中表现出色,函数级定位准确率提升了46.94%-113.32%,Issue Solving任务上达到了35.67%的性能,展示了其在未来软件开发中的应用潜力。
247 0
CodeFuse-AAIS:改进低智能体框架助力高效程序修复
|
10月前
|
存储 人工智能 运维
下一代研发大模型需要哪些关键能力?
CodeFuse 支持从设计到运维的整个软件开发生命周期。项目已开源多个项目,欢迎社区共建。其中Rodimus作为 CodeFuse 的重要组成部分,旨在降低推理复杂度,优化大模型性能,支持低资源设备上的高效运行。
270 6
|
人工智能 Oracle Java
蚂蚁 CodeFuse 代码大模型技术解析:基于全仓库上下文的代码补全
CodeFuse 代码补全插件是 CodeFuse 系列产品中用户数量最多、留存率最大,调用AI能力最多的产品~欢迎大家体验试用https://github.com/codefuse-ai/RepoFuse
2138 7
蚂蚁 CodeFuse 代码大模型技术解析:基于全仓库上下文的代码补全
EMNLP 2024 Oral | CoBa:均衡多任务收敛之道
我们提出了一种满足了以上两种需求的新的 MTL 方法——CoBa,旨在以最小的计算开销有效控制多任务收敛的平衡。CoBa 利用相对收敛分数(RCS)、绝对收敛分数(ACS)和发散因子(DF),在训练过程中动态地调整任务权重,确保所有任务的验证集损失以均匀的速度朝向收敛推进,同时缓解了个别任务提前发散的问题。本文在四个不同的多任务数据集上进行实验,结果表明,CoBa 不仅促进了任务收敛的平衡,而且与最佳基线方法相比,还使 LLMs 的性能至多提升了 13%。
205 3
|
机器学习/深度学习 人工智能 Devops
破解自注意力推理缺陷的奥秘,蚂蚁自研新一代Transformer或实现无损外推
随着大语言模型的快速发展,其长度外推能力(length extrapolating)正日益受到研究者的关注。尽管这在 Transformer 诞生之初,被视为天然具备的能力,但随着相关研究的深入,现实远非如此。传统的 Transformer 架构在训练长度之外无一例外表现出糟糕的推理性能。
253 0
|
数据采集 SQL 算法
大代码时代的基建:CodeFuse-Query代码大数据分析平台
在当前的静态分析领域,CodeFuse-Query 带来了一种新的范式。它不仅满足了大规模、复杂的代码库分析需求,还能适应不断变化和多元化的静态分析场景。CodeFuse-Query 的以数据为中心的方法,使得其在处理大数据环境中的代码分析问题时具有独特优势。CodeFuse-Query 的设计,旨在解决大规模软件开发环境中的静态分析问题。它能够将源代码和分析结果视作数据,使得其可以灵活地融入大型组织的各种系统中。这种方法不仅可以有效地处理大规模的代码库,还可以应对各种复杂的分析需求,从而使得静态分析工作变得更加高效和准确。
638 2
|
机器学习/深度学习 存储 人工智能
ACL 2024|D2LLM:将Causal LLM改造成向量搜索模型的黑科技
D2LLM:一种针对语义搜索任务的新颖方法,它结合了大语言模型(LLM)的准确性与双编码器的高效性。实验表明,D2LLM在多项任务上的性能超越了五个领先基准模型,尤其是在自然语言推理任务中,相对于最佳基准模型的提升达到了6.45%
328 1
|
机器学习/深度学习 人工智能
ACL 2024 | CoCA:自注意力的缺陷与改进
CodeFuse团队从一个全新的视角,剖析了传统的 Transformer架构在长文本推理的糟糕表现,并给出了相应的解决方案
352 1