中智凯灵 2023年11月20日 12:03 北京

以下文章来源于腾讯云CloudStudio ，作者Cloud Studio

腾讯云CloudStudio.

Cloud Studio 是基于浏览器的集成式开发环境，为开发者提供了一个永不间断的云端工作站。用户在使用 Cloud Studio 时无需安装，随时随地打开浏览器就能使用。

▼

11月24-25日，以 “AI驱动软件研发全面进入数字化时代”为主题的AiDD峰会将于深圳深铁皇冠假日酒店隆重开启。本届峰会聚焦十三个主题论坛和两个企业专场，策划60+精彩议题内容，邀请了来自BAT、华为、字节、网易、蚂蚁、小米等大厂和各大高校学者在内的近百位技术专家，融合主题演讲、互动研讨、案例分享、实战演练等多种形式，共筑AI盛会。本届峰会承办单位为国内领先的专业数字人才发展平台中智凯灵，协办单位深圳市软件行业协会，钻石合作伙伴腾讯云，战略合作伙伴网易数帆。

由于本届峰会备受欢迎，且AiDD峰会的办会宗旨明确深意，即推动软件研发全面进入数字化时代。因此，为了能给每一个软件企业或团队带来重大的参考价值，能够指导他们完成下一年度AI战略的重构、相关AI部署和行动的规划，为相关行业提供更加精准的解决方案。AiDD峰会现推出限量专场体验福利票给到大家，赶快抢占先机吧！

-通义专场-

大模型正在加速推动智能化时代的到来，而人类和机器是智能化时代的两大主体。人类以自然语言为中心，机器以代码语言为中心。本次分享重点介绍通义家族的两个成员--通义晓蜜和通义灵码。通义晓蜜以对话大模型为基础构建企业对话服务，通义灵码以代码大模型为基础打造智能编码助手。另外，正如ImageNet推动了深度学习的发展一样，本次分享会介绍通义实验室在大模型时代围绕高质量benchmark数据集构建方面的工作。

-蚂蚁专场-

随着AIGC技术的不断发展，测试领域在智能化方向上也将迎来一场深刻的变革。围绕测试分析、测试用例生成、测试数据构建等核心测试领域场景，我们结合大模型技术探索并初步落地了测试AIGC体系，基于大模型重新定义智能化测试。测试生成蚂蚁专场聚焦当前蚂蚁落地测试AIGC的实践案例，交流大模型在测试领域落地的实际应用场景和无限可能性，让测试变得更智能。

-代码生成与优化专场-

聚焦于大模型时代下的代码生成与理解，包括代码补全、代码自动生成、单元测试代码自动生成、针对代码的大模型构建等话题，分享该领域最新研究成果，探讨真实落地应用场景。

⭐精选内容抢先看

演讲嘉宾汪晟杰——腾讯云开发者产品高级经理

历任阿里高级技术专家，从事钉钉云效核心业务线、Teambition 合伙人、Autodesk 首席软件架构师、十多年 SAP 云平台、SuccessFactors HCM、Sybase数据库 PowerDesigner 等产品的开发经理，在软件架构设计、产品管理和项目工程管理、团队敏捷提效等方面拥有逾 18 年的经验。

演讲内容简介：腾讯云认为AI对世界的改变，一定是通过与产业融合实现的。机器决策、自主生成、自然交互等一系列变革，将推动产业实现更高效率、更低成本、更好体验和更大创新。未来的企业，也将向智能原生进化。而软件工程和代码能力也是构建和链接数字世界的有效手段，可以大幅降低数字经济的创新门槛和成本。如今在人工智能迅猛发展的大趋势下，软件工程将步入3.0时代。怎样通过AI能力加持软件工程与代码能力，今天将就该话题进行一个分享和汇报。

《AI 加持下的新时代软件工程》

 软件工程 3.0 与 AISE 

软件工程的发展可以分为三个阶段：软件工程 1.0、软件工程 2.0 和软件工程 3.0。在这三个阶段中，AI for SE（人工智能在软件工程中的应用）的发展历程如下：

软件工程 1.0

