Después del preentrenamiento, los modelos de lenguaje pasan por varias etapas de mid- y post-training para volverse útiles: seguir instrucciones, razonar, usar herramientas, y mantener seguridad. ¿Qué pasa cuando quieres añadir o mejorar una habilidad después de todo ese proceso? Normalmente o vuelves a entrenar desde cero, o arriesgas que el modelo olvide cosas. BAR propone otra vía: entrenar expertos por separado y combinarlos con una arquitectura MoE para mantener flexibilidad y evitar degradaciones.
Qué es BAR y por qué importa
BAR significa Branch-Adapt-Route. La idea clave es modularizar el post-entrenamiento: cada dominio (por ejemplo math, code, tool use, safety) se entrena como un experto independiente que pasa por su propio pipeline completo. Luego se combinan en un solo modelo usando un mixture-of-experts y un router que decide qué experto activar en cada entrada.
¿Por qué es relevante? Porque en desarrollo real de modelos hay equipos distintos, calendarios distintos y datos que aparecen de forma asíncrona. Volver a ejecutar todo el pipeline cada vez que actualizas código o datos es caro e impráctico. BAR te da una alternativa que escala linealmente con las actualizaciones de dominio.
Cómo funciona BAR
BAR tiene tres etapas claras: entrenamiento independiente de expertos, fusión de expertos, y entrenamiento del router. Hay una contribución técnica central: una pauta de descongelado (progressive unfreezing) de los parámetros compartidos que cambia según la etapa de post-training.
Etapa 1 - Entrenamiento independiente de expertos
Cada experto se implementa como un MoE de dos expertos: un "anchor" congelado que preserva los pesos FFN del modelo base y un experto entrenable.
Los expertos pasan por las etapas que su dominio necesite. En los experimentos de BAR, math y code pasaron por mid-training, SFT y RLVR. Tool use y safety usaron SFT solamente.
Progressive unfreezing:
Mid-training: todas las capas compartidas congeladas. Esto funciona porque la adquisición de conocimiento suele residir en las FFN.
SFT: se descongelan la capa de embeddings y la cabeza de lenguaje LM head. Es necesario si el dominio añade tokens especiales o nuevos formatos de salida. En el benchmark BFCL, el experto de tool use pasó de 20.3 a 46.4 después de permitir este descongelado.
RLVR: se descongelan todos los parámetros compartidos, incluyendo atención. El RL produce cambios de comportamiento que no caben solo en las FFN.
Cada experto entrena con una mezcla de datos específicos de dominio y datos generales de SFT. Entrenar solo con datos de dominio mejora el desempeño en dominio, pero destruye capacidades generales.
Etapa 2 - Fusión de expertos
Tras entrenar, se mergean los expertos en un único MoE.
Los parámetros compartidos que divergieron entre corridas (porque se descongelaron) se promedian. Sorprendentemente, este promedio produce poca o ninguna pérdida mensurable en las evaluaciones por dominio.
Etapa 3 - Entrenamiento del router
Se entrena el router del MoE con todos los pesos de expertos y compartidos congelados.
Bastó con una muestra estratificada del 5% de los datos SFT para obtener un router efectivo, lo que hace esta etapa rápida y barata.
Resultados y comparaciones
Los modelos evaluados son al menos de 7B y parten de un Olmo 2 ya post-entrenado.
BAR supera a todas las alternativas que no requieren volver a hacer mid-training desde cero: 49.1 vs 47.8 para retrain con post-training solamente.
Ventajas notables en math (+7.8) y code (+4.7) frente a ese baseline.
Fusión densa después de mid-training falla de forma catastrófica: promedio 6.5. Sin mid-training, la fusión densa queda en 36.9 vs 49.1 de BAR.
BTX, que entrena expertos como modelos densos totalmente independientes, queda por debajo de BAR (46.7 vs 49.1), probablemente porque la ausencia de parámetros compartidos aumenta la divergencia y complica el ruteo.
La reentrenamiento completo con mid-training sigue siendo el techo de rendimiento (50.5) pero exige acceso completo al checkpoint de preentrenamiento y reprocesar todo, lo cual es costoso.
Actualizaciones modulares: coste y beneficios
Una ventaja práctica de BAR es la capacidad de actualizar expertos individualmente:
Actualizar datos: reemplazar el experto de code por uno entrenado con datos mejores y RL da +16.5 puntos en code en el modelo combinado, sin afectar otros dominios.
Añadir una etapa: añadir RL a un experto de math mejora math en +13 puntos en el modelo combinado, con mínimo impacto en las demás áreas.
Estas actualizaciones solo requieren retrenar el experto afectado y el router, lo que implica un coste lineal por dominio frente al coste casi cuadrático de retomar un pipeline monolítico.
Lecciones prácticas y recomendaciones
Post-training necesita más flexibilidad que pretraining. No basta con congelar todas las capas compartidas; hay que descongelar selectivamente según la etapa.
Mezcla de datos: nunca entrenes SFT solo en datos de dominio. Mezclar datos generales es crítico para preservar habilidades generales como seguir instrucciones.
Promediado de pesos funciona mejor de lo que muchos esperarían. Aunque los parámetros compartidos divergen, el promedio introduce poca degradación.
No todos los expertos deben activarse siempre. Activar 4 de 5 expertos alcanzó resultados casi iguales, lo que sugiere optimizaciones de eficiencia con ruteo más agresivo.
Mirando hacia adelante
BAR adapta el flujo de trabajo de entrenamiento a la realidad del desarrollo de modelos: equipos separados, actualizaciones asíncronas y necesidad de iterar rápido en capacidades puntuales. No reemplaza el reentrenamiento completo si buscas exprimir el máximo rendimiento absoluto, pero ofrece un camino práctico, escalable y económico para mejorar y extender modelos post-entrenamiento.
Una dirección natural es partir de arquitecturas nativamente sparse en vez de "upcyclings" de modelos densos. Eso podría aumentar la eficiencia y la escalabilidad de la modularidad.
BAR no es solo un truco académico; es una receta para organizar el entrenamiento en equipos reales y reducir el costo de mantener modelos complejos sin sacrificar seguridad o habilidades críticas.
