Uma técnica de auto-destilação surpreendentemente simples para melhorar o desempenho de geração de código

• Simple Self-Distillation (SSD) é um método em que grandes modelos de linguagem reaprendem o código gerado por eles mesmos para melhorar o desempenho sem modelo professor nem aprendizado por reforço
• No modelo Qwen3-30B-Instruct, a pontuação pass@1 do LiveCodeBench v6 aumentou de 42,4% para 55,3%, com melhora de +15,3pp especialmente na faixa de problemas difíceis
• O SSD reduz o conflito entre precisão e exploração durante a geração de código e, dependendo do contexto, suprime probabilidades de cauda enquanto mantém diversidade útil
• Ajustar apenas a temperatura ou mudar a política de decodificação não reproduz o mesmo efeito, pois o SSD reformula a própria distribuição interna do modelo
• Como um procedimento simples de treinamento pós-processamento que pode ser aplicado sem dados externos nem validação, ele apresenta uma alternativa prática para melhorar a qualidade de geração de código de LLMs

---

Auto-Destilação Simples (Simple Self-Distillation, SSD)

• SSD (Simple Self-Distillation) é um método para melhorar o desempenho de grandes modelos de linguagem (LLMs) usando as próprias saídas de código geradas pelo modelo sem modelo professor, validador ou aprendizado por reforço
  • O modelo gera amostras com determinadas configurações de temperatura (temperature) e truncamento (truncation), e depois reaprende esses resultados com ajuste fino supervisionado padrão (SFT)
  • Não são necessários dados rotulados externos, modelos de recompensa nem ambiente de execução
• No modelo Qwen3-30B-Instruct, a pontuação pass@1 do LiveCodeBench v6 subiu de 42,4% → 55,3% (+12,9pp, +30% de melhora relativa)
  • A maior melhora ocorre especialmente em problemas difíceis (hard split) (+15,3pp)
  • Generaliza em modelos de 4B, 8B e 30B das famílias Qwen e Llama
• O SSD funciona mitigando o conflito entre precisão e exploração (precision-exploration)
  • Durante a geração de código, alguns tokens exigem alta precisão (“lock”), enquanto outros exigem exploração diversa (“fork”)
  • O SSD suprime distribuições de cauda desnecessárias de acordo com o contexto, mantendo a diversidade útil

---

1. Contexto da pesquisa

• A escassez de sinais supervisionados de alta qualidade (por exemplo, código escrito por humanos) limita a melhoria do desempenho de geração de código por LLMs
• Limitações das abordagens existentes
  • Destilação baseada em modelo professor: herda os limites de desempenho do modelo professor
  • Aprendizado por reforço (RL): requer modelo de recompensa e validação baseada em execução, além de ser instável
  • Alternativas não supervisionadas (ex.: voto majoritário, minimização de entropia): risco de colapso em treinamento de longo prazo
• O SSD demonstra que é possível melhorar sem dados externos nem validação, usando apenas as próprias saídas do modelo

---

2. Metodologia do SSD

• Síntese de dados

  • Para um conjunto de prompts de problemas X, faz-se amostragem do modelo pθ com temperatura Ttrain e configuração de truncamento ρtrain (top-k, top-p)
  • As saídas geradas (y) são usadas diretamente como dados de treinamento (DSSD), sem validação
  • Na maioria dos casos, N=1 (uma amostra por problema) é suficiente

• Treinamento

  • O ajuste fino supervisionado é feito com a perda padrão de entropia cruzada
  • L(θ) = −E(x,y)∼DSSD Σ log pθ(yt | x, y<t)

• Inferência

  • O modelo treinado pθ* é decodificado com temperatura de avaliação Teval e configuração de truncamento ρeval

  ---

3. Experimentos

• Configuração dos modelos

  • Llama-3.1-8B-Instruct, Qwen3-4B/30B (Instruct, Thinking) e outros 5 modelos
  • 2 famílias (Llama, Qwen), 3 escalas (4B, 8B, 30B), 2 estilos de raciocínio (Instruct, Thinking)

