隆重推出 Instinct:由 Continue 构建的世界级开源 Next Edit 模型

认识 Instinct,Continue 的开源 Next Edit 模型,旨在预测您的下一次编辑,让您保持流畅

Introducing Instinct: the world’s best open Next Edit model, built by Continue

我们很高兴地分享 Instinct,这是我们的开源 Next Edit 模型,它能够智能地预测您的下一步操作,让您保持流畅。

当我们推出 Next Edit 时,我们首次使用了 Inception 的 Mercury Coder。今天,我们通过 Instinct 扩展了可能性:这是一个我们内部训练的开源模型,开发人员可以在本地的 GPU 上运行它。

 当您编写代码时,Instinct 会看到您的编辑轨迹并自动执行下一步操作——估计比手动编辑快 6.4 倍。 

💡
在 VS Code 中使用 Ollama 和 Continue 立即试用

为何训练一个开源模型?

尽管用于智能编码任务的开源模型在近几个月取得了飞速发展,但 Next Edit 的工作仍处于初步阶段。Zed 在其 Zeta 模型上取得了大部分进展,我们很高兴能够借鉴他们的学习成果。我们的目标之一是强调开源机会,并为未来的努力奠定基础,这将不仅造福我们的团队,还将造福我们的社区和更广泛的开发者生态系统。

虽然像 Mercury Coder 这样的现有模型已经展现出出色的性能,但 Instinct 使开发人员能够在自己的 GPU 上运行或定制 Next Edit 模型,从而满足隐私和定制需求。

什么是 Next Edit?

方面 传统自动完成 Next Edit
更改范围 仅在光标处插入文本 重写代码窗口(删除、插入、替换)
复杂更改 需要多次接受 一次操作即可处理复杂的重构
代码重构 无法删除或重构代码 理解编辑轨迹和开发人员意图
开发者流程 频繁的中断会打断流程 通过更少的中断来维持流程

传统的 Tab 自动完成只能在你输入时*在光标处*插入*代码。当快速输入样板代码时,这很有用,但大多数时候开发人员是在重构、维护、迭代——*编辑*——代码。

例如,重构一个函数可能需要:删除旧参数(5 次击键)、移动到 return 语句(2 次光标跳转)、更改返回类型(8 次击键),以及更新函数体(20+ 次击键和 5+ 次光标跳转)。有了 Instinct,整个序列就变成了一个 Tab 接受操作,将原本 40+ 次手动操作变成了一次。

模型训练

真实世界训练数据

为了创建我们的 Next Edit 模型,我们需要高质量的训练数据。我们没有合成生成示例,而是从 Continue 团队在处理我们开源代码时自动收集了超过 4000 个真实世界的编辑。这比今年早些时候发布的 Zeta 数据集还要多一个数量级,并且比可以从 git commit 中构建的纯合成数据更能代表真实世界的开发模式。

每个数据示例包括: 

  • 开发人员进行的最近五次编辑
  • 来自其他文件的相关上下文
  • 要重写的代码区域
  • 开发人员对该区域进行的真实更改

我们遇到的一个基本问题是“编辑”的定义。每一次击键?每一次用户点击保存?在某个时间窗口内进行的所有击键?经过多次迭代,我们定义了一系列基于行和时间的启发式方法,将单个击键“分块”成格式良好且独立的 diff。

当我们检查这些 diff 的序列时,我们注意到开发人员有时会来回跳跃,一遍又一遍地迭代相同的几行。我们定义了过滤器来丢弃这些示例,因为我们希望 Instinct 能够进行高效、非重复性的编辑。

Continue 的 自动完成上下文管道 提供了关于代码库的相关信息,提示中还包含了来自当前文件的内容。我们将可编辑区域(模型将重写的代码范围)定义为从光标上方一行开始,到光标下方五行结束。这个决定是基于我们在数据集中看到的 diff 的自然特征做出的。

总而言之,编辑序列、上下文、当前文件内容和可编辑区域提供了推断开发人员意图并预测编辑序列下一步所需的信息。

维护多语言支持

我们遇到的一个问题是 Continue 团队主要使用 Typescript 代码。但是,我们希望我们的模型能够保留对多种语言的支持。除了以稳健的方式训练模型(稍后将详细介绍),我们使用了一个自托管的 Qwen3-Coder-30B 模型来合成地“翻译” diff、上下文和文件内容为 Java、C、Python 和 Rust,从而在 Typescript 数据的基础上引导了一个多语言数据集。一套精确的数据校正器和过滤器确保了高质量以及 4000 多个合成示例之间相似的编辑分布。

针对 Next Edit 任务的稳健训练

有了多语言数据集,就可以进行监督微调 (SFT) 了。对于 Next Edit 等特定任务的 SFT 通常使用低秩自适应 (LoRA),因为尽管它*学习得较少,但它也*遗忘得较少*预训练模型的一般编码能力。

