通义灵码AI编码助手和AI程序员背后的技术

简介: 通义灵码AI编码助手和AI程序员背后的技术,由通义实验室科学家黎槟华分享。内容涵盖三部分:1. 编码助手技术,包括构建优秀AI编码助手及代码生成补全;2. 相关的AI程序员技术,探讨AI程序员的优势、发展情况、评估方法及核心难点;3. 代码智能方向的展望,分析AI在软件开发中的角色转变,从辅助编程到成为开发主力,未来将由AI执行细节任务,开发者负责决策和审核,大幅提升开发效率。

通义灵码AI编码助手和AI程序员背后的技术


内容介绍

一、编码助手技术

二、相关的AI程序员的技术

三、代码智能方向的展望

 

本次分享的主题通义灵码AI编码助手和AI程序员背后的技术,由通义实验室科学家黎槟华分享。

今天分享内容更多是通义灵码背后算法的相关技术。第一页是背景的引入。在大模型的软件工程或者是代码领域落地,是一个顺畅,且确定性比较高的事情。我们投入很多,通讯灵码想解决的就是开发者的开发效率,提升开发软件工程效率以及开发者自己能力的边界,从而使整个团队或者整个企业开发效率提升。由此将AI大模型对软件工程的影响分为了三部分,第一部分还没有大部分的额度高,开发者开发工具可能一些基金规则,基于一些简单审理网络的情况,小模型时代的工具配合的阶段。

第二个阶段是 developer 加上 copilot 阶段,现在相关的AI相对比较成熟。有了AI大模型的加持,使得AI可以充当copilot的角色,与开发者进行结对编程,帮助开发者提高开发效率。

最后一个阶段是我们未来往前走的一个阶段,AI的pilot加上人类的指导审核的阶段。AI在以后会成为开发的主力,开发者会担任更多的决策指导和审核工作。这些比较宏观的工作由人来做,比较细节的比较脏活累活的工作让AI做这样可以提高开发者开发的效率,同时也可以扩展开发者的能力边界。原来一年的程序员的产出,可能加上AI的加持之后,变成3.5产出是未来发展方向

今天分享的内容分为三部分:第一部分是编码助手的技术,第二部分是相关的AI程序员的技术,最后是代码智能方向的展望。

 

一、编码助手技术

1.构建优秀ai编码助手

其中,第一部分将重点介绍如何构建优秀的AI编码助手,包括评价和构建方法,以及注意事项。在编码助手中,有单元测试,集成模式训练等多个技术,我们将聚焦于代码生成补全这一最刚需的场景,这也是开发者最常使用的功能之一。根据相关报告,编码阶段是开发者耗费时间和精力最多的阶段,因此,AI在这一阶段能够解决的问题,将极大地帮助开发者提高效率。第二个是在自己的编码助手的统计可以发现在代码的补全采纳的函数上其实显著要多于问答。技术更能帮助开发者提升他的效率。

场景是几乎所有的AI的编码工具都会先做的场景。但是这样的场景并不是非常好我们想象中的特别简单的一个场,因为大家都做,所以觉得简单,但实际不容易。

2.代码生成补全

2.1面临挑战

代码的生成补全面临着真实挑战。总共有两个方面。第一个方面是保障代码的生成质量。第二方面契合开发者的行为,这两方面一起加起来才能去做生成补全的能力。质量是首先要面临的挑战。如果质量不好,就面临很多最基础的语法错误导致很多逻辑的错误。导致语法没问题,但是所写的跟业务逻辑不对,有代码幻觉。类没有API也没有成员变量。还有版本的错误,这是一个比较隐秘的错误。

比如刚才举个例子是这juni4和juni5,它是完全不一样的API的内容,spring的老版本2.2点多,可能和spring的三年级可能又是一个非常大的差别,还有vue等等。所以代码大模型必须要去感知到相关的版本,才能保障生成质量。在生成质量上,我们做了很多的工作,包括下面的高质量的代码的对齐做代码的postraning去做跨文件的感知,去做内固的版本,都是为了解决质量的问题,这其实是一个最基础的内容。所以我们要去重点去做的,需要很多时间和资源,第二方面契合开发者的行为。

