Automejora recursiva, explicada a través de un proyecto que realmente la implementa

“La automejora recursiva” es una de esas frases que se usan sobre todo para expresar una sensación. Definida sin mística, es más acotada que eso y más interesante: un sistema que propone su propio siguiente experimento, lo ejecuta y conserva o retira el resultado según una regla fijada de antemano, con los resultados alimentando la siguiente ronda. La recursión no es magia y no es ilimitada — es un bucle con una función de puntuación, y su calidad está determinada por completo por la honestidad con que se aplica esa función de puntuación. RSI-Jev, el proyecto abierto de terceros que construye modelos de decisión de Sistema Uno al estilo Jev, es un caso raro en el que se puede leer el bucle en lugar de discutir sobre él: cada hipótesis, cada brazo fallido y cada versión se publican con sus números, y el repositorio está fechado día por día. El modelo que esta página usa como ejemplo práctico es RSI-Jev v6.0-VL, un modelo de decisión tipado de 4B publicado el 2026-10-06, que está dentro de la última semana. No es el Jev de TypeSafe ni está afiliado a TypeSafe AI — la propia línea de licencia del proyecto dice exactamente eso, y lo que servimos en OrcaRouter es el otro, typesafe/jev-1.13, en nuestro endpoint systemone.

Una aclaración antes de que la palabra «automejora» haga algún trabajo, seguida de una fecha. Esto no es un modelo que se reescriba a sí mismo sin límite, y nada en esta página debería leerse así. El bucle en cuestión reescribe una receta: propone un cambio de entrenamiento, registra lo que espera que haga ese cambio, consume tiempo de GPU y luego conserva el cambio o anota por qué perdió. El modelo es una torre Qwen3.5-4B-Base con cabezas de decisión entrenadas —una arquitectura fija entrenada por un script de entrenamiento fijo, con la búsqueda ocurriendo sobre datos, objetivos y etapas. El bucle ejecuta sus propios experimentos y retira a sus propios campeones. Las personas deciden qué vale la pena medir. Y la fecha: v6.0-VL se publicó el 2026-10-06, y el proyecto ha publicado otra versión desde entonces —la línea avanza aproximadamente a diario, y las cifras de esta página son las adjuntas a la versión aquí nombrada, fechadas allí donde se leyeron. Vale la pena decirlo por adelantado en una página cuyo tema es un bucle que sigue ejecutándose.

Lo que significa el término, dicho sin rodeos

Si reducimos la frase a lo esencial, hay tres partes, y todas son ordinarias. Primera, un espacio de búsqueda: el conjunto de cosas que podrían cambiarse. Segunda, un evaluador: algo que dice si un cambio ayudó. Tercera, un registro: qué se intentó, qué ocurrió y qué se descartó. Un sistema está haciendo automejora recursiva cuando la salida de la ronda N es la entrada de la ronda N+1 en esas tres partes, sin que un humano vuelva a derivar el espacio de búsqueda ni a decidir el umbral cada vez.

Lo que la mayoría de los textos sobre el tema se salta es la segunda parte, y ahí es donde reside toda la cuestión. Un bucle con un puntuador débil optimiza al puntuador. Producirá una línea monótonamente creciente y un sistema que ha aprendido la forma de su propio examen. Ese fallo no requiere malicia ni un error — es lo que ocurre por defecto cuando el mismo número sirve tanto para seleccionar como para reportar. Así que cuando leas una afirmación de que algún sistema se mejora a sí mismo, la pregunta útil nunca es «cuánto mejoró». Es «quién fijó el listón, cuándo y si podría moverse después de ver el resultado».

Las versiones populares de este concepto —las que hoy posicionan para el término— son en su mayoría prospectivas: la entrada de Wikipedia describe un sistema que reescribe su propio código hacia una "explosión de inteligencia", y la cobertura más amplia suele girar en torno a si esa cronología está más cerca o más lejos de lo pronosticado. Ese es un argumento legítimo, y no puede responderse con la evidencia de la que dispone cualquiera en la actualidad. Lo que sí puede responderse es la cuestión más pequeña: si un bucle cerrado del tipo descrito anteriormente puede construirse y obligarse a cumplir sus propias reglas ahora mismo. Para eso, un proyecto con artefactos públicos supera una década de especulación, y de eso trata el resto de esta página.

