Una técnica de auto-destilación sorprendentemente simple que mejora el rendimiento en generación de código
(arxiv.org)- Simple Self-Distillation (SSD) es un método que mejora el rendimiento de los modelos de lenguaje grandes reentrenando el código que generan por sí mismos, sin modelo profesor ni aprendizaje por refuerzo
- Mejora la puntuación pass@1 de LiveCodeBench v6 del modelo Qwen3-30B-Instruct de 42.4% a 55.3%, con una mejora de +15.3 pp especialmente en el segmento de problemas difíciles
- SSD mitiga el conflicto entre precisión y exploración durante la generación de código y, según el contexto, suprime la probabilidad de cola mientras mantiene una diversidad útil
- No se puede reproducir el mismo efecto solo ajustando la temperatura o cambiando la política de decodificación; SSD reconfigura la distribución interna del modelo
- Como un procedimiento simple de entrenamiento posterior aplicable sin datos externos ni validación, plantea una alternativa práctica para mejorar la calidad de generación de código en LLM
Auto-destilación simple (Simple Self-Distillation, SSD)
- SSD (Simple Self-Distillation) es un método con el que un modelo de lenguaje grande (LLM) mejora su rendimiento usando sus propias salidas de código generadas, sin modelo profesor, verificador ni aprendizaje por refuerzo
- El modelo genera muestras con una temperatura (
temperature) y una configuración de truncamiento (truncation) determinadas, y luego vuelve a entrenarse con esos resultados mediante ajuste fino supervisado estándar (SFT) - No requiere en absoluto datos etiquetados externos, modelos de recompensa ni entorno de ejecución
- El modelo genera muestras con una temperatura (
- Mejora la puntuación pass@1 de LiveCodeBench v6 del modelo Qwen3-30B-Instruct de 42.4% → 55.3% (+12.9 pp, +30% de mejora relativa)
- La mayor mejora aparece especialmente en los problemas difíciles (
hard split) (+15.3 pp) - Generaliza a modelos de 4B, 8B y 30B de las familias Qwen y Llama
- La mayor mejora aparece especialmente en los problemas difíciles (
- SSD funciona mitigando el conflicto entre precisión y exploración (
precision-exploration)- Durante la generación de código, algunos tokens exigen alta precisión (“lock”) y otros requieren exploración diversa (“fork”)
- SSD suprime distribuciones de cola innecesarias según el contexto, mientras mantiene la diversidad útil
1. Antecedentes de la investigación
- La escasez de señales supervisadas de alta calidad (por ejemplo, código escrito por personas) limita la mejora del rendimiento de generación de código en los LLM
- Limitaciones de los enfoques existentes
- Destilación basada en modelo profesor: hereda los límites de rendimiento del modelo profesor
- Aprendizaje por refuerzo (RL): requiere modelo de recompensa y validación basada en ejecución, y es inestable
- Alternativas no supervisadas (por ejemplo, voto mayoritario, minimización de entropía): riesgo de colapso en aprendizaje de largo plazo
- SSD demuestra que es posible mejorar sin datos externos ni validación, usando solo las salidas del propio modelo
2. Metodología SSD
-
Síntesis de datos
- Para un conjunto dado de prompts de problemas X, se muestrea desde el modelo pθ con temperatura Ttrain y configuración de truncamiento ρtrain (top-k, top-p)
- Las salidas generadas (y) se usan tal cual, sin validación, como datos de entrenamiento (DSSD)
- En la mayoría de los casos, N=1 (una muestra por problema) es suficiente
-
Entrenamiento
- Se realiza ajuste fino supervisado con la pérdida estándar de entropía cruzada
- L(θ) = −E(x,y)∼DSSD Σ log pθ(yt | x, y<t)
-
Inferencia
- El modelo entrenado pθ* se decodifica con temperatura de evaluación Teval y configuración de truncamiento ρeval
3. Experimentos
-
Configuración de modelos
- Llama-3.1-8B-Instruct, Qwen3-4B/30B (Instruct, Thinking) y otros 5 modelos
- 2 familias (Llama, Qwen), 3 escalas (4B, 8B, 30B), 2 estilos de razonamiento (Instruct, Thinking)
-
Datos
- Se usaron alrededor de 10K problemas de programación competitiva del dataset rSTARcoder
- Sin validación de respuestas correctas, aplicando solo un filtrado sintáctico simple
-
Configuración de entrenamiento
- Basado en Megatron-LM, usando 8× GPU B200
- Optimizador AdamW, longitud máxima de secuencia 65,536
- 2,500 pasos para modelos Instruct y 300 pasos para modelos Thinking
-
Evaluación
- Se usó LiveCodeBench v6 (LCB v6) como benchmark principal
- Evaluación desglosada por pass@1, pass@5 y por dificultad (Easy/Medium/Hard)
4. Resultados principales
-
Mejora general del rendimiento
- Qwen3-30B-Instruct: 42.4% → 55.3% pass@1 (+12.9 pp)
- Qwen3-4B-Instruct: +7.5 pp, Llama-8B: +3.5 pp
- Los modelos Thinking también mejoran entre +2 y +3 pp
-
Mejora por dificultad
- Qwen3-30B-Instruct: Easy +6.5 pp / Medium +14.2 pp / Hard +15.3 pp
- En los modelos Thinking, la mayor mejora también aparece en el segmento Hard
-
Conservación de la diversidad
- La mejora en pass@5 es mayor que en pass@1 → la diversidad de generación se mantiene y mejora
- Ejemplo: Qwen3-30B-Instruct pass@5 +18.1 pp (Hard +23.0 pp)
-
Generalización entre dominios
- El rendimiento se mantiene también en tareas de matemáticas, código general y comprensión, además de programación competitiva
5. Comparación con políticas de decodificación
-
Ajustar solo la temperatura no puede reproducir el efecto de SSD
- En el barrido de temperatura del modelo base, la variación de pass@1 fue de apenas 1.5–3.0 pp
- SSD mejoró +11.8 pp en las mismas condiciones (Qwen3-30B-Instruct)
- La diferencia es especialmente grande en problemas Hard y en pass@5
- SSD cambia la distribución interna del modelo, por lo que no puede sustituirse con un simple ajuste de decodificación
6. Interacción de hiperparámetros
- El producto entre la temperatura de entrenamiento (Ttrain) y la temperatura de evaluación (Teval), Teff = Ttrain × Teval, determina el rendimiento
- El mejor rendimiento aparece cerca de Teff ≈ 1.2
- Cuanto más alto es Ttrain, más sensible se vuelve al cambio en Teval
- Agregar truncamiento (
truncation) eleva el techo de rendimiento- Configuración óptima: Ttrain=2.0, Teval=1.1, top-k=10 → pass@1 49.7% (+7.3 pp)
- El truncamiento aporta mejora adicional al eliminar la cola de baja probabilidad
7. Cómo funciona SSD
-
Conflicto entre precisión y exploración (Precision–Exploration)
- Lock: posiciones donde la respuesta correcta está casi fijada por la gramática → requieren baja temperatura
- Fork: posiciones donde son posibles varias soluciones → requieren alta temperatura
- Es difícil satisfacer ambas necesidades con una sola temperatura
-
Papel de SSD
- En Lock, suprime la probabilidad de cola para reforzar la precisión
- En Fork, aplana las probabilidades entre los candidatos principales para mantener diversidad de exploración
- Como resultado, realiza una reconfiguración de la distribución dependiente del contexto
8. Validación experimental
-
Experimento en entorno simulado
- Se aplicó SSD en un entorno simple con estructura de 1 Fork + 3 Lock
- Tras SSD, aumentó la probabilidad de éxito y se amplió el rango óptimo de temperatura
- Se confirmó que el entrenamiento y la decodificación se complementan mutuamente
-
Análisis de modelos reales
- Después de SSD, aumenta la probabilidad acumulada de los tokens principales y disminuye la probabilidad de cola
- Incluso con Teval alto, aumenta el número de candidatos principales efectivos y sube la entropía
- Es decir, SSD logra al mismo tiempo eliminar la cola y expandir la distribución superior
9. Análisis teórico
- La pérdida de entrenamiento de SSD se descompone en tres términos
- Support Compression: eliminación de probabilidad de cola
- Within-Support Reshaping: reconfiguración de la distribución superior
- Alignment to Base Model: mantenimiento de alineación con el modelo base
- En Lock, domina el primer término → eliminación de cola
- En Fork, opera el segundo término → aplanamiento de la distribución superior
- La entropía total disminuye, pero se mantiene la entropía de exploración útil
- Un simple ajuste de decodificación no puede realizar esta reconfiguración dependiente del contexto
10. Experimento con datos anómalos
- Con Ttrain=2.0 y sin truncamiento, el 62% de los datos generados era ruido sin sentido (
gibberish) - Aun así, después de aplicar SSD
- pass@1: 42.4% → 48.1% (+5.7 pp)
- pass@5: 53.5% → 64.0% (+10.5 pp)
- Mejora de +7.3 pp / +13.8 pp en problemas Hard
- Esto muestra que SSD puede impulsar mejoras aprendiendo la estructura de la distribución, no la calidad de la respuesta correcta
Conclusión
- Simple Self-Distillation (SSD)
- mejora el rendimiento de generación de código usando solo las propias salidas del modelo, sin profesor externo ni validación
- mitiga el conflicto entre precisión y exploración y logra mejoras generalizadas mediante reconfiguración de la distribución
- SSD se presenta como un método simple pero potente, aplicable en la etapa de post-training, que ofrece una alternativa práctica para mejorar la calidad de generación de código en LLM
1 comentarios
Comentarios en Hacker News
Lo interesante de este paper es que implementa de verdad el concepto de decodificación consciente del contexto (context-aware decoding)
Explica que durante la generación de código van alternando puntos de “fork” (bifurcaciones creativas donde caben varias interpretaciones) y puntos de “lock” (decisiones sintácticas que requieren exactitud)
Impresiona que la técnica SSD (Simple Self-Distillation) mejore el ranking de los tokens óptimos en ambas situaciones, ayudando a que el modelo sea más creativo cuando explora y más preciso cuando necesita exactitud
Incluso el cerebro humano ha sido estudiado durante miles de años y sigue teniendo muchas partes incomprensibles
Hasta el comportamiento emergente del flujo de tráfico no se entendió con claridad sino hasta hace relativamente poco
Así que seguir descubriendo nuevas propiedades de los LLM es algo normal
Si se usa muestreo basado en gramática o grammar-aware decoding, los tokens gramaticalmente únicos podrían insertarse directamente sin llamar al modelo
Pero en los sistemas ampliamente usados hoy casi no se aplica
Me pregunto si sería posible un enfoque generalizado que use más cómputo en las decisiones importantes y menos en los tokens obvios
Ahora estoy pensando si debería aplicar lo mismo también durante la inferencia
En código la diferencia es que la estructura está más clara, pero el mecanismo fork/lock sirve para muchas áreas de problemas
Self-Distillation parece ser una dirección clave en la evolución de los LLM
El estudio Self-Distillation Fine-Tuning(SDFT) publicado por equipos del MIT y ETH ya había mostrado alta eficiencia
El SSD (Simple Self-Distillation) de este paper es básicamente una continuación de esa línea, solo que con otro nombre
Que además lo llamen SSD también resulta confuso porque se superpone con SSD (unidad de estado sólido)
Ojalá hubieran reconocido con más claridad el origen y la genealogía del trabajo original SDFT
Hace poco vi un video de Gemma 4 corriendo en local a 50 tokens por segundo
Ya muestra capacidades del nivel de Sonnet 3x~4
Si a eso se le suman técnicas como SSD, para 2028 probablemente se masifiquen los modelos de código baratos y potentes
Es muy probable que los desarrolladores experimentados ejecuten sus propios modelos como un transpilador no determinista que convierte lenguaje natural en código
Ahorita se siente como si estuviéramos “construyendo una casa sobre clavos”
La hipótesis central de SSD, el conflicto entre precisión y exploración (precision–exploration), se parece al problema que intenta resolver Adaptive Decoding
Durante la inferencia parece obvio que hacen falta temperatures altas cuando se requiere pensamiento creativo, y temperatures bajas cuando se necesita exactitud sintáctica
Incluso repetir simplemente la pregunta “¿esta es la solución más elegante?” mejora visiblemente la salida del LLM
Si el modelo puede encontrar una respuesta mejor tan fácilmente, surge la duda de por qué no lo hizo así desde el principio
Primero haces algo que funcione, y solo después de varias pasadas de refinamiento termina volviéndose conciso
Algunos se pasan medio día pensando antes de escribir código, y otros implementan enseguida la primera solución
Los LLM actuales se parecen más a estos últimos
Esta investigación tiene mucho potencial para llevar a mejores modelos de generación de código
Pero seguimos sin entender bien qué está pasando en espacios de alta dimensión
Al final seguimos explorando con un enfoque de “tirar cosas y ver si se pegan”
Los grandes avances en machine learning muchas veces parecen simples a primera vista
Así fue con Transformer, y ahora pasa lo mismo con SSD
Probablemente porque todavía no tenemos una base teórica profunda
La complejidad muchas veces es señal de falta de comprensión
Por mi experiencia programando, esta es una regla bastante confiable
Irónicamente, Apple sigue publicando investigación en IA, pero OpenAI no
Alguien resumió este paper como “un modelo afinado para dar buenos resultados solo en código de benchmarks”, pero en realidad no es así
Después, un modelo con ajustes de decodificación (temp, top-k) logra resultados mejores que el original
O sea, no es simplemente fine-tuning adaptado al benchmark, sino una mejora basada en su propia salida
Este estudio puede compararse con practicar golf
Tras golpear la pelota miles de veces y automatizar el swing básico, en una partida real puedes intentar con confianza tiros creativos y arriesgados
SSD sigue una idea parecida: reforzar los patrones básicos para ganar margen en las elecciones creativas