Bridged Self-Distillation enseña a modelos pequeños a razonar con cualquier maestro, incluso a través de una API

La destilación de razonamiento de un modelo potente a uno pequeño choca desde hace tiempo con dos problemas: el estudiante no puede reproducir las soluciones del maestro, y las probabilidades de tokens del maestro o son incompatibles con su vocabulario o directamente no están disponibles. Los autores de Bridged Self-Distillation (BSD) proponen un esquema único que cubre tres escenarios a la vez: un maestro con el mismo tokenizador, un maestro con otro tokenizador y un modelo cerrado detrás de una API. Al maestro solo se le exige una cosa: generar el texto del razonamiento.

Dónde falla la destilación habitual

La destilación on-policy tiene una lógica clara. El estudiante genera sus propias respuestas y el maestro las evalúa, de modo que el entrenamiento se produce sobre la distribución que el estudiante realmente genera. Así se elimina el sesgo entre los datos de entrenamiento y el comportamiento del modelo en inferencia. Pero el método tiene limitaciones.

Primera: las soluciones de un maestro potente pueden ser demasiado complejas para un modelo pequeño. El estudiante no es capaz de reproducir la cadena que produjo el gigante, y el entrenamiento se convierte en la persecución de una meta inalcanzable. Segunda: para obtener una señal a nivel de token se necesitan las probabilidades del maestro en el espacio de tokens del estudiante. Con tokenizadores distintos, esas probabilidades se alinean mal, y en las API cerradas con frecuencia ni siquiera existen. Hasta ahora cada situación se resolvía con su propio tipo de supervisión, y no existía una receta universal.

Cómo BSD sortea la incompatibilidad de tokens

La idea consiste en sacar al maestro de la ecuación y dejar en el bucle solo su texto. Un maestro externo escribe de antemano una reasoning trace, y puede hacerlo offline, una sola vez. Esa traza se convierte en contexto privilegiado.

Después trabajan dos copias del mismo modelo. El estudiante genera rollouts sin acceso a la traza, igual que tendrá que hacer en tareas reales. La segunda copia, el self-teacher, recibe la misma traza en su contexto y evalúa precisamente esos rollouts. La evaluación se expresa en el espacio de tokens del propio estudiante, así que el problema de compatibilidad de vocabularios desaparece: el modelo se compara consigo mismo, con la pista y sin ella.

La decisión final la toma el verificador. La guía a nivel de token del self-teacher se usa para corregir las actualizaciones en los rollouts fallidos. Los intentos exitosos los confirma la señal externa del resultado, mientras que el análisis de los errores recibe una pista precisa sobre el punto en que el razonamiento se desvió.

Al maestro externo se le consulta solo para obtener el texto, por lo que el procedimiento de entrenamiento es idéntico en todos los escenarios. No hace falta reescribir el pipeline para cada pareja de modelos.

Qué se sabe del planteamiento y de los resultados

• Tres escenarios de maestro: tokenizador común, tokenizadores distintos y API cerrada.
• Aportación del maestro: solo el texto del razonamiento, que puede generarse offline.
• Roles: el estudiante genera rollouts sin contexto; el self-teacher (copia del estudiante con la traza) los evalúa.
• Señal: guía a nivel de token más el veredicto final del verificador.
• Aplicación: corrección de las actualizaciones en los rollouts fallidos.
• Resultado según los autores: BSD mejora el modelo base y supera a los métodos de referencia diseñados para cada uno de los escenarios.
• El código está publicado en GitHub, en la cuenta TUMLegalTech.

A quién le sirve ya

El principal valor práctico es que el método elimina la dependencia de las entrañas del maestro. Un equipo que quiera mejorar un modelo abierto pequeño en matemáticas, código u otro dominio verificable puede obtener trazas de cualquier modelo frontier a través de una API normal. Para ello no se necesitan logits, ni un tokenizador compatible, ni acuerdos especiales con el proveedor.

La segunda ventaja tiene que ver con el coste. Las trazas se generan offline y una sola vez, de modo que no hace falta mantener al maestro caro dentro del bucle de entrenamiento. Solo se paga por el texto, y el grueso del cómputo recae en el modelo más pequeño.

La limitación también es evidente: el esquema se apoya en un verificador. Donde la respuesta puede comprobarse automáticamente (tareas con un resultado inequívoco, tests para código), el método encaja de forma natural. Para tareas abiertas sin un resultado verificable habrá que pensar en un sustituto del verificador.

Para la industria, es un paso más para que el conocimiento de los modelos cerrados fluya hacia modelos abiertos compactos. Los proveedores de API no pueden cerrar esa puerta solo ocultando los logits: basta con que entreguen el texto del razonamiento. Y quienes construyen sus propios modelos small deberían revisar el repositorio y probar el esquema en su tarea de dominio.