揭秘华为研发代码大模型是如何实现的-Toy模板网

这篇具有很好参考价值的文章主要介绍了揭秘华为研发代码大模型是如何实现的。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

本文分享自华为云社区《风靡万千软件开发者：揭秘华为研发代码大模型是如何实现的？》，作者： DevAI 。

秉持“自己的降落伞，自己先跳”的原则，由公司装备部门牵头，携手华为云PaaS作为基础能力提供方，与公司各产品线共同研发面向产业的代码大模型。在研发过程中，我们已取得初步成果，为了巩固各产品线的代码生成探索经验，我们将产品线研发成果迅速投入业务应用。在此基础上，我们总结了前期的方法和经验，期待更多产业的加入与交流，共同推动产业代码大模型的演进与推广落地。

本文深入探讨了当前研发大模型在实际产品中代码生成能力所面临的挑战，阐述了探索的总体思路、数据标准与语料层次、演进策略以及模型训练方案设计。同时，还介绍了RAG方案设计以及某产品线Dopra在真实场景中的应用，并总结了一套可快速复制的方法论。最后，对未来发展趋势进行了讨论：研发大模型是否有可能取代程序员？

1 产业研发大模型面临的挑战

华为拥有超过10万名代码开发者，每天新增代码行数达千万级别。在这种情况下，提高开发过程的效率变得至关重要。研发过程涵盖了需求理解、系统分析与设计、软件开发（包括手工编写代码、测试用例、代码检视）、系统集成与验证以及研发维护等环节。在整个研发过程中，编写代码的部分大约占据20%的比重。在人工智能大模型的时代，为了提升研发效率，利用大模型辅助生成代码的需求已经迫在眉睫。

在与产品线领域代码专家进行交流时，我们发现，由于产业数据未纳入训练过程，开源代码大模型在研发阶段基本上无法发挥作用。在产业领域，我们面临以下挑战：

首先，信息通信技术（ICT）专业领域知识繁杂且多变，开源模型未系统学习过程领域知识和系统设计等方面，因此难以处理复杂任务。

其次，华为代码仓库中存在数十万自定义的数据类型、函数API和变量引用，这些代码的语义复杂性较高。由于公司部分产业导向代码自注释，结构类型和成员、函数、变量缺少足够的人工注释。

此外，代码具有单一性，不同产品之间的代码关联性较小，导致代码语料数据泛化性不足。同时，文本与代码关联的语料数据在质量和数量方面都存在不足。华为嵌入式系统主要基于C/C++开发，C/C++代码具有固有特征，如头文件机制使类型和函数逻辑实现分离，状态空间更为庞大。

最后，代码依赖链路较长，涉及Void *、指针、结构体、宏定义、头文件等多种元素。项目级的跨文件和多层嵌套导致上下文依赖链路较长，从而降低了代码生成的准确性。

根据实地考察的业务需求以及公司研发战略目标，我们将重点关注具有业务价值的场景。目前，研发大模型项目组正致力于攻克代码辅助生成（C/C++/Java/Python）的难题，以构建软件领域的代码大模型，从而推动软件开发领域的新范式。

2 研发大模型构建探索总体思路

为了提高研发迭代的反馈效率，华为云PaaS大模型团队制定了5项数据标注与清洗规范、以及5个脚本工程项目。

图1 研发大模型探索的总体思路

在整个流程中，从原始训练语料的准备与清洗、SFT语料的提取，到训练、评估和部署的全自动化操作，华为云PaaS团队已经制定了5个数据标注和清洗规范。在训练流水线过程中，涉及到的5个脚本工具（包括清洗工具、SFT提取工具、训练脚本工程、部署脚本工程和IDE插件）也已经得到了产品线业务专家的认可和落实。这些措施显著提高了大模型研发的效率。

3 那些数据应该参与研发大模型的训练？

数据是大模型研发的基石，其质量直接影响到模型的最高性能。若大模型未经过专业领域数据的训练，就如同“文科生学理科”。针对产业特有的数据特征和挑战，我们首先对产业数据的训练配方表进行了梳理。明确了训练语料的范围、目标、场景、数据标准、处理规则、处理工具、试点产业以及质量评价等相关信息。

图2：研发大模型语料层次表

L0 开源阶段：对 GitHub、Stack Overflow 等高质量数据进行清洗。