在这个阶段，软件工程主要关注结构化编程、模块化设计和数据结构。主要集中在基于规则的 MIS 专家系统、模式识别、平台型工具等方面。当时如 Borland、Sybase 等产品，我在 05 年加入 Sybase PowerBuilder 和 PowerDesigner 产品组，负责过建模工具、MIS 系统开发平台、UEP 移动开发平台工具集（后面贡献给到了 eclipse 开源组织）。这些产品当时试图解决软件工程下复杂应用投入产出高的问题，后来推出面向组件开发范式（OOC：面向组件编程）来提高开发效率，快速发布上线，那个时候还不能称为 IDE，我们还是称 RAD（Rapid Application Development）。当时我们也探索过 Big Code 的语义搜索能力也逐步开始研究等，但受限于当时的计算能力和 AI 技术水平，效果有限。

软件工程 2.0

软件工程逐渐从结构化编程转向面向对象编程。AI for SE 的应用范围和技术水平得到了进一步发展。例如，基于遗传算法的优化技术被用于软件设计和测试；神经网络技术NLP被用于软件缺陷预测；自然语言处理技术被用于需求分析和知识表示等。此外，软件工程 2.0 更聚焦于流程统一，例如一些产品如 CODING DevOps、Gitlab 等。

软件工程 3.0

在这个阶段，软件工程的关注点从面向对象编程转向云计算和 AI。随着 AIGC 技术的这一年的高速发展，以 LLM 为首的面向大模型的软件工程体系也被国内外提出，如 GitLab Duo、Github Copilot X 等，使得 AI for SE 的应用前景变得更加广泛。例如，深度学习技术被用于代码生成和补全、缺陷检测和自动修复；数据挖掘技术被用于软件过程改进；自然语言处理技术被用于需求分析、代码审查和文档生成等。

AI for SE 和 SE for AI

AISE，我先用中文「智能化软件工程」来定义，实际上他有两个方向：一个是 AI for SE，另外一个方向是 SE for AI。

这两个区别，我们先问下 ChatGPT，看看 AI 是怎么解答的：

可见，软件工程 3.0 就是 AI for SE，解决软件工程 2.0 流程中的 AI 化，促使效率提升，流程化简，让 AI 在关键节点赋能开发。

SE for AI 是另一个维度，即思考软件工程流程体系怎么来实现智能化软件应用，例如 ML-Ops 流程化 AI 应用研发。

这里我们先围绕 AI for SE 进行展开，至于智能化应用系统，如最近很火的面向AI的 Mojo 语言、更面向 AI 化的应用框架等等，我们以后再进行阐述。

 基于 LLM 的代码生成 

大型代码语言模型(Code LLM)的兴起。其中一个用在软件工程任务里面的最基本的一个问题，就是代码生成。

从 Codex 讲起

在 2021 年 7 月 OpenAI 发布出 Codex 论文《Evaluating Large Language Models Trained on Code》，这个论文当时可能并没有太大的反响，虽然他们发布了 HumanEval 的数据集，效果也不错，但是在众多文章中并没有得到太多的关注。论文里提到了 3 个模型，一个是基于 GPT-3 在代码上微调来通过文本描述生成代码的 Codex 模型（非监督学习）；另一个是进行监督训练，通过文本描述生成代码的 Codex-S 模型；最后一个是通过代码生成代码文本描述的 Codex-D 模型.

代码微调Codex

利用 GitHub 上面的 5400 万个公开仓库，代码是在 2020 年 5 月从 GitHub 上搜集的，每个 Python 文件是 1MB 以下的。最终我们的数据集是 159GB。

GitHub Copilot

代码补全的产品价值

2021 年 10 月 29 日 OpenAI 发布 Copilot 后，大家去试用有一个很深切的感受，确实是很震撼，它的能力比起之前的技术提升了一大步。

根据 DeveloperSuvey，受访者认为人工智能编码助理将如何改变他们明年的工作，其中编写代码占了 82.55%，70% 的受访者正在或计划在开发过程中使用人工智能工具，并且学习者比专业人士更有可能使用它们。

下图为腾讯云 AI 代码助手针对怎样达成高用户价值的思考框架。我们通过代码模型精调训练，在代码补全、技术对话上给开发者提高效率。这点也已在内部进行了多次论证：当产品处于非常好的体验的时候，会获得非常高的用户留存率。这里提到的代码生成的体验，更关注在补全性能、产品交互、以及用户开发习惯等方面。

