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）。
• 整合至編輯器工作流程： 若嵌入開發環境，請將模型的下一次編輯預測與編輯器的接受動作搭配使用（例如，「只需按 Tab 接受」，如文章所述）。

使用情境

• IDE/編輯器中主動編碼時的下一次變更建議： 當你進行一系列修改時，使用 Mercury Edit 2 建議你很可能接下來要變更的內容，目標為低延遲回應。
• 重構輔助與針對編輯的提案： 產生如重新命名、重構步驟或其他結構化編輯的建議，其中「下一次編輯」框架適合工作流程。
• 適應編輯的 FIM/行補全式工作流程： 在僅補全不夠用的情境下，使用下一次編輯預測，從目前編輯序列與周圍程式碼提出後續編輯。
• 功能實作迭代： 在新增功能時，依賴下一次編輯預測根據近期修改建議後續變更（例如後續調整）。
• 透過偏好對齊減少不想要的建議： 使用偏好訓練行為降低原本會干擾你的編輯頻率與長度（文章描述為明確訓練動機）。

常見問題

• Mercury Edit 2 針對什麼問題？ 它針對程式編輯工作流程中的下一次編輯預測，系統需以低延遲建議你接下來要變更的內容。

• 它與自動補全有何不同？ 文章指出，Mercury Edit 2 補充現有自動補全端點，專注於編輯建議而非一般補全。

• 模型如何訓練以更實用？ 文章描述使用從接受對拒絕回饋建構的人類偏好資料集，然後套用名為 KTO 的非配對強化學習方法進行對齊。

• 文章如何評估模型品質與速度？ 品質使用開源編輯相關基準（Instinct、FIM、NEP）加上內部下一次編輯基準進行測試，採用 LLM-as-a-judge 評估正確性（FIM 則執行測試案例）。速度則透過代表性請求的端到端延遲測量。

• 模型可在哪裡使用？ 它可透過 Inception Platform API 取得。

替代方案

• 專注自動完成的程式編輯助理： 這些旨在預測即將出現的 token 或文字，而非針對性的下一次編輯；它們可能更適合前綴補全，但不會專精於「你要改什麼」。
• 通用程式碼補全模型： 你可以提示通用程式碼 LLM 提出 diff 或編輯，但它們可能未針對下一次編輯預測延遲及編輯接受/拒絕對齊進行最佳化。
• 其他下一次編輯 / 填中間樣式編輯預測器： 同類替代方案會在類似編輯情境（行補全、變數重新命名、重構、功能實作）上評估，差異在於生成編輯的方式，以及品質與速度的平衡。
• 測試驅動編輯生成系統： 有些方法透過執行測試案例驗證編輯（後文提到 FIM 使用測試案例執行）。這些系統可透過執行強調正確性，但工作流程速度與延遲權衡可能不同。