AIGC是亏钱货？网易杭研是如何抓住大模型价值的

生成式 AI 已经成为软件行业的一个重要推动力。在过去的一年里，包括网易在内的许多公司都在积极探索如何将这项技术应用到他们的产品中。如今，网易已经推出了多个生成式 AI 的实际应用产品，包括编码助手、大数据分析产品和低代码平台。在最新一期的“极客有约”对话节目中，鱼哲与网易杭州研究院人工智能部的算法负责人刘东一同探讨了有关大型模型产品的成本、速度和精确度等关键问题。

本文经编辑，原视频地址：https://www.infoq.cn/video/Wu1iSPABRu9NTVRrrywi

亮点：

• 大型模型帮助程序员编写代码是一项很有价值的技术，但从商业角度来看，它并不一定是一个特别有利可图的生意。

• 微调只是为了有针对性地增强它，使其更好地满足用户指令，所以首先需要基准模型能支持该任务。

• 我们从算法的角度出发，努力构建了一个优秀的领域子模型，以尽量避免通用模型的幻觉问题。

• 我们引入了一个"可信 AI"的概念，包括过程可验证、用户可干预和产品可运营三个方向。

• 从能力的角度来看，大语言模型已经展现出强大的表现，但我们需要根据投资回报率（ROI）来判断是否使用这些大型模型。

嘉宾简介：

鱼哲，Lepton AI 创始团队成员，产品负责人。

刘东，网易杭州研究院人工智能专家，AI 算法团队及产品团队负责人，专注于前沿算法研究与商业化应用。相关技术成果曾获浙江省科技进步奖一等奖。

鱼哲： 我个人认为 Codex 和 Copilot 等工具具有广阔前景，而 AIGC 也在广泛推广。刘东老师，您能否简要介绍一下，网易杭州研究院在 AIGC 技术以及软件工程领域的技术研究方向有哪些？

刘东： 关注 AIGC，特别是在软件研发领域，我们认为它在各个环节都有实际价值。例如，在需求分析和设计方面，大型模型已经能够提供出色的设计建议。在编码和开发阶段，Copilot 已经非常成熟，可以显著提高程序员的效率。在代码调试、分析和优化阶段，大型模型也能提供有益的优化建议，包括检测潜在的错误。甚至在测试阶段，我们也尝试使用大型模型生成测试案例。在运维环节，例如线上日志的实时分析和监控，也可以受益于大型模型的能力，提高效率。

从应用的角度来看，我们目前在编码和开发阶段最快地实现了 AIGC 的应用。特别是我们内部为研发同事提供了类似 Copilot 的工具，已经看到效率有所提升。此外，我们还开发了一些外部商业化产品，如在 BI 产品中引入了对话功能，推出了 ChatBI 产品，以及在低代码产品中使用大型模型来加速低代码开发效率。

鱼哲： 关于 Copilot，我之前在 GitHub 上也尝试过，还尝试过 Code Llama。我想代表我们的观众逐一提出一些问题。首先，所有程序员都非常熟悉的一个问题是，我们花费很多时间思考如何分解代码的功能实现，以及编写和调试代码。特别是编写单元测试，在后端开发中经常需要，虽然我们不会讨厌，但有时候确实不太愿意做这项工作。

然而，AI 辅助编程作为一个产品，我看到市场上已经有很多竞品，比如 GitHub 的 Copilot、OpenAI 的 Codex，以及 AWS 的 Code Whisper 等。有很多成熟的产品存在。我想问一下，为什么网易杭州研究院选择在这个领域开展工作？此外，微软在收购 GitHub 后表示支持 Copilot 业务，但据报道，这一业务目前亏本，因为 Copilot 对于开发者来说价格相对较高。微软在财报中也提到，他们每月支持一个开发者需要 100 美元，但实际只收取 20 美元。在这种情况下，您如何看待网易在这一领域的角色和作用？

刘东： 我们考虑这个问题时，有几个方面的考虑。首先，从安全的角度看，每家企业都有一些核心代码不愿意与外部共享，因此希望能够拥有相对可控的服务，并在其中使用大型模型以提高程序员的效率。 因此，就可控性和安全性而言，自研可能是一个较好的选择。