在高留存率目标驱动的同时，还必须控制优化好成本，防止高频访问导致速度下降与成本上升、从而劣化产品体验。需要重视 bad case 反馈与处理闭环、针对性专题性能调优、采取批量计算等策略；通过用户看板观察总结模型版本升级带来的能力增益。最终通过一系列平衡手段，实现 AI 代码助手在补全场景下的产品价值。

 应用形态思考 

面向开发者的编程提效

开发者有两大群体，一类是专业的开发人员，就是软件工程师，那么产品目的就是为了提高开发人员的开发效率，把程序员从简单重复的劳动中解放出来，从而关注架构、设计等复杂任务。现实场景中，用户使用代码生成特性时，通常会尝试读生成的代码，从而决定是否采用或修改生成的代码段。这是对 AI 项目理解能力的批判性思维，因此我们认为目前的代码生成/补全还是在为 AI 辅助生成建议、生成相似逻辑。

实战中，在腾讯云 AI 代码助手的配合下，我举三个高频使用的场景：

• 按 Entity 对象完善 getter/setter，甚至是关联对象。
  
  

• 通过结构体，自动生成 SQL 及 DAO 对象。
  
  

第二类是代码钻研者、寻求代码相关解答的开发者。这类用户有什么特性呢？他们执著于代码本身，如算法，特定问题的解答，特定描述下的代码生成（代码建议后的试错）。这类开发者的目的是：创建小的、即时使用的任务型应用程序，比如函数计算程序、支持用户快速完成日程的任务。当然也有代码学习者，对于代码不是很熟悉的，可以通过代码对话对代码进行解读，在对话中进行有效提问。

技术对话和代码补全在实战下是相辅相成的，为了做到更好体验，技术对话会采用更大规模的模型来获得更好的推理能力，而代码生成场景下则会采用更小的代码模型来获得更好的写代码的体验感。

高粘性的编程体验

• Fill in Middle 技术
  

• Fill in Middle的原理简介：
  

假设我们有一个如下所示的训练示例：

我们希望模型学习 jumps over 从前缀 The quick brown fox 和后缀预测中间文本 over a lazy dog。首先，我们进行两次切割来分隔这些部分，引入新的标记<PRE>、<MID>、<SUF>和<EOM>

然后我们简单地转置中间和后缀：

现在，我们的训练与之前完全相同，jumps over 从之前的文本预测接下来的文本。

The quick brown fox a lazy dog。该模型自动学习特殊标记的含义，并了解到它应该生成在前缀之后但在后缀之前有意义的文本！在推理时，如果我们尝试填充如下所示的文档：

我们可以将其呈现为：

到模型并请求字符，直到模型发出令牌，此时它已成功将前缀与后缀连接起来。

下面几张截图是 AI 代码助手通过 FIM 技术，实现通过光标上下文快速填补中间片段。在真实场景下，非常适合做成对出现的代码函数，比如：加解密函数、通过 CR 自动生成 U(pdate)D(elete) 函数等。

• 更小的代码补全模型
  

代码补全的触发时机是真正伴随在日常开发中的，无时无刻去根据上文生成下文代码，如下图所示。所以这里的模型更应该是小模型。在 AI 代码助手下，我们将其定义为补全小模型，带来的性能收益是巨大的。GitHub Copilot 也尝试在端上内置更小的微模型，让成本、速度优先作为补全产品的前提。

基于混元大模型的AI 代码助手的行业产品

面向行业开发的 SMAF 机遇

腾讯自研的代码模型也充分考虑到企业内部数据资产监管所面临的各项挑战和实际诉求，让受管控企业也可以在一个受控的环境内将 AI 代码助手使用起来，并且希望能够支持全场景。让项目经理、市场人员、设计、开发及测试人员都可以有自己的实现场景，这是我们主要的目标。

• 什么是SMAF？
  

SMAF 包含以下内容：

Security：AISE 产品部署在私有云环境。业务代码内网托管，通过内部训练模型，构建集成 IDE 环境，通过自定义逻辑集成业务代码与模型输入/输出，杜绝引入外部安全漏洞；

MaaS：具备多模型统一管理能力。引入多个行业模型，基于不同业务特性和团队习惯进行二次训练，从而得到专属的企业模型；

Analysis：具备指标可观测看板。定义关键指标，对于企业管理者，可以有效观察团队使用代码助手对团队的提升效果。

