¿Qué es RSI-Jev? Un bucle de automejora que construye modelos de decisión estilo Jev

RSI-Jev es un proyecto de investigación abierto de terceros que construye modelos de decisión System One al estilo Jev, y el modelo del que trata esta página es su versión 4B, RSI-Jev v6.0-VL, con fecha 2026-10-06. Está escrito por Shanghua Gao (@gasvn), con Sufian (@SufianTA) acreditado en los agradecimientos del repositorio, y no es el Jev de TypeSafe ni está afiliado con TypeSafe AI: la propia línea de licencia del proyecto dice exactamente eso. La idea que subyace es lo bastante acotada como para enunciarla en una frase: haz una pregunta tipada sobre un documento, un chat o una imagen —sí/no, elegir uno de k, evaluar según una rúbrica— y una única pasada hacia adelante devuelve una probabilidad calibrada para cada opción. No se genera nada, así que no hay tokens de razonamiento que gastar, y no se gasta ninguno. v6.0-VL no es la primera versión del proyecto; es la séptima en doce días, lo cual es lo más importante que hay que entender sobre ella, porque la información útil aquí está en la forma de la línea más que en cualquier checkpoint concreto.

Hay que decir una cosa antes de cualquier cifra, porque determina la fecha de todas ellas. v6.0-VL encabezó la lista durante exactamente un día. El 2026-10-07 a las 07:56 UTC —esta mañana— el proyecto publicó RSI-Jev v6.1-VL, que es el promedio de v6.0-VL, con un peso de 0,5 para cada uno, con un segundo ajuste fino del mismo Qwen3.5-4B-Base entrenado con otros datos, y que obtiene 50,98 en el kit Decision Index 0.3 del proyecto frente a los 46,23 de v6.0-VL en ese mismo kit. No se entrenó nada después del promedio. Su calibración es peor que la de v6.0-VL, y su propia ficha lo dice. Esa publicación es real y actual; esta página no trata sobre ella. Todas las cifras que aparecen a continuación se leen del registro de publicación de v6.0-VL, fechado el 2026-10-06, y cuando un recuento ha cambiado desde entonces —el recuento de publicaciones, el recuento de experimentos—, esta página ofrece tanto la cifra tal como estaba para v6.0-VL como la cifra tal como se lee hoy.

También vale la pena poner desde el principio lo que RSI-Jev no es, porque dos de las tres suposiciones obvias son incorrectas. No es un producto alojado al que puedas llamar hoy a través de una API general, y no lo sirve OrcaRouter: nuestro catálogo no incluye ningún id rsi-jev, ningún id shgao ni ninguna ficha de modelo para él. Lo único que sí tenemos es el modelo cuyo contrato HTTP copia este proyecto: el Jev comercial de TypeSafe, que servimos como typesafe/jev-1.13 en el endpoint systemone. De esos dos, a uno lo llamas y el otro lo descargas y lo sirves tú mismo. Todo lo que sigue proviene del propio repositorio del proyecto, sus tarjetas de lanzamiento y su documentación de servicio, leídos el 2026-10-07, y cuando una cifra es del propio proyecto en lugar de una medición externa, esta página indica de quién es.

Lo que la cosa realmente hace

El proyecto se describe a sí mismo en una línea como "un sistema de investigación que se mejora a sí mismo de forma recursiva y que construye modelos System One al estilo Jev", y los artefactos que produce son decisores en lugar de generadores. Le entregas un estado —un documento, una transcripción de chat, una transacción y, en las versiones con visión, hasta cuatro imágenes— y una o más preguntas tipadas con criterios con nombre. Devuelve, para cada pregunta, una probabilidad para cada opción. Tres tipos de preguntas cubren el espacio, y son los que define la API de TypeSafe:

• noul — un juicio de verdadero/falso, devuelto como una única probabilidad, sin distribución y sin valor de confianza, coincidiendo exactamente con la forma de la respuesta de la referencia.

