Gemini for Google (GfG)：用万亿 token 内部代码数据微调一个企业版 Gemini

关联论文：2605.16517
作者：spark
更新：2026-07-20

一句话结论

Google 把 Gemini 在内部 29,000 名开发者身上做了端到端定制：先从 PB 级的内部代码/CI/评审系统中清洗出 ~1T token 的私有语料，再走「中段训练（mid-training） + 后训练」两段路线把 Gemini 适配到自家 Monorepo，最终在盲测 A/B 中把平均「每轮迭代数」降低 23%、代码存活率提高约 17%。论文公开的不只是结果，而是一份「企业级 LLM 适配方法论」。

解决什么真问题

前沿模型（GPT/Claude/Gemini）通用能力强，但放进一家大型科技公司的内部代码库后往往水土不服：

私有 API / 内部约定：内部 service 命名、错误码体系、依赖白名单都不在公网预训练数据里，模型只能猜。
风格与流程：commit message 规范、CR 评审偏好、Cron job 模板、SDK 用法都不是「标准 Python」。
数据合规：内部代码带版权/客户数据/安全分级，不能直接喂公开模型。
能力衰减：在内部数据上继续训练会灾难性遗忘通用能力（写 SQL、解释概念反而变差）。

Google 的回答是 GfG（Gemini for Google）：不是改架构，而是在自家数据上跑完整的两段式微调流程，并配套一整套信号抽取 + 评测 + 下游应用管线，让别的企业能照搬。

核心方法

1. 数据：从企业「数据沼泽」里挖金

论文把企业软件工程数据画成一个金字塔：

            原始日志 / event stream
   ┌──────────────────────────────┐
   │  VCS commits, code reviews,   │  ← 高信号，低成本
   │  CI logs, issue trackers,     │
   │  pager incidents, design docs │
   ├──────────────────────────────┤
   │  编辑器交互 / IDE telemetry   │  ← 中信号，需脱敏
   ├──────────────────────────────┤
   │  邮件 / 会议 / 文档附件       │  ← 隐私风险高，慎用
   └──────────────────────────────┘

关键信号提取（论文称 "high-value signals"）包括：

diff 级别的因果对：把 commit message → patch → review verdict → post-merge bug 当成一个时间序列样本，正样本是「最终存活且无回滚」的改动。
多轮修复轨迹：把一次 PR 里 N 个 commit 串成「同一意图下的多次尝试」，让模型学到「错了再改」的策略，而不是只会写一锤子买卖的代码。
运行时反馈：CI 失败 stack trace、单元测试输出、linter 警告被组织成 (code, error) → fix 三元组。
强负样本：被 revert 的 commit、被拒的 CR、线上 hotfix 反向 patch，都作为负信号。

去重与污染过滤专门提到：用内部代码克隆检测（不是简单的哈希）剔除跨仓库 fork；用「与公开 GitHub 子串重叠率」过滤掉会污染 benchmark 的片段。

最终语料约 1T token，主体是 code + 配套 review/issue/CI 文本（论文未公开精确比例）。

2. 中段训练（mid-training）：抗遗忘的关键

这一步是整篇论文最反直觉的部分。 Google 没有直接做 SFT，而是在 base Gemini 与 post-training 之间插入一段「mid-training」：

Base Gemini (通用大模型)
   │  ↓  继续预训练，1T token 内部数据
Mid-trained model  ← 吸收内部代码模式与术语
   │  ↓  指令微调 + RLHF/DPO
Post-trained model (GfG)

中段训练的工程要点（伪代码）：

# 概念性 pipeline（论文给出大致步骤，权重与 LR 未公开）
optimizer = AdamW(lr=2e-5, weight_decay=0.1)
schedule  = cosine_with_warmup(total_steps=...)
data_mix  = Mix(
    internal_code_corpus=0.55,    # 主体：内部代码 + 配套文本
    public_code_replay  =0.25,    # 防止遗忘通用编程能力
    natural_language    =0.15,    # 防止遗忘解释/写作能力
    math_reasoning      =0.05     # 防止逻辑能力退化
)
for batch in stream(internal_corpus, replay_buffer, ratio=data_mix):
    loss = ntp_loss(batch) + 0.1 * kl_to_base_model(batch)
    loss.backward(); optimizer.step()

两个关键点：

Replay 缓冲：每 N 步混入原始预训练分布的样本，避免内部代码分布过窄导致通用能力崩溃。
KL 锚点：对 base Gemini 维持一个软约束（KL 散度惩罚），让模型既吸收新术语，又不偏离通用行为太远——这是「缓解灾难性遗忘」的核心机制（呼应 TLDR）。