Cerrado, no meramente iterativo: cinco mecanismos

Un bucle no está cerrado por el hecho de repetirse. Muchos pipelines automatizados se repiten sin llegar a cerrarse nunca, porque un pipeline que puede ajustar su umbral después de ver el resultado hace algo categóricamente distinto de uno que no puede. Las propias reglas de RSI-Jev son inusualmente explícitas sobre la diferencia, y pueden leerse como definiciones más que como un manifiesto. Cinco de ellas hacen la mayor parte del trabajo.

Las predicciones se registran antes de la ejecución. Una hipótesis se anota con el número que espera mover y en qué medida, antes de gastar tiempo de GPU. Una versión que no alcanza su propio umbral se entrega como un fracaso en lugar de reajustarse en silencio. Este es el mecanismo que impide que el bucle se convierta en una máquina para escribir explicaciones post-hoc, y tiene un costo real: el registro contiene entradas cuyo único contenido es que alguien se equivocó en el registro.

Los pisos nulos se miden, no se asumen. El equipo ejecuta brazos demostrablemente idénticos al control —verificados por identidad de objeto antes de cualquier tiempo de GPU— y la dispersión entre esos brazos es el piso de ruido. Una diferencia menor que ese piso no es un resultado, sea cual sea su apariencia. El propio umbral del proyecto lo refleja: en su suite interna el umbral es +0.006, con una desviación estándar por semilla en un solo benchmark de 0.011–0.016, por lo que las diferencias de un solo benchmark por debajo de eso no son hallazgos. La mayor parte del ruido en este negocio se mide, no es estadístico.

Un conjunto reservado se agota una vez que se lee. Cada versión lee el conjunto reservado una vez, así que dos versiones todavía pueden compararse en igualdad de condiciones —y, como leerlo lo agota, cada versión congela la comparación de la siguiente. Merece la pena conservar intacta la propia formulación del proyecto: el conjunto reservado "se aparta del entrenamiento, no se sella frente a la búsqueda". Es una verificación de la memorización, no una garantía de novedad. Y la propia cifra de la suite tiene un agujero que el proyecto publicó: una tarea interna se solapó con varios cientos de filas de entrenamiento, así que a partir de la v6.0-VL la suite se reporta sin ella —0.770— y el 0.764 anterior de la v5.0-VL se reformuló como 0.763 sin ella. Esa reformulación es lo importante. Un número se estaba inflando, se encontró la causa, y la tarjeta de la versión anterior se corrigió en lugar de dejarla como estaba.

Los fracasos se publican, incluidos los que acabaron con el propio campeón del proyecto. Los recuentos principales del repositorio, consultados el 8 de octubre de 2026, van en la misma línea: ocho versiones en trece días y cientos de experimentos documentados con los fracasos incluidos. Un resultado negativo se trata como el producto. La guía de contribución es contundente sobre el porqué: la parte cara de una búsqueda no es ejecutar al ganador, sino ejecutar a los perdedores, así que un negativo bien medido desde fuera elimina una rama y vale más que un pequeño positivo.

La cadena de versiones es el proyecto. Una tarjeta por versión, todas ellas, en la rama principal de forma permanente. Cada tarjeta lleva los números de su propia versión, de modo que la velocidad y la calibración de una versión nunca sobrescriben las de otra. El proyecto declara la razón directamente: esa cadena es la única forma de ver si un bucle de automejora está mejorando. Todo lo demás —la receta, los scripts, el stack fijado— lleva únicamente la versión actual, porque la regla opuesta haría imposible saber qué es lo actual. Un checkpoint publicado lleva su propio código para que las versiones antiguas sigan siendo ejecutables sin ramas antiguas.

Lo que cuesta la disciplina, y lo que aporta

Dos historias del registro son el contrapeso honesto a la palabra «auto-mejora», porque ambas son casos en los que las propias reglas del bucle hicieron el trabajo más lento y mejor al mismo tiempo.