• Dados

  • Uso de cerca de 10 mil problemas de programação competitiva do dataset rSTARcoder
  • Aplicado apenas filtro sintático simples, sem validação das respostas corretas

• Configuração de treinamento

  • Baseado em Megatron-LM, usando 8× GPU B200
  • Otimizador AdamW, comprimento máximo de sequência de 65.536
  • Modelos Instruct: 2.500 steps; modelos Thinking: 300 steps

• Avaliação

  • LiveCodeBench v6 (LCB v6) como benchmark principal
  • Avaliação segmentada por pass@1, pass@5 e dificuldade (Easy/Medium/Hard)

  ---

4. Principais resultados

• Melhora geral de desempenho

  • Qwen3-30B-Instruct: 42,4% → 55,3% pass@1 (+12,9pp)
  • Qwen3-4B-Instruct: +7,5pp, Llama-8B: +3,5pp
  • Modelos Thinking também melhoram +2~3pp

• Melhora por dificuldade

  • Qwen3-30B-Instruct: Easy +6,5pp / Medium +14,2pp / Hard +15,3pp
  • Nos modelos Thinking, a maior melhora também aparece na faixa Hard

• Manutenção da diversidade

  • O ganho em pass@5 é maior que em pass@1 → a diversidade de geração é mantida e ampliada
  • Ex.: Qwen3-30B-Instruct pass@5 +18,1pp (Hard +23,0pp)

• Generalização de domínio

  • Fora da programação competitiva, o desempenho também é mantido em tarefas de matemática, código geral e compreensão

  ---

5. Comparação com políticas de decodificação

• Só ajustar a temperatura não reproduz o efeito do SSD

  • Na varredura de temperatura do modelo base, a variação de pass@1 ficou em torno de 1,5–3,0pp
  • O SSD melhorou +11,8pp nas mesmas condições (Qwen3-30B-Instruct)
  • A diferença é especialmente grande em problemas Hard e no pass@5
  • O SSD altera a própria distribuição interna do modelo, então não pode ser substituído por simples ajuste de decodificação

  ---

6. Interação de hiperparâmetros

• O produto entre a temperatura de treinamento (Ttrain) e a temperatura de avaliação (Teval), Teff = Ttrain × Teval, determina o desempenho
  • Melhor desempenho perto de Teff ≈ 1,2
  • Quanto maior o Ttrain, maior a sensibilidade a mudanças em Teval
• Adicionar truncamento (truncation) eleva o teto de desempenho
  • Configuração ótima: Ttrain=2.0, Teval=1.1, top-k=10 → pass@1 49,7% (+7,3pp)
  • O truncamento fornece melhora adicional ao remover a cauda de baixa probabilidade

---

7. Como o SSD funciona

• Conflito entre precisão e exploração (Precision–Exploration)

  • Lock: posições em que a resposta gramaticalmente correta é quase fixa → requer baixa temperatura
  • Fork: posições em que várias soluções são possíveis → requer alta temperatura
  • É difícil satisfazer ambas as exigências com uma única temperatura

• Papel do SSD

  • Em Lock, reforça a precisão ao suprimir probabilidades de cauda
  • Em Fork, mantém a diversidade de exploração ao achatar as probabilidades entre os principais candidatos
  • Como resultado, realiza uma reformulação de distribuição dependente do contexto

  ---

8. Verificação experimental

• Experimento em ambiente simulado

  • Aplicação do SSD em um ambiente simples com estrutura de 1 Fork + 3 Locks
  • Após o SSD, a probabilidade de sucesso aumentou e a faixa ótima de temperatura se ampliou
  • Confirmou-se que treinamento e decodificação são complementares entre si

• Análise em modelos reais

  • Após o SSD, a probabilidade acumulada dos tokens principais aumenta e a probabilidade de cauda diminui
  • Mesmo com Teval alto, o número de candidatos principais válidos aumenta e a entropia sobe
  • Ou seja, o SSD alcança simultaneamente remoção da cauda e expansão da distribuição principal

  ---

