ecom.tech compara el ajuste evolutivo de Qwen3-4B con SFT y GRPO en pruebas para Kotlin

El equipo de ecom.tech comprobó si es posible lograr que un modelo pequeño, Qwen3-4B-Instruct, escriba pruebas unitarias útiles para un backend en Kotlin no con el SFT habitual, sino con un algoritmo evolutivo, Evolution Strategies. El resultado práctico fue sólido: en la generación de pruebas, este enfoque superó tanto al ajuste supervisado (SFT) como a GRPO en reward final y coverage. Pero junto a la ventaja en especialización, los investigadores vieron la otra cara: cuanto mejor se adaptaba el modelo a la tarea concreta, más capacidades generales perdía.

El motivo del experimento era totalmente práctico. En el servicio de generación de código del equipo aparecía un problema típico: el LLM primero produce código funcional y luego escribe pruebas que parecen verosímiles, pero que no respetan las convenciones internas y no siempre verifican la lógica de negocio realmente importante. Para evaluar si el ajuste fino podía corregirlo, los investigadores reunieron un conjunto de 1500 ejemplos: 1300 para entrenamiento y 200 para prueba. El modelo recibía no solo la clase a probar, sino todo el contexto a su alrededor, reunido por un agente basado en qwen-code, y debía generar un archivo listo con pruebas unitarias.

Se usaron dos métricas. La primera es Coverage, pero no en el sentido habitual de cobertura de líneas, sino como cobertura funcional: hasta qué punto la prueba generada alcanza la misma funcionalidad pública que la de referencia. La segunda es CodeBLEU, una métrica que no mira solo la coincidencia de tokens, sino también la sintaxis y el flujo de datos del código. Como el CodeBLEU estándar no admite Kotlin, el equipo tuvo que añadir ese soporte por separado con tree-sitter-kotlin y un conjunto propio de palabras clave. La función de reward se mantuvo simple: 0,6 de peso para CodeBLEU y 0,4 para Coverage, de modo que se tuvieran en cuenta tanto la forma del código como su utilidad práctica.

En este experimento, Evolution Strategies funcionó así: en lugar de actualizar por gradiente, se tomaron unas 30 copias perturbadas del modelo base, añadiendo ruido gaussiano a los pesos; luego cada copia generaba una respuesta en modo determinista y se evaluaba con la recompensa. Después, los pesos base se desplazaban hacia los cambios que dieron mejor resultado. Este enfoque es más fácil de paralelizar, no exige almacenar gradientes pesados y, según los autores, es menos propenso al reward hacking.

Como base se usó el proyecto abierto Evolution Strategies at Scale con aceleración mediante vLLM, y el modelo se entrenó en un clúster de 8 H100. Dado el coste de recorrer todo el conjunto de datos en cada iteración, se introdujo batching: se elegían al azar 32 ejemplos.

El experimento mostró una mejora notable ya tras 500 iteraciones. Al final del entrenamiento, CodeBLEU creció un 21,3 % respecto al modelo base y Coverage, un 18,6 %. El mejor resultado de ES alcanzó un coverage de 0,7381 y el máximo reward final; según las métricas elegidas, superó no solo a SFT y GRPO, sino incluso al mucho mayor Qwen3-Coder-480B. El panorama de los métodos rivales fue revelador: SFT producía pruebas sintácticamente limpias, pero acertaba poco con la lógica necesaria, mientras que GRPO, en esta configuración, empeoró en ambas métricas. Para una tarea de ingeniería acotada, la conclusión es directa: el ajuste evolutivo puede ser una herramienta útil incluso para un modelo relativamente pequeño.

Después llegó la parte menos agradable. A raíz de trabajos recientes sobre el olvido catastrófico, el equipo comprobó por separado qué ocurre con el conocimiento general del modelo ajustado. Para ello, la versión ES de Qwen3-4B-Instruct se evaluó en GPQA, un benchmark científico difícil.

La accuracy cayó de media un 2,1 % en zero-shot y un 5,3 % en five-shot chain-of-thought. Especialmente notable fue la pérdida de la capacidad de aprovechar pistas del contexto: el beneficio de los ejemplos few-shot se redujo entre un 41 % y un 72 %. La hipótesis coincide con lo que muestran otros estudios: ES introduce cambios densos en casi todos los pesos del modelo, de ahí que resuelva mejor la tarea objetivo, pero se aleje más del estado base y olvide parte de sus habilidades previas.

¿Qué significa esto en la práctica? Evolution Strategies parece menos un sustituto universal del RL y más una herramienta especializada y potente para empresas a las que les importa más sacar el máximo de un modelo en un pipeline concreto. Si hay una función de reward clara, recursos de cómputo suficientes y es aceptable un compromiso en las capacidades generales, ES ya puede dar una ventaja tangible. Para los equipos de producto es además un recordatorio: mejorar en una tarea no es gratis, y la competencia no será solo por nuevas métricas, sino por formas de ajustar modelos sin perder su flexibilidad básica.