El primero es el bug que hay detrás de v1.0. Encontrarlo requirió siete negativos registrados. Cada uno de los siete era una corrección del lado del optimizador que reducía una inestabilidad de entrenamiento sin eliminarla, porque la causa era un error de precisión que no estaba ni cerca del optimizador —y la solución final fue una línea. Ninguno de los siete merecía publicarse por sí solo. Juntos son lo que hizo que la causa fuera siquiera localizable, y ese es todo el argumento para registrar y conservar negativos: su valor es conjunto, no individual.

Lo segundo es menos halagador y el proyecto lo publica de todos modos, en una nota al pie. Un brazo inicial falló exactamente una salvaguarda —MMLU-Pro quedó 0,026 por debajo del listón frente a un límite de 0,020— y se registró como rechazado. El responsable de la ejecución luego amplió el límite a 0,030, con el argumento de que MMLU-Pro es una salvaguarda contra el olvido más que un objetivo, y el brazo se confirmó con cuatro semillas nuevas y se convirtió en la siguiente versión. El rechazo original se dejó en el registro, con el propio comentario del proyecto de que un listón movido después de ver el resultado es el tipo de cosa que un lector debería poder pillar al proyecto haciéndolo.

Esa nota al pie es el párrafo más útil del repositorio para cualquiera que intente evaluar este tipo de afirmación en condiciones reales. Un umbral que se movió no es prueba de mala fe —el razonamiento dado es defendible, y el umbral ampliado tuvo que superar después cuatro semillas nuevas—. Pero un umbral que se movió en silencio es un bucle que ya no está cerrado, y la diferencia entre ambos radica por completo en si se dejó por escrito. La regla general que el proyecto adoptó después es la que vale la pena llevar a otros sistemas: un casi fallo que falla exactamente una salvaguarda recibe un diagnóstico y una reparación específica en lugar de descartarse; y si la reparación falla, se convierte en un callejón sin salida con un registro.

Con qué frecuencia el bucle está mal: catorce configuraciones, dos conservadas

Este es el número que hay que tener presente. A lo largo de la versión que lee imágenes, el proyecto cuenta con catorce configuraciones de aprendizaje por refuerzo y 63 brazos entrenados por recompensa. Se conservaron dos.

Cada configuración se juzgó contra un control supervisado entrenado con los mismos elementos durante el mismo número de pasos, que es la comparación que hace que el conteo sea significativo — un brazo de RL que supera una línea base que nunca tuvo que igualar no prueba nada. Las pérdidas instructivas, en palabras del propio proyecto:

• RL de acierto binario — la salida de probabilidad colapsó a 0 y 1. Recompensar el acto de acertar en lugar de la honestidad de las probabilidades reportadas empuja una distribución hacia las esquinas, y un modelo de decisión cuya confianza siempre es total es inútil para aquello para lo que sirven los modelos de decisión.

• RL de proper-score, la reconstrucción del objetivo estilo Laya — bien a los 300 pasos, divergió a los 1.500. Estable mientras no hacía gran cosa, e inestable justo cuando empezó a importar.

• RLCR — empató en exactitud, peor calibración bruta. No compró ninguna capacidad y lo pagó en la única propiedad que el modelo existe para proporcionar.

• Bandit RLCD, donde solo se revela el resultado de la opción elegida — no mejor que el entrenamiento supervisado con la misma retroalimentación. El proyecto canceló aquí su propia prueba preregistrada: el brazo tenía que superar al entrenamiento supervisado en al menos dos de cuatro métricas de calibración y ganó una.

El ganador, y la razón por la que ganó, es el hallazgo más transferible de la página. Es una recompensa listwise —calidad de ranking medida sobre el orden de muchos candidatos puntuados por separado, en lugar de tratar a cada uno de forma aislada. El recall de reranking en la primera posición pasó de 0.192 para el modelo supervisado original a 0.308, con victorias y derrotas en una prueba pareada. La explicación del proyecto no es una historia de ajuste de hiperparámetros: un objetivo de entrenamiento por elemento puntúa a cada candidato por sí solo, y ninguna etiqueta única codifica la calidad de un orden entre candidatos. Donde la recompensa decía algo que las etiquetas no pueden expresar, RL superó al entrenamiento supervisado en las mismas filas. Donde no lo hacía, el entrenamiento supervisado lo igualó.

