AIGC+软件开发新范式

AIGC+NewParadigmofSoftwareDevelopment20242024更多内容，进入阿里云云原生官方公众号了解趋势洞察04更多内容，进入阿里云云原生官方公众号了解01当「软件研发」遇上AI大模型02谈谈我对AIGC趋势下软件工程重塑的理解2003微调工程师岗位可能并不存在，但使用AI编码工具已经成为刚需36AI程序员系列4104我们团队来了一位新同事，主动要求帮忙敲代码！欢迎AI001号4205阿里云首个AI员工入职，围观开发工程师使用反馈4406“AI程序员入职系列”第二弹：如何利用通义灵码光速改写项目编程语言？4607通义灵码实战系列：一个新项目如何快速启动，如何维护遗留系统代码库？4908通义灵码牵手阿里云函数计算FC，打造智能编码新体验09国内唯一！通义灵码入选全球智能编码助手使用率TOP榜单5710阿里云参编业内首个代码大模型标准，通义灵码获2023AI4SE“银弹”案例59 大家好，我是通义灵码的产品技术负责人陈鑫。过去有八年时间，我都是在阿里集团做研发效能，即研发工具相关的工作。我们从2015年开始做一站式DevOps平台，然后打造了云效，也就是将DevOps平台实现云化。到了2023年，我们明显感觉到大模型时代来了以后，软件工具将面临着彻底的革新，大模型和软件工具链的结合那它第一个落脚点在哪？实际上就是辅助编程，所以我们就开始打造了通义灵码这款产品，它是一个基于代码大模型的的AI辅助工具。今天我借这个机会和大家分享通义灵码技术实现上的一些细节以及我们如何看待大模型在软件研发领域的发展。我会分为三个部分来分享。第一部分先介绍AIGC对软件研发的根本性影响，从宏观上介绍当下的趋势；第二部分将介绍Copilot模式，第三部分是未来软件研发Agent产品的进展。为什么我会提到CopilotAgent，稍后我给大家讲解。这张图是我过去几年画的一张图，我认为企业研发效能的核心影响因素是这三点。第一点是人员技能。人员技能决定了企业研发效能的一个非常大的因素，比如说谷歌可以招聘到个人能力强于他人十倍的工程师，一个人等同于十个人，那由一群十倍工程师组成的一个小团体，战斗力就很强，甚至可以实现全栈，他们的角色分工可能就非常简单，工作非常高效，最终的效能也非常大。但是实际上我们企业内部，尤其是中国企业，没有几个能够达到谷歌的水平。这是客观影响因素，我们认为人员技能是效能基石，当然也是效能的破局点。第二点是协同消耗。在我们不可能要求每个工程师能力强大的基础上，每个人一定是有专业分工的，比如有些做软件设计，有些做开发、做测试、做项目管理。这些人组成的团队随着软件架构的复杂度越来越大，组织的复杂度也会正相关的变大，这就造成了协同消耗也会越来越大，最终拖慢了整体的研发效能。第三点是成本控制。我们发现做项目的时候人员不可能总是富裕的，永远是缺人手，也不可能有无限的资金去招到十倍工程师，所以这也是一个制约因素。今天在AIGC的时代，这三个因素已经产生了一些根本性变化。在人员技能上，通过AI辅助可以快速将一些初级工程师的能力提升。这个其实在国外是有一些报道的，初级工程师使用了代码辅助工具的效果是明显高于高级工程师的，为什么呢？因为这些工具对于初级工作的替代，或者说它的辅助效果是非常好的，所以它可以快速补齐初级工程师的能力短板。在协同消耗上，如果今天AI能够变成一个超级个体，实际上它对流程协同消耗的降低是有帮助的。比如一些简单的工作就不需要跟人打交道了，AI直接就可以做，也不需要给每个人都讲一遍需求应该怎么测试，AI做简单测试就可以了，这样时间的效率就提升了。所以可以通过超级个体去有效的降低协同消耗。在成本控制上，实际上AI大量的用法就是代替事务性工作，包括现在用代码大模型去做代码辅助，也是希望代替70%的日常事务性劳动。那具体来看的话，会有这四个挑战以及智能化的机会。第一个是个体效率，刚刚也给大家介绍了，大量研发工程师的重复工作和简单沟通都可以通过AI来完成了，它是一个Copilot模式。另外一个协作效率，一些简单的工作直接让AI做，可以使协同消耗降低，这点刚刚我已经讲述的比较清晰了。7第三个是研发体验，过去DevOps工具链关注的是什么？一个接一个拼成一个大的流水线，拼成整个的工具链。其实每个工具链在不同的企业里可能有不同的使用习惯，甚至有不同的账号体系、不同的界面、不同的交互、不同的权限。这种复杂度给开发者带来了非常大的上下文切换成本和理解成本，这在无形中让开发者其实很不爽。但是在AI时代发生了一些变化，我们可以通过统一的对话入口，用自然语言的方式去操作很多工具，甚至在自然语言的窗口里解决很多的问题。我举个例子，比如过去查一个SQL到底有没有性能问题，我们应该怎么办？可能先在代码里面把SQL语句抠出来，把它变成一个可执行的语句，再放到一个DMS系统里面诊断一下看看它有没有用索引，有没有问题，然后再人工判断一下到底要不要改这个SQL去优化它，最后再到IDE里把它变更掉，这个流程需要切换多个系统，要做很多的事情。那在未来，如果我们有代码智能工具的话，就可以圈选一个代码，问大模型这个SQL有没有问题，这个大模型可以自主的调用一些工具，比如DMS系统去分析，并且拿到的结果可以直接通过大模型告诉我SQL应该如何优化，直接告诉我结果，我们只需要采纳它就可以解决，整个操作链路会被缩短，体验就会提升，从而提升研发效率。第四个是数字资产，过去大家写了代码放在那都变成了屎山代码或者说是负债，当然里边有非常多优秀的金矿没有被挖掘出来，然后还有很多文档想要找的时候找不到了。但是在AI时代，我们做的最重要的事之一就是需要去梳理我们的资产以及文档，通过SFT、RAG的方式去赋能给大模型，让大模型变得更聪明，更加符合企业的个性化理解，所以今天这种人机交互方式的变化，会带来体验上的变化。人工智能从刚刚的几个影响因素再往下拆，它核心是带来了三种人机交互方式的变化。第一种是AI会变成一个Copilot，和工具进行结合，到第二阶段，实际上大家应该有共识了，它变成Agent，也就是它具备了一些自主完成任务的能力，包括自主写代码或者做测试。其实工具扮演的是一个多领域专家，我们只需要给定上下文并完成知识对齐即可。第三个阶段我们判断AI可能会变成一个决策者，因为在第二阶段决策者还是人，在第三阶段有可能大模型会具备一些决策能力，包括更高级的信息整合分析能力。这时候人会更多的聚焦于业务的创意和纠偏，很多事情都可以交给大模型做。通过这种不同的人机模式的变化，让我们整体的工作效率会变高。还有一点是我们刚刚讲到的知识传递形式也发生了根本性的变化。在过去是通过口口相传、通过培训，老带新去解决知识传递的问题。未来很有可能不需要这样，只需要让模型具备业务知识和领域经验，让每一个开发工程师都使用智能化工具，它的这些知识就可以通过工具传导到研发过程中，就会变成右边图上所示的现在DevOps的一站式工具链。积累了大量代码和文档资产后，将这些资产梳理清楚跟大模型放在一起，通过RAG、SFT，模型嵌入到DevOps工具的各个链路，从而又产生更多数据，形成了这样的正向循环，一线开发者在这个过程中就能享受到资产带来的红利或者说能力。以上就是我从宏观的角度介绍了现在大模型影响研发效率的核心因素，以及两个最重要的形态改变：第一个是人机交互的形态发生了改变，第二个是知识传递的方式发生了根本性变化。现在由于各种各样的技术限制以及大模型发展阶段的问题，我们做的最好的还是Copilot人机交互模式，所以接下来就介绍下我们的一些经验，如何去打造最佳的这种Copilot人机交互模式。我们认为代码开发的人机交互模式，目前只能解决比如小任务的问题、需要人工采纳的问题、这种频次非常高的问题，还有短输出的问题，不会说一下子就生成一个工程，甚至不会一生成一个类，我们每次都是生成一个函数或者几行。为什么要这样来做呢？其实和模型本身能力的限制有很大关系。因为我们现在上下文宽度还非常有限，假如要完成一个需求，没有办法把所有的背景知识全部交给它一次性搞定，所以要不就是通过Agent去拆成一堆的小任务，逐步解决。要不就在Copilot模式里让它完成一个最简单的工作，比如按照一个注释去生成一小段代码，这样我们叫做解决小任务。在人工采纳上，人工现在必须对代码大模型生成的结果做判断。目前做的好的可能也就是30%-40%的采纳率，也就是说我们有超过一半的生成代码实际上是不准确的，或者是不符合开发者预期的，所以要不断的消除幻觉问题。但是让大模型真正能在生产级使用最重要的还是要人工确认，然后高频次是不要生成太多，每次生成一点，因为人工去确认这段代码是否ok的成本也是影响效能的，后文会讲一些我们的思考和我们做的事情，通过高频次去解决准确性率有限问题。另外短输出主要是考虑性能和成本问题。现在代码助手这种模式，实际上是特别精确的命中了大模型的一些技术限制，才让这样的产品能够快速落地，它有一个非常好的时机。在我们看来，开发者最喜欢的Copilot模式，是以下四个关键词：高频刚需、触手可及、知我所想、唯我专属。第一个是我们要解决高频和刚需的场景，这才能让开发者觉得这个东西是真的有用，而不是个玩具。第二个是触手可及，也就是随时可以唤醒它，随时可以帮我们解决问题。不再像以前需要通过各种搜索引擎去搜索代码，它就像在我身边一样，随时可以唤醒它帮我解决问题。第三个是知我所想，也就是它回答我问题的准确度，以及它在什么时机回答我的问题都是非常重要的。最后还要为我所属，它能懂我私有的一些知识，而不是说只了解完全开源的东西。我们把这四点具体再展开讨论一下。高频刚需我们需要判断什么是软件研发最高频的场景。我这边有一些真实的数据，第一个数据来自JetBrains在2023年做的一个开发者的生态报告，整理了开发者最耗时的活动，其中可以看到百分之七八十都是编写代码，理解代码及互联网搜索、调试、写注释、写测试。这几个场景实际上就是代码智能工具的功能，像通义灵码这样的产品最核心解决的问题，其实就是最高频的问题。后面这两个数据是通义灵码线上几十万用户的数据分析。我们现在线上采纳的代码，73%来自于补全任务，27%来自于问答任务的采纳。所以今天大量的AI替代人去写代码，还是在IDE的行间生成，这是从真实的情况下反映出来的一个结果。后面是使用问答功能的比例，有76%的比例是来自于研发问答，剩下的10%是代码优化和解释代码等等一系列的代码任务。所以绝大部分的开发者还是在使用我们的工具去问一些常用的研发知识，或者通过自然语言的方式让代码大模型生成一些算法，解决一些小的问题。其次的23%才是我们真正的一些细节的代码任务，这是给大家一个数据洞察。因此我们就有了核心的目标。第一，我们要解决好代码生成的问题，尤其是在行间生成。第二，要解决研发问题的准确度以及专业性问题。触手所及我们最终要讲的是打造沉浸式编程体验，我们希望今天开发者绝大部分的问题都可以在最终写上代码复制放到IDE里面调试编译，不通过了再去查，这样的话就会非常耗时。我们希望能在IDE里面直接问大模型，让大模型帮我生成代码，这样体验就很爽。我们通过这样的一个技术选择，解决了沉浸式编程体验的问题。补全任务是一个性能敏感型任务，它的输出需要在300到500毫秒，最好不要超过一秒，所以我们有一个小参数模型，它主要是用来生成代码的，而且它的大部分训练语料也来自于代码。它虽然的模型参数很小，但是在代码生成的准确度上非常高。第二个我们要去做好专项任务，我们还有20%~30%实际上的任务是来自于这些，包括注释生成、单元测试、代码优化、运营错误排查等七项任务。我们目前使用了一个中等参数模型。这里主要考虑的，一是生成效率，二是调优。一个非常大参数的模型，我们调优的成本是很大的，但是在这种中等参数模型上，它本身的代码理解和代码生成效果已经不错了，所以我们选择了中等参数模型。然后在大模型上面，尤其是我们70%多的研发问题回答上，我们追求的是高精度，而且追求的是实时的一些知识。所以我们通过一个最大参数的模型，叠加了我们的RAG技术，让它外挂了一个近乎于实时的基于互联网的知识库，所以它回答的质量和效果就非常高，并且能大幅消除模型幻觉，提升回答质量。我们通过这样的三个模型支持了整个沉浸式编程的体验。第二点是我们要实现多端，因为只有覆盖了更多的端，才可以覆盖更多的开发者。目前通义灵码支持VScode和JetBrains，主要解决的是触发问题、展示问题，还有一些交互性问题。最核心层次下面，我们本地Agent服务是一个独立的进程。这个进程跟上面的插件之间会进行通信。这个进程最主要解决的是代码核心的一些能力，包括代码智能补全的部分，会话此外，语法分析服务也非常重要，我们要解决跨文件引用的问题等，都需要语法分析。如果我们要做本地的检索增强，我们还需要轻量级的本地向量检索引擎。所以整个后端的服务实际上是通过这样的方式就可以快速的实现扩端。这是可以脱网去做的，包括JetBrains最近也上了一个跑在本地的小模型。通过这种方式，也会保证我们的一些数据安全隐私问题，比如本地的会话管理、本地的存储，全部都放到了本地电脑上知我所想知我所想对于IDE插件这个工具而言，我认为有几点。第一是触发时机，在什么时候触发，对于开发者体验的影响也非常大。比如我在空格的时候要不要触发？IDE已经生成提示的时候要不要触发？在删除这段代码的时候要不要触发？我们大概有超过30~50个场景去梳理，到底在这个场景上要不要进行代码触发，这部分通过规则就可以搞定，只要一点点细心去摸索，去调研开发者体验，就可以解决，这不是很高深的技术。但是在代码生成长度方面，我们认为是比较难的。因为在不同的编辑区的不同的位置，它生成什么样长度代码，直接影响了我们的体验。如果开发者只是倾向于生成单行代码，带来的问题就是开发者不能理解整个生成的内容，比如生成一个函数，他不知道这个函数到底要干什么，生成一个if语句，他不知道if语句里边的业务逻辑是什么，就没有办法完整的判断功能单元，影响了他的体验。我们用一些固定的规则去做，也会导致一个问题，即它会比较死板。所以我们的做法实际上是基于代码的语义信息，通过训练的方式，经由大量的样本，让模型理解了今天在什么场景下应该生成多长，我们实现了由模型自动判断类级别、函数级别、逻辑块级别及行级别的生成力度，我们把它叫做自适应的生成力度决策。我们通过做这项大量的预训练，让模型去感知，从而提升了生成的准确度，这块我们认为也是一个比较关键的技术项。再往下最关键的就是如何去消除模型的幻觉，因为只有幻觉得到足够的消除，才能够提升我们的采纳率。所以我们一定要实现基于库内的跨文件上下文感知，在这里，我们做了很多的基于代码的语义分析，引用链追踪，相似代码以及动态语言类型推导等。最关键的就是想方设法的去猜开发者在这个位置补全他可能需要什么样的背景知识，这些东西可能还会涉及到一些语言、框架、用户习惯等，我们通过各种各样的东西将它的上下文获取出来，并且进行优先级排序，把最关键的信息放到上下文里面去，然后给到大模型进行推导，让大模型去消除幻觉。通过这样的技术就可以实现跨文件上下文感知的测试集，我们的准确率从22%提升到了66.9%，我们还在不断的去精进提升补全的效果。最后一个是我们本地的库内检索增强。刚刚其实也说了，上下文感知也只是猜测开发者在触发位置的上下文。更多的场景是今天开发者要问一个问题，让大模型基于本地的库内所有文件去帮我解决一个问题，比如帮我修复一个bug，帮我增加一个需求，帮我填充一个文件，自动实现增删改查，甚至帮我的Prompt文件增加一个新的包的版本，类似这样的需求其实有很多，要实现的话实际上是要给大模型外挂一个检索引擎。因为我们不可能把整个工程的文件全部塞给大模型，因为上下文宽度的影响，我们必须使用到一个技术，叫做本地的库内检索增强。这个功能就是来实现我们基于库内的自由问答的，在本地去建立一个库内的检索增强服务，我们判断这样的方式对于开发者的体验是最好的，安全性也是最高的。代码不需要上传到云端，就可以完成整个链路。从整个链路上来讲，开发者问一个问题以后，我们就会去代码库提取需求的关键信息进行任务拆解，拆解完了做本地的向量检索召回，然后再做检索的结果合并及重排，以及去企业内部的数据知识库检索，因为企业有统一的知识库管理，是企业级的。最终把全部的信息汇总起来发送给大模型，让大模型去生成和解决问题。唯我专属我觉得企业要想让代码大模型真的能实现一个非常好的效果，都逃不过这一关。比如如何实现企业数据的个性化场景，比如在项目管理阶段，如何能够让大模型按照需求/任务/缺陷内容的一些固有的格式和规范去生成，帮我们实现一些需求的自动拆解、自动续写、自动总结等等。开发阶段可能是大家最关注的，经常有企业会讲要有符合企业自己的代码规范，引用企业自己的二方库，调用API生成SQL，包括使用企业自研的一些前端框架、组件库等等，这些都属于开发场景。测试场景也要生成符合企业规范的，甚至是理解业务的测试用例。在运维场景，要时刻查找企业的运维知识，然后去回答，去获取企业的一些运维的API快速生成代码。这些都是我们认为要做的企业数据化个性化场景。具体的做法是要通过检索增强或者微调训练的方式来实现。在这里我列了一些简单的场景和需要注意的事项，包括代码应该怎么处理，文档应该怎么处理，代码过来要进行过滤、清洗、结构化，然后才能够可用。在我们训练的过程中，要去考虑开放域数据和私域数据的混入。比如我们要去做一些不同的参数调整，在检索增强上，我们要考虑不同的检索增强策略，我们其实也是在不断的进行探索，包括如何在代码生成场景里面命中我们所需要的上下文信息，以及我们在问答场景里面如何去命中我们需要的回答的上下文信息，这属于检索增强。我们要做的就是企业级的检索增强方案，企业级的检索增强方案目前的架构图大概是这样。中间是知识库的管理服务，包括数据解析的调度、问题的理解、整理回答、结构化的解析、数据分块等等，核心的能力在中间这块，向下是我们比较常用的Embedding的服务，包括大模型的服务、向量的存储和检索。向上是我们管理的一些后台，在这个场景下支持了我们关于文档的检索增强以及代码生成的检索增强。代码生成也就是补全这个场景的检索增强它所需要的处理方式和技术跟文档其实还是略有不同。过去我们跟复旦大学也做过几年的学术研究，非常感谢他们的付出，我们也有一些论文在发表，当时我们测试集的结果也是用一个一点几B的模型，再配合检索增强，它实际上的准确率和效果就可以达到一个大概7B以上模型的同等效果。我们认为未来软件研发一定会进入到Agent时代，也就是说它具备一些自主性，并且它可以非常容易使用我们的工具，然后理解人类的意图，完成工作，最终会形成一个如图所示的多智能体的协同模式。就在今年三月份，Devin的诞生其实让我们感觉到这个事情真真实实的被加速了，我们从来没有设想到这个事情能够完成一个真实的业务项目，我们过去都没有想象到，甚至我们都觉得这个事情可能还要一年以后，但是它的出现让我们觉得，今天真的可以通过大模型拆解数百上千个步骤，并且一步一步执行，出现问题它还可以自我反思，自我迭代，和推理能力让我们非常意外。随着Devin的诞生，各个专家学者就开始投入，包括我们通义实验室，马上发起的一个项目叫OpenDevin。这个项目在短短的几周内star数就超过了2万，可以看到大家对这个领域非常的热情。然后马上开源了SWE的Agent项目，把SWE-bench的解决率又推升到了断在这个领域的学术研究会非常快，我们大胆猜测一下，很有可能在2024年年中左右的6到9月份，很有可能SWE-bench的解决率会超过30%。我们大胆猜测一下，如果能够达到百分之五六十解决率的话，它的测试集实际上是一些真实的Githubissue，让AI完成Github上面的issue，可以去修复bug，去解决需求的这样一个测试集。如果这个测试集能够让AI的自主完成率达到百分之五六十，我们认为真的是可以在生产级中落地了。至少一些简单的缺陷可以交给它来修复，这是我们看到的目前业界的一些最新的进展。但是这张图也不是马上就能实现的，现在从技术路线上来讲，我们会沿着这四步逐步实现。第一步我们现在还在做单库的问答Agent，这个领域是非常前沿的，我们现在在做单库的问答Agent，近期会上线。下一步我们希望推出能独立完成编码任务的Agent，它的作用主要是具备一定的自主规划能力，可以使用一些工具去了解背景知识，能够自主的完成单库范围内的编码任务，还不是跨库，可以想象一个需求有多个代码库，然后前端也改、后端也改，最终形成一个需求，我们觉得还很远。所以我们先实现单库的编码Agent，下一步我们会去做测试Agent，测试Agent可以基于代码Agent的生成结果，自动完成一些测试任务，包括理解任务的需求、阅读代码、生成测如果这两步的成功率做的比较高的话，我们就会进入到第三步。让多Agent基于AI调度共同完成任务，从而实现从需求到代码到测试的全流程自主化。从工程的角度来讲，我们会一步一步这么来走，确保每一步都达到一个比较好的生产级落地，最终去做产品。但是从学术来讲，他们研究的速度会比我们更快，现在我们是从学术、工程讨论的，我们还有第三个分支就是模型演进。这三条路就是我们现在阿里云和通义实验室一起联合在做的一些研究。最终，我们会形成一个Multi-Agent概念架构，用户可以跟大模型进行对话，大模型可以进行任务的拆解，然后有一个多Agent协同系统。这个Agent可以外挂一些工具，它有自己的运行环境，然后多Agent之间可以互相协同，它们还会共享一些上下文机制。这个产品图会分为三层。最下面是基础层，对于企业来讲，可以先把基础层做好。比如现在可以引入一个代码大模型，我们虽然没有马上实现AIBot，但是现在已经具备了IDE代码生成插件的这些能力，已经可以做一些工作了，就是Copilot的模式。Copilot模式在基建层上面，进化了Agent这一层，实际上基建是可以复用的。该做的检索增强、微调训练和知识库，现在就可以做起来了。这些知识的梳理，资产的积累，是来自于原来DevOps平台的积累。现在就可以通过一些提示词工程的方式，将现在基础的能力层跟整个DevOps工具链进行结合。我们做了一些实验，在需求阶段要想让这个大模型来实现一个需求的自动拆解，我们可能只需要将过去的一些拆解数据，还有现在的需求拼成一个prompt给大模型，大模型就可以比较好的去完成拆解并且完成人员的分配。在实验中发现，结果的准确率还是蛮高的。其实现在整个DevOps工具链，并不需要所有东西都要用Agent或者都要用Copilot。我们现在用一些提示词工程，就有很多场景可以马上去赋能，包括我们在CICD过程中的自动排错，在知识库领域的智能问答等都可以实现。DevOps平台透出，甚至在我们的IM工具里面透出。它实际上是一个拟人的智能体。本身这个智能体它会有自己的工作区，在这个工作区里我们的开发者或者说管理者可以去监控它到底是如何帮我们完成代码编写的，如何帮我们完成测试的，它到底在互联网上获取了什么样的知识去完成工作，会有一个它自己的工作空间，最终实现整个任务的完整流程。今天给大家带来的话题是AIGC趋势下的软件工程重塑。今天这个话题主要分为以下四大部分。第一部分是AI是否已经成为软件研发的必选项；第二部分是AI对于软件研发的挑战及智能化机会，第三部分是企业落地软件研发智能化的策略和路径，第四部分是我们现有可落地的工具，在这一部分我也会重点介绍通义灵码整体的产品能力和概况。这张图是我过去几年画的一张图，我认为企业研发效能的核心影响因素是这三点。这张图是麦肯锡最近发布的一个研究报告，大家可以看到他把软件工程列在了整张表格的右上角，也就是影响最大、影响速度最快的一部分。他为什么会有这样的观点？这是因为在大模型时代，我们发现大模型在代码生成和整体的逻辑推理方面是特别擅长的，所以涌现出了类似GithubCopilot这种非常有代表性的智能编码工具，可以瞬间提升大量企业开发工程师的研发效率，而且Copilot是至今为止在世界范围内商业化最成功的大模型的领域之一。这位美国的KOL，他也有同样的观点。他认为在大模型时代，可能有大量的技能会被替代，我们10%的技能会被1000倍的提升，这个跟我们的观点是相似的，尤其是在大模型时代，大模型可以大量地替代开发者的日常事务性工作，这部分的占比很可能超过70%，让开发者得以聚焦于剩下30%的业务和技术的创新。这张图给大家展示的是前一段时间JetBrains的一个调研报告，他们在26500名工程师之间做调研，想看一下今天有多少开发者已经开始熟练地使用生成式AI工具，这份调研也出乎很多人的意料，调研显示，现在84%的开发者已经在或多或少地使用生成式人工智能工具了。其中有哪些场景是开发者最耗时，也是最想提效的场景？他们在这里也做了一个调研，就如左图所示，首先是编码场景，然后是理解代码，接着是互联网搜索，也就是查询各种各样的研发问题，以及进行调试、编码注释、写测试、代码评审等等一系列的工作。这张图大家可以看到，有哪些场景是AI助手辅助频率最高的？解释代码、生成测试等等。其实大家可以发现这一个调研的结果跟上一个其实是非常吻合的。也就是说在我们最高频的场景下，AIGC其实能起到非常关键的作用。这也是为什么代码智能生成工具已经逐步成为了每个企业必须采用的一项产品的原因。这张图也是微软针对GithubCopilot用户发放的一份调研问卷，了解他们使用类似AIGC的代码助手对整个的研发效率或者说研发体感有多少提升，可以看到有很多指标都是80%以上的，或者接近80%。其实我们也针对通义灵码的使用者发放过类似的调研问卷。有超过80%的用户都感觉到使用工具以后生产力有了大幅的提升，跟这个调研报告也非常吻合。根据前面的调研报告和后面相关的调研数据，大家可以看到，在世界的开发者范围内，AI已经成为了开发者的必选项，我们软件研发的未来一定是AI驱动的场景。在2023年6月，我们组织过一次大规模的专家研讨会，在这个研讨会上大家都在讨论智能化未来对软件研发或者软件工程领域的深刻影响。在这个会上，我们有位专家提出了一个观点，他认为软件工程是人类历史上第一次大规模的集体智力的协作活动，它本身是有本质的复杂性在的。例如《人月神话》的作者所讲的，他认为软件本质的复杂性是现在软件系统中无法规避的内在特性，比如复杂度、一致性、可变性和不可见性。在过去的若干年，为什么软件效能或者说研发效率提升非常困难，就是因为这些维度没有得到非常好的解决。今天在大模型时代，通过AI逐步地去替代人类的事务性工作后，它可以起到非常大的改进作用。我们总结下来有以下四大方面。第一，是对个体效率的提升。例如我们可以采纳类似AI的智能代码助手，它可以大幅的代替研发人员的重复性工作、简单性工作。我们认为它是一种Copilot的模式，辅助各个角色去提升自己的工作效率。第二，是对协作效率的提升。因为有很多专业的分工，它们之间存在一些效率的竖井，互相沟通协作的一些偏差等等。当AI逐步地去替代事务性工作，并且形成了AI为主、人为辅的编程模式的时候，大家会发现一些角色的分工可能会出现模糊化。比如产品经理写完了需求，是不是可以马上交由AI去完成大量的编码工作，然后由工程师进行校验，测试人员进行简单的测试回归，AI也可以起到非常重要的测试作用，接下来就可以顺利的发布上线。如果是这样的一个以AI为主、人为辅的模式，其实人和人之间的沟通协同问题就可以很好地解决。第三，是研发体验的提升。在大模型时代，我们会构建软件研发的智能化大脑。这个大脑的表现可能是一个对话框，或者是一个对话形式。这个对话框会成为我们很多操作工具的入口。们写代码的一个入口。同样在我们原来的DevOps工具上，也会有这样一个对话的入口。在这个入口里我们可以完成很多工具的操作，解决很多问题。它有效地使现有的工具散乱问题得到了解决，统一了整个操作入口。第四，是数字资产的提升。过去企业内部有很多优质的代码、框架、规范等等，很难瞬间交给开发者，让每一个开发者去遵守。接下来我们会将这些数字资产利用检索增强或者微调训练的方式跟大模型结合起来，不断地在大模型上积累这些资产，而不是使现在产生的代码成为负债，这些积累的资产可以让软件工程师的效能进一步提升。通过这样的方式形成正循环，就可以大幅提升研发效率。在上图的右侧，大家可以看到每一项的改进，实际上都在解决软件研发的一些本质复杂性。比如说一致性问题、可变性问题、复杂性问题和一些知识显性化问题等等。因此我们认为，AI对于软件研发的影响是深刻的，尤其是在未来3到5年，软件研发的流程和软件研发范式会出现颠覆性的变化。大模型目前已经在深刻的改变智力协作模式，比如说现在常见的代码翻译，从我们的自然语言进行编程，像一些简单的需求，现在可以直接让大模型完成编码。但是现在复杂的业务需求还没有办法完成。不过随着大模型技术的发展，解决这个需求其实就是时间问题。第二个是知识检索。在海量的知识里，通过对话的方式可以快速地找到相关知识，由大模型输出，变成顺滑的自然语言。第三个是头脑风暴。其实这是现在开发者最常用的功能之一。比如使用通义千问时，让它给我写个算法，然后不断的纠正它，让它按照我的意图去修改代码，最终就会形成一个可以直接拿来用的代码片段，这个大家现在已经用得很熟练了。第四个是大模型非常擅长的整理归纳。我们可以用它来整理我们的需求、整理文档和知识，这四种模式实际上已经在改变我们的智力协作模式。在未来，我们主要有以下三种方式可以和AI进行协同。第一种是聊天模式，可以和AI聊我们的需求架构、编程思路，让它给我相应的建议。第二种是实时模式，在编码过程中大模型可以在背后给我相应的辅助，它是实时性的，帮我发现错误、推荐代码。第三种是伴随模式，也就是它随时随地可以被召唤出来完成一些事务性工作。比如帮我们做代码评审、异常排查等等，这三种模式会成为未来的主流。从技术的角度来看，我们也认为会有以下三大趋势。第一个是基础模型的变化，越来越长的推理上下文以及越来越大的参数量。其实现在GPT4、GB3.5、GB4都是非常大的千亿级的参数，包括现在的通义千问、通义灵码也是如此。随着模型的参数量越来越大以及推理上下文越来越长，模型它能感知的知识以及它能处理的任务会越来越复杂。现在它可能还只是完成一些简单的编程任务，在未来很有可能会完成复杂需求的编写。第二个我们认为它在向纵深去拓展，更深度的去接管编码过程。比如GithubNext上面的一些项目，我们可以看到未来的一些趋势。比如让大模型去预测下一个编辑位置，让大模型直接完成需求到代码的自动编写以及我们甚至可以通过自然语言描述的方式，让大模型编写好一个框架，直接生成整个代码，也就是说实现自然语言编程。这些在业界都有相应的探索，大家有兴趣的话可以去看相关的Demo，还是非常酷炫的。第三个是我们认为现在已经在逐步的向横向扩展，也就是说会贯穿到DevOps的整个链路。比如可以用大模型进行辅助的文档查阅、生成评审、辅助编写，大模型已经开始逐步渗透到软件工程的各个领域。对于企业而言，在这个AIGC或者说大模型爆发的时代，应该如何去落地研发智能化，它的路径和策略是什么？看到这张图，我们可以跟过去十年的软件工程模式说再见了。因为在过去，我们一直追求的是整体的DevOps全链路一站式体验以及构建效能洞察数据体系，去找到效能改进点，不断推进研发效能提升。在未来十年，我们认为是以大模型为驱动的智能化软件研发体系，也就是有智能化的软件研发工具链，及大语言模型和相关的数字资产，再配合智能的决策辅助，去帮助企业大幅提升软件研发效率以及突破现有的效能瓶颈。在这里我们推荐企业采用三个阶段来逐步构建研发的智能化。阶段一，可以先引入DevOps基础大模型去构建研发智能大脑。如我们通过编码场景，在IDE的编码助手的场景中进行落地。为什么我们会选取这个场景？是因为我们发现大模型目前的技术瓶颈，还没有办法实现一些非常复杂的大面积的编码。但是在跟人类pair的场景下，它就可以起到非常好的作用。比如说代码续写，圈选一段代码去进行单元测试生成、代码注释生成，这些都非常擅长，而且它的效果也非常好。所以说我们认为可以在这个场景先进行切入，先去落地，取得最大的效能红利，我们把这个过程叫做Landing。阶段二，我们建议是以长期效率为核心，持续的治理和构建个性化数据。也就是说要实现企业的模型个性化，提供全量、全要素的数据，比如优质的代码数据，优质的业务文档数据，将这些数据收集起来，构建企业个性化的数据集。再通过检索增强或微调训练技术跟大模型结合起来，构建一个企业私有的研发大脑。我们把这一步叫做Growth。阶段三，要以大模型为中心，完成整个研发工具链的智能化升级。比如将研发领域的各种工具都接入大模型，进行智能化的整体改造，实现端到端的智能化，进一步的代替各种研发工程师的事务性工作，我们把这一步叫做Expanding。从阶段一、阶段二到阶段三，循序渐进的这种模式是我们比较推荐的。现在一般企业都有整体的软件研发的全生命周期管理的工具链，也有沉淀出来的企业非常好的一些数字资产。将数字资产跟大模型结合，进一步去赋能工具链，然后工具链又可以正向地产生更多的资产，因此形成一个循环，让效能越来越高，这就是我们期待的一个模式。在需求阶段、编码阶段、集成测试阶段、发布部署阶段、咨询学习阶段、效能管理阶段等各个阶段实现智能化升级。首先可以在编码阶段进行切入，逐步向测试阶段、发布部署阶段进行扩展。像一些和需求与业务连接的复杂场景，可以放到最后去进行提升，通过这种方式逐步落地，最终实现端到端的智能化改造。接下来我讲一些简单的场景，给大家参考。例如我们可以实现智能的项目管理，可以实现细化需求，拆分子需求，智能的指派负责人，拆比如在代码评审场景，可以实现智能化的推荐评审人、描述和标题生成、摘要生成、大评审拆分、代码检测、修复方案的生成以及冲突的自动修复。相当于有一个AI评审员，帮助完成了很多复杂的授信工作，而人类进行最终的确认就可以了。做代码评审，这些都可以做。然后像图上蓝色部分，我们也有一些技术方案可以在现阶段大模型的技术基础上落地。我们也可以做智能化的平台工程。比如说我们有一些场景：K8syaml的辅助编写，CICD的编排辅助，构建错误排查，部署过程排错，异常代码定位和运维知识问答。最终去实现配置编排→CICD→部署过程观测→异常排查，整个CICD主链路的智能化改造，我们把它叫做智能的平台工程，这些点我们都可以在现阶段进行落地了。最后一个是智能的研发问答，我们可以实现统一的问答入口，将企业的知识跟大模型结合在一起，以后所有的工程师首先会想到在这个入口去问各种各样的知识，然后获得实时的答案。以及可以做代码的文档搜索，不管是文档还是代码都可以问，甚至可以让它在这里帮我生成业务代码，包括自然语言的操作、个人的智能助理，这些都是马上可以落地的一些场景。最终，我们就在企业内部形成了这三重结构。最上层就是应用层，也就是研发工具应用和服务，它其实是一个以大模型为核心的工具和服务。中间层是模型层，我们要构建一个核心的企业个性化的大脑。最后还要有技术和算力，现在阿里云在公共云上提供了非常强大的GPU算力，未来我们可以直接上云来享受这一部分的AI给大家带来的技术红利。最后我们认为在大模型时代，要坚守以下这四个原则。第一是要以数据为先，高质量的数据输入会让大模型越来越聪明。所以对企业而言，未来非常大的工作量就是梳理研发资产。比如代码资产、文档资产等，首先要对它们进行梳理，识别出哪些是优质的，哪些是不优质的。然后将最优质的部分过滤出来，输入给大模型进行相关的知识沉淀，这些知识它就不会消失了，也不会形成负载，而是顺利地去赋能新员工或者其他的角色，实现相关的效能提升。第二要坚持以人为本，AI并不是来替代人的，而是让人更加专注于自身擅长的业务和技术创新。所以企业应用了AI工具以后，企业的创造力会越来越强，跑得越来越快，这是我们认为最重要的。而且现阶段AI是没办法替代人类的，它只能解决人类目前的一些事务性工作。第三是安全合规，这个是我们非常重视的。尤其是通义灵码构建的时候，特别注重代码的隐私安全。对企业来讲，应用大模型的时候也要充分考虑这一点。第四我们希望是持续收益。大家不要希望今天引入大模型的智能化软件开发工具链后，就可以实现质的提升，现在的产品还没有发展到这个程度，而且技术还有相应的瓶颈。所以我们可以采用Landing、Growth、Expanding三步走的方式，持续的前面给大家介绍了企业落地AI智能研发的相关路径。现在我们再进一步来看，当下有哪些事情可以做。在这里推荐每个企业都应该去应用智能编码工具，通义灵码就是其中非常优秀的代表。现在给大家介绍一下通义灵码。通义灵码是我们去年在云栖大会上重磅发布的一款基于代码大模型的新一代智能编码助手，这个工具主要有以下两大部分的能力。我们可以在左侧的这个框里进行随意的问答。比如让大模型帮我生成一个算法，解答各种各样的智能的问题，研发的一些问题它可以瞬间找出相关的答案，再通过多轮会话的方式去纠正它。右侧就是编辑框，可以在里面输入中文的一些注释，或者输入代码，这时候由大模型去预测我即将写什么代码，并且给我相关的答案，如果我觉得OK就可以采纳。通过这样的方式我们可以和大模型进行配合，相当于它是一个助手，不断地猜我想要什么，从而提升写代码的效率。通义灵码主要包含三大核心功能：第一个是代码智能生成。可以进行行级、函数级的自动续写、单元测试生成、自然语言生成代码、代码注释生成等。第二个功能是研发智能问答。研发领域的自由问答、异常报错智能排查、代码的优化建议等等，这些都是可以做的。第三个功能是企业个性化能力。刚刚讲了Growth阶段其实就是需要构建一个企业私有的研发大模型，我们可以在这里面实现代码和文档的检索增强以及专属模型的微调训练，通过这样的方式去构建企业的个性化能力。但使用AI编码工具已经成为刚需03本文节选自QCon北京特别策划圆桌节目，内容摘自阿里云通义灵码产品技术负责人陈鑫在圆桌对话里的精彩回答。全文见：Sora很难跟进？微调就不是一个岗位？大力出奇迹将继续适用？大模型将对软件生态带来哪些变化？员未来一段时间将被淘汰。陈鑫（神秀去年，ChatGPT火了以后，我们立即开始着手利用大模型技术进行代码智能生成方向的工作。在此之前，我们已经有些探索，我们团队大约在2021年开始尝试代码工都无法超过当时GitHub的投入。随着大语言模型的火热，我们意识到这个方向的商业化价值以及给开发者带来的价值都是巨大的。因此，去年年初，通义灵码就成为通义系列大模型产品家族的一员。通义灵码是一款基于通义大模型的智能编码助手，提供自然语言生成代码、单元测试生成、代码优化、注释生成、智能问答等能力，通义灵码上线4个月，目前下载量已经超过130在国内AI编码工具领域使用率第一。但是，从最开始的产品发布、到现在灵码的产品能力获得用户的一致好评，这中间我们经历了非常多的困难。最开始，我们尝试了基于开源模型，然后基于通义的基础模型进行训练，这其中挑战与机遇并存。一方面，我们感觉与GithubCopilot的差距在逐步缩小，但我们也非常担心出现Sora这种情况，即突然有一个全新的架构或算法来颠覆我们之前的努力。另一方面，从国内接受度来看，最近一些媒体包括我们自己也进行了广泛调研，发现开发者对AI编码工具的接受度非常高，甚至有报道称80%到90%的开发者都在采用相关工具，这就意味着这种生产力工具对开发者的价值是实实在在的。代码智能生成工具可能是业内最成功的大模型相关应用之一。我们现在跟很多客户接触，客户也觉得在基础模型的落地上需要探索很多场景，解决方案的复杂度很高，而代码模型的门槛非常低。我们发现大模型代码生成在IDE编码场景下非常适合当前的技术现状，因为不仅用户的接受度高，而且特别适合当前的技术现状。我认为它在这个领域的成功可能是必然。我们最近访谈了很多企业，发现一些先驱型企业已经在思考如何使他们的代码框架和研发模式适应AI。这可能是许多人未曾思考过的问题，如今AI对代码的理解方式还存在一定局限性，但我们可以通过一些调整让AI生成的准确率更高。我们最近访谈的一个客户，他们的做法是让高级工程师用自然语言编写伪代码，然后将其定义好的数据和接口与自然语言注释一起交给大模型生成代码。然后初级工程师对其进行修正，这样提高了研发效率，也提升了高级工程师的价值。初级工程师的效率也得到了提升，整体上提升了专业性，不再是一个人从头到尾完成。这种方式避免了重复工作和精力浪费，企业未来可能会考虑采用所谓的AI原生（AINative）研发模式。国外一些项目已经尝试使用自然语言框架，按照AI理解的方式生成代码，大模型帮助生成整个工程的代码，生成的代码既有注释又有代码，这样如果出现变更，大模型可以很容易理解它自己生成的代码，形成良性循环。我认为这可能会在一年内实现，随着基础模型能力和理解力的提升以及AI原生编程框架的发展，可能会出现全新的代码编写模式。开放模型拥有广阔的前景，大模型未来的竞争很可能是流量入口之争、是生态之争。而谷歌是否会将陈鑫（神秀在模型开源方面，阿里云做了很多工作，包括开源了7B、14B等模型，前几个月还开源了72B和72B模型的1.5版本。我们内部也是通过外面媒体得知有新版本的消息，之后才进行模型的升级。我觉得阿里云在开源领域非常用心，特别是在通义团队这边。开源模型对企业，尤其是中大型企业的整体业务能力构建起到了关键作用。有了开源版本，企业可以以较低的成本进行实验，而不必花费大量资金购买商业化模型。企业可以先利用开源模型做一些实验，并结合一些Prompt的调优，就可以得到比较好的结果。从我对企业的观察来看，开源对大模型产业的推进非常关键。我担忧现在模型参数量的增加会带来更大的算力需求。虽然开源模型的参数量越来越大，但企业面临的最大难题仍然是缺乏足够的算力。即使是2B模型的训练成本也很高，而现在很多企业甚至连推理资源都买不到，更别说进行训练了。企业需要考虑在公共云上构建训练，而不是自建。很多企业过去可能不考虑上公共云，但是现在这个问题可能会长期存在。企业需要权衡自建和使用公共云的成本，并考虑自建是否会导致错过竞争优势。虽然现在各个厂商都在推动开源，但是将开源的价值真正落到企业的生产效益中仍然面临许多挑战。但我相信各个厂家已经意识到了这一点，并且可能会在未来几个月推出更多的芯片，希望能够解决企业面临的算力问题，包括云上算力的问题，希望我们能够尽快度过这个难关。越高。陈鑫（神秀这个话题我们非常感同身受，因为代码大模型的质量与高质量数据息息相关。提升模型本身的能力主要依赖于高质量数据，而代码领域又是一个专业的领域。过去几个月，我们花费了大量时间和资深专家去处理数据，只有将数据处理到足够好，才能获得更好的调优结果。代码优化是一项艰巨的任务。我们需要确定有问题的代码，解决bug后优化的代码，优化的原因可能是风格问题、内存泄漏或安全性问题等。数据收集、处理和分析是关键，对下游任务的影响很大。我们在调整大模型以准确预测开发者行为和生成期望结果的过程中，需要处理大量数据，包括各种语言的语法分析、切分和数据构造等。预训练过程中可能会发现数据处理中的bug，导致生成代码中出现语法错误或不合适的情况，需要返回修正。这一工作量较大且需要资深专家。刚开始的阶段，人们可能认为数据标注不需要大量人工，会考虑使用AI代替，但随着深入了解，发现这些看似容易的事情实际上还是需要专家去做。未来，有经验的程序员可能会投入更多时间到企业内部的数据标注和处理，并训练企业专属的代码模型，以生成符合企业规范要求的代码。GitHubCopilot过去一直未推出企业个性化套件，直到最近才推出了类似于私有化模型的训练方法，通义灵码的个性化套件也将在4月份上线。我们预测接下来的趋势是，各个企业的员工可能都在尝试使用AI工具进行编码，随后各公司可能需要专人投入到数据处理和标注，以训练企业私有模型。对于专家和工程师来说，尤其是那些曾经从事代码框架、中间件、规范、基础SDK和API开发的人，他们首先会将这些内容编写出来，然后将这些内容融入到大模型中，以便所有人都能从代码生成中受益，这是未来各企业需要考虑的重要问题。通过公共云平台获取算力是算力紧缺的当下值得企陈鑫（神秀在代码领域，我们观察到一个明显的趋势：具有较大参数量的模型（例如72B）在推理能力和理解能力上，尤其是处理长上下文方面，表现得比小参数模型要好得多。例如，当你要求模型为1,000行代码生成注释或单元测试时，小参数模型可能在处理前一两百行代码时还能保持正常，但随后性能会逐渐下降，甚至可能出现偷懒、忘记任务或开始出错的情况，而参数量较大的模型则能更好地处理这些问题。我认为在一段时间内，尤其是在代码领域，我们无法摆脱“大力出奇迹”的规律。对于一些简单的任务，使用非常大的参数模型可能并不必要。例如，在通义灵码平台上，线上也并不全是使用千亿参数的模型。我们有不同参数规模的模型，如百亿参数、几十亿参数的模型，并且会根据任务的不同，将任务调度到相应的模型上。我们也在尝试形成各种专家模型的组合，并计划进行DevOps整个全链路的智能化改造。这有点类似于企业的流程再造，只是DevOps的软件生产流程与企业生产流程相似。在这个流程中，并不是所有的任务都需要使用非常大的参数模型。我们可以通过组合各种不同参数规模的模型，以及训练出的下游任务能力，来完成流程的改造。我认为，使用多大规模的模型是需要企业去不断尝试的。但首先，我们需要解决算力问题。一旦解决了初始的算力问题，我们就可以开始逐步前进。至于后续的芯片问题，我相信最终也会得到解决。包括许多互联网大厂和国内顶尖的芯片制造企业，现在都在努力去创造一些改变。真正的价值点。陈鑫（神秀如果你想要进行微调，但不理解业务，那么你的价值就会非常有限。如果将微调定义为一个岗位，那么这个岗位应该具有深厚的价值，并且需要长期的积累和能力。如果这个岗位的价值和能力很容易被替代，或者很容易学习，那么它可能就不会成为一个独立的岗位。以我们的例子来说，通义灵码本身就包含了一个非常简单的微调训练平台。这是因为我们把工程师在微调代码模型的所有经验都内置到了平台中，并且添加了一些配置。一个工程师通过一两天的培训，基本上就能掌握这些概念，开始进行微调工作。在代码领域，至少在我看来，这个门槛并没有大家想象的那么高。但在其他领域，门槛可能会更高。对于专家知识来说，如何选择合适的数据、如何处理数据、如何解决出现的问题、如何校正训练不佳的模型、如何通过不断实验训练出符合预期的模型，以及是否清楚自己训练模型的目的，这些都是微调工程师需要考虑的问题。例如，如果你想并在代码补全时生成可以直接调用企业内部SDK或API的代码，那么你需要考虑如何教会模型实现这一点，构造什么样的数据，如何标注数据，以及如何筛选和处理数据。这些问题可能不是一个简单的微调工程师就能解决的。未来，像原来的效能工程师或者中台的资深研发人员可能都需要具备微调的能力，将自己的代码资产训练到大模型中，让整个公司的人都能使用。所以，未来每个人都需要具备理解模调工程师”的岗位了。我们预计将看到大量Agent相关的实践和落地陈鑫（神秀）：在关于AIAgent的话题，我认为今年它肯定会非常火热，甚至在代码领域也会受到关注。根据当前的趋势，我们可以预见这个过程将分为几个步骤。首先，大家会开始采用能够进行代码生成或续写的模型。接下来，会进行企业个性化的定制。正如我们之前讨论的微调，实际上已经涉及到了这个过程。然后，我们会进一步扩展这些模型的能力，目标是提高整个软件生产链条的效率。为了实现这一目标，我们肯定会利用AIAgent技术。在没有模型的时候，我们需要训练这个“大脑”，然后通过像通义灵码这样的平台，专注于完成最核心、价值最大的任务。完成这些任务后，接下来就是构建AIAgent。我们会搭建好平台，让各个企业基于这个平台构建自己的AIAgent。研发领域的场景可能有上百甚至几百个，如果每个企业都进行个性化定制，那将是成千上万的需求，这显然不是一个团队能够独立完成的。现在，各方面的技术探索已经非常成熟，我认为今年确实是AIAgent落地的关键