微调工程师岗位可能并不存在，但使用 AI 编码工具已经成为刚需

智能编码工具的快速普及是否会带来全新的编程模式？“大力出奇迹”的规律还将继续适用吗？本文节选自 QCon 北京特别策划圆桌节目，内容摘自阿里云通义灵码产品技术负责人陈鑫在圆桌对话里的精彩回答。全文见：Sora很难跟进？微调就不是一个岗位？大力出奇迹将继续适用？大模型将对软件生态带来哪些变化？

观点 1：智能编码工具将被更加广泛的应用，甚至出现全新的编程模式。不擅长利用大模型来辅助代码开发的程序员未来一段时间将被淘汰。

陈鑫（神秀）：去年，ChatGPT 火了以后，我们立即开始着手利用大模型技术进行代码智能生成方向的工作。在此之前，我们已经有些探索，我们团队大约在 2021 年开始尝试代码工具的研发。起初，我有些悲观，因为我觉得以现在的投入，无论是在数据、算法还是人才方面，都无法超过当时 GitHub 的投入。随着大语言模型的火热，我们意识到这个方向的商业化价值以及给开发者带来的价值都是巨大的。因此，去年年初，通义灵码就成为通义系列大模型产品家族的一员。

通义灵码是一款基于通义大模型的智能编码助手，提供自然语言生成代码、单元测试生成、代码优化、注释生成、智能问答等能力，通义灵码上线 4 个月，目前下载量已经超过 130 万，在国内 AI 编码工具领域使用率第一。但是，从最开始的产品发布、到现在灵码的产品能力获得用户的一致好评，这中间我们经历了非常多的困难。

最开始，我们尝试了基于开源模型，然后基于通义的基础模型进行训练，这其中挑战与机遇并存。一方面，我们感觉与 Github Copilot 的差距在逐步缩小，但我们也非常担心出现 Sora 这种情况，即突然有一个全新的架构或算法来颠覆我们之前的努力。另一方面，从国内接受度来看，最近一些媒体包括我们自己也进行了广泛调研，发现开发者对 AI 编码工具的接受度非常高，甚至有报道称 80% 到 90% 的开发者都在采用相关工具，这就意味着这种生产力工具对开发者的价值是实实在在的。

代码智能生成工具可能是业内最成功的大模型相关应用之一。我们现在跟很多客户接触，客户也觉得在基础模型的落地上需要探索很多场景，解决方案的复杂度很高，而代码模型的门槛非常低。我们发现大模型代码生成在 IDE 编码场景下非常适合当前的技术现状，因为不仅用户的接受度高，而且特别适合当前的技术现状。我认为它在这个领域的成功可能是必然。

我们最近访谈了很多企业，发现一些先驱型企业已经在思考如何使他们的代码框架和研发模式适应 AI。这可能是许多人未曾思考过的问题，如今 AI 对代码的理解方式还存在一定局限性，但我们可以通过一些调整让 AI 生成的准确率更高。

我们最近访谈的一个客户，他们的做法是让高级工程师用自然语言编写伪代码，然后将其定义好的数据和接口与自然语言注释一起交给大模型生成代码。然后初级工程师对其进行修正，这样提高了研发效率，也提升了高级工程师的价值。初级工程师的效率也得到了提升，整体上提升了专业性，不再是一个人从头到尾完成。这种方式避免了重复工作和精力浪费，企业未来可能会考虑采用所谓的 AI 原生（AI Native）研发模式。

国外一些项目已经尝试使用自然语言框架，按照 AI 理解的方式生成代码，大模型帮助生成整个工程的代码，生成的代码既有注释又有代码，这样如果出现变更，大模型可以很容易理解它自己生成的代码，形成良性循环。我认为这可能会在一年内实现，随着基础模型能力和理解力的提升以及 AI 原生编程框架的发展，可能会出现全新的代码编写模式。

观点 2：开放模型拥有广阔的前景，大模型未来的竞争很可能是流量入口之争、是生态之争。而谷歌是否会将 Gemma 开放模型融入 Android 和 Chrome 生态是值得期待的。

陈鑫（神秀）：在模型开源方面，阿里云做了很多工作，包括开源了 7B、14B 等模型，前几个月还开源了 72B 和 72B 模型的 1.5 版本。我们内部也是通过外面媒体得知有新版本的消息，之后才进行模型的升级。我觉得阿里云在开源领域非常用心，特别是在通义团队这边。