Eso se generaliza a una regla sobre cuándo este tipo de bucle puede encontrar algo en absoluto. Con una etiqueta de oro en mano, la actualización esperada del gradiente de política equivale al gradiente de una pérdida supervisada —la frase del propio proyecto—, así que un «brazo de RL» puntuado contra decisiones etiquetadas es en realidad un brazo de diseño de pérdida. Y los cambios a nivel de pérdida movieron la suite interna como máximo 0.002, mientras que los datos nuevos la movieron 0.13. Leído en conjunto: la palanca del bucle nunca estuvo en el objetivo. Estaba en lo que se medía y en lo que se introducía.

Lo cual es la respuesta honesta a una pregunta que un lector tiene derecho a plantear. Las configuraciones de RL se citan en otros lugares como evidencia sobre la automejora en general; aquí son evidencia sobre un único bucle en tareas de decisión. El resultado listwise es una sola semilla, y el proyecto lo dice: la comparación emparejada de RL frente a aprendizaje supervisado se ejecutó sobre un modelo padre distinto de aquel al que lo aplicó la versión publicada, y esa versión «no tiene un control supervisado emparejado». Un hallazgo con esa salvedad es más valioso que uno sin ella, y por eso la página que estás leyendo no lo generaliza.

Donde se sienta el humano

El proyecto es explícito, y la explicitud es la parte interesante: el bucle ejecuta sus propios experimentos y retira a sus propios campeones, pero no decide qué merece la pena medir, y no se da cuenta por sí solo cuando un número es técnicamente cierto y prácticamente engañoso. Eso lo hacen las personas.

Dos de las reglas del propio proyecto existen porque alguien presentó resistencia. La salvaguarda de MMLU-Pro se amplió en lugar de dejar que se descartara un caso límite. El requisito de semillas ahora escala con el tamaño del efecto en lugar de gastar cuatro semillas en cada diferencia — porque la semilla de confirmación, el único número por el que no se seleccionó un brazo, es la que soporta la carga, y gastar cómputo en diferencias que ya puedes ver no sirve de nada. Una de las versiones de la cadena comenzó como una negativa a eliminar un brazo que había fallado una salvaguarda. El proyecto acredita por su nombre a las personas que enviaron esos comentarios, en los agradecimientos.

Así que «automejora» aquí describe la parte media del bucle, no su totalidad. El bucle es una búsqueda que avanza sin que un humano gire la manivela. El humano sigue en la parte superior del bucle eligiendo el objetivo, y en la parte inferior, leyendo críticamente el resultado —que es precisamente la disposición que impide que el bucle se convierta en una máquina para confirmar sus propias preferencias. Cualquier explicación de la automejora recursiva que omita ese puesto está describiendo un sistema distinto de este, y probablemente uno hipotético.

Lo que los propios números del proyecto no muestran

La disciplina anterior solo merece ser descrita si sus límites se enuncian al mismo tiempo, y el historial de RSI-Jev los enuncia por sí mismo.

• Es un proyecto, un tamaño de modelo a la vez, una semilla. El checkpoint publicado es el de una sola semilla, fijada de antemano como primaria en lugar de elegida para obtener la mejor puntuación. La evidencia de RL es una sola semilla.

• Son tareas de decisión, no de generación: una pregunta de sí/no, de elegir una entre k o de calificar según una rúbrica sobre un documento, un chat o una imagen, respondida en una sola pasada hacia adelante con una probabilidad calibrada por opción. No se genera nada, así que no hay tokens de razonamiento que gastar. Lo que el bucle demuestra aquí es que puede mejorar un evaluador de esa forma.

• Parte de ello no es reproducible solo a partir del repositorio. Los corpus de entrenamiento y los conjuntos de desarrollo de políticas no son públicos, y el proyecto lo dice claramente en la tarjeta de publicación: «las etapas no se pueden volver a ejecutar solo desde este repositorio». Un generador de corpus necesita unos 96 GB de memoria y no se volvió a ejecutar de principio a fin.

• No todo es comprobable en absoluto. La suite interna nunca se mantuvo completamente al margen. De los quince benchmarks, diez aportan datos de entrenamiento de alguna forma, así que ninguno de esos números es zero-shot — el conjunto reservado es la comparación que se mantiene al margen, y es la única.

