GitHub Copilot: La Evolución de las Sugerencias Inteligentes con el Nuevo Modelo NES

La edición de código a menudo implica una serie de pequeños pero necesarios cambios, desde refactorizaciones hasta correcciones y manejo de casos extremos. En un esfuerzo por optimizar este proceso, GitHub ha estado trabajando en mejorar su herramienta estrella, Copilot. En febrero, se lanzó **Next Edit Suggestions (NES)**, un modelo personalizado de Copilot que predice la siguiente edición lógica basándose en el código que ya has escrito. Desde su lanzamiento, han implementado varias actualizaciones importantes del modelo, incluyendo la última versión a principios de este mes.

¿Por qué las sugerencias de edición son un desafío?

Predecir la siguiente edición es una tarea más compleja que predecir el siguiente token. NES debe comprender lo que estás haciendo, por qué lo estás haciendo y lo que es probable que hagas a continuación. Esto implica varios desafíos clave:

El modelo debe responder rápidamente para seguir tu flujo de trabajo.
Debe saber cuándo no sugerir nada (demasiadas sugerencias pueden interrumpir tu concentración).
Debe inferir la intención a partir del contexto local sin indicaciones explícitas.
Debe integrarse profundamente con VS Code para que las sugerencias aparezcan exactamente donde las esperas.

Los modelos iniciales no cumplieron con las expectativas de calidad y latencia. Los modelos más pequeños eran rápidos pero producían sugerencias de baja calidad, mientras que los modelos más grandes eran precisos pero demasiado lentos para una experiencia de edición fluida. Para obtener velocidad y calidad, era necesario entrenar un modelo personalizado.

NES no es un modelo de chat de propósito general. Es un modelo de baja latencia y específico para tareas que se ejecuta junto con el editor y responde en tiempo real. Es el resultado de alinear el entrenamiento del modelo, el diseño de prompts y la experiencia de usuario en torno a un único objetivo: la edición fluida dentro del IDE. Esto requirió una estrecha coordinación entre el entrenamiento del modelo, el diseño de prompts, el diseño de la experiencia de usuario y el equipo de VS Code: el modelo solo funciona porque el sistema fue codiseñado de principio a fin.

Este enfoque “AI-nativo” donde cada parte de la experiencia evoluciona en conjunto es muy diferente de entrenar un modelo de propósito general para cualquier tarea o prompt. Así es como creen que se deben construir las funciones de IA: de principio a fin, con la experiencia del desarrollador en el centro.

Entrenamiento del Modelo NES: El Dato es la Clave

La parte difícil no fue la arquitectura, sino los datos. Necesitaban un modelo que pudiera predecir la siguiente edición que un desarrollador podría hacer, pero ningún conjunto de datos existente capturaba el comportamiento de edición en tiempo real.

El primer intento utilizó datos internos de pull requests. Parecía razonable: los pull requests contienen diffs, y los diffs se parecen a las ediciones. Pero las pruebas internas revelaron limitaciones. El modelo se comportaba con demasiada cautela, reacio a tocar código inacabado, vacilante a sugerir cambios en la línea que un usuario estaba escribiendo y, a menudo, optaba por no hacer nada. En la práctica, funcionó peor que un LLM básico.

Ese fracaso dejó claro el requisito: necesitaban datos que reflejaran cómo los desarrolladores realmente editan el código en el editor, no cómo se ve el código después de la revisión.

Los datos de pull requests no fueron suficientes porque:

Muestran solo el estado final, no las ediciones intermedias que hacen los desarrolladores
Carecen de orden temporal, por lo que el modelo no puede aprender cuándo ocurren los cambios
Casi no contienen muestras negativas (casos en los que la acción correcta es “no editar”)
Se pierden las ediciones abandonadas, las reescrituras en curso y otros comportamientos de edición comunes

Así que reiniciaron su enfoque y construyeron un conjunto de datos mucho más rico mediante la realización de un esfuerzo de recopilación de datos personalizados a gran escala que capturó sesiones de edición de código de un conjunto de voluntarios internos. Descubrieron que la calidad de los datos era clave en esta etapa: un volumen más pequeño de datos de edición de alta calidad condujo a mejores modelos que aquellos entrenados con un volumen mayor de datos que estaba menos curado.

