AI 研发产品进化论:从 AI 编码助手到 AI 程序员
内容介绍
一、通义灵码落地过程中的困难与阻碍
二、不断突破能力上限的核心思路
三、全工程理解:解决精准度问题
四、企业级检索增强:解决个性化问题
五、自定义扩展:解决能力宽度问题
六、智能体:突破代码助手能力上限
本次分享的主题是AI研发产品进化论:从 AI 编码助手到 AI 程序员,由阿里云智能集团资深技术专家陈鑫分享。
一、通义灵码落地过程中的困难与阻碍
今天将与大家分享关于AI编程的话题,分享近一年的进步和领域的技术动态。
近一年以来AI编程领域特别火热。左边有特别多产品提供开发者服务。右边是一张Gartner数据报告,它描述了所有的技术现在处于什么样的阶段,可以看到最顶峰那个点是AI编程辅助。不管是市场表现还是大家的关注度来看,AI编程一定是AI领域最耀眼的新星之一。
阿里云在这里面投入了大量精力改进和完善通用零售化产品。从2023年11月,发布以来到现在,Vs code和jet being公开市场上的插件下载量已经超过了500万。这是一个非常快的增速,并且为中国的开发者提供了被接纳的代码总共超过了10亿行,而且现在每个月都在高速的增长,这代表受到了开发者广泛的喜爱,并且对开发者有了一点小贡献。当前通义灵码已经建设了从IDE插件到核心的能力以及到下面的企业级的管理能力等一系列完整的产品矩阵。核心功能包括大家熟悉的代码补全、问答、全库检索、企业级的rag、模型的微调训练等能力完整齐全,深受客户的喜爱。并且在人工智能大会、Gartner得到了国内外的认可和奖项。
企业在落地编码的过程中不是一帆风顺的,往往会遇到以下四大难题。
第一,AI生成准确度有限,AI生成代码不准确会导致开发者阅读成本比较高。这可能会面临重新阅读AI编码比直接输入编码耗时,这个问题如何解决。
第二,相比于国外的友商到底胜在哪里,有没有能力超过他,让国内的企业顺畅的使用。如企业数据适配的问题,大模型都是基于开放性的数据,类似于Gartner给数据或者开源的数据训练而成。他能够理解企业内部的代码吗?它能够生成符合企业研发规范的代码么?这都是未知数。代码助手往往只能实现代码补全如问答和测试组成等任务。在整个代码开发过程中有大量开发工作,如胶水层代码的批量生成有一个自己的框架。
框架代码如何批量生成、如何看一个SQL语句、它性能如何、如何对SQL语句进行性能优化、如何批量生成测试数据、有非常多的场景如何覆盖。如何拓展在AI编程里面的场景覆盖度的问题。最后一个是如何给老板讲清楚用了智能工具以后对生产效率提升有多大,以及怎么样持续增长。这些是真正落地过程中非常大的痛点。
二、不断突破能力上限的核心思路
第一点是精准度。精准度是这个产品的核心。通过数据、算法、模型、能力不断演进来提升模型和效果。第一点是数据。一定要获取足够多的数据让模型感受到才能推算出符合开发者预期的代码。不但要感受到当前打开功能的所有代码数据,而且还要感受到企业上传的一些规范性程序编写的范式,还需要感知企业内部各种各样的系统数据。如代码库,若需求管理产品,数据库里其他的额外数据能帮助生成更精准的代码。所以数据要收集到足够全,感知要足够全。
第二要有很强的算法,包括代码库、代码的算法、检索算法,如Agent算法。如果生成单元测试解决bug,比如生成提示词。通义灵码设计了好几款模型,包括专门的代码补全模型,专门做各种专项任务的专用模型,如做单元测试、算法优化等都有专用模型。如针对AI程序员训练了一个专用的模型,所有模型构成了现在的核心能力持续严谨的基础,并且都是基于通义大模型的基础上构建的。让大家享受到最先进模型的便利。最后一个是能力,不断扩充通义灵码的能力边界,包括企业级的检索能力、自定义的扩展能力,扩展通义灵码的一些场景包。还提供专属模型训练的能力,这些能力真正符合企业级的特性。
三、全工程理解:解决精准度问题
足够的代码精准度核心思路是全工程理解。如ID打开一个本地代码工程,代码推荐能不能获取这个库里的上下文并且精准定位,是一个非常大的难题。所以获取本地工程的所有信息,包括当前代码上下文工程信息以及即将推荐位置的相关性代码和相似性代码。国外一些友商可能是最近打开几个文件里面的相似和相关性代码,但是通义灵码能获取到整个工程,包括二方依赖和三方依赖。第二个企业势力。企业可以主动干预开发者推荐的代码,比如可以上传一些示例性代码,即规范性代码(约定成熟的通用的业务逻辑)。上传上去可以影响推荐的结果,让推荐的代码更加符合企业规范。这就是数据和感知。模型需要针对感知到的相关性、相似性代码以及工程信息做出精准预测。通过这一系列工作可以精准度变得非常高。
可以看到这是一个数据库的实体表,如果没有相关性代码补全看到d的是一堆无效的字段。这一段SQL是完全没有办法接纳的。如果有了相关性感知就会精准的生成表结构字段,这个叫做相关性的代码补全,可以大幅的消除现在模型的幻觉。第二相似性。在前端场景应用重复性代码,当前工程里面有一个叫bar two tips的组件的。如果没相似性生成的属性是不对的。有了相似性生成的这个属性和在其他文件中写过的是非常相似的,这时采纳率就会变高,也就是说大模型读懂了整个库。通过这样的策略不断提升采纳率。第三个是性能。如果前端有非常大段代码的时,开发者要刻意的去等待。在Vs code中实现了流式补全,在模型返回首包时可以展示整段的代码。首次展现时间可以降低在500ms左右甚至更短,这样的体验让开发者有一种不需要等待的感觉。不需要刻意迎合AI,而是让AI适应我们,这样的体验会更好。通过这一系列的措施,不断优化模型提高数据检索精准度,带来的结果是采纳率不断提升。
从去年11月份百分之十几的采纳率,到现在主流语言已经全面过了30%,并且还在以一个非常快的速度演进。随着基础模型能力升级、颧骨感知的精准度的优化以及一些bad case消除,采纳率还会进一步进行突破。
四、企业级检索增强:解决个性化问题
满足企业的个性化特点就是如何适配企业内部数据。主要技术策略是检索增强。
检索增强提供两个主要的方向,第一个叫代码补全建构增强。代码补全建构增强就是在代码补全过程中可以上传一些代码主动干预它生成的结果。这个时候往往存在相似性逻辑的生成,一段约定成俗的加密的算法或者一个约定成俗的API调用。这时开发者只需要写一个简单的注释,不管是英文还是中文都可以帮他迅速的推荐一些写法,减少重复代码工作量让代码整齐划一。
第二个是自研框架的生成。尤其是前端场景,很多后端场景实际上都是企业内部私有框架。平时开发者在写代码时就会命中这些资源框架的标准化写法推荐出来。代码补全建构增强提供了能力让企业内部的管理员,有可能能够针对企业代码生成的Bad case进行定向消除。如果这个场景下生成代码不是想要的就上传一个这段代码应该生成的标准化范例。这个时候back taste大概率可以被消除掉,企业管理员有这样手段优化采纳率。
第二个是研发问答场景。研发问答场景提供研发文档的问答、API生成代码、规范性代码优化等能力。通过对话的方式检索企业内部的知识。具体的使用场景第一个是前端的资源代码生成,可以看到刚刚那个框是上传到知识库的一个组件库的标准化写法。这时trace ID就可以准确的推荐出trace ID的标准化写法,这是企业通过上传前端自研组件库样例代码产生的效果。内部团队实验可以提升采纳率8个点之多,整个的效果提升比较明显,尤其是在前端场景。在后端同样可以上传一个这样的加密算法的标准化写法。这个时候大模型准确点推荐的标准化写法,可以实现企业内部的知识复用,我们可以主动去干预它的生成。
第三个是企业知识的检索场景。首先演示的是用OSS访问的凭证。先用workspace本地工程问答,然后去库里面寻找oss的访问凭证代码是在AK DEMO test写的,这个时候用workspace进行全库查找,顺利找到了这份代码。这时用企业内的知识库,企业推荐的oss凭证管理的方式有哪些?首先要问一些技术方案。这时通过企业内部的知识库检索,大模型已经推荐了8个文档,这8个文档中列出来的标准的oss访问凭证的管理的方法推荐出来。
这个时候写代码只需要圈选右侧的这串代码,然后让知识库根据推荐使用自动轮转AK的方式把这段代码改掉。它的原理就是企业知识库获得标准化的技术方案以及oss访问的代码的标准化写法,针对它的代码进行编写,并且推荐了一个标准化的程序逻辑以及二方库、三方库的引用以及配置文件应该怎么写。通过这个小的demo给大家演示如何通过企业知识库和开发任务目标顺利完成一个小功能的编写。可以看到非常顺利的让企业OSSAK的管理的方式统一化。
五、自定义扩展:解决能力宽度问题
适配企业内的个性化场景主要通过扩展性,在当前通义灵码的版本已经推出了自定义的扩展指令。自定义扩展指令可以理解为prombed,可以用代码来写,可以连接企业内部系统,可以编程,可以实现非常复杂的业务逻辑,可以实现自定义的扩展指令,未来通义灵码的右键菜单企业可以扩展出10个、20个功能,这叫扩展指令。大量的企业内部信息需要通过插件获取才能够进行代码生成。比如DB的schem,比如get上面的dif,比如说一手,就是代码任务的文本信息各种各样,都可以通过孔门来自用组装,通过程序访问拿到企业内部系统的上下文拼装到prompt里面给大模型进行生成,这个就非常丰富了。
最后是非常高端的,可以自己写一个智能体Agent加入到通讯密码里面去进行扩展。以一个开发者在Java开发时的典型场景给大家做演示。内部团队认为比较常见的一些场景,比如doo模块代码生成,这块的代码生成完全是模式化的。自动读取数据库的表结构,读取DB scheme遵循MY框架把所有的xml map到PU等文件批量生成,实现增删改查。第二个是辅助命名,企业内部有自己的命名规范。有时命名不规范,可读性非常差AI可以辅助命名,这个是AI非常擅长的,以及AI根据代码写出一个漂亮的API文档,然后使用企业团队内部的自定义规范去做代码检查。
第一个场景是代码自动生成。右侧是自定义指令,通过代码化的方式实现了自动访问数据库获取DP scheme以及prompt。左边执行自定义指令就自动的去生成了pu类、map类、相关的道以及my bataste增长改查都可以批量生成。可能10几行代码就可以轻松的实现这个功能,而且具备非常强的扩展性的。这是通过代码化的方式实现自定义指令。
第二个场景是通过白屏化实现更简单的自定义指令。不需要运行程序,它只是一个prompt。在管理后台可以配置prompt,在这里员工就可以使用通义灵码给安全检测模块来取名。这时他就给了一系列的建议,比如给交易系统起名,他同样给出一些命名建议,这是一个非常简单的场景。通过企业后台可以快速的配置一个,这样prompt给到整个企业员工来使用。
第三个场景是API的文档自动生成。写一个自定义指令可以让大模型迅速的根据圈选的这类代码,生成一个markdown文档。这里面详细的描述了API的入参、出参,可以调整prompt生成测试代码,即示例型代码,这样可以快速生成一个漂亮的文档。团队自定义的规范检查同样可以写一个这样的规范,一个固定的prompt让大模型进行整体的检测,可以按照企业内部的特定要求给出相关的注意事项,提醒开发者进行相关的代码修正。可以实现每个企业千起千面或者说千人千面,甚至后面会支持企业内部的一些市场机制,让开发者发挥自己的创造力创造各种各样的自定义的指令。通过这样的方式可以实现各个领域的自定义能力融合到IDE中,甚至像任务提醒写周报,做一些代码的批量生成,做一些异常排查。根据ID里面做的错误信息把一些其他的日志报错信息复制的到自定义指令里面,让通义灵码进行生成测试的辅助代码审核辅助,可以想出各种各样的场景来进行实现。
所有的这些能力都支持SQ可以通过编程的方式来解决,进一步去扩张自定义指令的能力边界,可以实现企业级的自定义指令、团队级的、个人级的甚至是工程级的,实现每个不同层级的场景都可以有自己的个性化特点。通过这种机制进一步扩展通义灵码的开放性。
六、智能体:突破代码助手能力上限
前面给大家简单汇报了一下通义灵码近的一年的进展。今天没有讲第四个话题即如何给企业的老板们讲清楚通义灵码的价值,因为真正能讲清楚的价值实际上是在代码智能体。因为现在通义灵码代码助手都在第一个阶段即copilot。在这个阶段人类其实是完成绝大部分工作的,这时候AI只能帮助完成一些事务性工作。工作流程没有变很多事情还需要人去参与,能提效的幅度就在10%~15%这一部分的效率是很被度量和澄清的。过去有一个非常大的难点即如何能证明通讯零码的核心价值、它的提效比例多大,很难讲清楚。
业界有各种各样的公式,最后大家都会挑出很多的毛病,那改变思路,如果今天AI进入到第二阶段和第三阶段的时候会发生什么,比如一些整块的工作可以完整交给AI来做。如果今天AI能够基本上无人工参与的情况下,独立修复一个bug。这时候修复的整块时间就已经被AI完全解决掉了。比如写一个单元测试需要花10分钟、20分钟。如果AI能够批量编写,也就是说写完这段代码业务逻辑可以一键让他针对新增的代码写出单元测试节约多少时间,这个时间的节省是非常好容易度量的。我们认为真正能讲清楚AI产品带来的价值的时候,一定伴随着第一个特点,就是AI对大片工作的整片替代,可以独立工作。
第二个是它的提效比例已经非常显著。现在通义灵码正在进入第二阶段和第三阶段,这也是今天AI编程辅助必然的技术和产品发展趋势。现在通义灵码已经推出了通用编码AI程序员。这个产品实际上是一个基于多智能体协同架构的新一代的AI编程工具。它可以独立帮助开发者完成代码任务,包括不限于缺陷修复、单元测试生成甚至更高阶的需求实现。在这里要由易到难,逐步的去落地。今天做的不是一个DEMO,不是一个学术性研究的东西,我们要考虑如何能在企业的真正的生产性环境里面去落地的。所以会从由易到难逐步去实现代码场景的扩充。先从缺陷修复和测试用例批量生成这两个场景进行切入来实现,第三个场景可能实现的还不太好,但是会逐步去完善。没关系,我们先把整个场景实现已经非常大价值了。在整个产品定义上来讲明显区分了人和机器所要做的事情的边界,也就是开发者只需要输入要求、确认计划、对AI的所有的plan进行纠偏,最终确认AI做的结果就OK了。AI需要独立完成需求理解、任务拆解、编码实现和自主测试,甚至提交代码。人类主要来做的是把关,而AI要交付成品,这是整个产品的核心的定义。
在这个定义下,有几个具体的技术场景可以实现。第一个是bugfix的agents,在6月份通义灵码在swe-bench的light的测试拿到了33%的解决率。这个测试集实际上是业界证明或者说实验多Agent架构的一个编程智能体,到底能解决多少真实世界的问题,现在这个测试集解决成功率已经被刷到了40%多。我们可以认为在真实世界中,大概有40%多的任务场景或者需求场景是可以被AI独立完成和解决的。在做这个榜单的过程中去做的灵码agent产品化,输出到AI程序员产品里面去,实现了全自动bugfix。
这一套agent体系可以根据缺陷上下文生成可用经过验证的修复的缺陷的代码,并且能自动的提交PR。它的工作原理是能够去读懂这些缺陷是什么,怎么去复现。第二尝试去复现,包括不限于运行测试、运行代码然后尝试复现。复现完了以后做整个缺陷的定位。缺陷在哪、有哪些文件可能会引起缺陷。尝试根据错误的对战以及缺陷的描述去进行缺陷修复。修复完以后再提交murder request由人类去code。在这个过程中,他有多次的跟人类的交互以及进行自我的迭代来最终实现这个效果。在内部的测试集上也做了测试,通过设计的这一套人机交互模式,可以在测试集中达到大概40%左右的缺陷解决成功率,也就是说有40个是可以完整解决的。但是现在这个数值还不是特别高,还在努力提升。这是第一个缺陷自动化修复。第二个场景大概在10月份左右推推出。UnitTest Agent做全自动化的单元测试生成,也就是说单元测试是AI比较擅长的,比较容易切入的场景,并且能够大幅的去提升整个的代码质量。这也是很多头部公司非常关注的一个领域。实现UnitTest的能力提升要对模型进行专项训练。
训练这个模型主要解决几个问题,第一个,要控制单元测试生成的数量包括它分支的覆盖要教会模型什么才是一个好的覆盖率。
第二个规范性,Java的given的单元测试这样的范式,我们要教会模型生成,可读性会比较高,会比较规范。
第三个,保证单元测试框架的支持,原来的大模型经常会把ju unit4,Ju unit unit5各种各样的不同的框架搞混导致编译不通过。要教会模型不同的框架如何生成正确的测试。这个要通过模型训练以及做agent如何对编译错误进行修复等等这些问题,通过一系列的这样的模型训练。实际上通义灵码已经能够做到单元测试的一次性编译通过率大概在40%左右。这是业界非常高的一个数字。但是生成了40%还有60%的单元测试生成是编译不通过的,还要人为去修改代价还很大,能不能实现接近于100%的单元测试的编译通过率,甚至是运行通过率能不能做到。这个时候就必须使用Agent技术,通过agent建立一个复杂的工作流,这里面包括生成、编译、尝试运行、搜索失败问题进行自主定位最终给开发者一个报告,生成了哪些、覆盖率如何由开发者最终来确认和采纳。在这个过程中是一个自主迭代的生成,通过这样的技术可以确保编译生成的一次性通过率甚至是运行通过率达到一个非常高的数值,甚至可以实现整目录、整库针对代码地锁变更批量化生成大幅提升代码质量。
这个片子演示了如何进行缺陷修复,首先描述了各种各样的缺陷,AI会自动读取问题,找到一些具体复现步骤。开始尝试拉取代码,自动下载代码库到一个环境里面,尝试进行确认定位。这时已经产生了一个plan,即这个缺陷在哪、如何对这个缺陷进行修复,这时由人类进行确认,确认完了以后由AI生成修复片段,最终结果由人类确认。这时AI会生成code review提交到代码平台里边,由开发者或审核员进行真实的代码审核。通过这样的方式由AI来确认问题,复现问题,找到它的缺陷位置在哪,然后由人类确认修复方案再真实地进行修复,修复完之后再由人类确认修复的问题是否满足预期,大体符合预期之后自己在进行测试工作,最终完成端到端的修复过程。这个叫做自动化确认修复,这个功能已经在AI程序员产品中上线了,现在开启了校测过程。欢迎广大开发者体验产品,这个产品还是一个雏形,还需要时间的打磨。针对各种各样复杂的模型场景模型训练和专项调优,最终达到一个非常高的解决率时会将产品正式上映到通义灵码中以供开发者使用。