其次，每家企业都有大量的特定代码积累，而如何有效地利用这些代码，以在其业务中发挥价值，这也是一个重要问题。像 Copilot 这样的云服务通常比较通用，很难让企业将其自有代码集成进去并进行优化，以适应企业自身的习惯。

因此，我们通过自研的方式，利用自己的模型来更好地适应网易的需求和场景，以提供程序员更好的使用体验。这是我们的出发点。

至于亏本的问题，我也认为大型模型帮助程序员编写代码是一项很有价值的技术，但从商业角度来看，它并不一定是一个特别有利可图的生意。因为在这一领域，客户通常比较价格敏感，即使收费较低，用户也可能觉得价格昂贵。但从成本角度来看，确实需要较大的投入。因此，我们的考虑是综合各方因素来实施这项工作。

鱼哲： 除了安全性问题，您在网易情况可能会注意到一些特别适合的场景，不管是在电商还是游戏等许多场景中。您能否举一个具体的例子，展示我们在什么情境下通过自研的 Copilot 项目，更好地支持业务方编写其业务代码的案例呢？

刘东： 我们进行了大量的定制和优化，比如在游戏运营场景中，游戏经常需要举办各种活动。这些活动的方案通常由策划部门提出，要求程序员按照方案进行实现，但实现后可能代码只用一次，然后就不再使用。这种场景非常常见。

但是，由于许多游戏之间存在相似性，企业的代码库中可能有很多人写过类似的代码，具有很大的参考价值。在这种情况下，如果使用通用的 Copilot，它通常无法了解企业专有的代码信息，因此在这种场景下提供的提示效果可能不够理想。但如果我们进行企业定制，就可以通过一些增强的方式，将这些信息集成到提示中，然后将其提供给大型模型，使其能够参考这些代码来提供更好的提示。这样，我们就可以更好地实现降本增效。

鱼哲： 您刚才提到了在业务场景中进行了许多优化，特别是在模型层面。您能详细介绍一下优化工作是在模型层面进行的，还是在输送给模型的提示工程这一层进行的？或者说，在模型的不同方面都进行了优化，可以谈谈具体的优化思路是什么吗？

刘东： 我们的优化思路主要围绕两个关键点展开，以发挥大型模型的价值。第一个关键点是确保模型本身的强大性，这涉及将企业的专有知识融入到模型参数训练中，以使模型能够理解企业的专有领域知识。

第二个关键点是优化提示工程，即我们如何提供给模型更有信息量的上下文，以便模型更好地理解上下文，产生对程序员有价值的输出。我们发现，仅仅将当前代码片段的上文或下文提供给模型并让其继续生成，效果通常一般。因此，我们考虑了编程过程中的各种信息来源，包括引入的外部第三方库、工程中的其他项目文件、类似的工程项目，甚至程序员在编程过程中浏览和检索网页、查找答案以及执行粘贴和复制等操作。这些行为都是宝贵的提示信息，我们通过将这些信息融入到模型的提示中，帮助模型更好地理解当前的上下文，从而更好地输出对程序员有价值的信息。这些工作使我们的模型能够更好地与业务结合，提供更好的效果。

鱼哲： 您提到了模型微调，确实，在 Google 和其他地方，人们一直在进行对模型的微调。通过微调一个基础模型，将其完全适配到特定任务，这是一个非常有效的方法。许多人认为，只要有基本模型，然后进行一些微调，就可以将其应用到任何任务上，使其成为该任务的专家。您对这个问题是怎么看的？

刘东： 如果我要进行微调，内部除了我们自己训练的基础模型，还有许多开源的基准模型可供使用。我们进行了大量的评估，具体思路是，如果要进行微调，首先要分析基准模型是否足够强大，是否在具体任务上已经表现得相当不错，微调只是为了有针对性地增强它，使其更好地满足用户指令。如果基准模型根本不支持该任务，仍然强行进行微调的话，效果可能不太好，或者可能需要寻找一种成本更高的微调方式，类似于继续进行预训练，以将知识融入模型，然后再进行微调，例如 LORA 微调。我认为 LORA 微调可能只对现有的基准模型进行提升和补充有意义。当然，如果基准模型本来就不太好，那么可能不会获得太大的收益，或者预期的性能可能不会特别出色。