只做好第一个质量问题,只是解决了一个学术界的问题。比如大模型怎么生成一个好代码。需要加上后面的契合开发者的行为,才能形成一个产品。如果没有契合开发者行为,就会导致生成的代码不知道什么时候停止,不知道要写一行还是多行,不知道要写一个类,还是写一个函数。开发者体验会非常不好。

第二风格混乱,可能别的工程都是驼峰的命名,补全的内容是下划线的连接,可能完全不一样。第三重复造轮子有一个工具类,已经写好比如说日期处理,当前补权的时候,正好要一个日期处理。结果自己做了一个日期的格式化的操作。没有调用原来的函数就变成了一个重复造轮子,造成这种重复代码到处都是。虽然质量没问题,也能执行正确的,但是它不符合开发者想要的内容。最后过度打扰。在一个光标的位置,模型要识别这一行是否完整了,如果不完整,应该补全。完整了就应该补全一个空,应该不补全,不输出任何的内容才是正确的,不要去打扰开发者的顺畅的行为。

因为开发者在一个光标的时候,他虽然停顿了,但他预期的内容不是一个补权的代码,而是思考下一行怎么写。这是一个开发型的。我们在开发情况下也做了很多包括自适应的力度的生成,比如相似度的ig都是为了解决风格问题,不要重复造轮子的问题,相关性的代码,还有场景的巨型生成。比如某些情况,模型不生成才是对的。我们做了很多的工作,我们自己感觉在质量上大家都会注意引进。开发者的行为上,其实我们做了很多去提升开发者体验真正的带来效率提升的内容。

2.2解决方案

有了上面的一些挑战,和我们想要解决方案,那怎么评价。传统的评价包括PV15,glasU这些数据去做一些代码上的补权的模型校验。但是更多的是给出注释和签名,生成函数内容,场景太过单一,和真实的场景还是有很大的区别。我们提出了一些代码生成补权的数据集。我们在真实的场景去在开发者的真实的场景里面去做出非常多的差异化的场景。跟真实的距离很小,才能去真实评价我们代码生存的质量和契合开发者的行为。这种情况下,我们就提出了多个的政治场景下行为前提下,生成质量的评价方式。

那么我们什么样的行为才是契合开发者的?我们做了一些统计,我们有两个简单的维度,其实还有很多维度。但是这两个维度我觉得已经很具有代表性了。补全是代码不当成补权长度的需求的分布,可以看到有几乎50%的是希望能补全单行,就可以了。也是很多编码助手,可能默认的行为他碰到了一个回车,他们就停止了。其实天然的具有50%的契合行为。但是还有50%,包括行内的补全就是他一半还有完整的多行补权。比如补全一个函数补全一个类,还有11%,其实是我们很早就注意到了巨石在某种情况下不应该补出任何的内容。

第二个是生成力度的需求,也就是说开发者在开发代码的过程中,主要在写什么。比如说70%接近70%是一个一条语句、逻辑语句。还有很多的是类函数,还有ifelse语句。我们要在评价一个代码大模型的时候要去考虑到这些,不能仅仅都是评价一句单句的语句。比如说if里边的条件究竟对不对。然后注释续写对不对,inport 语句能不能知道要写什么,然后写上,这些都是我们要去考虑的评价维度。

我们怎么去构建。首先是我们希望拿到真实的业务的数据。真实的业务的数据。比如getup上有很多的仓库,但是这些仓库很多都是类库级别的。它是一个工具类。但写业务代码的时候,可能会更多的是写一个什么系统,业务逻辑和类库的逻辑还是不太一样的。然后第二个是我们要根据刚才的分布,根据经验去筛选出非常多的分布的场景,才能去正确的评价。然后第三个就是我们评价的时候,即使要考虑这种生存的正确性,也要考虑开发者行为。所以我们构建了一个整个的链路,通过恢复牌子的调用链,通过去挖空,通过去最后单侧的执行去得到最终的评价结果。基于这样的数据集,我们其实在评价了很多的模型,这有取得了一个比较典型。

