NUS publica Jeva-4B: la opción «ninguna adecuada» y la caché entran en la arquitectura de decisión
Según New Zhiyuan, el xML Lab de la Universidad Nacional de Singapur propone Jeva, que usa Qwen3.5-4B como backbone más un bloque de decisión para emitir directamente una elección, null o una puntuación; el artículo reporta cero tasa de inversión de orden, 69,88% de exactitud con 2048 candidatos, y los pesos ya publicados en Hugging Face.
Qué ha cambiado
Según un reportaje de New Zhiyuan del 26 de octubre de 2026 (fecha correspondiente a la marca de tiempo 1792987620000 del original), el xML Lab de la Universidad Nacional de Singapur publicó un artículo y código que proponen la arquitectura Jeva para tareas de decisión, y liberaron el modelo Jeva-4B. El reportaje indica que el modelo usa Qwen3.5-4B como backbone, más un bloque de decisión ligero: un codificador compartido representa por separado la petición y las opciones candidatas, y el bloque de decisión lee todo el conjunto de candidatos y solo actualiza el estado de la petición, de modo que la representación de las opciones puede cachearse y reutilizarse, mientras que el juicio actual se recalcula en cada ocasión. El reportaje enumera cuatro objetivos de diseño: distinguir «cuál candidato es mejor entre ellos» de «si existe alguna respuesta aceptable en todo el grupo», estimando esto último por separado con una probabilidad de cobertura y permitiendo emitir null; agregar de forma simétrica sobre el conjunto de candidatos, para que la probabilidad siga a la identidad del candidato y no a su posición en la lista; aplicar la misma regla de puntuación a cada candidato, y así procesar directamente el conjunto completo en lugar de hacer eliminaciones en varias rondas; y cachear la representación semántica de las opciones y sus proyecciones por capa, reutilizándolas cuando el conjunto de candidatos se recombina. Un mismo cómputo soporta tres tipos de salida: Choice, Noul (probabilidad de que una proposición sea verdadera) y Score. Los resultados experimentales citados en el reportaje provienen todos del artículo: sobre 3.080 peticiones construidas a partir de BANKING77 (16 candidatos por petición, con 588 casos sin respuesta), el AUROC de detección de null fue 98,66%, frente a 93,61% de KEV-BF16, 84,27% de InternDecision-4B y 79,44% de JevK5; en 600 muestras Choice se probó el orden original, el inverso y hasta tres permutaciones aleatorias, y la exactitud de Jeva en el orden original y la de «responder bien en todos los órdenes probados» fueron ambas 76,67%, sin que se observara inversión de decisión, mientras que los controles mostraron tasas de inversión de 17,00%, 22,67% y 26,17%; en configuraciones de ToolRet con 32 a 2.048 candidatos, con 2.048 candidatos la exactitud fue 69,88% y la latencia mediana por petición en una sola H200 fue 12,04 segundos, frente a 67,47% y unos 28,35 segundos de JevK5; fijando 83 preguntas y ampliando los candidatos de 32 a 2.048, Jeva acertó 58 de esas preguntas en todas las escalas, JevK5 acertó 48 y CLM 7; en el experimento de documentos largos MLDR, cuando todos los candidatos estaban en caché la latencia mediana por petición bajó de unos 2,10 segundos a 75,1 milisegundos, y el reportaje afirma que no se observaron cambios de decisión bajo distintas condiciones de caché. Todas estas cifras son reportadas por el artículo y no han sido reproducidas de forma independiente en este texto.
Impacto para desarrolladores
Para los desarrolladores, Jeva no propone otro modelo de chat general, sino una forma que acopla «ordenar + rechazar + cachear» dentro de la ruta de inferencia, lo que cambia el diseño de integración de varios tipos de sistemas. Primero, cambia el contrato de salida: el conjunto de candidatos es la entrada de una petición y el modelo devuelve una distribución o puntuaciones con null, no un texto que haya que volver a parsear. Adaptar una cadena de prompts actual del tipo «haz que el modelo emita JSON y elija uno» a este tipo de modelo exige definir en la capa de servicio los ID de candidatos, el umbral de probabilidad de cobertura y el comportamiento de degradación ante null, y los registros deben guardar también el conjunto completo de candidatos de esa petición; de lo contrario, después no se podrá distinguir si un rechazo se debió a candidatos inadecuados o a un fallo del modelo. Segundo, la caché baja de la capa de prompts a la capa de arquitectura: el reportaje dice que lo que se cachea es la representación de las opciones, no la respuesta, lo que tiene sentido directo para escenarios como cláusulas de políticas, bibliotecas de documentos largos o criterios de puntuación fijos, donde «los candidatos son relativamente estables y las preguntas cambian continuamente», pero implica que la clave de caché debe vincularse a la versión del modelo, al tipo de decisión y a la configuración de codificación; si cambia el modelo o la configuración de codificación, la caché antigua debe invalidarse. Tercero, el tamaño del conjunto de candidatos ya no necesita controlarse mediante eliminaciones en varias rondas: el reportaje indica que 2.048 candidatos todavía se comparan en la misma cabeza de decisión, lo que simplifica el flujo de reordenamiento posterior a la recuperación, pero también vincula directamente la latencia al número y la longitud de los candidatos; la latencia mediana de 12,04 segundos muestra que los conjuntos grandes de candidatos siguen siendo tareas offline o asíncronas, no llamadas interactivas. Cabe señalar que la información sobre los nombres de los modelos de control citados en el reportaje (como Jev-1.13.0, JevK5 y CLM) y sobre la configuración de las líneas base es limitada; los lectores no deberían extrapolar estas cifras comparativas a su propia distribución de datos ni a sus conjuntos de candidatos de negocio en chino.
Integración y evaluación
Lo siguiente son recomendaciones y análisis condicionales, no hechos del reportaje. Decisión uno: si sustituir la «selección generativa» actual por una interfaz de cabeza de decisión depende de si tus candidatos son enumerables y de si el rechazo debe ser explícito. Si en el negocio existe realmente el caso de «ningún candidato del grupo sirve» (por ejemplo, asignación de tickets o enrutamiento de intenciones), el diseño con reconocimiento de null del reportaje merece una validación aparte: construye un lote de peticiones de tu distribución real con «ningún candidato adecuado», mézclalas con peticiones con respuesta, barre el umbral y registra el AUROC y la tasa de recuperación con una tasa fija de falsos rechazos (por ejemplo, 5%); solo si esta métrica es claramente mejor que la solución actual basada en prompts vale la pena asumir el cambio de interfaz. Si tus candidatos siempre tienen una respuesta correcta, el beneficio de esta capacidad es limitado y la prioridad del cambio debería bajar. Decisión dos: adoptar o no la caché de opciones depende del patrón de reutilización de la biblioteca de candidatos. Primero analiza un lote de peticiones en línea y calcula la proporción de solapamiento entre conjuntos de candidatos (el ejemplo del reportaje son solapamientos progresivos como ABC, BCD, ACD); si el solapamiento es alto y los textos de los candidatos son largos, puedes medir, siguiendo la idea del reportaje, la diferencia de latencia por petición entre el caso de acierto total en caché y el de cero aciertos; además, debes verificar que la decisión de una misma petición sea consistente antes y después de un acierto de caché, porque el reportaje solo afirma que en sus experimentos no se observaron cambios de decisión, lo que no garantiza equivalencia en tus datos. Si los candidatos son casi siempre nuevos, la complejidad de la capa de caché podría superar el beneficio. Decisión tres: el límite superior del tamaño de candidatos debe fijarse según el presupuesto de latencia y no solo según la exactitud. El reportaje da con 2.048 candidatos una exactitud de 69,88% y una latencia mediana de 12,04 segundos, y ambas cifras deben mirarse juntas: si tu escenario exige respuesta en segundos, tendrás que medir la curva de exactitud con conjuntos de candidatos más pequeños, encontrar el punto de inflexión en el que la exactitud empieza a caer y decidir entonces si amplías los candidatos o mantienes el recorte actual de recuperación. Al evaluar, fija las preguntas y aumenta los candidatos gradualmente (el enfoque del reportaje de usar 83 preguntas y pasar de 32 a 2.048 puede reutilizarse directamente) y registra la proporción de «aciertos en todas las escalas», que expone mejor la estabilidad que una exactitud puntual. Decisión cuatro: la robustez al orden debe ser un elemento de regresión fijo antes del despliegue. Siguiendo el método del reportaje, prueba con el mismo lote de muestras el orden original, el inverso y varias permutaciones aleatorias, alinea los resultados por identidad del candidato y no por posición, y registra la tasa de inversión. En escenarios de cumplimiento, riesgo o puntuación, la tasa de inversión es una métrica a la que hay que prestar más atención que a la exactitud media.
Límites y cuestiones pendientes
Todas las cifras experimentales de este artículo provienen de los resultados del artículo tal como los relata New Zhiyuan, no han sido reproducidas de forma independiente, y la configuración y los detalles de entrenamiento de los modelos de control están incompletos en el reportaje, por lo que la comparación entre modelos debe hacerse con cautela. El reportaje no especifica los términos de licencia concretos bajo los que se publican los pesos de Jeva-4B en Hugging Face; que los pesos se puedan descargar no equivale a que se puedan usar comercialmente o redistribuir, y antes de desplegar hay que verificar por cuenta propia la model card y el texto original de la licencia. El reportaje tampoco ofrece información sobre servicio de API, precios o disponibilidad alojada; si existe alguna forma de invocación, debe regirse por lo que indique el emisor. Además, los experimentos del reportaje se centran en tareas en inglés como BANKING77, ToolRet y MLDR, y el rendimiento en conjuntos de candidatos en chino, terminología sectorial y documentos largos es desconocido. Cabe señalar en particular que la versión Jeva-4B no está actualmente en el catálogo de modelos de KimiSeek; en KimiSeek no existe una entrada que corresponda exactamente a esta versión, y cualquier afirmación sobre su disponibilidad vía API se refiere solo al emisor y no a este sitio; si necesitas realizar tareas de decisión similares en KimiSeek, deberás evaluar por separado los modelos ya listados en este sitio y guiarte por la página de precios.