Bridged Self-Distillation ensina modelos pequenos a raciocinar com qualquer professor, até por API

A destilação de raciocínio de um modelo forte para um pequeno esbarra há tempos em dois problemas: o aluno não consegue reproduzir as soluções do professor, e as probabilidades de tokens do professor ou são incompatíveis com o vocabulário do aluno, ou simplesmente não estão disponíveis. Os autores do artigo Bridged Self-Distillation (BSD) propõem um esquema único que cobre três cenários de uma vez: professor com o mesmo tokenizador, professor com tokenizador diferente e modelo fechado atrás de uma API. O professor só precisa fazer uma coisa: gerar o texto do raciocínio.

Onde a destilação convencional falha

A destilação on-policy segue uma lógica simples. O próprio aluno gera as respostas, e o professor as avalia, de modo que o treinamento acontece sobre a distribuição que o aluno de fato produz. Isso elimina o descompasso entre os dados de treino e o comportamento do modelo na inferência. Mesmo assim, o método tem limitações.

A primeira: as soluções de um professor forte podem ser complexas demais para um modelo pequeno. O aluno não consegue reproduzir a cadeia de raciocínio produzida por um modelo gigante, e o treinamento vira uma corrida atrás de uma meta inalcançável. A segunda: o sinal em nível de token exige as probabilidades do professor no espaço de tokens do aluno. Com tokenizadores diferentes, elas são difíceis de alinhar, e nas APIs fechadas muitas vezes nem existem. Até agora, cada situação era resolvida com um tipo próprio de supervisão, e não havia uma receita universal.

Como o BSD contorna a incompatibilidade de tokens

A ideia é tirar o professor da equação e manter no ciclo apenas o texto dele. Um professor externo escreve antes um reasoning trace, e isso pode ser feito offline, uma única vez. O trace passa a ser um contexto privilegiado.

Depois entram em ação duas cópias do mesmo modelo. O aluno gera rollouts sem acesso ao trace, como terá de fazer em tarefas reais. A segunda cópia, o self-teacher, recebe o mesmo trace no contexto e avalia exatamente esses rollouts. A avaliação é expressa no espaço de tokens do próprio aluno, então o problema de compatibilidade de vocabulários desaparece: o modelo se compara consigo mesmo, com e sem a dica.

Quem toma a decisão final é o verificador. A orientação em nível de token do self-teacher é usada para corrigir as atualizações nos rollouts malsucedidos. As tentativas bem-sucedidas são confirmadas pelo sinal externo de resultado, e a análise dos erros recebe uma indicação pontual de onde o raciocínio saiu do caminho.

O professor externo é consultado apenas pelo texto, por isso o procedimento de treinamento é o mesmo em todos os cenários. Não é preciso reescrever o pipeline para cada par de modelos.

O que se sabe sobre a configuração e os resultados

• Três cenários de professor: tokenizador compartilhado, tokenizadores diferentes e API fechada.
• Entrada vinda do professor: apenas o texto do raciocínio, com geração possível offline.
• Papéis: o aluno gera rollouts sem contexto, e o self-teacher (cópia do aluno com o trace) os avalia.
• Sinal: orientação em nível de token mais o veredito final do verificador.
• Aplicação: correção das atualizações nos rollouts malsucedidos.
• Resultado, segundo os autores: o BSD melhora o modelo base e supera os métodos de referência desenvolvidos para cada um dos cenários.
• O código está publicado no GitHub, na conta TUMLegalTech.

Quem pode aproveitar já

O principal valor prático é que o método elimina a dependência dos componentes internos do professor. Uma equipe que queira melhorar um modelo aberto pequeno em matemática, código ou outra área verificável pode obter traces de qualquer modelo frontier por meio de uma API comum. Logits, tokenizador compatível e acordos especiais com o fornecedor não são necessários.

A segunda vantagem está no custo. Os traces são gerados offline e uma única vez, então não há necessidade de manter o professor caro dentro do ciclo de treinamento. Paga-se apenas pelo texto, e o grosso da computação roda no próprio modelo pequeno.

A limitação também é clara: o esquema depende de um verificador. Onde a resposta pode ser checada automaticamente (tarefas com resultado inequívoco, testes de código), o método se encaixa naturalmente. Para tarefas abertas, sem desfecho verificável, será preciso pensar em um substituto para o verificador.

Para a indústria, é mais um passo para que o conhecimento de modelos fechados migre para modelos abertos compactos. Os provedores de API não conseguem fechar essa porta apenas escondendo os logits: basta que entreguem o texto do raciocínio. E quem desenvolve seus próprios modelos small deveria dar uma olhada no repositório e testar o esquema em uma tarefa do seu domínio.