鱼哲： 您提到了成本问题，确实，在特别是语言模型（LM）这个领域，模型的推理成本随着参数数量的增加呈指数级增长。我们了解到，网易内部使用 Copilot 不仅仅涉及生成代码，还可能涉及解释代码推理方面。用户可能以多种不同的方式使用它。您是使用一个巨大的模型或者一个具有固定参数的模型来支持所有使用方式，还是根据不同的使用方式智能地调整背后模型的大小呢？

刘东： 我们选择了后者的方式，即 根据不同的使用方式智能地调整背后模型的大小，这是有充分考虑的。 从成本和效率的角度考虑，这是一个综合的决策。特别是在编程场景中，代码提示是一个非常高频的任务，因为每输入几个字母，都会触发一次提示请求。在这种情况下，模型需要足够快，因为如果太慢，程序员可能会自己完成输入，这样就不会提供太多价值。

另一方面，这个场景通常涉及到代码生成，相对来说是一个相对固定且不太复杂的任务，与通用任务相比，难度较低。因此，我们更倾向于选择规模较小的模型，以确保效率，并且不会明显降低质量。

对于像代码解释、调试分析或注释生成这样的任务，难度较大，可能需要更大的模型才能实现良好的效果。但好的一点是，这些任务通常不会有太高的使用频率，因此在这种情况下，我们可以选择相对更大的模型，而不需要进行大规模的冗余部署，因为请求量本来就不会太大。这种综合考虑帮助我们更好地控制了成本。

鱼哲： 随着大型语言模型的发展，特别是像 Copilot 这样的方式，例如像 LLAMA 这种模型，我们是否仍然需要手动编写注释呢？大家讨厌别人不写注释，但自己也不喜欢写。

刘东： 写注释与不写注释在很大程度上是一个习惯问题。写注释的主要目的首先是为了给自己提供提示，使代码更容易理解和维护。其次，注释也有助于他人理解代码，尽管注释的覆盖度要求可能并不高，因为大模型可以帮助填充一些细节。然而，写注释的程度可以因程序员而异，有些程序员可能倾向于写详尽的注释，解释每个细节，而有些人可能只写简要的概述性注释。这与个体的写作风格和代码质量意识有关。

鱼哲： 在网易杭州研究院，我们不仅在内部广泛应用这些先进的技术，还在一些领域提供对外的技术支持和合作机会。在对外方面有哪些技术合作呢？

刘东： 除了为内部提供技术支持，我们还将这些大语言模型的能力整合到商业化产品中，以为客户提供更多的服务。其中，我们的代表性产品之一是 BI 产品。通过整合大语言模型的能力，为 BI 产品引入了自然语言交互功能，使用户可以通过自然语言查询所需的数据和报表，这完全是由大语言模型驱动的。

另一个重点领域是低代码平台，我们的 CodeWave 平台，它通过低代码编程方式，降低了编程的门槛，提高了编程的效率，从而帮助企业节省成本并提高效率。在这个平台中，我们引入了大语言模型的能力，以提高效率和降低编程门槛。这两个领域是我们当前主要投入和发展的方向。

鱼哲： 我们还有一个低代码产品，可以介绍下这个产品的使用体验吗？

刘东：Low code 不同于 0 code，简而言之，它是一种基于可拖放的方式进行软件开发的方法。它不要求专业的程序员从头编写代码，也不同于完全无需编码的 0 code 方式。在低代码中，你可能需要配置一些固定的模板，定义数据模型，设计流程结构，还可以使用预定义的组件，通过拖拽的方式连接各种逻辑，最终生成软件产品。

这种方法的核心优势在于相对于传统的完全编码软件开发，用户需求较低，无需像计算机专业的本科毕业生或有丰富经验的人才那样写代码。但与 0 code 方法相比，它仍然保持了软件开发的灵活性，因为它可以实现复杂的逻辑。低代码的定位介于传统软件开发和 0 code 之间，兼顾了易用性，同时也能满足一些较为复杂的软件开发需求。

鱼哲： 您能简单介绍下这个产品的对外发布节奏吗？我看到官网上有些资料相关。

刘东： 我们目前在网易数帆官方网站上提供了一些基础材料和介绍。此外，我们即将在 11 月 2 日举行 2023 网易数字 + 大会，届时将提供更详细的产品介绍以及有关技术的分享。我们期待在发布会上与大家分享更多信息。