开源模型对企业，尤其是中大型企业的整体业务能力构建起到了关键作用。有了开源版本，企业可以以较低的成本进行实验，而不必花费大量资金购买商业化模型。企业可以先利用开源模型做一些实验，并结合一些 Prompt 的调优，就可以得到比较好的结果。

从我对企业的观察来看，开源对大模型产业的推进非常关键。我担忧现在模型参数量的增加会带来更大的算力需求。虽然开源模型的参数量越来越大，但企业面临的最大难题仍然是缺乏足够的算力。即使是 2B 模型的训练成本也很高，而现在很多企业甚至连推理资源都买不到，更别说进行训练了。企业需要考虑在公共云上构建训练，而不是自建。很多企业过去可能不考虑上公共云，但是现在这个问题可能会长期存在。企业需要权衡自建和使用公共云的成本，并考虑自建是否会导致错过竞争优势。

虽然现在各个厂商都在推动开源，但是将开源的价值真正落到企业的生产效益中仍然面临许多挑战。但我相信各个厂家已经意识到了这一点，并且可能会在未来几个月推出更多的芯片，希望能够解决企业面临的算力问题，包括云上算力的问题，希望我们能够尽快度过这个难关。

观点 3：简单的标注被 AI 取代，复杂标注对“人”的要求越来越高。

陈鑫（神秀）：这个话题我们非常感同身受，因为代码大模型的质量与高质量数据息息相关。提升模型本身的能力主要依赖于高质量数据，而代码领域又是一个专业的领域。过去几个月，我们花费了大量时间和资深专家去处理数据，只有将数据处理到足够好，才能获得更好的调优结果。

代码优化是一项艰巨的任务。我们需要确定有问题的代码，解决 bug 后优化的代码，优化的原因可能是风格问题、内存泄漏或安全性问题等。数据收集、处理和分析是关键，对下游任务的影响很大。我们在调整大模型以准确预测开发者行为和生成期望结果的过程中，需要处理大量数据，包括各种语言的语法分析、切分和数据构造等。预训练过程中可能会发现数据处理中的 bug，导致生成代码中出现语法错误或不合适的情况，需要返回修正。这一工作量较大且需要资深专家。

刚开始的阶段，人们可能认为数据标注不需要大量人工，会考虑使用 AI 代替，但随着深入了解，发现这些看似容易的事情实际上还是需要专家去做。未来，有经验的程序员可能会投入更多时间到企业内部的数据标注和处理，并训练企业专属的代码模型，以生成符合企业规范要求的代码。

GitHub Copilot 过去一直未推出企业个性化套件，直到最近才推出了类似于私有化模型的训练方法，通义灵码的个性化套件也将在 4 月份上线。我们预测接下来的趋势是，各个企业的员工可能都在尝试使用 AI 工具进行编码，随后各公司可能需要专人投入到数据处理和标注，以训练企业私有模型。

对于专家和工程师来说，尤其是那些曾经从事代码框架、中间件、规范、基础 SDK 和 API 开发的人，他们首先会将这些内容编写出来，然后将这些内容融入到大模型中，以便所有人都能从代码生成中受益，这是未来各企业需要考虑的重要问题。

观点 4：通过公共云平台获取算力是算力紧缺的当下值得企业认真考虑的解决方案，短期内我们可能很难摆脱“大力出奇迹”的规律。

陈鑫（神秀）：在代码领域，我们观察到一个明显的趋势：具有较大参数量的模型（例如 72B）在推理能力和理解能力上，尤其是处理长上下文方面，表现得比小参数模型要好得多。例如，当你要求模型为 1,000 行代码生成注释或单元测试时，小参数模型可能在处理前一两百行代码时还能保持正常，但随后性能会逐渐下降，甚至可能出现偷懒、忘记任务或开始出错的情况，而参数量较大的模型则能更好地处理这些问题。

我认为在一段时间内，尤其是在代码领域，我们无法摆脱“大力出奇迹”的规律。对于一些简单的任务，使用非常大的参数模型可能并不必要。例如，在通义灵码平台上，线上也并不全是使用千亿参数的模型。我们有不同参数规模的模型，如百亿参数、几十亿参数的模型，并且会根据任务的不同，将任务调度到相应的模型上。我们也在尝试形成各种专家模型的组合，并计划进行 DevOps 整个全链路的智能化改造。这有点类似于企业的流程再造，只是 DevOps 的软件生产流程与企业生产流程相似。在这个流程中，并不是所有的任务都需要使用非常大的参数模型。我们可以通过组合各种不同参数规模的模型，以及训练出的下游任务能力，来完成流程的改造。

