软件工程的发展可以分为三个阶段：软件工程1.0、软件工程2.0和软件工程3.0。在这三个阶段中，AIforSE（人工智能在软件工程中的应用）的发展历程如下：
软件工程1.0
软件工程2.0
软件工程逐渐从结构化编程转向面向对象编程。AIforSE的应用范围和技术水平得到了进一步发展。例如，基于遗传算法的优化技术被用于软件设计和测试；神经网络技术NLP被用于软件缺陷预测；自然语言处理技术被用于需求分析和知识表示等。此外，软件工程2.0更聚焦于流程统一，例如一些产品如CODINGDevOps、Gitlab等。
软件工程3.0
总之，从软件工程1.0到软件工程3.0，AIforSE的发展历程可以概括为从初步尝试到逐渐成熟，再到广泛应用。随着AI技术的不断进步，AIforSE将在未来的软件工程领域发挥更加重要的作用。
AIforSE和SEforAI
AISE，我先用中文「智能化软件工程」来定义，实际上他有两个方向：一个是AIforSE，另外一个方向是SEforAI。
这两个区别，我们先问下ChatGPT，看看AI是怎么解答的：
可见，软件工程3.0就是AIforSE，解决软件工程2.0流程中的AI化，促使效率提升，流程化简，让AI在关键节点赋能开发。
SEforAI是另一个维度，即思考软件工程流程体系怎么来实现智能化软件应用，例如ML-Ops流程化AI应用研发。
这里我们先围绕AIforSE进行展开，至于智能化应用系统，如最近很火的面向AI的Mojo语言、更面向AI化的应用框架等等，我们以后再进行阐述。
大型代码语言模型(CodeLLM)的兴起。其中一个用在软件工程任务里面的最基本的一个问题，就是代码生成。
从Codex讲起
代码微调Codex
利用GitHub上面的5400万个公开仓库，代码是在2020年5月从GitHub上搜集的，每个Python文件是1MB以下的。最终我们的数据集是159GB。
GitHubCopilot
2022年GithubCopilot正式上线对外公测，它是基于Codex的模型的训练，背靠Github仓库集，通过精调训练的一套面向开发者的代码补全产品。
代码补全的产品价值
2021年10月29日OpenAI发布Copilot后，大家去试用有一个很深切的感受，确实是很震撼，它的能力比起之前的技术提升了一大步。
根据DeveloperSuvey，受访者认为人工智能编码助理将如何改变他们明年的工作，其中编写代码占了82.55%，70%的受访者正在或计划在开发过程中使用人工智能工具，并且学习者比专业人士更有可能使用它们。
在高留存率目标驱动的同时，还必须控制优化好成本，防止高频访问导致速度下降与成本上升、从而劣化产品体验。需要重视badcase反馈与处理闭环、针对性专题性能调优、采取批量计算等策略；通过用户看板观察总结模型版本升级带来的能力增益。最终通过一系列平衡手段，实现AI代码助手在补全场景下的产品价值。
面向开发者的编程提效
实战中，在腾讯云AI代码助手的配合下，我举三个高频使用的场景：
按Entity对象完善getter/setter，甚至是关联对象。
通过结构体，自动生成SQL及DAO对象。
技术对话和代码补全在实战下是相辅相成的，为了做到更好体验，技术对话会采用更大规模的模型来获得更好的推理能力，而代码生成场景下则会采用更小的代码模型来获得更好的写代码的体验感。
高粘性的编程体验
FillinMiddle技术
FillinMiddle的原理简介：
假设我们有一个如下所示的训练示例：
我们希望模型学习jumpsover从前缀Thequickbrownfox和后缀预测中间文本overalazydog。首先，我们进行两次切割来分隔这些部分，引入新的标记
、、 和 然后我们简单地转置中间和后缀：
现在，我们的训练与之前完全相同，jumpsover从之前的文本预测接下来的文本。Thequickbrownfoxalazydog。该模型自动学习特殊标记的含义，并了解到它应该生成在前缀之后但在后缀之前有意义的文本！在推理时，如果我们尝试填充如下所示的文档：
我们可以将其呈现为：
到模型并请求字符，直到模型发出令牌，此时它已成功将前缀与后缀连接起来。
下面几张截图是AI代码助手通过FIM技术，实现通过光标上下文快速填补中间片段。在真实场景下，非常适合做成对出现的代码函数，比如：加解密函数、通过CR自动生成U(pdate)D(elete)函数等。
更小的代码补全模型
代码补全的触发时机是真正伴随在日常开发中的，无时无刻去根据上文生成下文代码，如下图所示。所以这里的模型更应该是小模型。在AI代码助手下，我们将其定义为补全小模型，带来的性能收益是巨大的。GitHubCopilot也尝试在端上内置更小的微模型，让成本、速度优先作为补全产品的前提。
基于混元大模型的AI代码助手的行业产品
未来基于混元会对外推出公测版本，结合小模型提供可商业化、可私有化、可共创合作，为行业客户的研发AI赋能。
目前支持Python、JavaScript/TypeScript、Java、C/C++、Go、Rust、swift、SQL等主流语言，并支持各大主流IDE平台。
AI代码助手的产品从开发者的频次最高的场景作为切入，以代码补全作为优先行业落地的能力，以技术对话模型共创成对话平台，并计划接入测试和诊断能力。
机遇与挑战
面向行业开发的SMAF机遇
代码模型落地企业会遇到很多挑战。像海外的企业，对于使用Copilot，ChatGPT没有太多的顾虑，但是在国内绝大部分的软件企业或研发软件机构，自己企业或机构内部的代码是不能够流传至外网的，需要私有化部署。私有部署往往需要性能强大的GPU集群，全面开发给大型软件研发团队使用成本很高；以及企业内网环境使用的的库或框架无法使用开源项目代码比如GitHub等，怎么能够支撑好这些场景都需要考虑如何解决。
腾讯自研的代码模型也充分考虑到企业内部数据资产监管所面临的各项挑战和实际诉求，让受管控企业也可以在一个受控的环境内将AI代码助手使用起来，并且希望能够支持全场景。让项目经理、市场人员、设计、开发及测试人员都可以有自己的实现场景，这是我们主要的目标。
什么是SMAF？
SMAF包含以下内容：
Security：AISE产品部署在私有云环境。业务代码内网托管，通过内部训练模型，构建集成IDE环境，通过自定义逻辑集成业务代码与模型输入/输出，杜绝引入外部安全漏洞；
MaaS：具备多模型统一管理能力。引入多个行业模型，基于不同业务特性和团队习惯进行二次训练，从而得到专属的企业模型；
Analysis：具备指标可观测看板。定义关键指标，对于企业管理者，可以有效观察团队使用代码助手对团队的提升效果。
我们在内部进行了长期持续的生产内测，正向反馈逐步增加，统计数数据也证明了产品具备相当的价值，这使我们对产品的进一步优化更有信心。
又如在某外部金融企业客户的实测中，我们基于多模平台导入私有化行业模型，基于内部安全合规的语料进行二次训练和微调，重点打磨代码补全、技术对话特性，逐步推广内部试用，完善产品体验，取得了令人初步满意的成效。
橄榄型产品设计和多模型接入
企业内部可能会存在多种代码模型，不同团队可能会使用不同的模型。而应用侧的产品交互体验，到数据效率报表，这两端则变化不大。于是我们提出了“橄榄型”的应用设想。什么是“橄榄型”呢，就是两端非常的统一，一端是应用交互、执行策略、Prompt设计等高度一致，另一端是数据统计的逻辑，监控和配置平台等高度一致，实现可管理可插拔。中间鼓出来的部分就是多模型接入。用户可以根据不同的业务属性，按需加载不同模型，也可以通过MaaS平台为企业按需训练模型，并发布到中间平台里，通过配置下发，自动更新端上配置，即可满足业务对于模型版本的升级。
大模型的“可信”挑战
我们认为一个值得信赖的代码生成模型，应该具备：
模型“评测”挑战
关于代码大模型的能力提升，这也是我们需要持续去应对的。程序语言和自然语言有很大不同，如何针对代码特性设计模型结构和训练方式是值得探索和推进的方向。只将静态代码输入给大模型会由于输入信息量不足而导致大模型对程序的理解不够，如何构造让模型更容易学习和理解的输入数据，比如增加动态执行信息，通过程序语义等价性生成额外的等价程序，会有助于大模型做到程序理解。
如今大家都采用HumanEval进行准确度评测，百分比不断提升，可能百分之七八十在特定的数据集上。但竞赛题是比较自包含的，没有太大的耦合度和环境，怎么在真实的代码场景里能做到更好也是一个开放性的课题，需要大家一起往前推进。
今年年初，还没有HumanEval的时候，我们非常头疼，怎么来验证模型的正确性和可靠性。我们采用了国外的一个开源框架，思路很简单：用GPT4做老师出题，题目从网上搜刮得来，通过GPT4搜索和清洗。然后进行模型的两两对比。对比打分的也是GPT4，打分标准依据代码的五大维度，即：代码语法、可读性、运行结果、复杂度、完整性。示例prompt如下：
软件工程AISE全流程覆盖的挑战
另一个挑战是代码大模型下游任务的生态建设，包括测试、调试等更多下游任务及应用细分领域的拓展，辅助解决更多的工程任务；以及更多支撑上下游任务的工具链，包括需求分解、测试用例生成、调试/修复等工具，以更好地支撑智能化软件工程任务。
我们目前只定位在开发工程师角度，其他流程下的不同角色还没有探索，也不能仅凭我们来定义。这类人群有着自己的领域知识、实践流程等等。
LLM的规模也许会越来越大，也会有各色的专业垂直LLM问世，扎深特定的方向，做透一个点，找到产品和商业价值，并与流程中的其他垂直人群正交。
AISE不仅覆盖开发者。即便是开发域，国内外的研发差异也不同，定义面向国内开发者的研发流程的AIforSE，需要通过我们对于行业的理解，不断深入思考并不断试错。
整体来讲，AIforSE以及软件工程3.0，是我们需要拥抱的能够让我们振奋人心的方向，但是我们也要冷静的思考，AI和LLM是手段，提高效率降本增效是诉求。如何利用好大模型的落地，控制好LLM的计算成本，找到行业内研发流程的核心问题，通过AI和LLM手段去解决，把最高最紧急的痛点去落地解决。由于大模型的挑战和特殊性，企业也必须冷静思考，推行安全可信的模型验证工作，把AISE的流程的每个核心场景做透做扎实。