鱼哲： 回到刚才提到的 ChatBI，我在以前做业务时常常需要与 BI 同事沟通，例如我想了解最近三个月华北地区哪个行业的客户增长最快，哪个行业的客户有一些困难，以及他们所遇到的产品使用情况。这种情况通常需要等待一两天的时间，不管是 BI 同事还是我自己去做，都需要花费大量的时间来查看数据地图，查看每个表的结构以及做相关的 SQL 查询，因为我们需要定义特定的指标，例如复购、沉默和活跃等。这是一个非常复杂的问题，之前尝试了许多模型，但它们存在幻觉的问题，导致了一些错误的结果，这是不能接受的。在 BI 领域，这个问题是非常严肃的，我们不能容忍存在幻觉的问题。我想了解一下，你们是如何处理这个问题，如何解决这种复杂性挑战的。

刘东：我们面对的确实是一个巨大的挑战，而且我们在这个产品上花费了很长时间，因为 BI 场景是非常严肃的，它的任务是提供准确的信息。如果我们只是编造数据或者输出不可信的信息，那这个任务基本上就失败了。因此，我们采取了多重方法来尽量避免这个问题。

首先，我们从算法的角度出发，努力构建了一个优秀的领域子模型，以尽量避免通用模型的幻觉问题。我们收集了大量的数据和各行各业的常见数据报表，通过数据增强和训练，使模型的能力更强。这个领域子模型专注于解决数据分析场景，能够通过自然语言输入生成高质量的 SQL 查询语句。

其次，尽管模型很强大，但我们也意识到大型生成式模型不是 100% 可控的，因此我们在产品层面进行了多方面的工作。我们引入了一个"可信 AI"的概念，包括过程可验证、用户可干预和产品可运营三个方向。

• 过程可验证：我们不仅仅相信模型生成的 SQL 查询语句，而是使用一个查询语句解析引擎将其解析为人类可理解的语言，以确保用户了解模型的工作原理。如果发现错误，用户可以立即识别并不信任结果。

• 用户可干预：我们允许用户对模型生成的查询进行干预。用户可以更改条件、操作等，以纠正错误或调整查询。这提供了用户对结果的额外控制。

• 产品可运营：我们希望产品不仅仅是一个静态的工具，而是能够随着用户的使用变得更智能。我们收集用户的行为习惯，正例和反例，不断优化模型。我们也提供产品配置，以使模型理解各行各业的“黑话”和简称。通过不断的运营，使模型越来越智能，适应用户的需求。

这些方法的结合，以及其他细节的优化，使我们的产品更可信、可控，提高了用户的工作效率。

鱼哲： 这是否意味着当用户使用产品时，他们需要在某种程度上提前注入表结构的一些信息？或者说，模型能够根据表的结构自行猜测字段的含义？

刘东： 大模型是通过自主猜测的。只要提供底层表结构，大模型可以自动获取这些信息，所以用户在一开始使用时通常不需要太多干预。

鱼哲： 您刚刚提到的这个反馈收集非常有趣，因为通过良好的 RLHF 方法，模型的性能可以显著提高。

刘东： 是的，必须逐步将其系统运营，使其随着使用而不断智能化，而不是采取一劳永逸的方式。这样做的话，问题通常不会被永久解决。但一旦将其运营起来，将负面案例的反馈馈送给它，它就会不断改进。

鱼哲： 刚才有个直播观众的提问：“对于这些垂直领域的模型，你们是在基础大模型的基础上进行微调，还是持续进行预训练，或者是从零开始使用领域样本训练参数较小的模型？”

刘东： 我们通常是基于基础的基座模型进行调整。网易内部我们已经进行了基础模型的玉言，这是一个从头开始训练的基座模型。从头开始训练的好处是，我们大致了解未来要覆盖的领域，因此在训练过程中，我们有意地将一些领域相关的数据融入其中。例如，如果要处理编程任务，就会注重将代码相关的数据纳入模型。如果要处理 SQL 的任务，就会加入一些 SQL 的数据。这个基座模型相对来说比较通用。然后，我们会在这个基础上为每个领域创建领域特定的子模型，以进行适配。

鱼哲： 您提到的 ChatBI 的问题，如果拥有一个基础模型并为其创建功能，同时提供大量数据时，我发现在这个工作中，最大的挑战实际上不在于微调模型，而是在于找到合适的数据，并将其准备成可供模型使用的形式。我认为这是最困难的部分。

