Se ha lanzado TRL v1.0, lo que representa un cambio significativo en la dirección de esta biblioteca. Originalmente concebida como una base de código de investigación, ahora se ha convertido en una herramienta confiable que los desarrolladores utilizan, con expectativas más claras sobre su estabilidad.
No se trata solo de un aumento de versión; TRL ahora impulsa sistemas de producción, asumiendo esa responsabilidad. Actualmente, TRL implementa más de 75 métodos de post-entrenamiento. Sin embargo, el objetivo no es solo cubrir todos los métodos, sino facilitar su uso práctico y comparativo.
1. Un objetivo en movimiento: el post-entrenamiento como un campo cambiante
El post-entrenamiento no ha evolucionado de manera lineal, sino que ha pasado por diferentes enfoques que han cambiado tanto el objetivo como la estructura de la biblioteca. Métodos como PPO [Schulman et al., (2017); Ziegler et al., (2019)] establecieron una arquitectura que parecía canónica, mientras que los métodos de estilo DPO, como DPO [Rafailov et al., (2023)], ORPO [Hong et al., (2024)] y KTO [Ethayarajh et al., (2024)], desafiaron esa estructura.
El aprendizaje por refuerzo variacional (RLVR), ejemplificado por GRPO [Shao et al., (2024)], también introdujo cambios significativos. En tareas como matemáticas y uso de herramientas, las recompensas a menudo provienen de verificadores o chequeos deterministas, lo que modifica la dinámica del aprendizaje.
2. De proyecto a biblioteca: TRL tiene un diseño adaptativo al caos
Construir una biblioteca para un campo en constante cambio implica, paradójicamente, no intentar capturar lo que es estable hoy. En lugar de ello, se debe diseñar para lo que podría cambiar. Los modelos de recompensa, por ejemplo, se consideraron esenciales en PPO, pero se volvieron opcionales en DPO y regresaron como verificadores en métodos RLVR.
Esta flexibilidad es crucial, ya que TRL se descarga 3 millones de veces al mes, y los proyectos importantes dependen de su estabilidad. A pesar de los cambios constantes en el campo, los usuarios requieren que la infraestructura no falle.
Un cambio de naturaleza: de código a contrato
TRL no decidió deliberadamente convertirse en una biblioteca, sino que lo descubrió al darse cuenta de que ya lo era. Proyectos como Unsloth y Axolotl han construido sobre los entrenadores y APIs de TRL, lo que hace que cualquier cambio importante en TRL afecte instantáneamente sus sistemas.
