De 1 598 artículos de RL, solo 37 llegaron a los frameworks: auditoría de siete stacks open source

Un nuevo análisis de siete frameworks abiertos para el posentrenamiento de modelos de lenguaje con RL muestra lo estrecho que es el camino entre un artículo y el código funcional. Los autores revisaron el historial de commits y lo cruzaron con 6 939 trabajos seleccionados de arXiv, publicados entre enero de 2025 y junio de 2026. De los 1 598 artículos que proponen un método general de entrenamiento con RL, solo 37 aparecen en al menos un framework. Es alrededor del 2,3%.

Para quienes trabajan con estos modelos, la diferencia es práctica: si el método está en el framework, se activa con una sola línea de configuración. Si no está, hay que reescribirlo por cuenta propia, y a escala de decenas de miles de millones de parámetros eso resulta caro y arriesgado.

El flujo de artículos crece, pero la cola de inclusión no avanza

Los autores dividieron los trabajos en cinco cohortes trimestrales. El tamaño de la cohorte pasó de 72 a 386 artículos, es decir, 5,4 veces más. Sin embargo, el número de métodos que los frameworks incorporaron en un plazo de 180 días se mantuvo en un rango de 5 a 7. Una estimación aproximada a partir de los extremos de ese rango: al inicio equivale a entre el 7% y el 10% de la cohorte; al final del periodo, a solo el 1,3–1,8%.

Todo apunta a que el cuello de botella no está en la generación de ideas, sino en los recursos de los mantenedores. Cada nueva implementación exige pruebas, mantenimiento y compatibilidad con el resto del código.

Qué métodos superan el filtro

Los artículos incluidos se distinguen claramente del resto de los trabajos de esos mismos trimestres:

• Políticas de 30B parámetros o más: 41% entre los incluidos frente a 10% entre los demás.
• Ajuste de coeficiente, clip, máscaras o pesos en una función de pérdida existente: 29% frente a 9%.
• Publicación del código: igual de frecuente en ambos grupos, de modo que un repositorio abierto no supone ventaja.
• Las dos brechas se mantienen si se excluyen los artículos de las empresas que mantienen los propios frameworks.

El último punto responde a la objeción más obvia, la de que los frameworks simplemente adoptan trabajos «propios». El patrón es más amplio: pasan los métodos probados en modelos grandes y que se integran con un cambio pequeño. Si un artículo requiere un componente nuevo o una reestructuración del pipeline, tiene menos opciones.

Los rechazos apenas se ven

La observación más llamativa se refiere a las discusiones públicas. En los issues y los pull requests, los métodos rara vez se rechazan de forma abierta. En más de nueve de cada diez métodos generales que no entraron en ningún framework no hay un solo hilo en el que se los cite o se los nombre. Muchas de las propuestas que sí aparecen se quedan abiertas y sin respuesta. Un método no recibe un rechazo: simplemente no llega a entrar en el radar.

Dos comprobaciones adicionales completan el cuadro. Por un lado, los usuarios rara vez informan públicamente de fallos de entrenamiento, así que los mantenedores tienen pocas señales sobre qué métodos hacen falta de verdad. Por otro, en los informes técnicos de 13 grandes modelos open-weight se mencionan 8 de los 13 métodos ampliamente incluidos. Parece que la práctica de los grandes laboratorios es una palanca potente, y no solo la calidad del artículo en sí.

Un tracker para quien tiene que elegir método

Los autores publican los datos en forma de tracker. Este vincula los fallos de entrenamiento con las implementaciones en los frameworks, y además recoge las normas de contribución de cada proyecto y las propuestas de métodos anteriores.

Para los equipos que entrenan modelos, de aquí se desprenden varias conclusiones. Antes de adoptar un método de un artículo reciente, conviene comprobar si ya está en el framework y en qué estado se encuentra su issue. Que no exista una implementación no indica que el método sea débil, pero sí significa que lo estarás validando en solitario.

A los investigadores que quieran ver sus ideas en estos stacks les conviene plantear el método como un pequeño ajuste de coeficiente, clip o máscara dentro de una función de pérdida existente, y probarlo en modelos de 30B o más. Y los usuarios de los frameworks deberían describir sus fallos en público con más frecuencia: ahora casi no ocurre, y los mantenedores eligen los métodos a ciegas.