• elección — elige una de un conjunto de opciones etiquetadas, devuelta con la distribución de probabilidad completa y un estadístico de confianza.

• puntuación — puntúa según una rúbrica ordenada, devuelto como un índice basado en cero ponderado por probabilidad dentro de los niveles, además de la leyenda y la distribución.

Como no hay paso de generación, no hay una segunda llamada al modelo ni muestreo. Una decisión sobre un documento que el modelo ya ha leído es, por construcción, una operación barata, y la propia frase del proyecto para ese coste —«unos 10 ms»— pertenece a su era 2B, no a la versión actual; las cifras medidas para v6.0-VL se dan más abajo.

Dos hechos sobre la titularidad importan más que cualquier otra cosa en esta página. RSI-Jev no es obra de TypeSafe y TypeSafe no lo ha respaldado. La línea de licencia, citada íntegramente: "Código: MIT. Pesos: Apache-2.0, siguiendo el modelo base; algunas fuentes de entrenamiento de imágenes son no comerciales, indicadas en la ficha de cada modelo. Sin afiliación con TypeSafe AI." Y la relación va en una sola dirección: el proyecto copia deliberadamente el formato de transmisión de Jev, y lo dice, porque el objetivo es un servidor compatible. "Estilo Jev" es la expresión que usa el propio proyecto para el tipo de modelo que construye. El Jev de TypeSafe es un modelo distinto, cerrado y comercial, y los dos no son lo mismo bajo un nombre más corto.

Dentro del modelo actual: una torre Qwen de 4B con tres salidas

RSI-JQ5-V6.0-VL es una torre Q3.5-4B con la torre ajustada y una cabeza de decisión entrenada encima. Esa es toda la arquitectura — no hay mezcla de expertos, ni un segundo modelo. Ejecuta el modelo base completo, que es, y no el 4B base: 3.2B están en las 32 capas transformer, 0.6B en la torre de visión, 0.2B en el principal, y 0.1B en las cabezas de salida temprana. El modelo publicado es autocontenido y de 8GB en bf16.

Se conectan tres cabezas de decisión, en las capas 16, 20 y 32 de la base, y son el mecanismo detrás de todo aquello por lo que se conoce la versión actual. Una cuarta salida en la capa 12 se construyó, se midió y se descartó —«La salida de la capa 12 perdió frente a la cascada de la 16 en todas las comparaciones y no está en el paquete»—, así que se entregan tres y cuatro no. Las salidas leen una copia desacoplada de su capa, un detalle que el proyecto descubrió a las malas: reajustar las cabezas en un tronco cuyas salidas se habían conectado durante el entrenamiento no había recuperado la precisión de las capas profundas, así que desacoplarlas fue lo que restauró la profundidad.

Un número aquí es la manera más fácil de malinterpretar el proyecto. Todo hasta v3.0 inclusive era un modelo 2B sobre Qwen3.5-2B-Base, y eso es el linaje, no el modelo actual. v4.0-VL era 2B, v5.0-VL redujo un modelo a 3B, y v6.0-VL es 4B. Una página que se refiere al modelo actual RSI-Jev como 2B está desactualizada por tres versiones.

El bucle es el proyecto en sí.

Los modelos son la salida; lo que se está construyendo es el proceso. El proyecto afirma que "el bucle que ejecuta la investigación es la próxima versión de AutoScientists", el sistema autoorganizado de equipos de agentes publicado por el laboratorio de Zitnik en Harvard, y funciona tal como implica esa frase. Los agentes de IA proponen hipótesis, registran sus predicciones antes de gastar tiempo de GPU, ejecutan los experimentos y retiran a sus propios campeones cuando la evidencia así lo indica. Dos recuentos lo concretan. Leído el 7 de octubre de 2026, el titular del repositorio anuncia ocho lanzamientos en trece días, de v1.0 a v6.1-VL; para el propio lanzamiento de v6.0-VL, el 6 de octubre de 2026, indicaba siete lanzamientos en doce días, cada uno entrenado, evaluado y documentado por el bucle. Y el recuento de experimentos, que era de 471 cuando se publicó el lanzamiento de esta página, hoy marca 496 —todos documentados, incluidos los fallos. Ambos recuentos son del propio proyecto, y ambos cambian.