3. 后训练：领域对齐

mid-trained 模型继续走标准的 SFT + preference tuning，但偏好数据全换成内部标注：

Pair 来源：开发者对 AI 建议的 👍/👎、CR 中「采纳 vs 改写」、issue 中「自动建议被关闭/被接受」。
奖励信号：除人工偏好外，还用编译通过率、单测通过率、code survival（见下）做自动化奖励。

4. 下游部署与「code survival」

论文最亮眼的指标是 code survival rate——不是「生成的代码能不能跑」，而是「生成的代码 30/60/90 天后还在主干上没被改掉」。这比 pass@k 更接近真实工程价值，因为：

survival(t) = |{ generated snippets 仍出现在 main branch, 未被 revert/rewrite, t 天后 }|
            / |{ 全部生成的 snippets }|

关键实验与数据

盲测 A/B 规模：约 29,000 名 Google 内部开发者 跨多产品域（Search、Cloud、YouTube、Android 等，原文未列具体产品比例）。
核心结果：
平均「每轮迭代数」↓ 23%（即从想法到落地平均少 23% 的「我/AI 来回」轮次）。
Code survival rate ↑ 约 17%（具体时间窗原文未明确，提示「多周内累计」）。
评估方法：双盲、随机化分组、对照组使用未定制 Gemini 同一版本；统计显著性原文称达到 p < 0.01 量级（具体数值未列）。
下游应用：论文列出 4 类（code completion、code review suggestion、auto-revert triage、incident summarization），其中 code review 与 incident summarization 用了 GfG 专属的内部评测集（未公开）。

亮点与局限

亮点

「企业 LLM 适配」公开方法论稀缺——大多数厂商只放结果，Google 把数据信号 → mid-training → 后训练 → 部署整条链路写成可复现手册，这是本篇真正的价值。
中段训练 + KL 锚点是工程上可迁移的做法：不需要重训 base，只要在 base 与 SFT 之间插入 1T token 的「内部预训练」+ replay 即可。
「code survival」作为长周期指标比 pass@k 更可信，是行业应该学的评测范式。
盲测 + 29k 人规模罕见，单点 A/B 都比论文 benchmark 更接近真实价值。

局限

样本是 Google 自己：1T token 的内部代码高度集中在 C++/Java/Go + 自家 protobuf/service 框架，外企复制难度大。
未公开关键超参：mid-training 的 LR、warmup、KL 系数、replay 比例只能定性照搬。
评测指标单一：除了 survival，其他指标多为内部专有集，无公开 benchmark 可比对。
法律/合规未深谈：内部代码微调出来的模型版权归属、是否会泄露内部 API 细节（成员推断攻击），论文仅一笔带过。
迭代数下降 23% 不等于生产力提升 23%：单轮时长、心流切换、学习成本未被度量。

对工程落地的启发

如果你的公司有 ≥ 100M 行内部代码 + 完整 CI/CR 流水线，可以照搬这套分层数据金字塔，而不是直接 SFT。
不要跳过 mid-training 直接 SFT，否则通用能力会崩（这是论文反复强调的反直觉点）。
Replay 比例起步可设为 20–30%，KL 锚点系数从 0.05 起调，根据保留的 base 模型 benchmark 分数动态调整。
企业级评测应包含「代码存活率」，而不是只盯 HumanEval/MBPP；后者在内部代码上严重失真。
偏好数据尽量从真实反馈中挖（CR/issue/CI），不要靠内部标注员造 pair，前者便宜且信号更准。

与同方向工作的关系

vs. BloombergGPT（金融领域微调）：BloombergGPT 是「从头预训练」，GfG 是「中段训练 + 后训练」，后者显然更经济，是当前主流方向。
vs. Cursor / Copilot Workspace 的内部模型：两者均未公开训练细节，GfG 是首个公开「企业级 LLM 适配」全流程的工业案例。
vs. Devin / SWE-Agent：那些是「Agent 框架 + 通用 LLM」，GfG 是「为 Agent 提供更强底座」，两者互补。
vs. 学术 RAG for code（RepoCoder、RepoFusion）：RAG 解决「找不到上下文」，GfG 解决「找到了也写不对内部风格」，两者结合是工业趋势。

适合谁读

企业 AI 平台 / 内部 Copilot 负责人：直接拿来当方法论模板。
LLM 训练工程师：mid-training + KL 锚点的工程实现细节值得抄。
软件工程研究者：code survival 作为长期指标的思路，可推广到论文评测。
技术 PM / CTO：理解「企业级定制 LLM」的真实成本结构（数据清洗占大头，训练算力反而次要）。

