结合领域知识治理并训练

选择真正理解业务的大模型

ENI:aiXcoder如何定义智能化软件开发2.0时代的？

刘德欣:智能化软件开发2.0时代：首先通过严格的数据治理和链式管理，对企业的特定领域知识进行全面的结构化处理，确保从需求定义、设计、编码到最终代码提交的每个环节都得到精准记录和系统关联。在此基础上，进行低成本、高度个性化的模型训练，构建基于领域软件工程的大模型。通过多智能体协同自动化、传统软件开发方法和最佳实践的有机结合，全面保障了开发流程的高效性与结果的准确性，使大模型从单一的代码生成工具转变为与企业开发过程深度协同的智能体集合，显著提升了开发效率和产品质量。

我们所定义的智能化软件开发2.0时代，其核心概念并不复杂。可以用一个公式来概括：智能化软件开发2.0 = 专业软工领域大模型 + 多Agent协同 + 传统软件工程方法。

首先，本阶段的智能软件开发强调对软件研发流程的高度数据治理。整个开发全过程，从需求分析、概要设计、详细设计、编码实现、测试，直到最终产品上线，每一个环节都通过结构化的数据治理和全面的数据链管理进行链式数据追踪，确保原始需求被精确记录并与系统紧密关联。这种全链条的协同工作方式，不仅使得大模型能够最大程度地理解企业特定的业务逻辑，还能够在开发的每一个阶段中准确实现这些逻辑。同时，基于经过治理的领域化数据集，对模型进行个性化训练，使大模型能够深入学习并应用企业的领域知识，从而构建一个低成本、高度个性化的企业领域化大模型，这将是最关键的一步。此外，在实现领域个性化的基础上，通过多Agent方式解决软件开发流程中的各类问题，并结合传统的软件开发工具和最佳实践，确保领域大模型输出的准确性和可靠性。

同时，通过对经过治理的领域化数据集进行个性化训练，使大模型能够深入学习和应用企业的领域知识，从而构建一个低成本、高度个性化的企业领域化大模型。在实现领域个性化的基础上，我们通过多Agent协同的方式解决软件开发流程中的各种问题，并结合传统的软件工程工具和最佳实践，确保领域大模型输出的准确性和可靠性。

这种结合了专业软工领域大模型、多Agent协同，以及传统软件工程工具与最佳实践的协同自动化方式，正是我们所定义的智能化软件开发2.0时代。

ENI：根据智能化软件开发2.0时代的定义和特性，刘总，您认为企业在迈入2.0时代时，应该重点关注哪些关键行动或策略？有哪些具体的准备工作是企业需要优先考虑的？

刘德欣:结合多年来对软件工程领域的深刻理解，以及aiXcoder在企业领域化大模型落地方面的丰富经验。我们总结了以下4个核心策略，帮助企业更好的拥抱智能软件开2.0时代。

第一是面向领域的开发数据治理，这一点非常关键。简而言之，企业需要对最原始的需求文档进行深入治理，将自然语言表达的“大白话”需求逐步转化为精确的开发语言描述，从需求分析、设计，到开发、测试及运维等环节的数据、知识都进行整合并进行全链条数据治理，并确保数据质量、规模与多样性，以服务于领域大模型的构建与优化。值得一提的是，这种数据管理框架和方法能够高效复用，日后大模型产生的海量数据都是基于该框架治理，从而可持续用于训练，这有助于提高企业在应对市场变化时的灵活性和响应速度。

第二是基于领域数据的个性化模型构建。通过利用治理好的领域知识数据集，并充分考虑企业算力资源、代码量等因素，对大模型进行灵活的个性化训练及参数调优，确保大模型能够精准捕捉并反映企业业务需求，使其逐步掌握企业特定的业务流程与逻辑、专业术语和编码规范。进一步地，通过应用PEFT、MoE、RAG和AI Agent等技术和方法，确保个性化训练能够根据企业具体业务需求进行灵活调整和优化。这样的策略不仅增强了模型的业务适应性，还提升了模型训练效率和输出的准确性。