在研究一篇论文时，我注意到在数据稀缺的情况下，他们提出了一个新名词叫 RLAIF，即通过人工智能来生成强化学习所需的数据，以支持强化学习任务。

对于像 ChatBI 这样的项目，我认为您需要大量的数据来对基础模型进行调整，而且需要具备高度的语义和推理能力。模型的规模不会小，而随着模型规模的增加，调整参数需要更多的精力、计算资源和数据。

我想了解一下，您是如何在数据准备方面处理这些挑战的？因为实际情况是，在这类项目启动之初，数据通常不够整洁，或者很多人最初并不清楚这些数据可能会有哪些用途。您是如何处理这一问题的呢？

刘东： 无论是在 ChatBI 领域还是在以前的代码自动补全项目中，数据准备工作都是至关重要的，也是相当具有挑战性的任务。我们投入了大量精力来应对这个挑战。

在 ChatBI 项目，我们获得数据的途径多种多样。首先，我们会在网上寻找一些开源数据。在这个领域，因为传统方法已经发展了相当长的时间，所以存在许多开源的评测数据，以及公开数据表结构的定义。我们可以利用这些表结构，以人工智能的方式自动生成问题和答案，从而使用 AI 来生成数据，这是一种当前相对流行的方法。此外，我们还投入了大量人力资源来进行数据的搜集和标注工作，将各个来源的数据汇总，综合使用，以满足我们的需求。

鱼哲： 我觉得这个趋势在从事 NLP 领域的同事中也非常明显。人们开始广泛使用语言模型来执行以前需要使用多个专门的小模型来完成的任务。举例来说，以前我们需要训练专门的模型来执行诸如语音到文字转换、地址解析以及标点符号分割等任务。而现在，像您刚才提到的，在生成数据方面也使用了语言模型。这引发了一个问题，即您是否认为大型语言模型会逐渐取代 NLP 领域中使用的多个小型专家模型呢？

刘东： 从能力的角度来看，大语言模型已经展现出强大的表现，但我们 需要根据投资回报率（ROI）来判断是否使用这些大型模型。这意味着，尽管它们非常有能力，但我们不必在每个场景中都采用大语言模型。例如，对于一些小型 NLP 任务，我们可以使用较小的模型，它们成本低廉，在线上表现良好，同时可以满足高并发需求，因此在这些情况下，不必迫切转向大型语言模型。

当然，大语言模型的能力毋庸置疑，它们在某些复杂任务上可能表现更出色。然而，我认为大语言模型与领域专家模型之间不是相互替代的关系，而是可以共存的。在不同的情境中，可以选择使用不同的模型，以便最好地满足特定需求。这种差异化的方法可能是更好的选择。

鱼哲： 因为我之前有时也会采取简便的方式，直接使用大型模型，特别是在拥有免费积分的情况下。但随着时间的推移，我发现在考虑长期投资回报时，仍需要寻找传统的常规模型。

刘东： 在 ChatBI 中，除了大型模型之外，有时需要将小型模型和大型模型结合使用。这是因为尽管大型模型拥有出色的能力，但它在成本和执行速度上可能存在一些问题。小型模型则执行速度非常快。在某些任务中，如果你不断地调用大型模型来执行和解析，可能会影响用户体验，因此需要进行综合考虑。

鱼哲： 您刚刚也提到了，一方面，生代码生成式大模型或 ChatBI 生成式大模型等，都在数据收集方面面临巨大挑战。我认为数据是其中的一个技术挑战。除了数据之外，在这个过程中还有哪些方面您认为非常具有挑战性，非常难的呢？

刘东： 我认为数据确实是一个巨大的挑战，不仅在收集方面，还在清洗数据方面需要耗费大量精力。清洗数据是非常关键的，因为如果不做好，会直接影响模型的效果。我们在数据清洗方面投入了大量精力，因为高质量的数据是确保模型效果的基本保障，这是第一个挑战。