我在这样的测试级的情况下,那么大部分模型在数据的生存质量上其实都是不错的。但是其实没有契合开发者的行为,导致分数会比较低一些。然后可以考虑到其实靠3.5还是非常强的。但是在这数据上其实表现的不太好。

然后其他的模型还是各自的表现。那么最后就是tuonima编码助手,目前的效果应该大家都看到过相关的数据了,我这里就不再去赘述

 

二、相关的AI程序员的技术

1.优势

第二部分是相关的AI程序员的技术。这里想讲的是AI程序的优势,他能解决什么样的问题。然后第一个就是AI编码助手是有一定的局限性的。他虽然能提高开发者的效率,但是还有一些局限性的。也就是说我们的基础的大模型加上代码的大模型,它其实能去做很多的任务,包括代码的补权、单侧等等,也能形成很多的产品。但是他有几个缺点。我们在代码的大模型的基础上,首先是不了解用户的仓库。不了解用户的仓库,不是整体不存在功能,而是在模型本身有代码大模型本身不是通过仓库的级别来训练的,它更多的是一个文件,一个文件。知道语法的正确性,知道语言知道走向逻辑,但是他不知道多个逻辑文件之间的关联。一个甚至是跨语言之间的关系。

比如说一个xml和一个java spring的一个类,他们之间是什么关系。大模型本身其实不是特别了解。所以我们需要去建立这样的关系,去让模型本身学会到,然后再通过外围的这种环境给他这些信息的时候,才会学会正确的利用。

第二个就是大模型它其实在训练的时候没有去了解过环境交互。不知道什么叫编译正确或者是什么叫运行正确。他没有和环境交互的信息,也没有学会如何使用编译或者堆栈的爆破去修复相关的代码都是因为没有环境交互,最后对软件工程的整个过程没有了解的概念,他不知道要去先去编码,得到一个高质量代码,再去调试,再去验证等等这条链路。所以不知道如何去规划,后面怎么去解决。我们希望让大模型本身就具备这样的能力,再在产品上,在整个工程链路上去加上相关的内容。

2.AI程序员发展情况

这一页讲的是说国内外的AI程序员的发展,包括今年四月份的发布的相关技术。然后这次引起了代码领域的相关内容比较火的一个点。有评价的指标,比较广泛的一些学术界的方案。比如swit agent左边其实是学术界的方案包括acrotercoler。右边是工业界的,比如说DEVON.date works等等。这些其实都是基于地缘模型,要么就是gpd四,要么四o要么是close3.5等等。那么其实在国内的产品已经没有办法使用,而且他们在Agent框架上可能还不是特别适合我们在产品落地的时候使用。

3.评估AI程序员

那么怎么去评估一个AI程序员?目前我们暂时使用的是学术界的方法。学术界的评估的是swebanch。方法是从gethub里面收集真实的内库issue。也就是用户提交的一些bug,或者是新需求等等。这些东西收集回来之后,让模型去根据issue去生成patch解决issue。然后最后单元测试通过之后执行正确了才能去算是解决问题,然后解决了问题百分比。就是整个AI的加上大模型的整体的AI城区的质量是怎么样的。

这样一个banch其实是非常有挑战性的,包括实际上是真实的项目,不是人均捏造的一些问题。因为这些真实的问题是人在写代码的过程中无意产生的,它就是人真实的反应。

第二个是说问题是真实的。

第三个就是这条链路很复杂。包括理解仓库,做代码的生成,做fly安装环境,并且执行最后ug正确了,我们才解决问题。然后榜单其实刷的很快,是去年的一个榜单。

今年DEVIN出来之后火起来了。从四月份到现在,其实从原来的最开始的非智能体的basline百分之几的解决率到现在智能体的解决方案,从10%多一直提升到40%多。然后我们自己的相关技术也在今年的6月份6月22号的时候提交了一个结果,然后拿到当时的说法,但是很快就被迭代被超过了。然后现在最高的结果其实是40%多的结果。