然而,使用 LoRA 的主要问题在于,它在训练开始之前就固定了要微调的参数。更可取的方法是*发现*哪些参数的权重更新最重要,并且只更新那些。与其将 Next Edit 视为学习新*知识*而牺牲以前的编码能力,不如让模型能够*适应* Next Editing 的*任务*,同时保留其预训练的编码知识。

我们在训练 NextCoder 指令代码编辑模型时使用的选择性知识迁移 (SeleKT) 算法中找到了这样的解决方案。SeleKT 计算密集梯度(如完整微调),按幅度提取前 *k* 个梯度,然后仅应用那些稀疏的权重更新。它通过实践来发现哪些需要改变,而不是事先猜测,因此,只有对 Next Edit *任务*最重要的权重才会被更新。此外,将小权重更新置零有助于防止过拟合和先前编码知识的侵蚀,这些问题在完整微调中会遇到。

我们使用 SeleKT 微调了 5% 的 Qwen2.5-Coder-7B 的参数。在初始超参数扫描后,训练过程是标准的,使用了对数预热和余弦衰减学习率调度,持续 5 个 epoch。我们使用 CodeBLEU 分数作为训练期间预测重写与真实重写之间的快速代理评估。跨数据集不同语言的 CodeBLEU 分数消融让我们能够调整数据混合,从而在各种语言上实现高验证性能。由于训练过程稳健,只需要少量的多语言示例。

性能结果:质量和速度评估

3.877 6.4 倍更快*
平均 LLM 裁判得分
(新的开源最先进技术)
比手动输入编辑
* 在我们的 8xH100 集群上

正式评估 Next Edit 建议的质量并非易事,因为完成相同的编码目标通常有多种方法。因此,我们部署了 Claude 作为 LLM 裁判,并指示其对 Next Edit 建议的质量进行五点评分,其中

  • 评分为五表示与开发人员的真实编辑功能匹配,
  • 评分为四表示与开发人员的真实编辑相似,尽管功能不完全匹配,
  • 评分为三表示编辑不匹配真实数据,但在这种情况下,专家开发人员会合理地进行此类编辑,
  • 评分为二表示编辑不符合之前的编辑和上下文逻辑,
  • 评分为一表示编辑可能会阻碍开发人员的进展,例如大的删除或完全无关,
  • 评分为零表示重写格式错误,与可编辑区域不匹配。

此评估方法与 Zed 用于 Zeta 的方法类似。我们注意到他们的裁判提示导致 LLM 只输出零分或五分,并且依赖于手工编写的断言来判断下一次编辑。我们创建了一个不同的系统提示,有助于表示完整的评分范围,并比较模型的编辑与开发人员的真实更改,而不是依赖于断言。通过对我们的不同 Next Edit 提示结构进行一些微小的调整,Instinct 的平均得分 3.877 优于 Zeta 在已评估数据集上的得分 3.735。我们期待看到进一步的工作能够继续改进这一基准。

Instinct 不仅提供高质量的建议,我们基于 Coeditor 的击键距离评估也表明,它极大地加快了您的工作流程。通过回溯 Levenshtein 距离计算器的动态规划 (DP) 表,可以提取出可编辑区域与建议重写之间的字符级差异。这个字符级差异可以被“分块”成编辑操作,*例如*,在一个位置添加三个字符,在另一个位置删除五个字符,等等。 

完成整个编辑所需的最小时间由完成所有编辑操作的击键和光标跳转的最优组合给出。这可以作为另一个 DP 问题来解决。我们假设开发人员的平均打字速度为 90 WPM,模拟了高亮和删除的能力,而不是反复按退格键,允许进行小的箭头移动而不是耗时更长的光标跳转,并使用光标位置之间的空间距离(*即*行和字符)而不是整个字符串中的索引。这个手动编辑时间的下限与我们在内部 SGLang 端点的平均模型推理时间加上一次击键(tab-to-accept)的时间进行了比较。

结果是,即使您立即知道要进行的确切编辑,*并且*以 90 WPM 的 DP 最优顺序执行,使用该模型仍然可以使高质量的编辑速度提高 6.4 倍。 

接下来呢?

首先,我们鼓励您试用一下!Instinct 是一个 7B 模型,所以您应该期望它在大多数笔记本电脑上运行缓慢,但如果有足够的硬件,它是一个自托管的好选择。请阅读我们的指南以了解更多信息。

如果您想在我们的数据集、训练管道或开源权重基础上进行构建(例如,运行 KTO 并使用您自己的接受/拒绝数据),我们建议您探索我们的 GitHub 仓库HuggingFace 模型卡 和数据集。

最重要的是,如果您有兴趣在最先进的技术方面做出贡献,无论是在社区层面还是在 Continue 团队,请联系我们