Mercury Edit 2

Mercury Edit 2とは？

Mercury Edit 2は、ソフトウェア開発ワークフローにおける次の編集予測専用の拡散LLM（dLLM）です。コーディング支援で最もレイテンシに敏感なステップ、最近の編集と周辺コードベースの文脈に基づいて次に変更しそうな内容を提案するよう設計されています。

このモデルは、Inceptionの既存のオートコンプリートエンドポイントを補完し、編集提案に特化しています。実務では、提案が作業に合えば予測された編集を受け入れられます（例: Tabキー）。

編集履歴とコード文脈からの次の編集予測: 「最近の編集」とコードベース文脈を使って、次に変更すべき内容の的確な提案を生成。
並列拡散ベースのトークン生成: 拡散を用いてトークンを生成し並列実行することで、低遅延UXを実現する初回提案時間を短縮。
人間のフィードバックによる好み整合訓練: 明示的な受け入れ/拒否フィードバックから人間の好みデータセットを構築し、ペアなし強化学習法（KTO）を適用して提案を人間の好みに整合。
選択性が高く、気になりにくい編集（投稿で測定）: 受け入れられた編集が48%増加、表示内容の選択性が27%向上。
編集の正確性と速度のベンチマーク評価: 品質はベンチマークセット（Instinct、Fill-in-the-middle (FIM)、Next-edit Prediction (NEP)などのオープンソース含む）および内部次の編集ベンチマークで評価。速度は代表的なリクエストでのエンドツーエンド遅延で測定。
Inception Platform API経由で利用可能: Inception API経由でMercury Edit 2にアクセス（Zedユーザー向けAPIZedProxy言及含む）。

Inception Platformでアクセス: Inception API Platformでアカウントを作成し、Mercury Edit 2を使い始めます。
API経由でモデルを呼び出し: Inception APIを使って次の編集予測リクエストを送信（投稿でAPIワークフロー言及、Zed統合のAPIZedProxy含む）。
エディターワークフローへ統合: 開発環境に埋め込む場合、エディターの受け入れアクション（例: 投稿記載の「Tabで受け入れ」）と並行して次の編集予測を使用。

Mercury Edit 2が対象とする問題は？ コーディングワークフローでの次の編集予測で、低遅延で次に変更する内容を提案。
オートコンプリートとどう違う？ 投稿によると、Mercury Edit 2は一般補完ではなく編集提案に特化し、既存のオートコンプリートエンドポイントを補完。
モデルをより有用にする訓練方法は？ 投稿では、受け入れ/拒否フィードバックから人間好みデータセットを構築し、KTOと呼ばれるペアなし強化学習法を適用して整合。
投稿ではモデルの品質と速度をどう評価？ 品質はオープンソース編集関連ベンチマーク（Instinct、FIM、NEP）および内部次の編集ベンチマークで評価。正確性はLLM-as-a-judgeとFIMのテストケース実行で。速度は代表リクエストのエンドツーエンド遅延で測定。
どこでモデルを使える？ Inception Platform API経由で利用可能。

オートコンプリート重視のコーディングアシスタント： これらは次のトークンやテキストを予測することを目的とし、対象の次の編集を予測しません。プレフィックス補完ではシンプルですが、「次に何を変えるか」に特化しません。
コード向け汎用補完モデル： 汎用コードLLMにdiffや編集を提案させることは可能ですが、次の編集予測の遅延や編集の受諾/拒否適合性に特化して最適化されていない場合があります。
他の次の編集 / 穴埋めスタイルの編集予測器： 同じカテゴリの代替案は、類似の編集シナリオ（行補完、変数名変更、リファクタリング、機能実装）で評価されたモデルで、編集生成方法や品質と速度のバランスが異なります。
テスト駆動型編集生成システム： 一部の手法はテストケース実行で編集を検証します（投稿ではFIMがテストケース実行を使用と記載）。これらのシステムは実行による正確性を重視しますが、ワークフロー速度と遅延のトレードオフが異なる場合があります。