所以从榜单的发展迅速,也可以看到AI程序员的整个赛道其实是非常受大家关注的。刚才那个榜单更多的是学术界的。我们现在需要把学术界的内容落地到真正的产品里面。所需要做的探索可能远远要比学术界的打榜困难很多,包括考虑模型的效果,考虑响应的时间。不能让用户等10分钟才出结果。要考虑可干预性,考虑推理的成本。这些看起来可能是一个产品落地的过程。但是这里面的每一步可能都需要模型的机制上与与其一起配合,所以是联动的很紧密的一个过程。我们整个链路包含了几个关键的词,一个是大模型,一个是环境交互,在软件工程里面可能就是编译器、执行器、语法检查等等。

然后还有就是planing,比如说怎么去规划,解决一个复杂任务,怎么去拆分。然后最后就是memory,也就是说我有没有一些经验可以使用,有没有一些很长的上下文,后面会用到的,提前去做一些记录。对,就这几部分会构成agent。现在这里列出的是两大最核心的部分,就是大模型agent和环境。会参考软件工程的典型比如说先去设计,然后再去生成代码,再去测试,再去验证等等流程来设计整个链路。

4.AI程序员核心难点

4.1数据构建

过程中,有四个难点。首先第一个就是软件过程的数据构件。然后第二个是项目感知。然后第三个是解决方案的生成,最后是缺陷的复线。然后这四个内容我后面会分别讲。

第一个是软件过程的数据,是整个事情里面最核心的部件。也就是说大模型可能目前来说还不能达到人类简单的几个样本,它就能去做,还是一个需要数据微算力的一个过程。所以数据的收集是这里面非常重要的点。因为代码任务其实是所有的任务,包括创作什么之类的,它是为数不多的记录了中间过程迭代的记录的事物发展完善过程的一个数任务。

中间有需求的文档有问题,有解决方案,有变更有更多东西是过程记录的。其他的任务包括创作,包括这种角色扮演,其实他没有这样的数据,所以代码任务也是得益于这一点。所以他的数据收集相对于这种思考过程的数据收集可能比其他领域要更简单一些。

里面包含了这种需求、设计、缺陷、提交等信息我们需要去做收集,体现了人在解决问题里面是怎么思考的也会通过过程的数据去教会模型应该怎么去解决问题。对过程我们分成两个部分,一个是软件开发更多的是一个0~0.8的过程。第二个是软件演化,0.8~1的过程。最后软件演化就是不断地去修一修去迭代、去版本升级。比其他任务要简单,但依然很难。因为软件过程记录的数据仍然有限,会丢失很多细节。比如要找到某个软件的设计需求文档非常困难,可能更多是关于问题和解决之处。

之前的数据收集可能只是粗糙收集,之后还要进行真正的数据提炼。我们收集的数据大部分是代码仓库,加上缺陷和需求描述以及解决缺陷的描述,但中间设计的哪些文档、如何召回变更点,即计划是什么,先做什么后做什么,以及如何调试通过等过程完全缺失。我们要通过合成数据的方式,利用合成数据的概念复现中间各个环节,让模型了解解决需求到提交代码的思考过程。这里只是框架图,实际涉及很多内容,因时间关系不展开。我们根据数据构件训练了一个验证版本,比如lingma swegpt和lingma agent在相关榜单上的解决率低于部分基于先进模型的结果,但也有一定成效,对研发效率提升有帮助。

因为闭圆的模型解决率可能达到40%多,其背后是GPUO或3.5等模型。我们自己训练的模型基于千问数据,但不是新模型而是之前的模型,wide大概为19% wide file中解决率为25%。即该模型在数据集上能自动解决20%无需人工干预,解决25%的相关问题。虽然解决这些问题可能很困难,但实际上解决了25%,在真实复杂系统中可能会降低,但自动解决20%多对研发效率提升是个好消息。

4.2项目感知

上面是数据收集和相关训练的结果。这一部分是项目感知,由于代码库很大,可能有上千个文件,无法直接放入大模型,确定变更点很困难。大家提及召回、检索、IG,但代码问题的变更不是简单检索过程,而是推理出解决方案,是否要修改以及哪里修改能解决问题,最好还有验证过程,所以这是较难的部分。

