Sora很难跟进？微调就不是一个岗位？大力出奇迹将继续适用？大模型将对软件生态带来哪些变化？

年初，Sora 爆火，其带来的视觉冲击让我们不禁期待国内企业是否能给我们带来更多惊喜？谷歌发布的 Gemma 首次提出开放模型的概念，这是否是开源、闭源之外的第三条路线？智能编码工具的快速普及是否会带来全新的编程模式？被誉为生成式 AI 最先看到商业落地价值的“Agent”是否能在 2024 年给我们一些冲击？“大力出奇迹”的规律还将继续适用吗？ 

在 QCon 全球软件开发大会暨智能软件开发生态展即将召开之际，我们特别邀请了本届大会的出品人数势科技 /AI 负责人李飞 博士 ，阿里云 / 云效、通义灵码产品技术负责人陈鑫（神秀），白鲸开源 CEO、Apache 基金会成员、TGO 鲲鹏会学员郭炜就上述问题进行了讨论，以下为 InfoQ 根据圆桌讨论进行的内容整理。

观点一：Sora 会给多模态等相关领域带来深远影响，但国内因为缺乏积累，短期很难跟进 

李飞：Sora 的初次亮相确实让国内感到意外。此前，大家对视频的认知大多是生成 3 到 4 秒的视频，但是 Sora 在最初发布时却展示了一段 60 秒的视频，这让很多人感到震撼。从视频呈现效果来看，Sora 的视频非常流畅和稳定。在公布的 60 秒视频中，人物主体与背景之间的流畅性和稳定性令人印象深刻。视频中还包括了一些多角度镜头和镜头切换，表现也十分流畅。虽然有人认为 Sora 展示了对物理规律和学习能力的超强理解，但在后续生成的视频中，我们发现它对物理规律的理解和学习能力还有欠缺。

简单来说，Sora 的技术原理和流程大致是文生视频、图生视频，然后扩展到原视频。Sora 的出现在短期内可能会对短视频制作以及影视行业的剪辑和视觉交互产生显著影响。长期来看，对于视频领域，比如自动驾驶中利用到的相关技术，包括场景模拟等，Sora 可能会带来深远的改变。

Sora 的出现也给国内的技术人员带来了启发。首先，它可以将我们的视频输入分解成类似于 3D 的 patch，然后经过压缩处理进一步分解为空间、时间相关的特征，让模型在时空上进行信息交换。其次，OpenAI 一直坚持 Transformer 技术的 Scaling Law，而在视频领域也得到了验证，即参数规模越大、训练时间越长、训练数据集越好或越大，生成的视频效果会更好。Sora 的出现将会带动国内视频领域的公司和创新者，给他们带来更多启发，推动这一领域的蓬勃发展。

郭炜： 此外，Sora 的出现，我们能明显看到国内和海外大模型之间的差距并没有缩小，反而呈现出明显增大的趋势。对于国内的大模型创业者来说，这确实是一个挑战。这种变化让我们清楚地认识到了这个现实问题。

在语言文字大模型方面，大家可能没有感觉到差距很大。但从视频生成来看，尤其是考虑到不同摄像头角度的影响，底层训练中使用的 Transformer 架构以及全新的创新理念，我稍微悲观地认为，在短期内国内可能无法做出像 Sora 那样质量的文生视频。尽管去年 ChatGPT 推出后，国内迅速出现了“百模大战”，但值得注意的是，Sora 发布后国内没有跟进，因为我们跟进不了。因为这项任务的难度和计算量，以及我们的人才储备都还不足够。 在 ChatGPT 推出时，我们已经积累了不少经验，但当 Sora 出现时，国内却没有任何 DiT 架构的准备。因此，我认为国内想要做视频原生大模型还是非常有挑战的，可以需要近 2～3 年的准备。

这个领域的前景还是非常广阔的，因为它把大模型引入了物理世界理解范畴，同时能够大大减少摄影棚、渲染等方面的成本和时间。 对于未来的科幻影片、个人短视频甚至电影导演行业来说，都将产生巨大变革。我相信在美国，也许在好莱坞的下一部影片中，将会广泛出现基于剧本的由大模型生成精彩视频，而中国的这个技术可能在未来两年仍然落后。

尽管未来两到三年，国内可能还无法做出像样的产品，但一旦中国找到了方向并不断尝试，未来的产品肯定会比海外更具成本效益、更普及、更实用。光明在前方，尽管目前还有些黑暗。

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

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

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

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

