Mercury Edit 2

Mercury Edit 2 是什么？

Mercury Edit 2 是一款专为软件开发工作流中下一处编辑预测而构建的扩散 LLM（dLLM）。它专为编码辅助中最敏感的延迟步骤而设计：根据近期修改和周边代码库上下文，建议你很可能接下来要更改的内容。

该模型补充了 Inception 现有的自动补全端点，专注于编辑建议。在实际使用中，当建议符合你正在处理的内容时，你可以接受预测的编辑（例如，通过 Tab 键）。

关键特性

• 基于编辑历史和代码上下文的下一处编辑预测： 使用“近期修改”加上代码库上下文，生成针对下一处更改的精准建议。
• 并行扩散式令牌生成： 使用扩散方法生成令牌并并行运行，以减少首条建议时间，实现低延迟用户体验。
• 使用人类反馈的偏好对齐训练： 从显式接受/拒绝反馈构建人类偏好数据集，然后应用非配对强化学习方法（KTO）来对齐建议与人类偏好。
• 更具选择性、更少干扰的编辑（按文章后述衡量）： 报告改进包括 48% 更高的接受率和 27% 更高的显示选择性。
• 编辑正确性和速度基准覆盖： 质量通过一组基准评估（包括开源基准如 Instinct、Fill-in-the-middle (FIM) 和 Next-edit Prediction (NEP)）加上内部下一处编辑基准；速度通过代表性请求的端到端延迟衡量。
• 通过 Inception Platform API 可用： 你可以通过 Inception API 访问 Mercury Edit 2（包括针对 Zed 用户的 APIZedProxy 提及）。

如何使用 Mercury Edit 2

• 在 Inception Platform 获取访问权限： 在 Inception API Platform 创建账户，开始使用 Mercury Edit 2。
• 通过 API 调用模型： 使用 Inception API 发送下一处编辑预测请求（文章提及 API 工作流，包括针对 Zed 集成的 APIZedProxy）。
• 集成到编辑器工作流： 如果嵌入到开发环境中，将模型的下一处编辑预测与编辑器的接受操作结合使用（例如，文章所述“Just Tab to accept”）。

使用场景

• IDE/编辑器中活跃编码时的下一处更改建议： 当你进行一系列修改时，使用 Mercury Edit 2 建议你很可能接下来要更改的内容，目标是低延迟响应。
• 重构帮助，通过针对编辑的提案： 生成重命名、重构步骤或其他结构化编辑的建议，其中“下一处编辑”框架适合工作流。
• 适应编辑的 FIM/行补全式工作流： 在仅补全不足的上下文中，使用下一处编辑预测提出基于当前编辑序列和周边代码的后续编辑。
• 功能实现迭代： 在添加功能时，依赖下一处编辑预测基于近期修改建议后续更改（如跟进修改）。
• 通过偏好对齐减少 unwanted 建议： 使用偏好训练行为降低原本会干扰你的编辑频率和长度（文章所述明确训练动机）。

常见问题

• Mercury Edit 2 针对什么问题？ 它针对编码工作流中的下一处编辑预测，系统需以低延迟建议你将要更改的内容。

• 它与自动补全有何不同？ 文章指出，Mercury Edit 2 补充现有自动补全端点，专注于编辑建议而非通用补全。

• 模型如何训练得更实用？ 文章描述使用从接受 vs. 拒绝反馈构建的人类偏好数据集，然后应用名为 KTO 的非配对强化学习方法进行对齐。

• 文章如何评估模型质量和速度？ 质量通过开源编辑相关基准（Instinct、FIM、NEP）加上内部下一处编辑基准进行基准测试，使用 LLM-as-a-judge 评估正确性（FIM 使用测试用例执行）。速度通过代表性请求的端到端延迟衡量。

• 在哪里可以使用该模型？ 它通过 Inception Platform API 提供。

替代方案

• 专注于自动补全的编码助手： 这些旨在预测即将出现的 token 或文本，而非针对性的下一处编辑；它们可能更适合前缀补全，但不会专注于“接下来你要改什么”。
• 通用的代码补全模型： 你可以提示通用代码 LLM 提出 diff 或编辑，但它们可能未针对下一处编辑预测的延迟及编辑接受/拒绝对齐进行优化。
• 其他下一处编辑 / 填入中间式编辑预测器： 同类替代方案是在类似编辑场景（行补全、变量重命名、重构、功能实现）上评估的模型，它们在生成编辑的方式以及质量与速度的平衡上有所不同。
• 测试驱动的编辑生成系统： 有些方法通过运行测试用例验证编辑（帖子提到 FIM 使用测试用例执行）。这些系统可通过执行强调正确性，但工作流速度和延迟权衡可能不同。