Y las partes externas tienen su propio tejido cicatricial. Una auditoría posterior a una versión encontró aproximadamente mil elementos de las filas de prueba del kit de referencia público en los corpus de entrenamiento —alrededor del 0,3 % de las filas del kit, y la mayor contribución individual fue de unos pocos cientos de filas provenientes de una sola fuente—. Al volver a puntuar sin ellos, el índice varía como máximo en 0,04. Esa corrección se publicó en la ficha de la siguiente versión en lugar de aplicarse en silencio, bajo la regla que el proyecto enuncia como «sin contaminación, comprobada en lugar de afirmada». Es una regla que les cuesta una cifra, que es el único tipo de regla que vale la pena tener.

Dónde puedes ejecutarlo realmente — y dónde no

Nada de lo que hay aquí es servido por OrcaRouter. Nuestro catálogo no contiene ningún id de RSI-Jev ni una tarjeta de modelo para él, y no habrá ninguna hasta que alguien lo sirva. RSI-Jev se instala desde su propio repositorio y ejecuta su propio servidor, que habla la API de Jev: apuntas un cliente Jev existente hacia él y cambias la URL base. Funciona en Linux, Windows y macOS, en una GPU CUDA, Apple Silicon o una CPU normal.

The one model we do host is the other side of that contract. TypeSafe's Jev 1.13, which we serve as typesafe/jev-1.13, is the commercial decision model whose request and answer shapes RSI-Jev reproduces, and it is reached on our dedicated systemone endpoint rather than through the chat-completions shape. That is the whole relationship, and it is a structural one rather than a quality claim: one is a hosted commercial model on a vendor's endpoint, the other is a checkpoint you download and serve yourself. Nobody has run an independent head-to-head between them, and this page is not going to declare a winner from two different harnesses.

Si lo que quieres es poner un modelo de decisión como este detrás de una aplicación, la cuestión del enrutamiento es independiente de la cuestión del modelo, y es la parte que decide si vale la pena siquiera ejecutar el experimento. OrcaRouter es una sola API para más de 200 modelos con 0 % de recargo — el precio de lista del proveedor se repercute tal cual, de modo que el cambio de precio de un proveedor es tu precio el mismo día — además de conmutación automática por error y un DSL de enrutamiento para componer varios modelos en una sola llamada. Para un modelo de bucle que aún no puedes invocar a través de una API general, eso importa de una manera concreta: significa que los candidatos alternativos con los que lo compararías ya están detrás de una sola clave, y la comparación es un cambio de configuración en lugar de una segunda integración.

La parte que vale la pena conservar

La razón para escribir sobre la auto-mejora recursiva a través de un proyecto como este, en lugar de hacerlo a través del argumento sobre si conduce a algún lugar dramático, es que las reglas del bucle son la parte transferible y la especulación no. Predicciones registradas, pisos nulos medidos, conjuntos reservados ya utilizados, fallos publicados, una cadena de versiones inmutable: nada de eso es una propiedad de una superinteligencia. Son propiedades de un laboratorio que decidió ser verificable, y están disponibles para cualquier equipo que hoy ejecute búsqueda automatizada, a cualquier escala, en cualquier modelo.

Visto así, la afirmación interesante en el registro de RSI-Jev no es la puntuación. Es que el propio registro del bucle dice que estuvo equivocado mucho más a menudo de lo que estuvo acertado —dos recetas conservadas de catorce configuraciones, siete negativos para encontrar un error de una línea, una barra que se movió y quedó anotada— y que el proyecto publicó el registro. Una subida de 38.38 a 46.24 en un índice público en un solo lanzamiento es una curiosidad sin los fallos junto a ella. Los fallos son lo que hace que el número signifique algo.

Lo cual es la postura honesta sobre el término en sí. La cuestión no es si un sistema puede mejorarse a sí mismo. Es si la mejora la mide algo que podría haber dicho que no. Donde esa separación es real y está por escrito, el bucle merece ser leído. Donde no lo es, una línea ascendente es una descripción de un puntuador, no la de un sistema que mejora — y no hay cantidad de recursión que arregle eso.