Mercury Edit 2

Qu'est-ce que Mercury Edit 2 ?

Mercury Edit 2 est un LLM de diffusion (dLLM) conçu pour la prédiction de la prochaine modification dans les workflows de développement logiciel. Il est pensé pour assister l’étape la plus sensible à la latence dans l’aide au codage : suggérer ce que vous allez probablement changer ensuite en fonction de vos modifications récentes et du contexte du codebase environnant.

Le modèle complète l’endpoint d’autocomplétion existant d’Inception en se concentrant spécifiquement sur les suggestions de modifications. En pratique, vous pouvez accepter une modification prédite (par exemple, via Tab) quand la suggestion correspond à ce sur quoi vous travaillez.

Fonctionnalités clés

• Prédiction de la prochaine modification à partir de l’historique et du contexte de code : Utilise les « modifications récentes » plus le contexte du codebase pour générer une suggestion ciblée sur ce qu’il faut changer ensuite.
• Génération de tokens par diffusion en parallèle : Génère les tokens via diffusion et les exécute en parallèle pour réduire le temps jusqu’à la première suggestion, assurant une UX à faible latence.
• Entraînement aligné sur les préférences via feedback humain : Construit un dataset de préférences humaines à partir de feedback explicite accept/reject, puis applique une méthode d’apprentissage par renforcement non apparié (KTO) pour aligner les suggestions sur les préférences humaines.
• Modifications plus sélectives, moins distractives (comme mesuré dans le post) : Améliorations rapportées : 48 % d’edits acceptés en plus et 27 % de sélectivité accrue dans ce qu’il affiche.
• Couverture de benchmarks pour la correction et la vitesse des edits : La qualité est évaluée sur un ensemble de benchmarks (y compris open-source comme Instinct, Fill-in-the-middle (FIM) et Next-edit Prediction (NEP)) plus un benchmark interne de next-edit ; la vitesse via latence end-to-end sur des requêtes représentatives.
• Disponible via l’API Inception Platform : Accédez à Mercury Edit 2 via l’API Inception (y compris mention d’APIZedProxy pour les utilisateurs Zed).

Comment utiliser Mercury Edit 2

• Obtenez l’accès sur Inception Platform : Créez un compte sur la plateforme API Inception pour commencer à utiliser Mercury Edit 2.
• Appelez le modèle via l’API : Utilisez l’API Inception pour envoyer des requêtes de prédiction de prochaine modification (le post référence un workflow API, incluant APIZedProxy pour l’intégration Zed).
• Intégrez dans un workflow d’éditeur : Si vous l’intégrez dans un environnement de développement, utilisez les prédictions de prochaine modification du modèle avec l’action d’acceptation de votre éditeur (ex. : « Juste Tab pour accepter », comme décrit dans le post).

Cas d’usage

• Suggestions de prochaine modification dans IDE/éditeur pendant le codage actif : Quand vous effectuez une série de modifications, utilisez Mercury Edit 2 pour suggérer ce que vous allez probablement changer ensuite, avec des réponses à faible latence.
• Aide au refactoring avec propositions ciblées sur les edits : Générez des suggestions pour des changements comme le renommage, étapes de refactoring ou autres edits structurés où le cadrage « prochaine modification » convient au workflow.
• Workflows de style FIM/complétion de ligne adaptés aux edits : Dans les contextes où la complétion seule ne suffit pas, utilisez la prédiction de prochaine modification pour proposer l’edit qui suit de votre séquence actuelle et du code environnant.
• Itération sur l’implémentation de fonctionnalités : En ajoutant des fonctionnalités, fiez-vous à la prédiction de prochaine modification pour suggérer les changements suivants (comme les modifications de suivi) basés sur les edits récents.
• Réduction des suggestions indésirables via alignement sur préférences : Utilisez le comportement entraîné sur préférences pour diminuer la fréquence et la longueur des edits autrement distractifs (comme décrit dans le post comme motivation d’entraînement explicite).

FAQ

• Quel problème cible Mercury Edit 2 ? Il cible la prédiction de prochaine modification dans les workflows de codage, où le système doit suggérer ce que vous changerez ensuite avec faible latence.

• En quoi diffère-t-il de l’autocomplétion ? Le post indique que Mercury Edit 2 complète un endpoint d’autocomplétion existant en se concentrant spécifiquement sur les suggestions d’edits plutôt que la complétion générale.

• Comment le modèle est-il entraîné pour être plus utile ? Le post décrit l’utilisation d’un dataset de préférences humaines construit à partir de feedback accept vs. reject, puis l’application d’une méthode d’apprentissage par renforcement non apparié appelée KTO pour l’alignement.

• Comment le post évalue-t-il la qualité et la vitesse du modèle ? La qualité est benchmarkée sur des benchmarks open-source liés aux edits (Instinct, FIM, NEP) plus un benchmark interne de next-edit, en utilisant LLM-as-a-judge pour la correction (et exécution de test-cases pour FIM). La vitesse via latence end-to-end sur des requêtes représentatives.

• Où puis-je utiliser le modèle ? Il est disponible via l’API Inception Platform.

Alternatives

• Assistants de codage axés sur l’auto-complétion : Ils visent à prédire les tokens ou le texte à venir plutôt que les modifications ciblées suivantes ; ils peuvent être plus simples pour la complétion de préfixe mais ne se spécialisent pas dans « ce que vous allez changer ensuite ».
• Modèles de complétion généralistes pour le code : Vous pouvez inciter des LLM de code généralistes à proposer des diffs ou des modifications, mais ils ne sont pas optimisés spécifiquement pour la latence de prédiction de la prochaine modification et l’alignement acceptation/rejet des modifications.
• Autres prédicteurs de modifications suivantes / style fill-in-the-middle : Les alternatives de la même catégorie sont des modèles évalués sur des scénarios de modifications similaires (complétion de ligne, renommage de variable, refactorisation, implémentation de fonctionnalité), qui diffèrent par leur génération de modifications et l’équilibre qualité/vitesse.
• Systèmes de génération de modifications pilotés par tests : Certaines approches valident les modifications en exécutant des cas de test (l’article note que FIM utilise l’exécution de cas de test). Ces systèmes mettent l’accent sur la correction via exécution mais diffèrent en vitesse de workflow et compromis de latence.