所以我们提出了蒙德卡罗空间的项目感知方式,通过构建蒙德卡罗数,一步一步确定代码片段。判断候选代码片段与缺陷描述是否有关系,大模型进行此判断,并通过卡门卡罗数构件逐渐确定,明确修改此处可解决问题。同时,利用函数间调用、类间同属关系以及文件与类的同属关系构建自信度扩散,通过这些关系确定要修改三个文件中的三个函数及三个位置,从而解决问题。这是一个详细的过程,并且我们还形成了一篇论文,可在阿卡上查看,这是项目感知部分内容。

4.3解决方案

解决方案生成方面,已知要修改的位置后,需正确修改代码。首先要设置正确的代码,可能要先进行第一步,第二步,第三步。因为代码间有依赖关系,最好先写具体实践内容再进行调用,这样会更顺畅。之后要考虑如何将其他代码合并到过程中,可能需要新增文件,新增函数,要确定新增文件和函数的放置位置,这需要模型考虑。通过实践和探索,确定了一个在检查计划在生存代码生成中的三步思路,每步可人为干预调整内容,最终形成一个较可产品化的链路,降低了对模型的要求和难度。

4.4缺陷复线

最后一个是缺陷复线。前面提到很多操作如检索、设置代码,但不运行无法判断对错,而运行前需明确运行什么。有人提议跑单侧,但在解决问题时,需先确定运行哪个单侧才能覆盖问题。所以要先进行缺陷复线,这是运行测试的基础,只有明确标准答案,才能让模型探索解决方案。

在学习修复过程中,同一项目可能存在相似缺陷。由于同一种语言有迹可循,可利用这些相似之处复用经验,比如解决加法、go、psy等问题时的经验可复用。为提高复线效率和准确度,我们提出基于经验复用的方法。先用大模型复现相关内容,然后对比运行结果是否一致,如期望结果和实际结果是否相同,若报错一致则可能正确复现了问题。正确复现后,提取经验并编辑合并到经验库,形成大模型该经验库可能是企业或语言独有的,作为长期记忆。

在解决问题时,可通过项目或语言找回相关经验进行复现。有了缺陷复线,就能明确正确答案和修改位置,中间过程大模型可能多次迭代,若迭代过多,人可干预,从而减少工作量,明确对然后是我的问题是什么?我的标准是什么?这样的话比较能去解决问题。

上面是AI成员一些困难的核心点,我们做了问题探讨和解决方案思路探讨。最后是对代码智能发展方向的探索和未来预判。

 

三、代码智能方向的展望

从三个阶段来看,我们的判断是:以前软件开发会有团队合作等困难,现在逐步引入AI,能否让AI生成解决方案,人进行判断,依赖AI可扩充软件开发的成功率和效率,这依赖超大算力。我们倾向于形成人继续开发、人审核的人力工程模式。例如在需求阶段,AI做自动需求分析,人确认和沟通,然后逐步走每个流程,AI和开发者相互配合。这是后续的判断,通讯部门会朝着提升开发者和企业开发效率的方向前进。

 