代码智能生成工具可能是业内最成功的大模型相关应用之一。我们现在跟很多客户接触，客户也觉得在基础模型的落地上需要探索很多场景，解决方案的复杂度很高，而代码模型的门槛非常低。我们发现大模型代码生成在 IDE 编码场景下非常适合当前的技术现状，因为不仅用户的接受度高，而且特别适合当前的技术现状。我认为它在这个领域的成功可能是必然。（QCon 大会【下一代生产力工具】专场，陈鑫老师将具体分享通义灵码相关内容：https://qcon.infoq.cn/2024/beijing/track/1620）

郭炜： 我是非常激进的，我们公司的每个程序员现在都有一个 Copilot ，他们每天大约有 20%-30% 的代码是由 Copilot 写的。在内部，我们还做了各种尝试。首先是它擅长通过学习历史代码，并简单地复用和填充相似的函数和历史调用方式，特别是存在类似代码的情况下。另一个尝试是稍微复杂一点，比如说我们有一个用于数据同步的开源项目 Apache SeaTunnel 。在这个项目中做 SaaS 连接器时，我们完全复刻了 ChatGPT 来生成相关的代码。我们甚至因为需要使用 ChatGPT ，将原本的 14 个接口的代码改成了 2 个接口，以适应大模型的代码生成。这样做可以让大模型自动生成很多代码，因为 SaaS 有很多。只要把 SaaS 的接口放上去，它就能自动生成这些接口代码。

而且，智能编码工具特别擅长的是提高效率。例如，我们在做 Apache SeaTunnel 项目时，已经与 GitHub 的接口对接，能够获取数据并生成代码流程。如果需要使用 Git、Gitee，也不用担心，将接口文档提供给 ChatGPT，它会自动生成代码，而无需重新考虑规范。与人类生成的代码相比，大约有 97% 是 OK 的。只要提供良好的示例，它就能产生出色的结果。

我认为，大模型在代码生成方面，可能会先被一些技术先驱人尝试使用。我之前看过 GitHub 的一份报告，该报告统计了全球活跃度排名前 5,000 个项目。在这 5,000 个项目中，有 3/5 的项目贡献者都已经开始采用大模型生成代码来辅助开发。现在全球范围内，如果你公司的程序员或公司尚未开始利用大模型来辅助开发，我觉得这个公司可能已经落后了。未来的一段时间内，如果程序员自己不擅长利用大模型来帮助开发代码，我觉得可能会在更短的时间内被淘汰。大模型的掌握与否，将如同过去写简历时说“我擅长 Java，擅长 C 语言”一样，可能会变成“我擅长使用 Copilot，擅长使用通义灵码”这样的标准。否则，你可能会在求职过程中被淘汰。

陈鑫（神秀）： 郭老师提到的观点非常好，特别是关于代码智能的话题。我相信他的公司一定是深入了解用户需求的，我们最近访谈了很多企业，发现一些先驱型企业已经在思考如何使他们的代码框架和研发模式适应 AI。这可能是许多人未曾思考过的问题，如今 AI 对代码的理解方式还存在一定局限性，但我们可以通过一些调整让 AI 生成的准确率更高。

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

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

李飞： 确实如此，越来越多的程序员现在使用代码生成工具进行日常代码编写。据一份报告显示，GitHub 的 Copilot 下载量已经接近 1,400 万次。我和一些美国朋友交流时得知，除了那些对安全合规性要求极高的企业之外，70% 以上的企业程序员都在使用代码开发工具，我们公司内部大多数开发者使用代码生成工具主要是做代码补全和模块化代码生成。

我一直在思考为什么代码生成工具在大模型落地方面进展如此迅速。我认为其中一个原因是代码补全和生成允许用户进行干预，从而保证容错率。为什么大模型在其他场景下（如营销文案生成）迟迟未能落地？我发现在这些场景下，用户可能难以对生成的内容进行干预。如果生成的内容不符合预期或不适合特定场景，用户很难对其进行修改，这可能导致整篇内容被废弃。在代码生成领域，程序员通常会对生成的代码进行修复和调试，这种交互模式使得用户能够容忍一定的错误率并进行人工修复，因此这种场景可能会更快地落地。

我注意到国外的一个统计报告显示，OpenAI 的代码生成工具，如 CodeX 和 ChatGPT，使用率比 GitHub 的 Copilot 更高。我认为这可能是因为 OpenAI 的交互界面更简单、更易于操作，用户使用量更高。我认为代码生成工具在现阶段已经得到了广泛应用，尤其是在重复性工作和程序编译方面。

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