El ajuste fino supervisado (SFT) de un modelo en este conjunto de datos personalizado produjo el primer modelo que superó a los modelos básicos. Este modelo inicial proporcionó un aumento significativo en la calidad y sirvió como base para las siguientes versiones de NES.

Refinando el Modelo con Aprendizaje por Refuerzo

Después de desarrollar varios modelos NES exitosos con SFT, se centraron en dos limitaciones clave de su enfoque de entrenamiento:

SFT puede enseñarle al modelo qué constituye una buena sugerencia de edición, pero no puede enseñarle explícitamente al modelo qué hace que una sugerencia de edición sea mala.
SFT puede aprovechar eficazmente las sugerencias de edición etiquetadas, pero no puede utilizar completamente el número mucho mayor de muestras de código no etiquetadas.

Para abordar estas dos limitaciones, recurrieron a técnicas de aprendizaje por refuerzo (RL) para refinar aún más su modelo. Comenzando con el modelo NES bien entrenado de SFT, optimizaron el modelo utilizando un conjunto más amplio de datos no etiquetados mediante el diseño de un calificador capaz de juzgar con precisión la calidad de las sugerencias de edición del modelo. Esto les permite refinar las salidas del modelo y lograr una mayor calidad del modelo.

Las ideas clave en el diseño del calificador se pueden resumir de la siguiente manera:

Utilizan un modelo de razonamiento grande con criterios de calificación específicos.
Analizan rutinariamente las salidas del modelo para actualizar los criterios de calificación, buscando constantemente nuevas cualidades que indiquen ediciones inútiles.
El calificador no solo debe considerar la corrección de la sugerencia de edición, sino también esforzarse por hacer que el diff de código que se muestra en la interfaz de usuario sea más fácil de usar (fácil de leer).

El post-entrenamiento continuo con RL ha mejorado la capacidad de generalización del modelo. Específicamente, RL extiende el entrenamiento a datos no supervisados, expandiendo el volumen y la diversidad de datos que tienen disponibles para el entrenamiento y eliminando el requisito de que se conozca la siguiente edición de la verdad fundamental. Esto garantiza que el proceso de entrenamiento explore constantemente casos más difíciles y evita que el modelo se colapse en escenarios simples.

Además, RL les permite definir sus preferencias a través del calificador, lo que les permite establecer explícitamente criterios para “malas sugerencias de edición”. Esto permite que el modelo entrenado evite mejor la generación de malas sugerencias de edición cuando se enfrenta a casos fuera de distribución.

Lecciones del Entrenamiento del Último Modelo NES Personalizado

Su lanzamiento más reciente de NES se basa en esa base con mejoras en los datos, los prompts y la arquitectura:

Optimización de prompts: NES se ejecuta muchas veces por minuto mientras editas, por lo que reducir la cantidad de contexto que envían en cada solicitud tiene un impacto directo en la latencia. Recortaron el prompt, reutilizaron más tokens en caché entre llamadas y eliminaron el marcado innecesario, lo que hace que las sugerencias aparezcan más rápido sin reducir la calidad.
Filtrado de calidad de datos: Utilizaron calificadores basados en LLM para filtrar muestras ambiguas o de baja señal para reducir las sugerencias inútiles o distractivas.
Datos sintéticos: Destilaron datos de modelos más grandes para entrenar uno más pequeño sin perder calidad.
Ajuste de hiperparámetros: Ajustaron los hiperparámetros para la nueva arquitectura base para optimizar la calidad de las sugerencias.

¿Cómo Evalúan los Candidatos a Modelo?

Entrenan docenas de candidatos a modelo por mes para asegurarse de que la versión que envían ofrezca la mejor experiencia posible. Modifican sus datos de entrenamiento, adaptan su enfoque de entrenamiento, experimentan con nuevos modelos base y apuntan a correcciones para comentarios específicos que reciben de los desarrolladores. Cada nuevo modelo pasa por tres etapas de evaluación: pruebas offline, dogfooding interno y experimentos A/B online.

Pruebas offline: Evalúan los modelos contra un conjunto de casos de prueba específicos para comprender qué tan bien se desempeñan en escenarios específicos.
Dogfooding interno: Los ingenieros de GitHub y Microsoft utilizan cada modelo en sus flujos de trabajo diarios y comparten comentarios cualitativos.
Experimentos A/B: Someten a los candidatos más prometedores a un pequeño porcentaje de solicitudes de NES del mundo real para rastrear las métricas de aceptación, ocultación y latencia antes de decidir qué enviar.

