Google 把 Gemini 定制进自己的代码库:29,000 名工程师参与的内部实验

Google DeepMind 最新论文详细披露企业级 LLM 定制全流程:从 1 万亿 token 专有代码数据集,到 mid-training + post-training 全栈调优,在 29,000 名开发者盲测中实现迭代次数减少 23%、代码存活率提升 17%,并提供可被其他组织复制的方法论蓝图。

研究速览

Google DeepMind 最新发表的论文《Customizing an LLM for Enterprise Software Engineering》(arXiv:2605.16517)1,详细披露了他们如何把通用版 Gemini 适配到 Google 内部软件工程生态,并在 29,000 名开发者参与的盲测中取得了具体结果。这是三大公司中少见的「企业级 LLM 定制全流程开源方法论」,兼有工程实践价值和技术路线参考意义。

为什么要定制,而不是直接用 Frontier 模型

通用 Frontier 模型在标准基准上已经很强,但企业内部有两类典型问题:
  • 私有知识壁垒:Google 内部数万个代码库、内部 API、内部代码规范,通用模型从未见过,补全时容易建议用已废弃的 API 或错误的调用约定
  • 代码演化信号未利用:每次代码提交、审查意见、函数改写、上线回滚,都是标注质量极高的训练数据,但通用模型无法利用
论文给出的核心命题:即使模型已经很强,用内部数据做定制仍然能带来系统性的增益。

数据集:从一万亿 token 的专有语料起步

构建数据集是整个流程中成本最高的部分。论文描述了两类主要信号来源:
  • 代码变更记录:每次函数改写的前后对比、代码审查评论(包含人类工程师对代码质量的真实判断)
  • 内部文档:API 文档、设计说明、接口规范
最终构建了 1 万亿 token 规模的专有数据集,其中大量来自 Code Review 中的审查评论——这类数据的特别之处在于,它隐含了「什么写法更好、为什么更好」的人类工程判断,而这恰恰是通用预训练数据里极难覆盖到的层面。1

训练策略:中间训练 + 防灾难性遗忘

论文最核心的技术贡献在于训练流程设计。他们采用的是 mid-training(中间训练) 策略,而非从头预训练或简单的 SFT(有监督微调):
  • 在已有 Checkpoint 的基础上继续用内部数据做预训练
  • 同时保留部分通用语料,防止模型「遗忘」通用编程知识(灾难性遗忘)
  • 之后再做 post-training(包含 RLHF / 偏好对齐)
这一路径的背后逻辑:如果只做 SFT,模型容易过度拟合内部风格而丧失泛化能力;如果只做预训练续训,对齐效果不足。mid-training + post-training 的组合是两者的平衡点。
论文称这套方法为「全栈模型调优(Full-stack model tuning)」,涵盖 continued pre-training 和 post-training 两阶段,并在论文中提供了迁移到其他组织时的「复制路径」。

核心实验结果:在 29,000 名开发者中做盲测

论文没有只报告 benchmark 数字,而是做了一项大规模的 盲测 A/B 实验,让真实工程师在不知道用的是哪个版本的情况下完成日常任务:
指标变化
每轮平均迭代次数减少 23%
代码存活率(写下来的代码最终被保留的比例)提升约 17%
参与规模29,000 名开发者
代码存活率这一指标尤其值得关注:它直接测量的是「模型给出的代码对工程师真实工作是否有用」,而非模型在合成 benchmark 上的表现。迭代次数减少意味着工程师需要更少的往返交互才能得到可接受的结果。1

方法论蓝图:论文给出了四步复制路径

论文明确表示,这套方法论设计为可被其他组织复制,给出了四个关键步骤:
  1. 信号提取:从软件工程数据中识别高价值训练信号(代码变更、审查记录、文档)
  2. 数据预处理:清洗、去重、质量过滤策略
  3. 全栈调优:continued pre-training → post-training 的完整流水线
  4. 下游应用部署:定制模型如何在 IDE 插件、代码审查工具等应用层落地
这意味着这篇论文不只是 Google 的内部总结报告,而是有意为外界提供的参考架构。对于有大量内部工程数据的组织(金融、医疗、大型软件公司)来说,方法论的复用价值可能超过数据集本身。

对技术路线的影响

这篇论文有几个值得关注的含义:
第一,企业定制路线与通用模型竞赛是两条并行赛道。在通用基准上领先并不意味着在企业内部部署上也最优——反之,内部数据的质量和针对性可能比模型基础能力更决定最终效果。
第二,code review 数据作为「隐含人类判断的高质量标注」,是当前鲜少被系统利用的训练信号。Code Review 中的每条评论背后都是有资历的工程师的判断,其密度远超通用的 RLHF 标注。
第三,「灾难性遗忘」的解法仍是工程上的难点。论文并未披露保留通用语料的比例,这也是这套方法迁移时面临的最大不确定性之一。
正在加载链接预览…

围绕这条内容继续补充观点或上下文。

  • 登录后可发表评论。