郭炜： 首先，我非常看好 Gemma 开放模型，因为从 Google 的角度来看，他们在开源生态方面做了很多工作。现在有了开放模型，他们先开放了 2B 和 7B 的模型，这可以与他们原来的开源生态结合得非常紧密。Google 很厉害，因为他们掌握了安卓生态。如果他们将开放模型内嵌在安卓生态中，会发生什么？将来的每个游戏可能都会生成一个角色，并根据故事与真人进行交互。如果每个安卓手机都内嵌一个 Gemma 开放模型，游戏调用这个模型时，用户的游戏体验会是怎样的？所有的安卓手机都可以通过 Gemma 模型提供自然语言对话，帮助用户做更好的个人助理，这会是怎样的感受？这样你就不再需要笨拙的 Siri 了。如果将来这种模型嵌入到 Chrome 浏览器中，那么浏览网页时，如果文章太长，你可以直接要求生成摘要。如果文章是学术论文，你可以要求查找相关论文，这是一种怎样的体验？用户可能会认为，我使用的是 ChatGPT 入口，我的 Google 搜索栏是入口，这是不对的。我认为，未来大模型的竞争将是入口和流量之争。Google 有很好的入口，拥有 Android 和 Chrome 这样的生态。我甚至认为，Google 可能会推出一个新设备，类似于之前的 Chromebook，但是内置了大模型和安卓或 Chrome 这些生态，可以是“Gemmabook”，不同于目前的所有手机、设备。这可能是一种全新的大模型生态，开放给人们体验。

我认为这只是 Google 布局的第一步，未来可能会更进一步。我也听到一些对 Google 的负面评价，说他们的大模型相对落后，因为他们的重点在“负责任的 AI”上，而且据说 CEO 要被换掉。如果 Google 仍然是我所崇拜的那个创新型企业，他们一定会将这个大模型嵌入到所有现有的生态中，并让全人类迭代到大模型流量入口的时代。未来一定是多模态入口的生态。所以我非常看好这个趋势，觉得有很大的发展潜力。（QCon 大会【开源产品的商业化】专场将邀请众多开源领域专家畅聊：https://qcon.infoq.cn/2024/beijing/track/1623）

李飞： 像 Google 这样的公司，他们推出了一个 2B 和一个 7B 的模型。对于 2B 模型，我不认为它是一个终点。换句话说，2B 模型应该朝着端模型的部署方向发展。在国内，一些模型厂商，尤其是手机厂商，也在这个赛道上努力。一些手机厂商可能会将模型嵌入到操作系统或类似浏览器的端口，这在操作系统层面上是可行的。另一方面，手机厂商是否可能在模型参数量方面接近 2B，这意味着未来越来越多的手机设备将具备大模型相关的能力，不仅在操作系统层面上，在整个手机设备或其他小型设备上也具备这种能力。对于国内来说，可能需要从另一个角度将大模型更好地赋能生活的方方面面。对于 7B 模型，包括之前的一些研究报告称它已经全面超越了一些常见的架构。这种开源生态的选择性可能会更高，这给国内的企业或厂商提供了更多的选择机会。

谷歌也在布局整个生态系统，未来是否会有 1B 甚至比 1B 更小的模型？这可能会更贴近我们日常生活的需要，可以满足我们使用大模型相关能力的需求。我们期待更好的模型出现。

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

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

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

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

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

李飞： 我认为在数据标注的环节中，人的角色很难消失。大模型发展到目前阶段，数据质量已经成为各家能力的主要要素。尽管数据标注在某些方面已经逐步自动化，但我认为人工标注仍然不可或缺。在处理复杂、模糊或特殊情况的数据时，人类能够提供机器无法匹配的准确性和洞察力。之前，OpenAI 提出了基于强化机器学习的 RLHF 的强化学习思路，谷歌也提出了基于强化学习的 AI 反馈概念，即要求 AI 系统的目标与人类的价值观和利益对齐，不会产生有害或有毒的结果。但我认为，在机器涉及人类 AI 伦理问题时，实现对齐是机器无法达到的，即如何将数据与人类的价值观进行对齐，我认为人类在其中扮演的角色是至关重要的。在过去，我们的数据标注通常针对类似于 QA 或一些分类，标签等级别对齐。在处理一些高质量数据时，我们看到 OpenAI 使用大量的高精尖知识分子来完成完全式的答案生成。这种高质量答案的生成，同时带有业务场景和领域知识，我认为机器很难做到。因此，我认为人的角色在数据标注环节将变得越来越重要，标注工程师的水平会不断提高。未来，标注工程师可能会成为跨学科的数据科学家或数据工程师，参与到人工标注的过程中。

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