另一个挑战是一旦大模型的能力达到足够强，如何在实际业务场景中找到合适的应用场景，确保它能够创造价值。这方面也非常具有挑战性，因为大模型面临效率、速度和成本等问题。虽然它在很多场景下效果出色，但用户体验可能难以保证。此外，大模型作为生成模型，不可能百分之百准确。如何找到那些既能容忍错误，同时又能为用户带来实际帮助的场景，让模型成功落地，也是一个非常大的挑战。

总之，技术本身的能力与业务场景的结合是非常关键的，只有找到合适的结合点，大模型的能力才能真正发挥作用，用户才能真正感受到其价值。否则，它将一直停留在演示的层面，其技术的价值和影响力都会受到限制。

鱼哲： 有时候出现了上下文的误解。例如，用户可能要求搜索最近三个月内是否有玩过某个游戏，但可能会被错误地理解为最近三年。在 ChatBI 场景中，我们可能有一个 SQL 生成工具，但它生成的 SQL 语句缺少一个关键的"where"子句。现在，关于 ChatBI，是它能够接受用户的自然语言查询并自动触发查询任务，还是它只返回 SQL 代码，用户需要将 SQL 代码用于传统的数据仓库查询窗口中查询？

刘东： 我们的当前设计是完全自动的。当用户提供一个查询后，系统会立即执行，而且像之前提到的那样，各种 AI 操作都会在执行后进行解释，并展示各种条件。用户可以根据查询结果和这些解释来判断查询的可靠性。

鱼哲： 所以用户不仅可以看到生成的代码，还能了解为什么会生成这段代码。此外，生成的数据会以表格的形式展示，用户可以导出数据。产品是否还提供可视化或建模分析能力，还是用户需要自己去处理这些方面的工作？

刘东： 我们目前主要提供可视化展示，对于后续的建模分析，我们正在进行研究和探索。

鱼哲： 您之前提到技术研究院需要同时具备技术和业务的理解，而最终需要为其结果负责。客户，无论是网易集团内部还是外部，都渴望了解这些生产力工具如何提升效率。这包括自动代码生成、SQL 自动生成以及低代码平台等技术，它们都旨在提高生产力。然而，生产力提升在实际中往往是一个具有挑战性的问题。难以证明这些技术是否可以直接提高生产力。关于如何证明生产力提升的问题，您是怎么解决的？

刘东： 我们一直在思考和探索这个问题，因为要传达技术的价值，需要从多个角度来考虑如何证明其价值。我们非常关注用户的反馈和实际使用数据，这对于衡量技术的有效性至关重要。

在我们内部使用低代码工具，例如代码补全工具，类似于 Copilot 工具，我们详细记录用户的使用情况，特别关注用户采纳提示的比例以及 AI 自动生成代码的比例。这有助于我们了解技术是否真正帮助用户减少编码工作，还是只是一个演示性的工具，用户不太愿意采纳其中的建议。

同样，对于 ChatBI 和低代码工具，我们也密切关注用户的使用情况。例如，如果没有 Chat 功能，很多业务人员可能无法自行使用 BI 工具来查询数据。但如果引入 Chat 功能，我们关心是否有人在使用，以及他们的使用频率。在低代码工具方面，我们使用自然语言来生成逻辑，然后观察生成情况和占比。这些数据帮助我们衡量技术是否真正提高了生产力，帮助用户在成本降低和效率提高方面取得进展。我们非常关注这些方面的数据。

鱼哲： 当我们致力于提高生产力效率时，如 AIGC 或大型模型的出现与以往的机械发明有很大不同。以前的机械或半自动机械本质上需要人的操作。例如，使用除草器可能需要有人操作设备，而自动化机械则需要人的干预。然而，像您刚才提到的 ChatBI，如果今天我可以使用自然语言描述业务需求，然后它可以为我生成正确的 SQL 查询并检索数据。那么对于那些传统的数据分析专业人员或 BI 同行，他们的存在可能会面临一些挑战，因为这种技术的出现可能改变了传统的数据分析方法。

刘东： 我认为这些工具主要是作为一种助力的角色存在的，而人的价值仍然不可或缺。无论是在 BI 领域还是在编码领域，它们的核心目的是帮助人们在一些简单重复的工作中提高效率。当拥有这种提高效率的工具时，我认为人们可以解放更多的时间，用于思考业务等更有价值的事情。这包括如何改进业务、更好地理解用户需求，以及如何提供更出色的软件产品。这是一种从不同角度思考问题的方式，而不是完全取代人的角色。因为这些技术目前正在逐渐发展，它们还没有达到 100% 可信并且能够胜任一切的状态。

