GitHub 升级 Copilot 下一步编辑建议：自研低延迟模型 + 强化学习持续迭代
GitHub 公布了新的 Copilot「Next Edit Suggestions（NES）」。功能面向代码编辑场景，目标是在开发者敲代码的同时，实时预测「下一步可能的编辑操作」，而不仅是传统意义上的「下一个 token 补全」。
通用大模型在这个场景要么质量不够、要么延迟过高，无法满足「编辑器内实时交互」要求。因此 GitHub 选择训练专用小模型：NES 被设计为低延迟、任务特化、深度集成 VS Code 的在线模型，而不是通用聊天模型。
团队认为难点在于数据而非架构。早期基于内部 Pull Request diff 训练的模型过于保守，常选择不编辑，效果不如通用 LLM，原因在于 PR 只反映最终结果，缺乏真实编辑过程的时序信息、负样本和中途放弃等行为数据。
为解决这一问题，团队重建数据管线，从内部志愿者处收集真实编辑会话，强调「高质量、小而精」的数据优先于大规模、噪声更高的数据。基于这些数据进行监督微调（SFT），才得到首个显著优于通用模型的 NES 版本，并在此基础上迭代多次。
源
GitHub 公布了新的 Copilot「Next Edit Suggestions（NES）」。功能面向代码编辑场景，目标是在开发者敲代码的同时，实时预测「下一步可能的编辑操作」，而不仅是传统意义上的「下一个 token 补全」。
通用大模型在这个场景要么质量不够、要么延迟过高，无法满足「编辑器内实时交互」要求。因此 GitHub 选择训练专用小模型：NES 被设计为低延迟、任务特化、深度集成 VS Code 的在线模型，而不是通用聊天模型。
团队认为难点在于数据而非架构。早期基于内部 Pull Request diff 训练的模型过于保守，常选择不编辑，效果不如通用 LLM，原因在于 PR 只反映最终结果，缺乏真实编辑过程的时序信息、负样本和中途放弃等行为数据。
为解决这一问题，团队重建数据管线，从内部志愿者处收集真实编辑会话，强调「高质量、小而精」的数据优先于大规模、噪声更高的数据。基于这些数据进行监督微调（SFT），才得到首个显著优于通用模型的 NES 版本，并在此基础上迭代多次。
源