代码优化是一项艰巨的任务。 我们需要确定有问题的代码，解决 bug 后优化的代码，优化的原因可能是风格问题、内存泄漏或安全性问题等。数据收集、处理和分析是关键，对下游任务的影响很大。我们在调整大模型以准确预测开发者行为和生成期望结果的过程中，需要处理大量数据，包括各种语言的语法分析、切分和数据构造等。预训练过程中可能会发现数据处理中的 bug，导致生成代码中出现语法错误或不合适的情况，需要返回修正。这一工作量较大且需要资深专家。刚开始的阶段，人们可能认为数据标注不需要大量人工，会考虑使用 AI 代替，但随着深入了解，发现这些看似容易的事情实际上还是需要专家去做。未来，有经验的程序员可能会投入更多时间到企业内部的数据标注和处理，并训练企业专属的代码模型，以生成符合企业规范要求的代码。

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

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

郭炜： 我开个脑洞，刚才李飞老师和陈鑫老师都提到了一个观点，现在标注工作的水平和要求越来越高，因为低级的标注工作可以被 AI 替代。例如，与 ChatGPT 对话并指出其中的错误或缺失部分，可以通过强化学习让 AI 生成文字来进行自我博弈，而不需要人工进行这种低级标注。

如果低级标注工作可以被替代，那么随着代码生成本身的复杂性增加，就需要更高级的人工标注。未来，随着大模型写代码的能力逐渐超越普通人，是否会取代这一步的标注工作人员？甚至更远一步，标注的人员是否会越来越高级？可能最后需要标注的人是人类的哲学家，控制大模型不做出破坏性的行为。这意味着人工标注的水平将越来越高，不太可能被完全取代。最后的标注人员可能是顶尖的人类学家或哲学家，为大模型提供必要的指导和标准。这是一种脑洞的想法，提出了一个重要的问题：在技术发展的过程中，人类如何与机器相互作用和控制，以确保人类不会失去控制权。

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

李飞： 我们主要面向企业市场，尤其是金融领域。陈老师提到的一句话让我印象深刻，就是现在很多企业根本没有可用的算力，甚至连推理算力都买不到。在金融领域，我们使用大模型的场景很多，比如金融研报、企业内部问答以及数据分析等。这些场景涉及的数据非常敏感，金融行业对合规性要求非常严格。对于金融客户来说，在云上部署的阻力很大。很多金融机构希望在有限的算力下使用效果更好的模型。我认为国内的大模型厂商，尤其是针对金融行业的厂商，应该提供私有化部署的解决方案。 我们需要思考国内的大模型厂商是应该继续增大模型参数，还是专注于开发参数较小但效果良好的模型，这也是我们需要与国内的大模型厂商进行交流讨论的问题。

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

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

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

郭炜： 与上述两位老师相同，我们服务的客户也涉及头部银行和券商。大模型项目的推进需要大量的算力资源，如果没有云上的资源或者租用资源的话，推进这些项目将变得非常困难。举个简单的例子，我们是做 DataOps，就是数据自动同步调度类的大模型项目，其中有一个自动写 SQL 的项目。虽然这个项目在我们这里成功验证了，并且客户也验证通过了，但在立项时却发现需要两张A100显卡。这时候，客户就会犹豫不决，认为只需要雇佣4个程序员就可以解决这个问题。这说明，尽管大模型是一个新兴且有潜力的领域，但在企业内部，它的 ROI不一定会那么高。 对于 72B 这样的大模型来说，两张 A100 显卡可能还不够，并发性也不够高。因此，要提高 ROI，就需要考虑使用更先进、更开放的显卡，在云上部署模型可能是一个好的机会。我相信在未来，随着显卡性能的进一步提升和 ROI 的提高，云上使用显卡的趋势会逐渐流行起来。 尽管现在有很多项目都在用大模型进行各种 fine-tuning 和训练，但很多并没有拿到项目机会。现在能拿到项目的往往是一些知识库，因为它们对模型的要求相对较小，显卡需求也不高。在稍微复杂一些的场景中，我认为进行私有化部署和训练的时机尚未到来，需要等待显卡成本进一步降低，大模型能力进一步提升，以至于比雇佣人员更经济实惠的时候，这个趋势才会真正蓬勃发展。

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

