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

El equipo ecom.tech probó si un pequeño modelo Qwen3-4B-Instruct podría ser hecho para escribir pruebas unitarias útiles para backends Kotlin no a través de fine-tuning supervisado estándar, sino a través de un algoritmo evolutivo llamado Evolution Strategies. El resultado práctico fue fuerte: en la tarea de generación de pruebas, este enfoque superó tanto el fine-tuning supervisado como GRPO en términos de recompensa final y cobertura. Pero junto con la victoria en especialización, los investigadores vieron el lado negativo: cuanto mejor se ajustaba el modelo para una tarea estrecha, más notablemente perdía algunas de sus capacidades generales.

La motivación para el experimento fue bastante práctica. Dentro de su servicio de generación de código, el equipo enfrentaba un problema típico: los LLMs primero producen código funcionando, luego escriben pruebas para él que se ven plausibles pero no siguen convenciones internas y no siempre verifican la lógica empresarial realmente importante. Para evaluar si esto podría solucionarse mediante fine-tuning, los investigadores reunieron un conjunto de datos de 1.500 ejemplos: 1.300 para entrenamiento y 200 para prueba. El modelo recibía no solo la clase siendo probada sino también el contexto completo alrededor de ella, recopilado por un agente basado en qwen-code, y tenía que generar un archivo de prueba unitaria listo para usar.

Utilizaron dos métricas para evaluación. La primera fue Coverage, pero no en el sentido familiar de cobertura de líneas, sino como cobertura funcional: qué tan bien la prueba generada realmente cubre la misma funcionalidad pública que la prueba de referencia. La segunda fue CodeBLEU, una métrica que examina no solo coincidencias de tokens sino también sintaxis y flujo de datos en el código. Como CodeBLEU estándar no admite Kotlin, el equipo tuvo que agregar este soporte por separado mediante tree-sitter-kotlin y un conjunto personalizado de palabras clave.

La función de recompensa era simple: 0,6 de peso fue a CodeBLEU y 0,4 a Coverage, para considerar tanto la forma del código como su utilidad práctica. La esencia de Evolution Strategies en este experimento funcionaba así: en lugar de actualizaciones basadas en gradientes, tomaron alrededor de 30 copias perturbadas del modelo base, agregando ruido gaussiano a los pesos, luego hicieron que cada copia generara una respuesta en modo determinista y la evaluaron con la recompensa. Después, los pesos base se desplazaron hacia los cambios que produjeron los mejores resultados. Este enfoque es más simple de paralelizar, no requiere almacenar gradientes pesados y, según los autores, es menos propenso a reward hacking.

Utilizaron un proyecto abierto Evolution Strategies at Scale con aceleración vLLM y entrenaron el modelo en un cluster de 8 H100s. Debido al costo de un paso completo a través del conjunto de datos en cada iteración, introdujeron batching: seleccionando aleatoriamente 32 ejemplos por lote.

El experimento mostró mejora notable ya después de 500 iteraciones. Al final del entrenamiento, CodeBLEU había aumentado 21,3% respecto al modelo base, y Coverage 18,6%. El mejor resultado de ES proporcionó una cobertura de 0,7381 y recompensa final máxima; según las métricas seleccionadas, superó no solo SFT y GRPO, sino incluso el más grande Qwen3-Coder-480B.

La situación con métodos competidores fue reveladora: SFT produjo pruebas sintácticamente limpias pero tuvo dificultades para acertar la lógica necesaria, mientras que GRPO de hecho se degradó en ambas métricas en esta configuración.

Para una tarea de ingeniería estrecha, la conclusión se ve directa: el fine-tuning evolutivo puede ser una herramienta viable incluso para un modelo relativamente pequeño. Pero luego vino la parte menos agradable.

Ante el trasfondo de trabajos recientes sobre catastrophic forgetting, el equipo verificó por separado qué ocurre con el conocimiento general del modelo fine-tuned. Ejecutaron la versión ES de Qwen3-4B-Instruct a través de GPQA—un benchmark científico desafiante. La caída en precisión fue en promedio 2,1% en zero-shot y 5,3% en five-shot chain-of-thought. La capacidad de usar pistas contextuales se vio particularmente afectada: el beneficio de ejemplos few-shot cayó 41–72%.

La hipótesis coincide con lo que muestran otras investigaciones: ES hace cambios densos en casi todos los pesos del modelo, lo que lo ayuda a resolver mejor la tarea objetivo pero lo hace desviarse más de la línea base y olvidar algunas habilidades previas.

¿Qué significa esto en la práctica? Evolution Strategies no se ve como un reemplazo universal para RL, sino como una poderosa herramienta especializada para empresas que se importan más en exprimir localmente el máximo rendimiento de un modelo para un pipeline específico. Si hay una función de recompensa clara, recursos computacionales suficientes y tolerancia para una compensación en capacidades generales, ES ya puede entregar ganancias significativas.

Pero para equipos de producto, también es un recordatorio: mejorar la calidad en una tarea no es gratis, y la batalla por delante será no solo sobre nuevas métricas, sino sobre formas de hacer fine-tune de modelos sin perder su flexibilidad de línea base.