La disciplina es lo que hace que esos números signifiquen algo, y el proyecto la expone sin rodeos. Los pisos nulos se miden en lugar de asumirse —brazos demostrablemente idénticos al control, verificados por identidad de objeto antes de cualquier tiempo de GPU, de modo que la dispersión entre ellos es el piso de ruido y una diferencia menor que esa dispersión no es un resultado. Las predicciones se registran antes de la ejecución, de modo que una versión que no alcanza su propio umbral se publica como un fracaso en lugar de ser reelaborada en silencio. Los artefactos se verifican: un checkpoint se recarga desde el disco y se vuelve a puntuar, y se publica solo si reproduce las predicciones por pregunta de su ejecución de entrenamiento, lo cual ambos checkpoints v1.0 logran con 1.0000. La contaminación se «comprueba en lugar de afirmarse». Y los fracasos se publican, incluidos los que acabaron con el propio campeón del proyecto.

Lo que es una contribución, según las propias palabras del proyecto en su guía de contribución: "Una contribución aquí suele ser una medición, no un parche". El registro de versiones publicadas se mantiene como una cadena en lugar de como una instantánea —"versions/ guarda una ficha por versión, todas ellas, en main para siempre… Esa cadena ES el proyecto"—, y por eso los números de una versión antigua pueden contrastarse con lo que el proyecto dice sobre ellos más adelante, y por eso la corrección que se comenta a continuación es visible en lugar de silenciosa.

Lo que cambió v6.0-VL: gasta profundidad en lugar de tokens

El mecanismo de la versión actual es una configuración llamada esfuerzo, y controla algo inusual: cuántas capas del modelo puede usar una solicitud. Como las cabezas se sitúan a tres profundidades, una pregunta fácil puede responderse en la capa 16 y una pregunta difícil puede recorrer las 32. bajo se detiene en la capa 16, medio en la 20, alto en la 32, y automático responde en la primera salida cuya probabilidad calibrada supera el umbral de esa salida. Latencia mediana por solicitud en la muestra Decision Index, medida en una H200 en bf16: 23 ms en el modo bajo, 27 ms en el modo medio, 40 ms en el modo alto, y 40 ms para el valor predeterminado sin establecer. Estas son mediciones propias del proyecto en su propio hardware y no deben mezclarse con los números GB10 de la documentación de serving, que son de una máquina diferente.

El comportamiento medido de auto es la parte interesante: en el conjunto de quince benchmarks del proyecto, el 20 % de las preguntas se detiene en la capa 16, el 46 % en la capa 20 y el 34 % llega hasta la 32, lo que promedia 23,3 de 32 capas. Un único umbral fijo promedia 20,9, y detenerse de más es lo que se consigue con un único umbral. auto no es un compromiso con la calidad, algo que merece la pena señalar porque eso es, por lo general, lo que es un ajuste adaptativo: obtiene la mejor fila del conjunto de cualquier ajuste (0,771 frente a 0,770 del predeterminado), la mejor fila de MMLU-Pro (0,444 frente a 0,440) y la mejor calibración final (ECE 0,024 frente a 0,036). El único lugar donde high gana es en el conjunto reservado, 0,702 frente al auto 0,696. Algunas tareas empeoran de forma medible con la profundidad —BANKING77 en 0,035, el emparejamiento de pies de foto de New Yorker en 0,060—, y por eso el nivel de esfuerzo es una elección que hace quien llama en lugar de una regla que impone el servidor.

