刚刚过去的 2023 年，对于大模型来说是元年，对于代码大模型来说，则是“狂飙”的一年。
一年以前，几乎没人知道代码大模型是什么，有什么用。
一年之后，很多公司和程序员都在考虑使用它。
作为诞生在 2023 年的 CodeFuse 代码大模型，它背后的团队其实也经历了巨大的观念改变。CodeFuse 的成长过程，其实是团队同学观念不断刷新，解决之前疑问的过程。
这些疑问包括：
- 大模型在代码领域有用吗？
- 我们能做出代码大模型吗？
- 我们的代码大模型能够有竞争力吗？
这些问题的答案是什么？我们找到了从第一天就加入项目的算法同学千奇，来听听他的说法。
2020年千奇加入蚂蚁研发效能，前期支持了语雀、研发小蜜的搜索推荐等工作。他在高校期间研究的是自然语言处理（NLP）相关方向，在效能团队也从事算法相关的工作。
大模型对代码有用吗？
2022 年，大语言模型宛如横空出世，进入大众的视线。在此之前，大模型并非 AI 的主流方向，无论是学术界还是产业界，很少有人相信，把模型的规模做到足够大，它就能自发的涌现出智能。
但是，CodeFuse 项目组的同学却很有信心，这是为什么呢？
原来，在 CodeFuse 之前，千奇和同事们就已经做过类似技术预研的事情，它就是 CodeFuse 的前身：青燕代码智能编程助手。
千奇回忆说，2022 年初的一天，主管找到他，问他是否有兴趣加入一个编程助手项目，应用人工智能来提升编码效率，就这样，他加入了青燕项目。
青燕原本并没有采用大模型相关的 AI 技术，而是使用之前的 NLP 技术，使用循环神经网络来实现代码智能补全，这条路线之前是业界的研究重点，有很多相关的论文和实现。
然而，青燕沿着这条路线前进，却很快就遇到瓶颈，补全代码预测的准确率，始终上不去，距离实用还有一段不小的距离。再往上提升，业界也没有先例，想要自己突破，还不知道要花多少时间和资源。终于，他们将目标转向了大模型。
更具体的来说，是 OpenAI 发布的 CodeX 代码大模型，它是 GitHub Copilot 代码助手背后的核心引擎。
2021 年中，OpenAI 发布了《Evaluating Large Language Models Trained on Code》论文，介绍了 CodeX，这也是代码大模型领域的开山之作。它主要介绍了两件事，第一个，当时的通用大模型在代码领域表现不佳，第二，通过针对性的微调，可以让大模型在代码任务表现大幅提升。论文的描述以及 GitHub Copilot 的表现，让青燕项目组下定决心，开始去试验这全新的技术路线。
从 0 到 1 的路，当然是艰难的，在经历过无数次在失败中的摸索，千奇和他的小伙伴们终于“炼制”出了一个 2.5 亿（0.25B）参数的模型，经过小范围的测试，结果令他们大喜过望：代码大模型是有效的！
【青燕效果视频片段】
https://mp.weixin.qq.com/s/TUPxsWOH8QdTsve3Gygg7g
他们还将青燕拿到业界去试了下水，参加了业界公开的微软 CodeXGLUE 测试，主要对 Java 代码行补全进行了评测。
结果令人欣喜， 他们的 24 层模型在 Code Completion 榜单上排名第一（截止到 2022.8.23）。可见，大模型在代码领域大有可为。
正因为做出过可用的产品，当 2023 年初 CodeFuse 立项的时候，千奇他们还是很有信心的。然而，很快就有一个问题摆在他们面前：大模型的训练需要大量的计算资源，而公司开始对这类资源的利用开始收紧，他们要如何说服公司来提供计算资源？
毕竟，没有资源，代码大模型只能是空中楼阁。
你们能做出代码大模型吗？
如果从公司的角度考虑，公司收紧计算资源的目的无可厚非，因为 AI 及大模型也是整个公司 2023 年的重点技术战略方向。从公司的角度，当然是要集中优势资源投入，打造出能够服务于整个公司和全体用户的通用大模型。
然而这对刚刚立项的 CodeFuse 不是个好消息。在经历多次碰头会议，以及向高管汇报之后，CodeFuse 终于确定了接下来的方针：
- CodeFuse 的眼光不能仅仅盯着编码这个环节，应该承担更重要的职责，那就是整个研发流程提效，这样它的优先级提高，才能分配更多资源；
- CodeFuse 在研发上要小步快跑，不要指望一口气吃成胖子，而是每个阶段都要拿出成果，然后再申请下个阶段的资源；
- 开源困难，那就要节流，优化算法，尽量提高利用计算资源的效率，榨干计算卡的最后一点算力。
最后也是最重要的，CodeFuse 团队必须尽快拿出一个可以运行的 Demo，来证明其技术可行性。而这个重任，落到了千奇头上。
“当时深感责任重大，心里想着，无论如何也要把这事办成。”回忆起当时的情形，千奇这样说。
说干就干，利用之前青燕时积累的经验，千奇很快训练出了一个 13 亿（1.3B）参数的版本，它的演示效果十分有说服力，让 CodeFuse 顺利走上正轨。
接下来，就是脚踏实地的研发了。
在小步快跑的方针下，CodeFuse 各个团队紧密配合，从 0 到 1 训练了 1.3B、6B、13B 等若干个代码大模型。并基于 13B 代码大模型打造了交互式代码大模型产品，于 6 月初开启在蚂蚁内部公测。
在优化算法和提升研发效率方面，千奇和小伙伴们不断吸收业界前沿的各种经验，将它们应用到 CodeFuse 中，比如旋转位置编码、ParallelAttention+FF、FlashAttention 等技术，提升模型效果和训练速度。
在研发过程中，他们遭遇过很多困难，比如节点故障、NVLink 连接超时，导致训练中断，有时半夜收到告警，还要爬起床打开电脑去重启任务。其中艰辛，不足为外人道。不过好在，在兄弟团队的帮助下，大部分问题磕磕绊绊的都解决了。
除了上面提到的，他们也实打实的受益于公司的大模型基建。比如百灵基座大模型，其中数据、训练、评测等方面有大量技术栈复用在 CodeFuse 研发中；CodeFuse 的数据和经验也融合到通用大模型中。还有公司的 AI 基础设施，为大模型分布式训练、推理和部署加速提供了一揽子解决方案，也是CodeFuse 的重要支柱。
然而，紧接着下一个问题又来了——
你们的代码大模型有竞争力吗？
如果按青燕时代的态势，大家还不怎么关注代码大模型，千奇对 CodeFuse 肯定是有信心的。但大模型的发展太快，俗话说：大模型一天，人间一年。
2023 年，不仅仅是 OpenAI 发布了 ChatGPT-4，Meta、谷歌都相继发布了自己的大模型产品，而国内，大模型更是如雨后春笋般出现，在开源社区，Llama、ChatGLM 等也在不断刷新人们对大模型的认识。大模型的参数量级攀升到千亿，甚至朝着万亿高歌猛进。
在这样的形势下，怎么保证自己的大模型是能打的呢？他们想到了一个方法：开源，去社区里去接受检验。
懂点软件开发的人都知道，开源对代码的要求很高，代码写的差了别人看到会吐槽，如果你宣称有某能力而代码却无法实现，对你在开源社区的名誉更是毁灭性打击。
而开源对大公司的要求更高，对于像蚂蚁这样的公司，如果你开源出去的项目没有任何亮点，也会受到别人嘲笑。
而在所有亮点里面，性能是最具有说服力的，在团队商议过后，他们决定去打榜——也就是参与业界最主流的 HumanEval 评测，用评测结果来说话。
“说实话当时心里是没底的，我们的时间和资源投入比业界标杆有所不如，能走到哪一步我们也不知道。”谈起当时决定打榜的情形，千奇告诉我。
不过让他心里稍有安慰的是，CodeFuse 评测的结果同样超过了他的心理预期，每一次微调，每一个版本，评测的数据都蹭蹭的往上涨。
打榜是一个漫长的过程，评测早在 CodeFuse 呱呱坠地第一天就开始了，但把它当成一个正经事，则是发布内测的前夕，而最终得到想要的结果，又花了几个月的时间与模型缠斗。
9 月初，CodeFuse 的开源工作已经准备停当，就等评测结果了。终于，在 Humaneval pass@1 评测中，CodeFuse 34B 版本结果从年初约 11% 提升到 74.4%，超过业界标杆位于第一！虽然以大模型业界的发展速度，这个第一的时间并不太长。
能拿到第一，CodeFuse 自然是有绝活的，其中最大的功臣要数他们自研的多任务微调框架 MFTCoder，相比之前的单任务微调 SFT 能够更好、更均衡的学习各个任务，在相关评测中取得更好的成绩。
这其中也离不开业界优秀的开源模型如 LLama、Qwen 等，为了回馈社区，CodeFuse 团队将 MFTCoder 沉淀下来并对外开源，还分享了如何使用 MFTCoder 的具体实践。
不过，最近业界也有一些声音质疑，有些大模型急功近利，为了宣传拿评测的题目训练后去刷榜，这样做的话，即使大模型能力还不行，也能在评测中拿到较好的结果。CodeFuse 如何保证自己的成绩是真实的呢？我向千奇发出了这个灵魂质问。
“我们也很注意这个问题，在训练的数据集中专门剔除了相关的数据，即使是关键词重合了也不行。我们的数据集已经开源了，大家可以去下载检验。”
接着他又补充道：“我们做评测，最主要的目的是发现问题从而不断改进，毕竟我们做 CodeFuse 是真的要给人用，我们在蚂蚁内测的过程中，除了评测还做了很多轮的反馈调研，调研结果也能一定程度上证明评测数据。”
事实上，团队在进行评测的过程中，觉得业界的一些评测不太好用，主要是脱离一线编码实际——业界的一些评测是将一段代码随机去掉一部分看模型是否能正确补全，而真实的编码并不是这样。于是他们改进了评测手段，并将经验通过开源反馈给社区。
更让团队开心的是，在 CodeFuse 开源后不久，他们介绍 CodeFuse 研发技术的论文被计算机 CCFA 顶级会议 ICSE 接收了，说明 CodeFuse 吸引到学术界的目光，并得到了一定程度的认可。
代码大模型与开发者的未来
10 月 24 日，CodeFuse 对外发布研发助手插件，可以帮助开发者在写代码时提升效率，但 CodeFuse 的目光不仅于此。
在 QCon 上海站，千奇的主管姜伟分享了 CodeFuse 对未来的展望蓝图，在 CodeFuse 的设想里，它会囊括从需求分析到运营数据洞察的研发全生命周期。
CodeFuse 曾经做过一个 demo，在未来的 AI 原生 IDE 中，开发者和它对话提交需求，让它直接生成一个支付宝小程序并测试和部署。整个过程中无需编码，你只需要在问答中一步步的细化自己的需求、设定配置、检查运行结果。
千奇十分肯定，未来的代码大模型，一定会很大程度上取代开发者的工作。经历这一年多的磨练，以及对大模型认识的不断深入，这几乎成为了他的信仰。
于是我问出了那个很多人都会抱有的问题：如果代码都让大模型写了，还需要开发者做什么？
千奇回答：“在智能研发时代，代码大模型和开发者是一种合作互补的关系，开发者只需要专注于直观的抽象层面，剩下的工作都可以交给AI去完成。简单的开发可以让不那么熟悉编程的人来进行，而复杂的开发还是要依赖软件工程师，而代码大模型可以给工程师提升效率。”
这样一来，未来能够从事软件开发的人反而会更多了。他说。
这看上去反常识，但如果仔细想一想，它实际上符合软件开发的发展趋势。
最初人们编程，使用的是汇编语言，人们需要操作每一个发给计算机的指令；后来是 C/C++ 等，开发者需要在程序中手动操作垃圾回收；再后来是 Java 等高级语言，可以自动进行垃圾回收，但还需要额外实现并行等操作；再到 Go 语言等新兴语言，直接把并行也作为语言底层实现，开发者无需担心了。
编程语言朝着门槛越来越低的方向在发展，正因为如此，开发者的群体越来越壮大，与此同时越来越多复杂的应用被开发出来，它们中的许多都应用了封装程度高的现代编程语言。
代码大模型与开发者，某种程度上也会是类似的关系。而代码大模型与 AI 原生开发，一方面继承了软件研发的发展方向，一方面又会颠覆以往的研发模式，掀起一场伟大的创新与变革。
而千奇和 CodeFuse，很幸运的站在了变革的开端。而接下来 CodeFuse 和代码大模型领域会如何发展，邀请每一个开发者一起来见证。
CodeFuse官网：https://codefuse.alipay.com