李飞： 在我们这个领域（数势科技专注于智能分析和营销场景下的 AI Agent 构建，希望通过自动化手段，让 AI Agent 能够将工具的能力、接口和任务规划拆解成具体任务，实现平台和工具的自动化）进行微调的投入可能不会像陈老师和郭老师那样多。因为我们主要专注于开发 Agnet、框架和构建方面。我认为微调仍然是最重要的，因为我们需要确定构建何种数据集、微调哪种模型以及这个模型解决什么业务场景。因此，我们解决的是分析场景，类似于郭老师提到的 Text to SQL 情境。对于这种文本转换场景，我们的指标是指标语义。我们需要准备大量的指标语义，就像微调一样。例如，当用户提到查询时，其语义需要与相应的指标对齐。在准备数据集时，我们发现这有点像从无到有的过程。在准备数据集阶段，我们需要专业的人士来帮助构建数据集。因为对于微调工程师来说，他们能够定义数据集的格式，但是什么是正确的，什么是错误的却很难定义。因此，在微调阶段，数据集的构建需要由业务专家参与，他们了解分析知识和能力。因此，在微调过程中，我们大部分的精力实际上都花费在数据集的构建上。

在微调过程中，我们会遇到一些问题。首先，如何在处理大数据集时进行微调，同时又不忽略所采用的基础模型及其本身的能力？我们之前的实验表明，针对数据集进行微调可能会相对较好，适用于我们的场景。当将模型部署到客户端时，客户可能会认为，这只解决了其中一个场景的问题，比如仅解决了数据查询问题，而对于所投入的大量成本和算力来说，ROI 不高。客户希望模型能够解决更多的场景，例如营销文案生成或代码编译等，因为场景越多，客户的付费意愿就越高，但是这会让我们会失去模型本身的能力。 如何让模型具备多个场景的能力，这是我们一直在努力解决的。总的来说，在微调阶段，我们很难把握模型在多个场景下的兼容性能力。对于原有的基座大模型，它通过预训练或 SFT 初始阶段学习了大量通用知识。我们发现通用知识在应用时也会有所损失。因此，微调是一项需要耐心和时间的工作。对于微调工程师而言，工作量需求还是很高的。我们面对的场景是多样的，微调是针对特定场景的，随着场景的增加，需要由业务专家和微调工程师共同参与微调。因此，我认为微调工程师不是短期职业，而是随着不断变化的场景而持续存在的职业，但是一定要具备对业务场景有深刻的认知和洞察能力。

郭炜： 说到微调工程师，这个职位在我看来似乎是不存在的。首先，在微调工程师之前，还有一个曾经非常热门的岗位叫做提示词工程师（prompt engineer）。尽管这个职位被提出来，实际上并没有真正成为一个职业。因为真正能够运用提示词的人，并不是因为他们对提示词本身的使用有多精通，而是因为他们对业务本身的理解有多深入。

Prompt engineering 实际上是一种工程学，它是可以学习的。它并不需要长时间的训练和经验积累才能掌握。比如，如果你使用 ChatGPT，你很快就会知道如何调整温度参数，如何设置 Top k 和 Top p。这些已经是它的瓶颈所在了，而且这个瓶颈并不高。我认为，更重要的是一个人是否了解自己的业务，以及他能否将业务需求转化为有效的 prompt，这实际上是非常困难的。

我们回过头来看微调工程师，情况也是类似的。真正的微调工程师，也就是 fine-tuning 工程师，他们实际上是 NLP 算法工程师。他们熟悉语言生成的场景、语料准备、标注以及整个流程。他们对算法本身非常了解，并且对当前的应用场景也有深入的认识。他们以前使用的是自然语言处理的相关算法，现在是将这些算法换成了大模型。实际上，我们并不改变算法本身，只是调整输入数据来进行 tuning。现在，我们所做的 tuning 工作只是将算法变成了一个大模型，而在参数和输出方面并没有区别。所以，我认为所谓的微调工程师这个职位，其实只是一时的炒作。但从长远来看，微调工程师仍然是算法工程师，只是他们使用的算法底层是大模型而已。

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

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

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

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

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

李飞： 我认为 AI Agent 的应用首先会在 B 端市场落地，因为 AI Agent 本质上是一个 Prompt 工程，结合了其他软件工程来构建架构。它的目的是让大模型进行深度思考，并控制模型输出的不稳定性。在 B 端，面向企业内部人员的使用场景中，容错率相对较高，这使得 AI Agent 更容易在 B 端落地。早期的 AI Agent，如 AlphaGo，通过环境感知做出决策，并根据决策结果执行行动闭环。AlphaGo 利用强化学习进行游戏，这展示了 AI Agent 在结构化环境和固定模式下的自动化能力。