El resultado que convirtió esto en un lanzamiento y no en un experimento está en el Decision Index público 0.2.1 del proyecto, donde la puntuación pasó de 38,38 para v5.0-VL a 46,24 para v6.0-VL en un solo lanzamiento. En la tabla pública con fecha 2026-09-28, esa es la puntuación más alta entre los modelos de 4B y cualquier modelo más pequeño, y el 14.º de 71 en total; la siguiente entrada de ese tamaño es JPT-4B con 43,04. Las versiones anteriores de esta línea son parte del linaje y no son el modelo actual: v5.0-VL (2026-10-02) recortó el modelo a las primeras 20 de 32 capas e hizo que dijera «unknown» cuando una pregunta no tiene respuesta; v4.0-VL (2026-10-01) fue la primera que lee imágenes; y v3.0 (2026-09-28) es el lanzamiento en el que el aprendizaje por refuerzo ayudó por primera vez, mediante una recompensa de ranking por listas —NDCG@5 sobre 16 candidatos— que elevó el R@1 de reranking de 0,192 a 0,308 frente a su modelo supervisado padre, a un costo de 0,0028 en la suite. Ahí es donde comienza la historia de RL del proyecto, y ya está tres lanzamientos atrás.

Las cifras, con las salvedades que las acompañan

El titular del Decision Index 0.2.1 para v6.0-VL es 46.24, en una ejecución completa en la que se respondieron las 150.759 solicitudes de la suite: conocimiento 28.8, lenguaje 46.2, recuperación 55.5, herramientas 65.8, artes 37.1. La suite de quince benchmarks marca 0.770, el conjunto reservado 0.698, MMLU-Pro 0.440 y el ECE final 0.024 con auto. Dos salvedades deben ir de la mano de esas cifras, porque sin ellas los números engañan.

Lo primero es un corte en la suite. La tarea interna de la suite open_jev_ood se superpuso con 579 filas de entrenamiento, por lo que su número se infló en una cantidad desconocida; a partir de v6.0-VL, el proyecto reporta la suite sin ella, en 0,770. El 0,764 de v5.0-VL se obtuvo con ella, y la tarjeta de v6.0-VL reformula esa versión como 0,763 sin ella. Las dos cifras no son comparables, y si las comparas, tienes que usar el 0,763 reformulado y decir que eso es lo que estás haciendo. El conjunto de validación, MMLU-Pro y BBH no tienen solapamiento y no se ven afectados. Una auditoría relacionada encontró alrededor de 1.000 elementos de las filas de prueba del kit de Decision Index en los corpus de entrenamiento — ANLI 274, RouterBench-GSM8K 90, ARC 5, y texto de consulta de BRIGHT/ToolRet sin etiquetas, aproximadamente el 0,3 % de las filas del kit — y volver a puntuar sin ellos mueve el índice como máximo 0,04 en la muestra del proyecto. Eso es una corrección al registro de v5.0-VL, publicada en la tarjeta de v6.0-VL, y es la propia regla de contaminación del proyecto la que le cuesta una cifra.

Lo segundo es de quién es este benchmark. El Decision Index es el tablero público de RSI-Jev, no un veredicto de terceros, y 46.24 es una puntuación en ese tablero. No es comparable con nada que TypeSafe haya publicado, porque las dos cifras no proceden del mismo entorno de pruebas, y nadie ha realizado una comparación directa e independiente entre RSI-Jev y Jev 1.13. Lo que se puede decir es estructural más que numérico: uno es un modelo comercial alojado en el endpoint de un proveedor, y el otro es un checkpoint que descargas y sirves tú mismo.

Dos piezas de contexto adicionales van con el conjunto. El proyecto dice explícitamente que «diez de los quince benchmarks aportan datos de entrenamiento de alguna forma, así que ninguno de estos números es zero-shot»; el conjunto reservado es la comparación que se mantiene reservada, y aun así «está apartado del entrenamiento, no sellado frente a la búsqueda». Y v6.0-VL ejecutó 97 brazos en su propia línea —93 si se dejan fuera las cuatro auditorías de datos—, que es la escala de búsqueda que produjo un salto de 7,86 puntos en ese índice.