9. Análise teórica

• A perda de treinamento do SSD se decompõe em três termos
  1. Support Compression: remoção da probabilidade de cauda
  2. Within-Support Reshaping: reformulação da distribuição principal
  3. Alignment to Base Model: manutenção do alinhamento com o modelo original
• Em Lock, o primeiro termo domina → remoção da cauda
• Em Fork, o segundo termo atua → achatamento da distribuição principal
• A entropia total diminui, mas a entropia de exploração útil é preservada
• Ajustes simples de decodificação não conseguem realizar essa reformulação por contexto

---

10. Experimento com dados anômalos

• Com Ttrain=2.0, sem truncamento, 62% dos dados gerados eram ruído sem sentido (gibberish)
• Ainda assim, após aplicar SSD
  • pass@1: 42,4% → 48,1% (+5,7pp)
  • pass@5: 53,5% → 64,0% (+10,5pp)
  • Melhora de +7,3pp / +13,8pp em problemas Hard
• Isso mostra que o SSD pode promover melhorias aprendendo a estrutura da distribuição, e não a qualidade da resposta correta em si

---

Conclusão

• Simple Self-Distillation (SSD)
  • melhora o desempenho de geração de código usando apenas as próprias saídas do modelo, sem professor externo nem validação
  • mitiga o conflito entre precisão e exploração e alcança melhoria generalizada por meio de reformulação da distribuição
• O SSD é um método simples porém poderoso, aplicável na etapa de post-training, e apresenta uma alternativa prática para melhorar a qualidade de geração de código de LLMs

[GN⁺]

Comentários do Hacker News

• O interessante deste artigo é que ele implementa de fato o conceito de decodificação sensível ao contexto (context-aware decoding)
  Ele explica que, durante a geração de código, pontos de "fork" (ramificações criativas em que várias interpretações são possíveis) e pontos de "lock" (decisões sintáticas que exigem exatidão) aparecem de forma alternada
  É impressionante que a técnica SSD (Simple Self-Distillation) melhore o ranking dos tokens ideais em ambas as situações, ajudando o modelo a ser mais criativo quando está explorando e mais preciso quando a exatidão é necessária

  • Na verdade, esse tipo de descoberta de novas propriedades dos LLMs parece menos surpreendente e mais algo natural
    Até o cérebro humano foi estudado por milhares de anos e ainda continua em grande parte misterioso
    Até mesmo o comportamento emergente do fluxo de trânsito não foi claramente compreendido até tempos recentes
    Então, continuar descobrindo novas propriedades dos LLMs é algo natural
  • O interessante é que o modelo usa a mesma quantidade de computação para tokens de "fork" e de "lock"
    Com amostragem baseada em gramática ou grammar-aware decoding, tokens gramaticalmente únicos poderiam até ser inseridos diretamente sem chamar o modelo
    Mas isso quase não é aplicado nos sistemas amplamente usados hoje
    Fico curioso se seria possível uma abordagem generalizada que use mais computação para escolhas importantes e menos computação para tokens óbvios
  • Ao fazer fine-tuning de um modelo pequeno, tive um problema de mode collapse, mas ele foi resolvido ao embaralhar aleatoriamente a ordem dos campos durante o treinamento
    Estou pensando se devo aplicar a mesma abordagem também na inferência
  • O interessante é que o SSD funciona mesmo sem ajustar a temperature em tempo real nem prever pontos de fork/lock
  • Esse conceito pode ser aplicado não só a código, mas também a outros tipos de conteúdo generativo em geral
    No código, a diferença é apenas que a estrutura é mais clara, mas o mecanismo de fork/lock vale para vários domínios de problemas

