Mercury Edit 2

¿Qué es Mercury Edit 2?

Mercury Edit 2 es un LLM de difusión diseñado específicamente (dLLM) para predecir el siguiente cambio en flujos de trabajo de desarrollo de software. Está pensado para ayudar en el paso más sensible a la latencia en la asistencia de codificación: sugerir qué es lo que probablemente cambiarás a continuación según tus ediciones recientes y el contexto del código circundante.

El modelo complementa el endpoint de autocompletado existente de Inception al centrarse específicamente en sugerencias de ediciones. En la práctica, puedes aceptar una edición predicha (por ejemplo, con tabulador) cuando la sugerencia se ajuste a lo que estás trabajando.

Características clave

• Predicción del siguiente cambio desde historial de ediciones y contexto de código: Usa «ediciones recientes» más el contexto del código para generar una sugerencia dirigida sobre qué cambiar a continuación.
• Generación de tokens basada en difusión en paralelo: Genera tokens mediante difusión y los ejecuta en paralelo para reducir el tiempo hasta la primera sugerencia y lograr una UX de baja latencia.
• Entrenamiento alineado con preferencias mediante retroalimentación humana: Construye un dataset de preferencias humanas a partir de retroalimentación explícita de aceptar/rechazar, luego aplica un método de aprendizaje por refuerzo no pareado (KTO) para alinear las sugerencias con las preferencias humanas.
• Ediciones más selectivas y menos distractivas (según se mide en la publicación): Las mejoras reportadas incluyen un 48 % más de ediciones aceptadas y un 27 % más de selectividad en lo que muestra.
• Cobertura de benchmarks para corrección y velocidad de ediciones: La calidad se evalúa frente a un conjunto de benchmarks (incluyendo open-source como Instinct, Fill-in-the-middle (FIM) y Next-edit Prediction (NEP)) más un benchmark interno de siguiente edición; la velocidad se mide mediante latencia de extremo a extremo en solicitudes representativas.
• Disponible a través de la API de Inception Platform: Puedes acceder a Mercury Edit 2 mediante la API de Inception (incluyendo mención a APIZedProxy para usuarios de Zed).

Cómo usar Mercury Edit 2

• Obtén acceso en Inception Platform: Crea una cuenta en la Inception API Platform para empezar a usar Mercury Edit 2.
• Llama al modelo a través de la API: Usa la API de Inception para enviar solicitudes de predicciones de siguiente cambio (la publicación menciona un flujo de trabajo de API, incluyendo APIZedProxy para integración con Zed).
• Integra en un flujo de trabajo de editor: Si lo incrustas en un entorno de desarrollo, usa las predicciones de siguiente cambio del modelo junto con la acción de aceptación de tu editor (p. ej., «Solo presiona Tab para aceptar», como se describe en la publicación).

Casos de uso

• Sugerencias de siguiente cambio en IDE/editor durante codificación activa: Cuando realizas una serie de ediciones, usa Mercury Edit 2 para sugerir qué probablemente cambiarás a continuación, con respuestas de baja latencia.
• Ayuda en refactorización con propuestas dirigidas a ediciones: Genera sugerencias para cambios como renombrados, pasos de refactorización u otras ediciones estructuradas donde el marco de «siguiente edición» encaje en el flujo.
• Flujos de estilo FIM/completado de línea adaptados a ediciones: En contextos donde la completación sola no basta, usa la predicción de siguiente cambio para proponer la edición que sigue de tu secuencia actual de ediciones y código circundante.
• Iteración en implementación de funciones: Mientras añades funcionalidad, confía en la predicción de siguiente cambio para sugerir modificaciones posteriores (como cambios de seguimiento) basadas en ediciones recientes.
• Reducción de sugerencias no deseadas mediante alineación de preferencias: Usa el comportamiento entrenado con preferencias para bajar la frecuencia y longitud de ediciones que de otro modo te distraerían (como se describe en la publicación como motivación explícita de entrenamiento).

Preguntas frecuentes

• ¿Qué problema aborda Mercury Edit 2? Aborda la predicción de siguiente cambio en flujos de codificación, donde el sistema debe sugerir qué cambiarás a continuación con baja latencia.

• ¿En qué se diferencia del autocompletado? La publicación indica que Mercury Edit 2 complementa un endpoint de autocompletado existente al centrarse específicamente en sugerencias de ediciones en lugar de completado general.

• ¿Cómo se entrena el modelo para ser más útil? La publicación describe el uso de un dataset de preferencias humanas construido a partir de retroalimentación de aceptar vs. rechazar, luego aplicando un método de aprendizaje por refuerzo no pareado llamado KTO para alineación.

• ¿Cómo evalúa la publicación la calidad y velocidad del modelo? La calidad se mide en benchmarks open-source relacionados con ediciones (Instinct, FIM, NEP) más un benchmark interno de siguiente edición, usando LLM-as-a-judge para corrección (y ejecución de casos de prueba para FIM). La velocidad se mide con latencia de extremo a extremo en solicitudes representativas.

• ¿Dónde puedo usar el modelo? Está disponible a través de la API de Inception Platform.

Alternativas

• Asistentes de codificación enfocados en autocompletado: Estos buscan predecir tokens o texto próximos en lugar de ediciones específicas siguientes; pueden ser más simples para completar prefijos, pero no se especializan en «qué cambiarás a continuación».
• Modelos de completado generales para código: Puedes indicarle a LLMs generales de código que propongan diffs o ediciones, pero no están optimizados específicamente para latencia en predicción de ediciones siguientes y alineación de aceptación/rechazo de ediciones.
• Otros predictores de ediciones siguientes / estilo fill-in-the-middle: Alternativas de la misma categoría serían modelos evaluados en escenarios de edición similares (completado de líneas, renombrado de variables, refactorización, implementación de funciones), que difieren en cómo generan ediciones y equilibran calidad frente a velocidad.
• Sistemas de generación de ediciones impulsados por pruebas: Algunos enfoques validan ediciones ejecutando casos de prueba (la publicación menciona que FIM usa ejecución de casos de prueba). Esos sistemas pueden enfatizar la corrección mediante ejecución, pero difieren en velocidad de flujo de trabajo y compensaciones de latencia.