第三点是将大模型的先进能力与传统软件工程的方法和工具相结合。许多企业在引入大模型后，往往倾向于完全依赖大模型，忽视了原本效果优异的软件开发工具。这种做法实际上并不合理，因为大模型虽然具有强大的能力，但其生成结果并非总是精准无误。为了确保大模型输出结果的准确性与可靠性，企业应继续结合和利用传统的软件工程工具与方法，使其与大模型协同工作，从而保障开发流程的时效性和结果的高质量。

最后一点是面向各场景的智能协同。通过引入Agent技术，将其与企业特有的软件开发流程和现有的软件开发工具相结合，以提升开发流程的透明度和效率。同时，确保所有自动化过程的合规性和可追踪性，实现需求分析、设计、编码、测试和部署等各个开发场景的深度协同。通过系统化的数据共享和流程整合，开发团队能够在各个阶段实现无缝衔接，从而更加高效地应对复杂的项目需求和快速变化的市场环境。

ENI: aiXcoder如何帮助企业落地智能软件开发2.0时代？

刘德欣:在与很多大型企业交流的过程中，我们发现目前企业普遍面临着搞不懂、训不转、学不会三大挑战，展开来讲，就是企业缺乏优秀人才，现有的技术人员搞不懂模型应该如何训练。有些企业技术积累较好，试图通过开源模型+各种微调的方式，尝试让大模型的能力更贴近企业的真实开发环境要求，最终还是发现大模型学不会企业的领域知识，效果不尽如人意。

为此，我们发布了一个大模型落地框架LLM Adoption Framework(LAF)，旨在帮助企业了解如何将大模型与领域知识相结合，并利用我们的经验，帮助来自各个领域和行业的企业有效地部署和落地领域大模型。具体来说，该框架是一种咨询的方法论，分为以下三个阶段：我们首先会根据企业的商业目标进行全面评估，深入了解企业已开展的工作，以及为何未能实现大模型落地的预定业绩目标，并分析导致这些差距的原因。基于这些差距企业应该怎么选择模型，怎么准备和处理数据，如何训练模型，可以通过哪些数据治理的方法来达到预期的状态。此阶段旨在精确构建并优化大模型，确保模型深度融合并体现企业特有的领域知识。在这一阶段，不仅进行模型架构的设计与搭建，还包括针对企业独特业务逻辑和领域特定数据的深入治理及训练过程。这一阶段主要涉及产品化的过程。我们将帮助企业将领域大模型与其内部多个平台通过API进行集成，并确保模型能力能够有效输出到业务端，所有这些都需要根据企业的实际需求进行定制化实现。

总而言之，aiXcoder的LAF并非特定于任何一个开源/闭源提供商，而是大量利用aiXcoder提供的大模型训练、领域经验和软件工程最佳实践为企业提供更具体的深度咨询和指导。同时，aiXcoder的LAF不仅限于aiXcoder模型使用，企业可以选择任何闭源和开源模型，它是通用的，并非“独门秘籍”，可以根据企业“领域知识”量身定制大模型落地实施及行动计划。

最后，总结一下我们的观点：

.无论是开源还是闭源，选择专业的软件工程大模型，而不是通用大模型。

.不关注大模型厂商宣传支持了多少功能和HumanEval、MBPP、MultiPL-E等常规的“打榜”评测集评测结果，要关注大模型实际生成内容是否真的理解企业的业务。

.务必要结合领域知识治理并训练，再做进一步微调。直接使用常规的全参微调、高效微调、RAG等方式帮助不大。

.大模型落地要高度自治、解耦，企业业务的复杂程度和连续性，更不允许绑定某个大模型厂商。

.一定要做个性化训练，不能直接落地代码大模型，同时培养自己的技术人员，有效规避直接部署模型的高风险。