Mejoras Continuas

Desde el envío del modelo NES inicial a principios de este año, han implementado tres actualizaciones importantes del modelo, cada una equilibrando la velocidad y la precisión.

Lanzamiento de abril: Este lanzamiento mejoró fuertemente la calidad del modelo y reestructuró el formato de respuesta para requerir menos tokens. ¿El resultado? Sugerencias más rápidas y de mayor calidad.
Lanzamiento de mayo: Para abordar los comentarios de los desarrolladores de que NES estaba mostrando demasiadas sugerencias, mejoraron la calidad de las sugerencias y redujeron el entusiasmo del modelo por hacer cambios. Esto condujo a sugerencias más útiles y menos interrupciones del flujo de trabajo.
Lanzamiento de noviembre: Después de probar casi treinta modelos candidatos durante el verano, ninguno de los cuales fue lo suficientemente fuerte como para reemplazar el modelo de mayo, este lanzamiento finalmente superó la prueba en las pruebas A/B. Ofrece sugerencias de mayor calidad con menor latencia al acortar los prompts, reducir la longitud de la respuesta y aumentar el almacenamiento en caché de tokens.

La siguiente tabla resume las métricas de calidad medidas para cada lanzamiento. Miden la tasa a la que se muestran las sugerencias a los desarrolladores, la tasa a la que los desarrolladores aceptan las sugerencias y la tasa a la que los desarrolladores ocultan la sugerencia de la interfaz de usuario. Estos son los resultados de las pruebas A/B que comparan la versión actual con la producción.

Release	Shown rate	Acceptance rate	Hide rate
April	+17.9%	+10.0%	-17.5%
May	-18.8%	+23.2%	-20.0%
November	-24.5%	+26.5%	-25.6%

Comentarios de la Comunidad

Los comentarios de los desarrolladores han guiado casi todos los cambios que han hecho en NES. Al principio, los desarrolladores les dijeron que el modelo a veces se sentía demasiado ansioso y sugería ediciones antes de que las quisieran. Otros pidieron lo contrario: una experiencia más asertiva donde NES interviene de inmediato y continuamente. Al igual que el debate de pestañas contra espacios, no hay una preferencia universal, y “útil” se ve diferente según el desarrollador.

Hasta ahora, se han centrado en enviar una experiencia predeterminada que funcione bien para la mayoría de las personas, pero ese equilibrio ha cambiado con el tiempo en función de los patrones de uso reales:

Reducción del entusiasmo: Agregaron más muestras de “sin edición” y ajustaron los umbrales de sugerencia para que el modelo solo intervenga cuando es probable que sea útil, no distractivo.
Aumento de la velocidad: Debido a que NES se ejecuta varias veces por minuto, continúan reduciendo la latencia a nivel de modelo, prompt e infraestructura para mantener las sugerencias dentro del flujo de edición.
Mejora de la experiencia del desarrollador: Refinaron cómo se muestran las ediciones, por lo que las sugerencias se sienten visibles pero no intrusivas, y ampliaron la configuración que permite a los desarrolladores personalizar cómo se comporta NES.

Mirando hacia el futuro, están explorando el comportamiento adaptativo donde NES se ajusta al estilo de edición de cada desarrollador con el tiempo, volviéndose más agresivo o más restringido en función de los patrones de interacción (por ejemplo, aceptar, descartar o ignorar sugerencias). Ese trabajo está en curso, pero está directamente informado por los comentarios que reciben hoy.

Como siempre, construyen esto contigo. Si tienes ideas sobre NES, a su equipo le encantaría saber de ti. Presenta un problema en su repositorio o envía comentarios directamente a VS Code.

¿Qué sigue?

Esto es lo que están construyendo:

Ediciones a distancia: Sugerencias en varios archivos, no solo donde estás escribiendo.
Respuestas más rápidas: Mejoras continuas de la latencia en todo el modelo y la infraestructura.
Ediciones más inteligentes: Mejor anticipación del contexto y las dependencias entre archivos.

Experimenta por ti mismo las sugerencias de edición más rápidas e inteligentes

Para experimentar el modelo NES más nuevo, asegúrate de tener la última versión de VS Code (y la extensión Copilot Chat), luego asegúrate de que NES esté habilitado en la configuración de VS Code.

Fuentes: