Bridged Self-Distillation apprend aux petits modèles à raisonner d'après n'importe quel enseignant, même via une API

La distillation du raisonnement d'un modèle puissant vers un petit modèle se heurte depuis longtemps à deux obstacles : l'élève ne parvient pas à reproduire les solutions de l'enseignant, et les probabilités de tokens de l'enseignant sont soit incompatibles avec son vocabulaire, soit tout simplement inaccessibles. Les auteurs de l'article Bridged Self-Distillation (BSD) proposent un schéma unique qui couvre trois scénarios à la fois : un enseignant avec le même tokenizer, un enseignant avec un tokenizer différent, et un modèle fermé derrière une API. L'enseignant n'a qu'une seule chose à fournir : un texte de raisonnement.

Où la distillation classique atteint ses limites

La distillation on-policy repose sur une logique simple. L'élève génère lui-même ses réponses, l'enseignant les évalue, et l'entraînement porte donc sur la distribution que l'élève produit réellement. Cela supprime le décalage entre les données d'entraînement et le comportement du modèle à l'inférence. Mais la méthode a ses limites.

Première limite : les solutions d'un enseignant puissant peuvent être trop complexes pour un petit modèle. L'élève ne peut pas reproduire la chaîne de raisonnement produite par le géant, et l'entraînement devient la poursuite d'un objectif inatteignable. Seconde limite : un signal au niveau des tokens exige les probabilités de l'enseignant dans l'espace de tokens de l'élève. Avec des tokenizers différents, elles s'alignent mal, et les API fermées n'en fournissent souvent tout simplement pas. Jusqu'ici, chaque situation se traitait avec son propre type de supervision, sans recette universelle.

Comment BSD contourne l'incompatibilité des tokens

L'idée consiste à mettre l'enseignant hors de la boucle et à n'y garder que son texte. Un enseignant externe rédige à l'avance une reasoning trace, et il peut le faire hors ligne, une seule fois. Cette trace devient un contexte privilégié.

Deux copies d'un même modèle entrent ensuite en jeu. L'élève génère des rollouts sans accès à la trace, comme il le fera sur des tâches réelles. La seconde copie, le self-teacher, reçoit la même trace dans son contexte et évalue précisément ces rollouts. L'évaluation est exprimée dans l'espace de tokens de l'élève lui-même, si bien que le problème de compatibilité des vocabulaires disparaît : le modèle se compare à lui-même, avec et sans indice.

La décision finale revient au vérificateur. Le guidage au niveau des tokens fourni par le self-teacher sert à corriger les mises à jour sur les rollouts ratés. Les tentatives réussies sont confirmées par le signal externe sur le résultat, et l'analyse des erreurs reçoit un indice ciblé sur l'endroit où le raisonnement a dévié.

L'enseignant externe n'est sollicité que pour son texte, donc la procédure d'entraînement est identique dans tous les scénarios. Inutile de réécrire le pipeline pour chaque paire de modèles.

Ce que l'on sait du dispositif et des résultats

• Trois scénarios d'enseignant : tokenizer commun, tokenizers différents, API fermée.
• Entrée fournie par l'enseignant : uniquement le texte du raisonnement, génération possible hors ligne.
• Rôles : l'élève génère les rollouts sans contexte, le self-teacher (copie de l'élève avec la trace) les évalue.
• Signal : guidage au niveau des tokens plus verdict final du vérificateur.
• Application : correction des mises à jour sur les rollouts ratés.
• Résultat selon les auteurs : BSD améliore le modèle de base et surpasse les méthodes de référence conçues pour chacun des scénarios.
• Le code est publié sur GitHub, sous le compte TUMLegalTech.

À qui cela peut servir dès maintenant

La principale valeur pratique tient au fait que la méthode supprime la dépendance aux entrailles de l'enseignant. Une équipe qui veut renforcer un petit modèle ouvert en mathématiques, en code ou dans un autre domaine vérifiable peut récupérer des traces auprès de n'importe quel modèle frontier via une API ordinaire. Il ne faut pour cela ni logits, ni tokenizer compatible, ni accord particulier avec le fournisseur.

Second avantage : le coût. Les traces sont générées hors ligne et une seule fois, donc il n'est pas nécessaire de garder l'enseignant coûteux dans la boucle d'entraînement. On ne paie que pour le texte, et le gros du calcul se fait sur le petit modèle lui-même.

La limite est tout aussi évidente : le schéma s'appuie sur un vérificateur. Là où la réponse peut être contrôlée automatiquement (tâches à résultat univoque, tests pour le code), la méthode s'applique naturellement. Pour les tâches ouvertes sans issue vérifiable, il faudra réfléchir à un substitut de vérificateur.

Pour l'industrie, c'est une étape de plus vers le transfert des connaissances des modèles fermés vers des modèles ouverts compacts. Les fournisseurs d'API ne peuvent pas fermer cette porte en se contentant de masquer les logits : il suffit qu'ils renvoient le texte du raisonnement. Quant à ceux qui construisent leurs propres small-modèles, ils ont intérêt à consulter le dépôt et à tester le schéma sur leur tâche métier.