Full：覆盖全开发流程。AI 代码助手应该覆盖沟通、编码、排错、评审、调优等必要场景。并优先关注编码，沟通环节注重行业深度落地。

我们在内部进行了长期持续的生产内测，正向反馈逐步增加，统计数数据也证明了产品具备相当的价值，这使我们对产品的进一步优化更有信心。

又如在某外部金融企业客户的实测中，我们基于多模平台导入私有化行业模型，基于内部安全合规的语料进行二次训练和微调，重点打磨代码补全、技术对话特性，逐步推广内部试用，完善产品体验，取得了令人初步满意的成效。

橄榄型产品设计和多模型接入

企业内部可能会存在多种代码模型，不同团队可能会使用不同的模型。而应用侧的产品交互体验，到数据效率报表，这两端则变化不大。于是我们提出了“橄榄型”的应用设想。什么是“橄榄型”呢，就是两端非常的统一，一端是应用交互、执行策略、Prompt设计等高度一致，另一端是数据统计的逻辑，监控和配置平台等高度一致，实现可管理可插拔。中间鼓出来的部分就是多模型接入。用户可以根据不同的业务属性，按需加载不同模型，也可以通过 MaaS 平台为企业按需训练模型，并发布到中间平台里，通过配置下发，自动更新端上配置，即可满足业务对于模型版本的升级。

大模型的“可信”挑战

现在不管是基于大模型的代码生成还是其他场景，怎么样确保可信非常关键。生成的代码或其他场景的产物不见得 100% 正确。有一些场景比如说娱乐、生图或者视频合成，只是在娱乐行业或者广告行业，没有严格意义上对错的场景，这些比较好理解，落地还是比较顺利的。但是在有确定对错的场景，如果万一错了，造成的后果较大，怎么去应对如果没有解决好可能会成问题的。

我们认为一个值得信赖的代码生成模型，应该具备：

• 准确率高；

• 鲁棒性高、稳定性高；

• 不生成危险代码，如不安全的代码、可能产生社会歧视的代码、可能泄漏隐私的代码；

• 行为可预测可控。

模型“评测”挑战

关于代码大模型的能力提升，这也是我们需要持续去应对的。程序语言和自然语言有很大不同，如何针对代码特性设计模型结构和训练方式是值得探索和推进的方向。只将静态代码输入给大模型会由于输入信息量不足而导致大模型对程序的理解不够，如何构造让模型更容易学习和理解的输入数据，比如增加动态执行信息，通过程序语义等价性生成额外的等价程序，会有助于大模型做到程序理解。

如今大家都采用 HumanEval 进行准确度评测，百分比不断提升，可能百分之七八十在特定的数据集上。但竞赛题是比较自包含的，没有太大的耦合度和环境，怎么在真实的代码场景里能做到更好也是一个开放性的课题，需要大家一起往前推进。

今年年初，还没有 HumanEval 的时候，我们非常头疼，怎么来验证模型的正确性和可靠性。我们采用了国外的一个开源框架，思路很简单：用 GPT4 做老师出题，题目从网上搜刮得来，通过 GPT4 搜索和清洗。然后进行模型的两两对比。对比打分的也是 GPT4，打分标准依据代码的五大维度，即：代码语法、可读性、运行结果、复杂度、完整性。示例 prompt 如下：

这样我们得到了很多国内外的评测结果。后来和 humaneval 测试结果进行比对，也具备一定的可参考性。

软件工程 AISE 全流程覆盖的挑战

另一个挑战是代码大模型下游任务的生态建设，包括测试、调试等更多下游任务及应用细分领域的拓展，辅助解决更多的工程任务；以及更多支撑上下游任务的工具链，包括需求分解、测试用例生成、调试/修复等工具，以更好地支撑智能化软件工程任务。

我们目前只定位在开发工程师角度，其他流程下的不同角色还没有探索，也不能仅凭我们来定义。这类人群有着自己的领域知识、实践流程等等。

LLM 的规模也许会越来越大，也会有各色的专业垂直 LLM 问世，扎深特定的方向，做透一个点，找到产品和商业价值，并与流程中的其他垂直人群正交。

AISE 不仅覆盖开发者。即便是开发域，国内外的研发差异也不同，定义面向国内开发者的研发流程的 AI for SE，需要通过我们对于行业的理解，不断深入思考并不断试错。

 小结