鱼哲： 我听闻有些公司在内部开展了类似工作遇到了许多障碍。其中一部分障碍来自于开发团队，他们担心这种工具可能会与他们的工作发生冲突，或者一旦工具成熟，公司将不再需要他们。在你们尝试推广这些工具的过程中，是否也遇到了类似的挑战？

刘东： 我们目前并没有遇到这类挑战，因为我们进行了一些统计，发现从软件研发的角度来看，程序员实际花在编码上的时间并不占很大比例。编码只是他们工作的一小部分，更多的工作包括需求分析、整体设计以及与其他方面的对接等。编码所占的时间并不是很多。我们的目标并不是取代程序员，而是让他们能够更多地投入需求分析和用户场景理解，以便提高编码的质量和整个软件产品的效果。

鱼哲： 我觉得程序员这个称呼有点狭隘，因为在编写代码时，实际上他们不仅仅在写代码，更多的时候在进行工程工作，也就是做工程师的事情。工程师通常需要将来自外部的各种复杂难以理解的需求和分散的模块整合到一起。在这方面，生成式模型的能力是不可替代的，不论是在短期还是长期。我认为很难通过直接应用一个大型模型来完成需要花费多年时间理解和深入了解的业务。这种情况下，使用生成式模型可能不太适用，因为你需要时间来积累对业务的深刻理解，然后才能进行创新性的工程工作。

你刚刚描述的这些能力听起来确实非常有趣和具有吸引力。然而，我们也明白，许多公司，包括像网易自己开发 Copilot 时，通常出于安全和特殊场景的考虑，不愿意使用市场上通用的产品。这种担忧在中国和美国的科技公司中都非常普遍，特别是当公司规模较大时，它们通常更倾向于采用私有化部署，无论是在公司自己的数据中心还是在云上的 IDC。

在传统金融领域，如银行、保险和证券等领域，这些能力可以显著提高工作效率和效能。然而，由于国家监管要求或公司性质的原因，很多银行和保险公司通常需要确保技术提供的方式支持 私有化部署。我们会积极考虑这些需求，以满足不同客户的特殊要求。网易在这方面是如何考虑的？

刘东： 我们的模型都是基于自己的基座模型调用的，因此完全 可控。我们也提供了私有化部署的能力。除了不断优化模型性能，我们还专门组建了一个工程团队，专注于推理效率的优化、部署方案的设计以及各种硬件适配工作。

在私有化部署方面，我们考虑如何尽量 降低用户的成本，因为大型模型的成本相当高。首先，我们根据业务场景找到了适合的模型规模，而不是盲目地追求巨大的规模，这样可以减少硬件集群的复杂性。

其次，我们进行了 大量的工程优化。这包括引入业界开源的先进技术，以提高性能。我们还根据模型的特点进行了自定义适配，包括自定义内核等，以提高吞吐量和效率。

此外，我们还考虑了量化加速等操作，以确保资源的可控性。因此，即使使用普通的显卡，我们也可以将大型模型部署上，并为用户提供良好的体验。这些措施都有助于提供高效的私有化部署解决方案。

鱼哲： 在私有化部署方面，你们是可以进行多方面的性能优化的吧？比如模型量化、压缩以及重新编写一些核心代码，从而提高性能和效率。在私有化部署的时候，一种方式是用户直接使用基座模型，这是一个即插即用的解决方案。另一种是用户在使用一段时间后，需要进行自定义微调，比如强化学习微调（RLHF）或自适应微调（RLAIF）等，你们是如何解决的？

刘东： 我们提供两种服务模式，以满足用户的需求。首先，我们提供一种自助工具模式，类似于业界已有的微调工具和强化学习工具。这些工具包括数据集管理、标注、训练任务和部署任务等功能。用户如果拥有足够的实力和理解相关流程，可以自行使用这些工具来满足其需求。用户可以随时尝试不同的方法，进行 A/B 测试，以确定哪种方式效果更佳。

其次，对于一些重要客户，我们也提供定制化的服务。在这种情况下，我们的算法专家会与客户合作，共同解决他们特定的问题。我们会与客户密切合作，确保他们获得最佳的解决方案。无论用户自行使用工具还是选择我们的定制化服务，我们都将竭诚为他们提供支持。