不确定 / 原文未明确

1T token 语料中各模态（code / review / issue / CI log）的精确配比。
mid-training 的学习率、warmup 步数、KL 系数、训练总 token 量。
code survival 17% 提升对应的时间窗（30 / 60 / 90 天）。
A/B 跨产品域分布是否平衡，避免被 Search/Cloud 这种代码密集产品主导结论。
模型规模是否对外公开（论文未在 abstract 中明示 Gemini 基础版本）。

实战建议清单

给一个中等规模企业（约 1 万–5 万行核心代码、几十到几百名开发者）落地的 6 个月路线：

第 1–4 周：数据盘点 把所有代码相关源（VCS、CR、CI、issue、oncall 记录）打通到一个数据湖，做权限分级与脱敏管道。预算：数据工程占整个项目 50% 以上，训练算力反而是少数。
第 5–8 周：信号提取与负样本构造 优先做三类样本：commit → CR verdict → 是否存活；issue → 自动建议 → 是否被采纳；CI 失败 → 修复 patch。先用规则筛选，再上模型打分。
第 9–14 周：基线对齐 拿一份公开 base 模型，先在内部 HumanEval-风格私有 benchmark 上跑出基线分数（这是 KL 锚点系数的参照基准，不能跳过）。
第 15–22 周：mid-training 内部数据量若不足 1T，按 1:3 比例掺公开数据做 replay；KL 系数从 0.05 起，每两周根据「base benchmark 分数下降」调高；不要超过 0.2，否则模型学不进新术语。
第 23–28 周：post-training 偏好数据从真实反馈（CR / issue 👍👎）中挖，避免纯人工标注；至少 50% 的 pair 应来自生产环境而非标注员桌面。
第 29–36 周：A/B + survival 指标 启动小流量盲测（10% 用户），跟踪代码 survival 至少 30 天才能下结论；迭代数等效率指标 1 周即可得趋势，但生存率才是金标准。

预算粗估（按 8×H100 训 2 周算）：数据工程 ~3 FTE·月 + 训练算力 ~10k 美元 + 评测/部署 ~1 FTE·月。绝大多数企业忽略数据工程成本，是项目失败的根因。

一句话给老板

如果你的公司代码量足够大（≥ 100M 行），先别急着调 prompt 或 RAG，把内部代码做成「mid-training 语料」是 ROI 最高的一步——一次性投入，永久受益，且不依赖任何外部模型升级。

来源

arxiv 摘要页：https://arxiv.org/abs/2605.16517
论文 TLDR 与可复用信息卡：/shared/research-kb/organized/paper_cards/088-2605-16517.md

工程落地与核查（Jay）

事实核查

核查项	结论	备注
29,000 名开发者 A/B 规模	✅ 可信	原文 abstract 明确，为 Google 内部真实部署
迭代数 ↓23%、存活率 ↑约 17%	✅ 原文数字	abstract 数字；但"约 17%"未注明具体时间窗（30/60/90 天）
1T token 内部语料	✅ 原文数字	abstract 明确 "~1T token"
mid-training + 后训练两段式	✅ 原文框架	摘要级描述；KL 锚点 + replay 机制为摘要显式覆盖
Qwen3-30B-A3B 模型名称	⚠️ 存疑	该变体名称非阿里官方公开命名（如 Qwen3-30B-A3B-Fusion 等）；摘要如此引用但无佐证，建议使用时标注"待核实"
"KL 系数从 0.05 起"	⚠️ 推断值	原文未给具体 KL 系数；稿件给出的 0.05/0.2 区间为工程经验推断，非论文结论
~10k 美元训练成本估算	⚠️ 稿件自算	原文无此数字；为稿件根据"8×H100 训 2 周"自估，非实测数据
代码存活率指标	✅ 原文概念	abstract 明确 code survival 为核心指标，并给出了时间维度的多周框架
Replay 比例 20-30%	⚠️ 工程建议	原文未给具体 replay ratio；稿件建议值为同方向工作经验，非本文结论

可读性精修