我认为，使用多大规模的模型是需要企业去不断尝试的。但首先，我们需要解决算力问题。一旦解决了初始的算力问题，我们就可以开始逐步前进。至于后续的芯片问题，我相信最终也会得到解决。包括许多互联网大厂和国内顶尖的芯片制造企业，现在都在努力去创造一些改变。

观点 5：微调工程师岗位可能并不存在，但微调是一项必备技能，了解业务并将其需求转化为真正的 Prompt 才是真正的价值点。

陈鑫（神秀）：如果你想要进行微调，但不理解业务，那么你的价值就会非常有限。如果将微调定义为一个岗位，那么这个岗位应该具有深厚的价值，并且需要长期的积累和能力。

如果这个岗位的价值和能力很容易被替代，或者很容易学习，那么它可能就不会成为一个独立的岗位。以我们的例子来说，通义灵码本身就包含了一个非常简单的微调训练平台。这是因为我们把工程师在微调代码模型的所有经验都内置到了平台中，并且添加了一些配置。一个工程师通过一两天的培训，基本上就能掌握这些概念，开始进行微调工作。在代码领域，至少在我看来，这个门槛并没有大家想象的那么高。但在其他领域，门槛可能会更高。

对于专家知识来说，如何选择合适的数据、如何处理数据、如何解决出现的问题、如何校正训练不佳的模型、如何通过不断实验训练出符合预期的模型，以及是否清楚自己训练模型的目的，这些都是微调工程师需要考虑的问题。例如，如果你想要微调模型以理解特定的 SDK 库，并在代码补全时生成可以直接调用企业内部 SDK 或 API 的代码，那么你需要考虑如何教会模型实现这一点，构造什么样的数据，如何标注数据，以及如何筛选和处理数据。这些问题可能不是一个简单的微调工程师就能解决的。

未来，像原来的效能工程师或者中台的资深研发人员可能都需要具备微调的能力，将自己的代码资产训练到大模型中，让整个公司的人都能使用。所以，未来每个人都需要具备理解模型、处理数据和进行微调的能力，如果这成为一个必备技能，那么就不会存在一个专门称为“微调工程师”的岗位了。

观点 6：2024 年，Agent 将率先在 B 端落地。今年下半年，我们预计将看到大量 Agent 相关的实践和落地案例。

陈鑫（神秀）：关于 AI Agent 的话题，我认为今年它肯定会非常火热，甚至在代码领域也会受到关注。根据当前的趋势，我们可以预见这个过程将分为几个步骤。首先，大家会开始采用能够进行代码生成或续写的模型。接下来，会进行企业个性化的定制。正如我们之前讨论的微调，实际上已经涉及到了这个过程。然后，我们会进一步扩展这些模型的能力，目标是提高整个软件生产链条的效率。为了实现这一目标，我们肯定会利用 AI Agent 技术。

在没有模型的时候，我们需要训练这个“大脑”，然后通过像通义灵码这样的平台，专注于完成最核心、价值最大的任务。完成这些任务后，接下来就是构建 AI Agent。我们会搭建好平台，让各个企业基于这个平台构建自己的 AI Agent。研发领域的场景可能有上百甚至几百个，如果每个企业都进行个性化定制，那将是成千上万的需求，这显然不是一个团队能够独立完成的。

现在，各方面的技术探索已经非常成熟，我认为今年确实是 AI Agent 落地的关键一年。经过去年一年对模型和参数的优化，今年我们应该开始考虑企业个性化以及 AI Agent 的实际应用。我们已经看到，2024 年将有大量行业领先的客户开始在代码生成或代码助手领域落地。一旦他们起到了带头作用，相关的实践经验将会被大家所看到。

目前，我们在网上很少看到关于 AI Agent 实践的案例，这是因为整个行业还没有发展到那一步。预计 6 月份之后，将会有实践经验出现，下半年将会有大量 AI Agent 落地的场景和效果展示的文章，我对 AI Agent 的发展前景抱有极大的期望，这也是我们今年建设的重点。

原文链接

本文为阿里云原创内容，未经允许不得转载。