目录
打赏
0
11
13
0
1007
分享
相关文章
如何抓住本世纪伟大成就AI的风口脱颖而出?AI到底会带来什么影响?AI对程序员的影响?AI对软件行业的影响?——2025年如何抓住AI的机会-成为AI工程师-程序员可成为高级AI工程师
如何抓住本世纪伟大成就AI的风口脱颖而出?AI到底会带来什么影响?AI对程序员的影响?AI对软件行业的影响?——2025年如何抓住AI的机会-成为AI工程师-程序员可成为高级AI工程师
169 54
SHMT:体验 AI 虚拟化妆!阿里巴巴达摩院推出自监督化妆转移技术
SHMT 是阿里达摩院与武汉理工等机构联合研发的自监督化妆转移技术,支持高效妆容迁移与动态对齐,适用于图像处理、虚拟试妆等多个领域。
48 9
SHMT:体验 AI 虚拟化妆!阿里巴巴达摩院推出自监督化妆转移技术
AI时代的网络安全:传统技术的落寞与新机遇
在AI时代,网络安全正经历深刻变革。传统技术如多因素身份认证、防火墙和基于密码的系统逐渐失效,难以应对新型攻击。然而,AI带来了新机遇:智能化威胁检测、优化安全流程、生物特征加密及漏洞管理等。AI赋能的安全解决方案大幅提升防护能力,但也面临数据隐私和技能短缺等挑战。企业需制定清晰AI政策,强化人机协作,推动行业持续发展。
39 16
阿里云通义实验室自然语言处理方向负责人黄非:通义灵码2.0,迈入 Agentic AI
在通义灵码 2.0 发布会上,阿里云通义实验室自然语言处理方向负责人黄非分享了代码大模型的演进。过去一年来,随着大模型技术的发展,特别是智能体技术的深入应用,通义灵码也在智能体的基础上研发了针对于整个软件研发流程的不同任务的智能体,这里既包括单智能体,也包括多智能体合并框架,在这样的基础上我们研发了通义灵码2.0。
103 21
现场领红包!通义灵码 AI 程序员给大家送福利啦
「AI实训营」大咖共学课新春专题来啦!巳巳如意,“福从天降”!本期为迎春节共学专题,大咖带你玩转通义灵码,0 基础带练“福从天降”小游戏!更有现场红包等你拿,速来上手通义灵码 AI 程序员!!
AI实践:智能工单系统的技术逻辑与应用
智能工单系统是企业服务管理的核心工具,通过多渠道接入、自然语言处理等技术,实现工单自动生成、分类和分配。它优化了客户服务流程,提高了效率与透明度,减少了运营成本,提升了客户满意度。系统还依托知识库和机器学习,持续改进处理策略,助力企业在竞争中脱颖而出。
33 5
BladeDISC++:Dynamic Shape AI 编译器下的显存优化技术
本文介绍了阿里云 PAI 团队近期发布的 BladeDISC++项目,探讨在动态场景下如何优化深度学习训练任务的显存峰值,主要内容包括以下三个部分:Dynamic Shape 场景下显存优化的背景与挑战;BladeDISC++的创新解决方案;Llama2 模型的实验数据分析
通义万相:视觉生成大模型再进化
通义万相是阿里云推出的视觉生成大模型,涵盖图像和视频生成。其2.0版本在文生图和文生视频方面进行了重大升级,采用Diffusion Transformer架构,提升了模型的灵活性和可控性。通过高质量美学标准和多语言支持,大幅增强了画面表现力。此外,视频生成方面引入高压缩比VAE、1080P长视频生成及多样化艺术风格支持,实现了更丰富的创意表达。未来,通义万相将继续探索视觉领域的规模化和泛化,打造更加通用的视觉生成大模型。
用AI Agent做一个法律咨询助手,罗老看了都直呼内行 feat.通义千问大模型&阿里云百炼平台
本视频介绍如何使用通义千问大模型和阿里云百炼平台创建一个法律咨询助手AI Agent。通过简单配置,无需编写代码或训练模型,即可快速实现智能问答功能。演示包括创建应用、配置知识库、上传民法典文档、构建知识索引等步骤。最终,用户可以通过API调用集成此AI Agent到现有系统中,提供专业的法律咨询服务。整个过程简便高效,适合快速搭建专业领域的小助手。
139 21
智答引领|AnalyticDB与通义千问大模型联手打造社区问答新体验
PolarDB开源社区推出基于云原生数据仓库AnalyticDB和通义千问大模型的“PolarDB知识问答助手”,实现一站式全链路RAG能力,大幅提升查询效率和问答准确率。该系统整合静态和动态知识库,提供高效的数据检索与查询服务,支持多种场景下的精准回答,并持续优化用户体验。欢迎加入钉群体验并提出宝贵意见。
智答引领|AnalyticDB与通义千问大模型联手打造社区问答新体验

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等