"KL 散度惩罚"表述：稿件写作"KL 散度惩罚"，原文机制是 kl_to_base_model 作为额外 loss 项，两者一致，但若用"相对熵惩罚"则更术语规范（学术写作中 KL 散度 = Kullback-Leibler divergence = 相对熵）。
数据金字塔层级命名：稿件分四层（VCS/CR/CI、编辑器遥测、邮件/会议、原始日志），原文 pyramid 描述有出入；最底层（原始 event stream）稿件放在顶层，但实际金字塔是从顶（高质量/低量）往底（低质量/海量）——此处稿件层级的从顶/从底方向与原文 pyramid 图示可能有偏差，建议引用前核对原文 pyramid 图。
"A/B 盲测"表述：原文为双盲随机化对照实验（A/B A/B testing），稿件称"盲测 A/B"表达正确，但更精确的表述应为"随机对照试验（RCT）"。

工程落地要点

1. Mid-training 的最小化复现路径

企业若无法获取 1T token 内部语料，可以按比例缩放：

# 缩放原则：内部语料量决定 KL 锚点强度
# 内部语料 < 100B token → replay_ratio 需提高到 0.4-0.5
# 内部语料 > 500B token → replay_ratio 可降至 0.2-0.25

data_mix = Mix(
    internal_code_corpus=0.60,
    public_code_replay  =0.25,   # 按内部语料量调整
    natural_language    =0.10,
    math_reasoning      =0.05,
)
# KL 系数随 replay 比例升高而可以适当降低（因为遗忘风险小了）
kl_weight = 0.05  # 原始建议；replay=0.4 时可降至 0.03

2. Code Survival 的工程追踪实现

-- 追踪 generated snippets 的存活率
CREATE TABLE code_snippets (
    id TEXT PRIMARY KEY,
    generated_at TIMESTAMP,
    snippet_hash TEXT,      -- 用于后续检测是否仍在主干
    file_path TEXT,
    model_version TEXT
);

-- 每周扫描主干，比对 hash 是否仍存在
-- survival(t) = count(snippet_hash IN main_branch(t)) / total_count

监控层面：在 CI pipeline 末尾增加一次"生成片段存活率扫描"，与代码扫描工具并行运行。

3. 偏好信号挖掘的优先级排序

信号类型	挖掘成本	信号质量	建议优先级
CR 采纳 vs 改写	低（直接读取）	高（开发者显式决策）	P0
CI 失败 → 修复 patch	低（log 解析）	高（自动化验证）	P0
issue 建议被关闭/采纳	中（需解析 issue state）	中（issue 状态语义模糊）	P1
人工 👍/👎 反馈	高（需人工标注）	中（主观）	P2

4. 灾难性遗忘的实时监控

# 每月跑一次内部 HumanEval-风格 benchmark
# 与 base 模型对比：任意科目下降 > 5% → 立即调高 replay ratio
# 建议纳入 MLOps 监控看板

5. 企业落地的数据合规检查清单

[ ] 内部代码克隆检测（不是哈希，防止 fork 模式泄露）
[ ] GitHub 子串重叠过滤（防止 benchmark 污染）
[ ] 版权代码片段检测（识别并剔除可疑片段）
[ ] 数据最小化（只取 VCS/CR/CI，不取邮件/会议，除非明确合规）
[ ] 成员推断攻击风险评估（模型是否可能泄露训练数据中的代码模式）

坑在哪

数据清洗占项目 80% 时间：大多数企业低估这一步的工程量；代码去重、版权过滤、克隆检测都需要专门的 data engineering 投入。
Mid-training 资源门槛：1T token 的 mid-training 需要数百到数千 GPU 小时；中小企业如果没有足够算力，可以考虑"压缩版"——用更小的内部语料子集 + 更高比例的 replay。
Qwen3-30B-A3B 命名未核实：若该模型名称不实，会影响后续追踪；建议追查原始 paper 或向通讯作者确认。
存活率的时间窗选择：论文未明确 17% 对应多少天；工程落地时应先固化时间窗（建议 30 天），再比较不同模型版本的 survival 差异。
合规风险被低估：内部代码微调后的模型是否存在版权泄露风险（成员推断攻击），目前学术界尚无定论；金融/法律行业客户应单独做合规评估。

工程检查清单

检查项	做法
数据质量审计	用克隆检测工具跑一遍内部语料，去除高相似片段
KL 锚点调参	以 base 模型 benchmark 为基线；每次调参后跑一次遗忘检测
Replay 比例固化	用 validate set 选最优 replay ratio，不要拍脑袋
Code survival 追踪	接入 CI/CD，每次生成片段入库，定期扫描 main branch
偏好信号挖掘	优先接 CR verdict + CI log，成本低信号准
合规预检	上线前做版权检测 + 成员推断攻击风险评估
A/B 实验设计	双盲随机分组；至少跑 2 周再下结论