Habla el formato de transmisión de Jev, con cuatro diferencias que el llamador debe conocer.

La superficie de compatibilidad es la razón por la que este proyecto existe con la forma que tiene. La misma forma de solicitud ({state, model, questions}), los mismos tres tipos de pregunta con las mismas formas de criterios, las mismas formas de respuesta, las mismas de 1 a 64 preguntas por solicitud, los mismos sobres de error y la misma estadística de confianza: el pico, (K · p_max − 1) / (K − 1), acotado a 0..1. La propia afirmación del proyecto sobre esa superficie es que «todo lo escrito para Jev funciona con esto sin cambios», y el servidor documenta qué se copia y qué no, lo cual es más útil que la afirmación.

• El prompt y la lectura son suyos. RSI-Jev es un modelo base con una cabeza de lectura entrenada, servido con el codificador con el que fue entrenado, porque usar el prompt de la referencia "sacaría al modelo de su distribución de entrenamiento". El contrato de conexión es la superficie de compatibilidad; el prompt no lo es.

• Las claves de opción son visibles para el modelo. La referencia las oculta, por lo que renombrar una clave demostrablemente no puede cambiar una respuesta allí. Aquí sí puede, y el servidor lo reporta honestamente como option_keys_visible_to_model: true.

• Los criterios deben ser cadenas o null. Un criterio estructurado —un objeto— se rechaza con un 422, porque ninguna versión se entrenó con uno. Este es el único caso en el que una solicitud que la referencia acepta no se ejecutará aquí.

• No se recorta nada. El servicio admite hasta 32.768 tokens de texto más el presupuesto de imágenes, y una solicitud más larga se rechaza con un 422 que lo indica en lugar de truncarse silenciosamente. La cifra de 2048 tokens que aparece en las tarjetas antiguas es la longitud con la que los modelos fueron entrenados, no un límite del servicio, y describir un truncamiento silencioso a 2048 como comportamiento actual es incorrecto.

Las cifras de opciones difieren por un amplio margen a favor del serving: hasta 5.120 opciones por pregunta (RSIJEV_MAX_ANSWERS), frente a 160 en entrenamiento y 64 admitidas por la referencia. No cites 160 como el límite máximo del serving. Una cosa es nueva en las respuestas de v6.0-VL en lugar de heredada: cada respuesta informa qué capa respondió, en usage.depth, junto con la confianza calibrada, de modo que una decisión adaptativa puede auditarse a posteriori. Las imágenes son una extensión que la referencia no tiene — de una a cuatro por solicitud, como URL de datos en base64, y el estado se refiere a cada una mediante un marcador literal.

Donde un lector realmente puede ejecutarlo, y donde no puede

RSI-Jev es un. El proyecto incluye su propio servidor, que habla esa API compatible con Jev, y la ruta documentada es una instalación con pip desde el repositorio seguida de su comando serve con el punto de control y un ajuste de esfuerzo. Los pesos están en Hugging Face bajo la organización shgao, publicados bajo Apache-2.0 siguiendo el modelo base, con una pregunta abierta que el propio proyecto plantea: cinco de las fuentes de entrenamiento de imágenes son no comerciales o solo para investigación, y "si los pesos entrenados con datos no comerciales heredan esos términos no está resuelto". El código es MIT.

El hardware no es la limitación. El proyecto se desarrolla en una HP ZGX Nano, una máquina NVIDIA GB10 que atribuye a HP y NVIDIA, y el servidor se ejecuta en cualquier GPU CUDA, en Apple Silicon o en una CPU normal —la última de las cuales la documentación estima en 733 ms para una sola pregunta en la propia CPU Arm de la GB10, así que es usable más que rápida.