L1 RawCode 阶段：清洗华为语料库中的 30 亿 tokens，涉及公司 10 余个产品线，以增强华为业务代码的基础能力。

L2 领域数据-SFT 阶段：包括代码地图、项目级的跨文件信息以及工程规范。通过 SFT 指令微调，利用跨文件上下文信息和领域专业知识，解决生成代码中的幻觉问题。

RAG（Retrieval Augmented Generation）阶段：在 IDE 项目文件中检索跨文件信息；在向量数据库中检索 API 接口说明、工程规范信息。根据 prompt 模板，将用户的需求描述与上述检索信息拼接成完整的 prompt，输入给大模型。

由于 L1/L2 模型训练需要一定周期，业务实践中项目组先使用 RAG 语料验证效果，逐步探索 L2 SFT/L1 Raw Code 匹配任务，以提升模型的理解能力和研发效率。

单一的 Prompt 工程/RAG 在一定程度上可以让模型接触到专业领域知识，增强专业表达。然而，更为关键的是让专业领域知识参与到模型训练过程中。

4 研发大模型整体演进策略与方案设计

为了提高大模型研发的效率，我们将整个研发过程分为两个阶段进行迭代和优化：

1、数据准备阶段。首先，我们对各产品线的代码仓库进行评估，挑选出高质量的代码仓库。接着，根据华为云PaaS研发项目组制定的五项数据标注和清洗规范对代码进行清洗。在《训练&推理语料层次表》的基础上，构建代码地图，并通过人工抽查与脚本校验自动化执行。最后，对训练数据进行格式统一，生成训练集、客观评测集和主观评测集。

2、在训练和评估阶段，我们针对第一阶段所准备的训练数据，在ModelArts平台上启动训练任务。通过每隔x个epoch生成的检查点（checkpoint）来进行训练迭代。在此基础上，我们进行批量模型评估，并将模型部署在Alpha环境中，以便用户进行评估和使用。

在Alpha环境中，IDE插件的上下文提取和RAG检索两个过程被巧妙地隐藏起来。IDE需要在项目层面跨文件进行上下文分析，从而提取当前编辑区域用户关注的跨文件上下文信息，并在prompt工程中进行组装。同时，RAG会根据用户的输入和意图，检索业务知识向量库。在prompt工程中，上下文信息和业务知识将按照重要性进行排序，然后送入代码大模型进行推理。生成的代码经过后处理后，最终呈现在IDE用户界面上。

在研发过程中，数据准备以及模型的训练和评估并非一蹴而就，而是需要经过多次迭代和验证。训练和评估过程中出现的现象和问题可以为数据迭代过程提供反馈。两个阶段紧密衔接，共同推进以实现最终的优化目标。

图3：研发大模型整体演进策略与方案设计

5 RAG：研发大模型的最后“一公里”

模型训练在一定程度上缓解了领域知识匮乏的问题（例如，避免使用不存在的数据对象和API，从而减少编译错误和运行错误）。然而，由于模型更新迭代周期较长且领域范围广泛，在实际产业应用中，仍需结合领域相关的《xx使用手册》、《xx白皮书》和《xx使用指南》等资料，以进一步减轻代码生成中的幻觉问题，提高知识的可追溯性和解释性。

RAG的设计方案和实现形式多样，我们的RAG方案主要关注自动化信息抽取和项目级上下文感知能力。

业务知识广泛分布于HTML、PDF、DOC、Word等多种形式，且范围广泛且接口不统一。为解决这一问题，项目组结合知识图谱和大模型技术，实现结构化、半结构化和非结构化信息的抽取，无需人工干预，即可生成低成本且高质量的知识。

自动化信息抽取同时解决了知识增量刷新机制的问题：通过工程化方法，克服了LLM知识更新的难题。将业务领域知识、华为编程框架、工程规范等模型所不具备的能力与模型相协同。在项目级上下文感知方面，基于项目静态结构、仓库演化历史以及开发者实时行为，精确检索与代码生成任务最相关的项目上下文。

以某产品线Dopra开发场景为例，我们整理了开发手册、线下文档、社区平台以及开发者经验等数据，汇总成Dopra开发的领域知识，并将这些知识向量化，存储到向量数据库中。当用户输入需求任务后，通过RAG能力，我们可以获取与该任务相关的开发经验信息。将这些信息通过“领域经验”提示模板输入给大模型，从而显著提高大模型输出代码的正确性。

图5 RAG方案中使用的Prompt版本示例