鱼哲： 我也认为在私有化部署后再进行模型训练是一项颇具挑战的任务。从前我在这个领域有一段时间的从业经验，我深知这种工作需要投入大量时间和精力。此外，私有化部署环境通常存在标准不一致的问题，因此需要耗费额外的时间来解决各种复杂情况。

刘东： 每个客户的环境都有所不同，因此我们的目标是将产品尽量标准化，同时确保工具功能完善。这种方法有助于客户自行进行调整、训练和部署，降低了使用成本和门槛。只要他们理解这个过程，几乎都可以通过简单的点击鼠标来完成，而不需要深入编程或处理复杂的问题，这对用户来说更加容易接受和理解。

鱼哲： 在应用 AIGC 技术能力来提高软件工程效率时，您认为在业务端的落地过程中，最关键的角色通常会是什么？

刘东： 我认为在这个过程的每个环节都非常关键，没有哪一个环节可以忽略。首先，理解场景和找到使大模型落地的有价值的点至关重要。然后，需要探索这些点，以确定大模型的能力是否足够可控和可解决。如果算法可以解决问题，那么从工程角度来看，是否有足够的投资回报、性价比和用户体验也是非常重要的。最后，如何将这一切标准化地交付给用户，确保他们能够持续使用，而不仅仅是一个演示，也是一个巨大的挑战。每个环节都需要表现出色，才能成功完成这项工作。

鱼哲： 您怎么看待编程以及软件工程的未来？

刘东： 我认为 AI 和 AIGC 技术并不是要取代软件工程，而是要为软件工程提供更强的支持。随着数据积累、通信和计算能力的提升，对软件工程的要求变得越来越高，而 AI 技术可以提高软件工程的生产力。未来，软件工程师的角色可能会发生变化，从以程序员为主导变为人机协作的模式，工程师需要花更多精力学习和应用 AI 技术，以提高工作效率和生成更好的软件。

鱼哲： 这实际上涉及到一个重要的哲学性问题，即通用性与特殊性之间的平衡。在优化时，我们必须在通用性和特殊性之间做出权衡。因为优化通常是为了特定场景和硬件而进行的，它可能会牺牲通用性。您认为，在未来多久内，我们是否会看到通过代码生成或自动化方式，针对特定硬件环境进行优化呢？比如剪枝、量化、压缩和算子的自动生成。

刘东： 实现这一愿景需要大量的基础积累和技术成熟度。目前的代码生成技术主要依赖于已有的能力和沉淀的代码，然后通过大型模型的学习和自动生成来解决更多问题。这种自动化生成代码的技术在广泛的硬件和环境中得到应用，可能需要更多的积累和实践。

对于新的硬件和场景，手动优化仍然是必要的，因为了解硬件和业务逻辑、分析性能问题等需要人的专业知识。自动化优化工具需要基于已有的知识和经验，而不是凭空生成优化方案。因此，即使技术不断发展，仍然需要工程师的专业知识来指导和验证自动生成的代码。未来，随着技术的发展和积累，可能会有更多的通用性优化工具出现，但在新的硬件和场景中，人工干预和专业知识仍然是至关重要的。这是一个逐步演进的过程。

鱼哲： 这是一个非常有趣的问题，因为实际上几乎所有的模型在实际应用中都需要经过优化才能顺利落地。在许多情况下，尤其是当涉及硬件时，例如服务器端或者嵌入式设备，优化工作变得尤为重要。

举一个例子，最近非常受欢迎的 Vox 模型，它能够根据自然语言指令为机器人生成指令。然而，在将这一模型应用到嵌入式设备时，通常需要进行大量的优化工作。这种优化工作可能包括模型规模的压缩，性能优化，硬件加速以及适用于嵌入式设备的特定算法的选择。对于这种情况，通常需要工程师深入了解硬件的性能特征以及特定领域的需求。

《行知数字中国数字化转型案例集锦【第二期】》重磅发布，覆盖多个行业，对话一线专家，挖掘企业数字化的实践故事，揭秘数字化时代背景下如何重塑企业组织、技术与人才。扫描下方二维码，关注「InfoQ 数字化经纬」公众号，回复「行知数字中国」即可解锁全部内容。