• Self-Distillation parece ser uma direção central no avanço dos LLMs
  O estudo Self-Distillation Fine-Tuning (SDFT), publicado por equipes do MIT e da ETH, já havia mostrado alta eficiência
  O SSD (Simple Self-Distillation) deste artigo está, na prática, na mesma linha, só com um nome diferente
  O nome SSD também gera confusão por coincidir com SSD (solid-state drive)
  Eu gostaria que houvesse um reconhecimento mais claro da origem e linhagem do trabalho original, o SDFT

• Recentemente vi um vídeo do Gemma 4 rodando localmente a 50 tokens por segundo
  Ele já mostra capacidades no nível do Sonnet 3x~4
  Se técnicas como SSD forem adicionadas a isso, parece provável que por volta de 2028 modelos de código baratos e poderosos se popularizem
  Desenvolvedores experientes provavelmente vão rodar seus próprios modelos como transpiladores não determinísticos que convertem linguagem natural em código

  • Eu também penso nisso às vezes. Se eu treinasse um modelo apenas com as versões mais recentes das linguagens que uso (PHP, SQL, JS etc.), ele talvez pudesse ser um modelo muito mais pequeno e rápido
    Hoje parece meio como “construir uma casa sobre pregos”
  • Claro, até lá modelos de fronteira com memória por projeto e aprendizado sob demanda talvez superem com folga os modelos pessoais

• A hipótese central do SSD, o conflito entre precisão e exploração (precision–exploration), é semelhante ao problema que o Adaptive Decoding tenta resolver

  • Eu também tenho muito interesse em Adaptive Decoding
    Durante a inferência, parece óbvio que é preciso temperature alta quando o raciocínio criativo é necessário e temperature baixa quando a correção sintática é necessária

• Apenas repetir a pergunta “essa é a solução mais elegante?” já melhora perceptivelmente a saída do LLM
  Se o modelo consegue encontrar uma resposta melhor com tanta facilidade, fica a dúvida de por que ele não fez isso logo de início

  • Na prática, soluções elegantes quase nunca surgem na primeira tentativa
    Primeiro se cria uma solução que funcione, e só depois de várias rodadas de refinamento ela enfim fica concisa
  • Com desenvolvedores humanos acontece a mesma coisa
    Algumas pessoas pensam por meio dia antes de escrever código, enquanto outras implementam imediatamente a primeira solução
    Os LLMs atuais estão mais próximos do segundo caso

• Esta pesquisa tem grande potencial de levar a modelos de geração de código melhores
  Mas ainda não entendemos de verdade o que está acontecendo em espaços de alta dimensionalidade
  No fim, continuamos explorando no estilo “jogar e ver se gruda”

• Avanços em machine learning muitas vezes parecem simples por fora
  Foi assim com o Transformer, e o mesmo vale para este SSD
  Provavelmente porque ainda não temos uma base teórica profunda

  • Como em muitas descobertas, na prática simplicidade costuma ser um sinal de correção
    Complexidade muitas vezes é sinal de falta de entendimento
    Pela minha experiência com programação, essa é uma regra bastante confiável

• Ironicamente, a Apple ainda publica pesquisas de IA, mas a OpenAI não

  • Eu também acho isso estranho. Não parece haver motivo para manter tudo fechado
  • Talvez seja porque a OpenAI ainda não tenha um “mercado” a proteger

• Alguém resumiu este artigo como “um modelo ajustado para ir bem apenas em benchmarks de código”, mas na verdade não é isso

  • Pelo artigo, sem validação de resposta nem avaliação de qualidade, eles simplesmente inserem as entradas do benchmark e reutilizam as saídas geradas no treinamento
    Depois, um modelo com configurações de decodificação (temp, top-k) ajustadas produz resultados melhores que o original
    Ou seja, não é apenas fine-tuning voltado para benchmark, mas uma melhora de desempenho baseada nas próprias saídas do modelo

• Esta pesquisa pode ser comparada a treino de golfe
  Depois de bater na bola milhares de vezes e automatizar o swing básico, a pessoa passa a conseguir tentar tacadas criativas e arriscadas com confiança em uma partida real
  O SSD segue essa lógica de reforçar padrões básicos para ganhar espaço para escolhas criativas