# 构建新版 GitHub Copilot 内联建议模型：第二部分 - 原标题：Building the new GitHub Copilot Inline Suggestions Model: Part Two - 类型：博客 - 来源：code.visualstudio.com - 发布时间：2021-11-03 - 首次精选：2026-10-29 23:09 - 分级：值得看 - 学习层级：深入 - 主题：[model-distillation]()（第 12 位）、[decoding-acceleration]()（第 29 位）、[coding-agents-engineering]()（第 57 位） - 原文链接：[https://code.visualstudio.com/blogs/2026/09/23/building-the-github-copilot-inline-suggestions-model-part-two]() - 本站页面：[https://oplearnx.com/resources/pk\_172ca66c2568]() ## 摘要 这是 VS Code 官方博客系列的第二篇，讲述把补全式幽灵文本、光标附近的下一处编辑建议和较远位置的编辑统一到单个“3-in-1”模型的过程。文中说明此前分别由独立模型负责，并指出统一后一次请求可覆盖多种代码编辑行为，减少模型调用与服务复杂度。适合关注 Copilot 内联建议实现与编辑器 AI 设计的人阅读。 ## 中文精读 ### 1. 开篇：把三类编辑统一到一个模型 - 补全式幽灵文本（ghost text）、光标附近的下一步编辑建议（NES）以及更远处的编辑，此前由不同模型分别驱动。 - 团队构建了同时覆盖这三类行为的单一模型，得到的结论是：最佳效果来自训练、评估与编辑器设计同步演进。 ### 2. 阶段二：三合一模型 - 第一部分介绍了第一阶段：把 NES 与长距离编辑统一为二合一模型；本文接着把补全行为也并入其中，得到三合一模型。 - 过去一次编辑机会可能先发补全请求、再发二合一模型请求；三合一后一次请求即可考虑全部编辑行为并给出最佳回应，或在一个回应中串联多次编辑。 - 这大幅减少了模型调用次数与服务复杂度，但最大价值不在效率：单一模型可以针对当下情境优化出最合适的编辑，而不必迁就架构造成的人为边界。 - 在最终候选模型中，虽然侵入性较低的幽灵文本占比相较二合一方案下降，用户满意度却有可测量的显著提升，文中后段会再展开。 ### 3. 训练 v4 模型：加入补全能力 - 沿用开发二合一模型的经验，训练分布需要改动：通过从原补全模型蒸馏幽灵文本并用 LLM 评判器筛选质量等方式收集幽灵文本数据，再嵌入原训练配方。 - 需要重新平衡继承自二合一配方的多编辑数据；幽灵文本过少或太急于离开光标的模型会打断用户流程、推高丢弃率。 - 于是专门构造了多编辑数据子集，其中第一个补丁就是光标处的幽灵文本补全；强化学习阶段沿用第一部分的评判器设计，让编辑序列从最贴近当前工作的续写开始，再向外扩展。 - 早期候选模型给出的幽灵文本和建议总量都更多；用 STests、Output View Kind 和伪在线评测（Pseudo-Online Evaluation）三个基准离线衡量，HumanEval 结果也因补全能力增强而提高。 - 与当时生产上的二合一模型加补全模型方案相比，接受率、丢弃率、展示率和用户参与度均无统计显著变化。 - 但“接受并保留的字符数”（接受建议后一定时间内未被用户回退的字符量）出现边际显著的退步。 ### 4. 训练 v4 模型：加入补全能力 - 为训练三合一模型，团队沿用二合一模型的训练配方，但因为要加入补全行为，训练数据的分布必须调整。 - 幽灵文本数据通过多种技术收集，其中一种是从原补全模型蒸馏出幽灵文本，再用 LLM 评判器（judge）做质量筛选。 - 继承自二合一配方、包含多次编辑的数据需要重新平衡：幽灵文本太少或模型太急于离开光标的版本，会更多打断用户流程，丢弃率更高。 - 为此专门构造了一个多编辑数据子集，其第一个补丁是光标处的幽灵文本补全；强化学习阶段继续沿用第一部分的评判器设计，让编辑序列从最贴近当前工作的续写开始，再向外扩展到相关后续改动。 - 早期候选模型因此更频繁地给出幽灵文本、建议总量也更多；离线用 STests、Output View Kind 和伪在线评测（Pseudo-Online Evaluation）三个基准衡量，HumanEval 结果也因补全能力更强而提升。 - 与当时生产上的“二合一模型加补全模型”方案对比飞行，结果相当有希望：接受率、丢弃率、展示率和用户参与度均无统计显著变化，但“接受并保留的字符数”出现边际显著的退步；团队考虑了几种可能原因（包括建议质量），在缺乏其他指标变化的情况下最终锁定一个假设：建议长度。 ### 5. 训练 v5 模型：幽灵文本完整性 - 假设是：模型产出的幽灵文本比生产补全模型略短，用户可能接受了看起来可行但不完整的建议，随后更频繁地回退或修改。 - 例如只写函数签名和文档字符串而不给出完整实现，用户可能删掉函数、手动修改或重写。 - 做法沿用二合一模型处理插入问题的经验：收集针对这类长输出场景的数据子集并做类似的上加权（upweighting）。 - 另外新增一个专门考察幽灵文本完整性的辅助评判器（auxiliary grader），只对这些精选样本启用。 - 离线度量上新增第二版 Output View Kind 数据集，比较模型回应中幽灵文本的字符长度与占比相对生产模型原始分布的变化。 - 飞行结果：接受并保留字符数的退步有所减轻但未消除，丢弃率呈上升趋势；内测（dogfooding）中的若干观察让团队把目光投向模型之外，印证了“客户端行为与模型同等重要”。 ### 6. 模型只是端到端体验的一环 - 好的内联建议体验是优秀模型与优秀端到端系统的结合，需要客户端精心编排，在最佳时机以最佳方式呈现编辑。 - 内测三合一候选时发现一个值得重审的历史客户端决策：幽灵文本被忽略后，若用户把光标移到别处，缓存的建议会被当作 NES 编辑重新展示。 - 初步估计这一行为可能把三合一模型的丢弃率抬高 7–8%；A/B 消融后影响更大：丢弃率从相对生产二合一方案的 \+15.9% 变为 -10.1%，相差 26%。 - 历史原因：独立 NES 模型的建议可在光标移动时异步到达，因此其幽灵文本被有意设计为持久存在；三合一模型对客户端自称 NES 模型，于是继承了这个行为。 - 通过客户端设置 nesMimicGhostTextBehavior 消融该持久化行为后，团队得以按新模型的行为重新做选择，说明新模型有新模式，值得重新端到端实验客户端设置。 - 除该消融外，还对编辑缓存、投机解码、编辑呈现方式、长编辑渐进展示等做了大量测试，每项都对体验影响很大。 ### 7. 客户端优化的五项联合配置 - 投机解码（speculative decoding）：原 NES 模型已用它降低延迟，但统一模型的输出格式要求重定投机内容；比较了只投机文件路径头、替换当前行、补全当前行三种方案。 - 经过负载测试、延迟分析、视图类型分布分析和在线飞行对比，最终选择投机“当前行补全”，在不对体验造成负面影响的前提下获得最低建议延迟。 - 幽灵文本渐进展示（progressive reveal）：先展示较长建议中立即相关的部分，再逐步展开其余内容，避免用户在长文本块中导航；该能力从原补全模型延伸到 NES，再移植到统一模型客户端。 - 基于 diff 的编辑渲染：统一模型输出的是 diff 补丁，团队需要在“直接按原始补丁展示”与“逐补丁解析出 diff 再渲染”之间选择。 - 由于模型可能为整体建议质量生成效率次优的补丁（如把 cuttlefish 替换为四种鱼再补回），解析后可以先给出一段插入式幽灵文本，再在另一行给出插入；在线 A/B 证实这是正向变化。 - 因此流程改为先解释补丁中的每处变化，再通过合适的渲染交互（幽灵文本、附近重写、较远重写、跨文件建议或不建议）呈现，而非直接按原始补丁结构渲染。 ### 8. 客户端优化的五项联合配置（续） - 缓存延迟与防抖（debounce）：建议来得太快反而造成干扰，略微延迟展示缓存建议更契合打字节奏；团队消融了多档缓存延迟配置，并测试了用户打字期间是否推迟调用模型，发现立即调用并不导致体验变差。 - 跨模式忽略建议抑制：同一建议对系统是不同视图，对开发者却是一样的不受欢迎建议；抑制后它不会在光标移动后立即以下一步编辑的形式复现。 - 结论：优秀模型只是复杂系统的一个组件，UX、客户端逻辑、网络与服务端逻辑都需精心设计并有意优化，端到端体验才是产品。 ### 9. 要点与经验总结 - 把补全并入统一模型的速度明显更快，因为直接建立在二合一基础上，说明学习的复利能加速每个战略阶段。 - 基于成功经验迭代：幽灵文本长度退步用与第一阶段相同的打法解决——针对性的长输出数据、上加权、只对完整性启用的专用辅助评判器。 - 模型只是端到端体验的一部分：改变底层模型行为与任务定义时，系统其他部分也必须随之改变；抑制被忽略幽灵文本复现这一客户端改动让丢弃率摆动 26%。 - 统一之利：三合一模型在线实验中丢弃率下降 10.1%，关键指标无回退，尽管非侵入性幽灵文本展示量少了 13%；由单一模型决定端到端最佳编辑胜过编排多个专用模型。 - 研发投入对比：二合一模型用了 15\+ 次 SFT 训练、170 次 RL 训练、数倍于此的检查点选择运行，产出 14 个 A/B 飞行候选；三合一仅在二合一之上做 RL，只用 35 次 RL 训练和 10 个飞行候选。 - 同期 VS Code 客户端团队提交了 113 个 PR 改进并支撑 NES 体验，涵盖实验与可配置性、模型集成、提示与上下文构建、服务与请求编排、缓存与变基（rebasing）、渲染与交互、遥测与可观测性、正确性与鲁棒性等。 ### 10. 要点与经验总结（续） - 把产品当作端到端系统来构建的回报是：模型与周边体验一起演进，彼此的学习不断塑造对方；这种加速学习的能力比任何单项里程碑都令人期待。 ### 11. 在线结果 - 三合一模型与当时生产基线（二合一模型加补全模型）对比飞行，丢弃率下降 10.1%，包括接受并保留字符数在内的关键指标均无统计显著回退。 - 值得注意的背景是：光标处幽灵文本占比相较对照组下降 13%，这为此前“非侵入性幽灵文本占比越高、丢弃率越低”的经验增添了细腻之处。 - 这说明统一模型的价值：模型能针对上下文选出最佳编辑，往往比编排多个独立模型的复杂客户端逻辑更有效，是“统一体验大于各部分之和”的有力数据点。 - 该统一系统把内联编辑视为一个连续谱，从补完当前行一直延续到把改动贯穿整个文件。 ### 12. 后续计划 - 两篇连载深入讲解统一内联建议模型的训练过程，后续还会发布更详细的技术报告。 - 团队正在扩展模型能力，包括个性化模型积极性（personalized model eagerness），在模型质量工作的基础上按用户偏好调整建议编辑的主动程度。 ### 13. 上手试用 - 统一的内联建议体验已向 VS Code 中的付费 GitHub Copilot 用户开放。 - 用户需更新到最新版 VS Code，并确认已启用下一步编辑建议（next edit suggestions）。 - 可以在重构或编写新函数时试用，体验“tab-tab-tab”的连续接受流程并反馈意见。 ### 14. 致谢 - 感谢 Luciana Abud、Alexandru Dima、Yu Hu、Simona Liao、Gaurav Mittal、Elsie Nallipogu 和 Nick Trogh 对本文的反馈、见解与贡献。 - 感谢开发者社区的持续反馈，以及 GitHub 与微软跨团队负责训练数据整理、训练流水线、评估套件与服务栈的研究人员、工程师、产品经理和设计师。 ### 15. 延伸阅读 - VS Code Wrapped: GitHub Universe 2026：回顾 VS Code 在 GitHub Universe 2025 至 2026 年间的演进，包括新的编码方式、与智能体协作、跨工具与环境管理工作。 - Tune GitHub Copilot Inline Suggestions with Configurable Eagerness：介绍如何选择 Copilot 提供内联建议的主动程度。 - Building the new GitHub Copilot Inline Suggestions Model: Part One：介绍 Copilot 如何把补全、下一步编辑与长距离建议统一到一个模型。 --- 来源：LearnMap · 学径（https://oplearnx.com）