Mercury Edit 2

Was ist Mercury Edit 2?

Mercury Edit 2 ist ein speziell entwickeltes diffusionsbasiertes LLM (dLLM) für Next-Edit-Vorhersagen in Softwareentwicklungs-Workflows. Es ist darauf ausgelegt, den latenzempfindlichsten Schritt in der Coding-Unterstützung zu unterstützen: Vorschläge dafür, was du als Nächstes wahrscheinlich ändern wirst, basierend auf deinen jüngsten Änderungen und dem umliegenden Codebase-Kontext.

Das Modell ergänzt den bestehenden Auto-Complete-Endpunkt von Inception, indem es sich speziell auf Edit-Vorschläge konzentriert. In der Praxis kannst du einen vorhergesagten Edit akzeptieren (z. B. per Tab), wenn der Vorschlag zu deiner Arbeit passt.

Wichtige Features

• Next-Edit-Vorhersage aus Edit-Historie und Code-Kontext: Nutzt „jüngste Änderungen“ plus Codebase-Kontext, um einen gezielten Vorschlag für die nächste Änderung zu generieren.
• Diffusionsbasierte Token-Generierung parallel: Generiert Tokens mit Diffusion und führt sie parallel aus, um die Zeit bis zum ersten Vorschlag zu minimieren und eine Low-Latency-UX zu ermöglichen.
• Training auf Vorlieben mit menschlichem Feedback: Baut einen Datensatz mit menschlichen Vorlieben aus explizitem Accept/Reject-Feedback auf, dann wendet es eine unpaired Reinforcement-Learning-Methode (KTO) an, um Vorschläge an menschliche Vorlieben anzupassen.
• Selektivere, weniger ablenkende Edits (gemessen im Post): Berichtete Verbesserungen umfassen 48 % mehr akzeptierte Edits und 27 % mehr Selektivität bei der Anzeige.
• Benchmark-Abdeckung für Edit-Korrektheit und Geschwindigkeit: Qualität wird anhand von Benchmarks evaluiert (einschließlich Open-Source wie Instinct, Fill-in-the-middle (FIM) und Next-edit Prediction (NEP)) plus internem Next-Edit-Benchmark; Geschwindigkeit via End-to-End-Latenz bei repräsentativen Anfragen.
• Verfügbar über die Inception Platform API: Mercury Edit 2 ist über die Inception API zugänglich (inkl. APIZedProxy-Erwähnung für Zed-Nutzer).

So nutzt du Mercury Edit 2

• Zugriff auf der Inception Platform: Erstelle ein Konto auf der Inception API Platform, um mit Mercury Edit 2 zu starten.
• Modell über die API aufrufen: Nutze die Inception API, um Anfragen für Next-Edit-Vorhersagen zu senden (der Post referenziert einen API-Workflow, inkl. APIZedProxy für Zed-Integration).
• In Editor-Workflow integrieren: Bei Einbettung in eine Entwicklungsumgebung kombiniere die Next-Edit-Vorhersagen des Modells mit der Accept-Aktion deines Editors (z. B. „Nur Tab zum Akzeptieren“, wie im Post beschrieben).

Anwendungsfälle

• IDE/Editor-Vorschläge für nächste Änderungen beim aktiven Coding: Bei einer Reihe von Änderungen nutzt du Mercury Edit 2, um vorzuschlagen, was du als Nächstes wahrscheinlich änderst – mit Low-Latency-Antworten.
• Refactoring-Hilfe mit edit-spezifischen Vorschlägen: Generiere Vorschläge für Änderungen wie Umbenennungen, Refactoring-Schritte oder andere strukturierte Edits, bei denen das „Next-Edit“-Framing zum Workflow passt.
• FIM/Line-Completion-Workflows angepasst an Edits: In Kontexten, wo Completion allein nicht reicht, nutze Next-Edit-Vorhersage, um den Edit vorzuschlagen, der aus deiner aktuellen Edit-Sequenz und umliegendem Code folgt.
• Iteration bei Feature-Implementierung: Beim Hinzufügen von Funktionalität verlasse dich auf Next-Edit-Vorhersage für nachfolgende Änderungen (z. B. Folge-Modifikationen) basierend auf jüngsten Edits.
• Weniger unerwünschte Vorschläge durch Vorlieben-Alignment: Nutze das preference-trainierte Verhalten, um Häufigkeit und Länge ablenkender Edits zu reduzieren (wie im Post als explizites Trainingsmotiv beschrieben).

FAQ

• Welches Problem löst Mercury Edit 2? Es zielt auf Next-Edit-Vorhersagen in Coding-Workflows ab, wo das System mit Low Latency vorschlagen muss, was du als Nächstes änderst.

• Wie unterscheidet es sich von Auto-Complete? Der Post erklärt, dass Mercury Edit 2 einen bestehenden Auto-Complete-Endpunkt ergänzt, indem es sich speziell auf Edit-Vorschläge statt allgemeine Completions konzentriert.

• Wie wird das Modell nützlicher trainiert? Der Post beschreibt die Nutzung eines menschlichen Vorlieben-Datensatzes aus Accept-vs.-Reject-Feedback, dann Anwendung einer unpaired Reinforcement-Learning-Methode namens KTO für Alignment.

• Wie evaluiert der Post Modellqualität und Geschwindigkeit? Qualität wird an Open-Source-Edit-Benchmarks (Instinct, FIM, NEP) plus internem Next-Edit-Benchmark benchmarkt, mit LLM-as-a-judge für Korrektheit (und Test-Case-Ausführung für FIM). Geschwindigkeit via End-to-End-Latenz bei repräsentativen Anfragen.

• Wo kann ich das Modell nutzen? Es ist über die Inception Platform API verfügbar.

Alternativen

• Autovervollständigungsfokussierte Coding-Assistenten: Diese zielen darauf ab, kommende Tokens oder Text vorherzusagen statt gezielte nächste Edits; sie sind einfacher für Präfix-Vervollständigungen, spezialisieren sich aber nicht auf „was du als Nächstes änderst“.
• Allgemeine Code-Vervollständigungs-Modelle: Du kannst allgemeine Code-LLMs prompten, um Diffs oder Edits vorzuschlagen, aber sie sind nicht speziell für Next-Edit-Vorhersage-Latenz und Edit-Akzeptanz-/Ablehnungs-Abstimmung optimiert.
• Andere Next-Edit-/Fill-in-the-Middle-ähnliche Edit-Vorhersager: Alternativen in derselben Kategorie sind Modelle, die auf ähnlichen Edit-Szenarien evaluiert werden (Zeilenvervollständigung, Variablenumbenennung, Refactoring, Feature-Implementierung), die sich in der Edit-Generierung und im Qualitäts-Geschwindigkeits-Ausgleich unterscheiden.
• Testgetriebene Edit-Generierungssysteme: Einige Ansätze validieren Edits durch Ausführen von Testfällen (die Post notiert, dass FIM Testfallausführung nutzt). Diese Systeme betonen Korrektheit durch Ausführung, unterscheiden sich aber in Workflow-Geschwindigkeit und Latenz-Kompromissen.