CodeFuseEval : 代码类大模型多任务评估基准

背景

2023年是大模型全面发展的一年,截止7月,中国累计有130个大模型问世,国外大模型138个,可谓名副其实的百模争鸣。在大模型研发过程中,模型能力评估已然成为必要环节。相比传统的系统架构,模型输出的内容是预测生成式,具有很大的不确定性,它可以基于已知的知识生成未知的知识,这些涌现的新知识证明了模型推理及泛化能力但也带来了不确定风险,特别是模型融入会话式产品,面对用户各类的问答,更容易激发能力涌现,如何及时发现这些新涌现的能力及如何保障模型的输出是有用的、无害的、真实的,是当前大模型评估面临的很大挑战,为此,代码大模型的评估基准必然需要多类多维。

附:代码类大模型HumanEval数据集打榜趋势图

如上图,可以看到进入23年以来,各个代码类大模型在HumanEval数据基准上pass@1表现提升显著,然而,我们发现代码领域打榜与实际用户体验,仍然存在一定的差异,这也说明靠单任务百十道题目证明模型的代码能力是远远不够的。在此背景下,我们基于蚂蚁代码大模型CodeFuse系列评测经验及众测反馈,探索并构建了适合企业项目的代码大模型的评测范式。后续,也将持续构建并开放“企业级”的「多类型代码任务」评测基准,帮助和牵引代码类大模型针对各编码场景的代码下游任务训练和调优,生成贴合企业场景的更高质量的代码内容。

什么是代码大模型评测

1、代码大模型的评测内容

代码领域作为自然语言大模型的一个垂类,除去NLP通用的一些技术能力评估、模型认知评估和安全可信评估外,对编码领域自身,需针对性评估模型自身在技术能力层面的表现,如不同类型代码生成能力、上下文或计算机知识的理解能力,以及在对外服务能力层面的表现,如服务体验、稳定性、开放性等。

附:编码垂类评估内容示意图

如下图,针对代码生成类和理解类的2个效果截图示例(代码补全和添加注释),在这2大类下会有一些技术能力和服务能力层面的共同关注点(代码正确性、语义准确性/可读、产品交互体验、内容合规安全等),

附:生成和理解2类效果示例

2、代码大模型的评测方法

目前对于大语言模型评测按照生成的结果是否可定量衡量分为「客观评测」和「主观评测」。其中客观评测指的是基于评测基准对生成内容进行各维度量化评估;主观评测指的是组织多位专业人员通过人模交互观察模型表现并根据基础标准、专家知识和经验综合评估。

按照评测执行方式可分为自动化评测、人工评测和模型评测三类。模型训练完成后,基于评估基准跑出评分,这个过程可以工程化的执行,因此称为自动化评测。人工评测部分,特别是领域知识,需要召集各领域专家进行测评,此种方式评估成本较高,但是评估结果更主观更具有说服力。模型评测模型即通过训练大模型学习到人类对不同生成文本的总体偏好,并作出基于习得的人类偏好来进行评价,这种评价方式相比人工更稳定、高效。

按照prompts设置方法评测又可分为:零样本(zero-shot)、小样本(few-shot)、零样本思维链(zero-shot-cot)、小样本思维链(few-shot-cot)。代码生成能力目前大部分采用的策略是零样本(zero-shot)。 

附:prompts分类评测示例

什么是CodeFuseEval

1、代码能力评测基准介绍

GPT3.5解释代码大模型评测基准回复如下,

附:GPT的回答

模型评测基准是优化模型、衡量不同架构模型的同类场景功能表现的最有效工具。如下表格,可以看到业界不同代码类评测基准,包含数据集、支持的代码语言、关键评估指标、支持的评测粒度等各个维度信息。

附:代码任务评估基准

从上述表格可以看到,代码类的评测基准也在逐步演进,从早期的单类型代码语言以及静态指标度量,到近几年支持多种类型代码语言和可执行的度量指标,到今年大模型迸发式发展后,多类型代码语言、多类型指标结合的基准体系。因此在可以预见的未来,代码评测也会成为一个很重要的大模型评测垂类领域。

附:评估基准的演进

2、CodeFuseEval评测基准介绍 

CodeFuseEval是结合CodeFuse大模型多任务场景,在开源的HumanEval-x、MBPP、DS1000评测基准基础上,开发的面向大模型代码垂类领域的企业级多类型编程任务评估基准。可用于评估大模型在代码补全、自然语言生成代码、测试用例生成、跨语言代码翻译、中文指令生成代码、代码注解释、Bug检测/修复、代码优化等不同任务的能力表现。旨在贴近企业实际应用场景,构建一套能够衡量大模型代码生成相关能力的「多维」、「多样」和「可信」的评测基准。

附:多任务评估基准(任务和指标)