大模型的出现为 Agent 带来了灵活性，使得在面对复杂任务时，可以利用大模型的知识和逻辑推理能力。通过慢思考的方式，我们可以激活大模型的规划和推理能力。最初，我们通过 prompt 工程与大模型交互，尝试让模型逐步思考以提高回答的准确性。随着时间的推移，我们发现大模型缺乏实时更新知识的能力，因此我们在 Agent 中引入了类似 memory 的结构，作为知识库的外挂，帮助引入外部知识和用户对话中的知识。

为了更好地让大模型完成工具调用和执行任务，我们可能会采用类似于 React 框架的结构。当大模型的推理能力不足时，我们会将其问题转化为规划领域的描述语言，并设计规划器来分解问题，将解决方案转化为可执行的任务，以满足不同场景的需求。

如果大模型提供的能力不可靠，我们可以通过 AI Agent 的机制，让它像人类一样进行任务分解、生成结果，并对结果进行反思和再思考。这构成了 AI 代理的整体框架。简而言之，AI Agent 的发展是为了弥补大模型的不足，提供更可靠的任务执行能力。

总的来说，AI Agent 主要利用了尝试性的思考和大模型的深度思考能力。我认为，在未来一年中，AI Agent 在B端市场的应用将会加速，因为当前许多软件工程正在以智能体或 AI Agent 为中心进行重构。

特别是随着 Sora 的出现，我有一个想法，即 未来 AI Agent 可能不再仅仅通过语言描述来构建，而是通过多模态信息，比如视频和图片，来更接近人类与机器交互的方式。 我对这个方向的 Agent 发展持乐观态度。同时，我们 QCom 今年也举办了关于 AI Agent 的主题活动，我们鼓励大家在 AI Agent 领域进行更多探索，分享各自在 AI Agent 研究方面的前沿知识（内容地址：https://qcon.infoq.cn/2024/beijing/track/1633）。

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

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

现在，各方面的技术探索已经非常成熟，我认为今年确实是 AI Agent 落地的关键一年。经过去年一年对模型和参数的优化，今年我们应该开始考虑企业个性化以及 AI Agent 的实际应用。我们已经看到，2024 年将有大量行业领先的客户开始在代码生成或代码助手领域落地。一旦他们起到了带头作用，相关的实践经验将会被大家所看到。目前，我们在网上很少看到关于 AI Agent 实践的案例，这是因为整个行业还没有发展到那一步。预计 6 月份之后，将会有实践经验出现，下半年将会有大量 AI Agent 落地的场景和效果展示的文章，我对 AI Agent 的发展前景抱有极大的期望，这也是我们今年建设的重点。

观点八：“数字人”从“人”的视角来探索应用场景，可能会有不错的前景 

郭炜：“数字人”可能需要改个名字，这里有几个问题。首先，当用户考虑购买数字人时，他们可能担心数字人会取代自己，这种关系处理起来比较复杂。其次，目前的数字人技术还不够成熟，很快就会遇到所谓的“不可思议谷”（Uncanny Valley），即当机器人或仿生对象与人类相似但又有细微差异时，会让人感到不适。在当前环境下，数字人技术似乎还无法跨越这个障碍。因此，将产品命名为“数字人”可能会加剧这个问题，使得产品难以做得更好。

我认为，如果将其称为数字助理，可能会更受欢迎。例如，如果李飞老师有一个数字助理，可以在他需要休息时帮助他回答问题，或者在直播中与观众互动，这将是一个非常好的应用场景。而不是试图创建一个完整的数字人，这在当前技术下可能会被批评为无用。

如果我们要探索数字人的应用，我建议首先从个人角度出发。例如，KOL 和那些愿意尝试新事物的人可能会愿意购买一个训练有素的数字助理，帮助他们阅读文章或制作视频。这可能是数字人服务首先被接受的方向。至于将数字人用于客服等场景，由于对质量的要求很高，可能会面临更多挑战，比如客服说错话、赔偿问题、客户投诉和隐私问题等。这些问题都很难处理。因此，个人用户可能会是数字助理技术的早期采用者。如果数字助理在这些场景中表现良好，那么未来可能会有更多的应用场景出现，这只是一个开脑洞的想法。

本文来自微信公众号“InfoQ”（ID：infoqchina），作者：赵钰莹，36氪经授权发布。