Lo que no hace es aparecer en un catálogo general de modelos, y aquí es donde tenemos que ser precisos sobre nuestra propia posición. RSI-Jev no está en OrcaRouter y no hay ninguna ficha de modelo a la que pueda enrutar. Lo que servimos es el Jev comercial de TypeSafe, typesafe/jev-1.13, en el endpoint dedicado systemone, al que se llega con un POST a /v1/systemone en lugar de la forma chat-completions de OpenAI — las mismas formas de solicitud y respuesta que implementa este proyecto, procedentes del modelo cuyo contrato copia. Esa es toda la relación: los dos hablan el mismo protocolo, nosotros servimos uno de ellos y tú ejecutas el otro por tu cuenta. Si ya tienes una clave con nosotros, la forma de llamada de Jev 1.13 es una ruta de primera clase en una API para más de 200 modelos con 0% de recargo (el precio de lista del proveedor se pasa tal cual, así que las rebajas de precio del proveedor están activas aquí el mismo día), lo cual importa para la comparación de una manera muy concreta. Una página como esta es barata de aprovechar si puedes probar primero el contrato comercial y solo después decidir si ejecutar tú mismo un checkpoint abierto de 4B merece el trabajo operativo.

Cómo leer RSI-Jev el 2026-10-07

Las debilidades que publica el proyecto son tan específicas como sus resultados, y las fechas importan. Las pruebas externas de v2.1 encontraron que el modelo se inclina por la opción más grave o costosa en elecciones ordenadas y puntuaciones de rúbrica, rara vez elige «desconocido» cuando el documento no puede responder, y responde de forma inconsistente a una pregunta y a su negación. Las versiones posteriores dirigieron los datos al caso «desconocido» —KoBBQ unknown-when-ambiguous alcanzó 0,891 en v4.0-VL, 0,932 en v5.0-VL y 0,918 / 0,939 en v6.0-VL—, y la ficha de v6.0-VL es sincera al afirmar que las mejoras vinieron de los datos y no de la profundidad, y que el 10 % de las preguntas que irían a la capa 32 y se detendrían en la 16 o la 20 son donde la política de profundidad todavía está adivinando. El reranking tiene aún más camino por recorrer: el propio orden de recuperación de hippo-memory obtiene 0,484 R@1 y sigue por delante del 0,308 que el modelo alcanzó en v3.0, una cifra que el proyecto no ha afirmado haber cerrado desde entonces. La evidencia de RL es una sola semilla, y v3.0 «en sí misma no tiene un control SFT emparejado». Los corpus de entrenamiento y los conjuntos de desarrollo de la política no son públicos, por lo que las etapas no pueden volver a ejecutarse solo desde el repositorio, y el generador del corpus de reranking —unos 96 GB de memoria— no se volvió a ejecutar de principio a fin.

Tracción, leída el mismo día: 73 estrellas, 5 forks, 0 issues abiertas, 7 releases de GitHub. Esos números cambian a diario, y un repositorio de tres semanas no es un proyecto consolidado, cualquiera sea su cadencia de lanzamientos. El resumen honesto es que RSI-Jev es uno de los esfuerzos de investigación más legibles en esta esquina del campo —una cadena de lanzamientos fechados, medidos y a veces perdedores, con la búsqueda publicada junto a las puntuaciones— y uno de los menos verificados de forma independiente, ya que casi todos los números de esta página son suyos y ninguna parte externa lo ha comparado con el modelo comercial con el que es compatible.

Lo que hay que observar no es la próxima versión, porque habrá una en cuestión de días a este ritmo; es si algo fuera del proyecto empieza a medir. Las dos cosas que cambiarían el panorama son una ejecución de benchmark independiente sobre los checkpoints publicados, y una comparación de modelos de decisión que haga pasar tanto al 4B abierto como al modelo alojado de TypeSafe por un mismo arnés. Ninguna de las dos existe hoy. Hasta que una exista, la forma útil de leer una puntuación como 46.24 es como una afirmación bien documentada de un proyecto que registra sus predicciones de antemano y publica los brazos que fallaron —lo cual es un rastro de evidencia más sólido que el de la mayoría, y aun así no es un resultado de terceros.