当前,CodeFuseEval已开源。本期开放的评测集包括代码生成、代码翻译、自然语言生成代码等多类任务共6300+任务覆盖Java、C++、JS、Python等6种编程语言。同时,开放了配套的环境镜像及框架,欢迎大家体验试用:

评测数据集构建

根据不同的任务类型,我们构建动态代码评测集对当前代码大模型不同类型任务进行持续评估。评测数据集按照来源可分为:开源评测集、内部数据评测集、众测数据、待训数据集按比例划分;

  • 开源评测集:调研选取业界权威机构发布的开源评测集评测代码类大模型,便于与业界进行横向对比如HumanEval-x/wikisql/CoNaLa等,注意开源评测集在纳入评测前需要先校验评测集是否被污染,是否有错误等;
  • 众测标注数据集:根据代码大模型的目标场景及用户,我们构建了基于代码类知识及众测信息的数据评测集,通过组织不同编程语言的专家众测和白名单用户众测,收集并分析这些真实的、贴合实际的、多样的数据补充开源数据集中缺失部分,比如中文场景/计算机学科知识等,建立代码类特定场景的基准便于版本迭代的纵向比较;
  • 待训数据集划分:从准备的完整数据集中按比例切分用来做测试集,划分比例会根据原始数据集大小来调整。
{
  "task_id": "Python/177",
  "prompt": "import java.io.*;\nimport java.lang.*;\nimport java.util.*;\nimport java.math.*;\n\n\nclass ProdSquare {\n    /**\n     * * Write a Java function to check whether the given number can be represented by product of two squares or not.\n     *\n     * > prodSquare(25)\n     * false\n     * > prodSquare(30)\n     * false\n     * > prodSquare(16)\n     * true\n     */\n    public static Boolean prodSquare(int n) {\n{\n        int a = 1;\n        int b = 1;\n        for (int i = 1; i <= n; i++) {\n            if (a * i < 0) {\n                b = b * i;\n            } else {\n                a = a * i;\n            }\n        }\n        return b == 1;\n    }\n}",
  "canonical_solution": "Write a python function to check whether the given number can be represented by product of two squares or not.def prod_Square(n):\r\n    for i in range(2,(n) + 1):\r\n        if (i*i < (n+1)):\r\n            for j in range(2,n + 1):\r\n                if ((i*i*j*j) == n):\r\n                    return True;\r\n    return False;",
  "test": ["assert prod_Square(25) == False", "assert prod_Square(30) == False", "assert prod_Square(16) == True"],
  "desc_en": "Write a python function to check whether the given number can be represented by product of two squares or not.",
  "Difficulty": "mbpp",
  "desc_cn": "写一个函数来检查给定的数字是否可以用两个正方形的乘积来表示。"
}

附1:开源评测集样例(翻译场景)

附2:评测样本prompt(含格式)示例

评测执行框架

大模型的代码能力相比文本评估对执行环境有更强的依赖。当前各个模型的基座、技术路径不尽相同,prompt、模型参数和分词加载策略也有很大差异,模型敏感度稍有不同,结果就不近人意,因此,为了从不同的维度衡量模型的代码类任务,我们的评测框架了增加了适配层的研发、构建了多语言执行镜像、评测基准保鲜策略等,旨在充分了解模型的最佳状态和风险阈值进而指导模型做工程化部署。

附:评测工程化框架

通过主观和客观相结合的方式进行评测包含代码补全、代码生成、代码注/解释等关键能力场景。如代码补全主要根据开发者编写的上下文快速生成符合该上下文的代码段包括函数、变量、表达式、注释等,代码生成则主要根据自然语言描述生成对应的代码实现,代码注/解释则主要根据代码和上下文生成与之对应的自然语言注释或解释等。如下2图,为针对代码生成类任务的客观和主观评测的实现示例。

附1:代码生成(翻译场景)客观评测示例,评测指标pass@k

附2:代码生成主观评测执行示例

3、评测结果示例

各类指标计算示例

详细评测执行过程可参考CodeFuseEval Github README文档

pass@k(功能正确性)

bluert(语义相似度)

bleu(词相似)

codebleu(语法相似)

评测结果可视化

「单任务-多模型-多代码语言」柱状图示例

「多任务-多模型」雷达图示例

4、未来展望

代码生成作为大模型研究的重点场景之一,模型评估见证着它的蓬勃发展。智能代码助理必将加快企业的研发速度,提升企业研发竞争力。代码大模型的评估基准也将从评测模型技术能力和服务能力两个方向四个维度(技能/效能/鲁棒/稳定)持续深入探索。

评测技术方面,我们坚持开放、创新、持续提升评测质量和效能,确保结果的可信度和可重复性,以适应模型快速增长的能力,匹配用户的真实体验。后续也会持续迭代和开放我们的评测基准,请大家保持关注。

参考文献

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值