System One: Jev, Strands Decider, Laya y los modelos que deciden en vez de hablar

Hace unas semanas apareció una categoría de modelos que no escriben: deciden. Les das un texto, una pregunta y unas opciones, y devuelven una probabilidad para cada opción, en milisegundos y sin una sola palabra de más. TypeSafe lanzó Jev el 15 de septiembre de 2026 y en cuatro semanas ya había una veintena de alternativas: Strands Decider de AWS, Laya de Convai, Clef de Cloudflare, pplx-decider de Perplexity y muchos más.

Este tema es una clase completa sobre ellos. No pretende venderte ninguno. Pretende que, al terminar, puedas explicar con tus palabras qué son, cómo leen una pregunta, cómo se entrenan, por qué su confianza es (o no es) fiable y cuándo conviene usarlos. Está pensado para ingenieras e ingenieros de IA: hay fórmulas, números reales y código, pero cada idea llega primero con una imagen.

La idea en una imagen: el columnista y el árbitro

Imagina que necesitas saber a qué equipo enviar un mensaje de soporte: “¡Mis pagos llevan tres días fallando!”. Un LLM se comporta como un columnista: le preguntas y escribe un párrafo. Puede ser brillante, pero tu programa necesita una etiqueta, no un párrafo, así que ahora tienes que parsear lo que escribió, validar que no se salió del formato y hacerlo esperar mientras redacta palabra por palabra.

Un modelo de decisión se comporta como un árbitro con tarjetas: solo puede levantar una de las tarjetas que le diste (billing, sales, retail) y, al levantarla, muestra además un marcador con cuánta seguridad tiene en cada una. No puede improvisar una cuarta tarjeta. No puede escribir otra cosa.

TypeSafe bautizó a esta clase System One, en referencia a la distinción de Daniel Kahneman entre el pensamiento rápido e intuitivo (Sistema 1) y el lento y deliberado (Sistema 2). El nombre conviene, con una advertencia que ellos mismos reconocen: lo rápido también puede equivocarse. Lo interesante no es que siempre acierte, sino que te diga cuánto cree acertar y que lo haga a bajo costo, de modo que puedas ponerlo en mitad de un flujo de software como un if “difuso”.

El contrato: estado, preguntas y tres tipos de respuesta

Aunque las arquitecturas difieren, casi todos usan el mismo contrato, el de Jev, que se volvió un estándar de facto: tanto el servidor de Strands Decider como el de Laya exponen POST /v1/systemone con la misma forma. Entra un estado (texto, JSON o una lista de mensajes) y un diccionario de preguntas tipadas:

{
  "state": "Help! My payouts have been failing for 3 days!",
  "questions": {
    "team":    { "type": "choice", "instructions": "Which team should handle this?",
                 "criteria": { "billing": "payments, payouts", "sales": "pricing", "retail": "stores" } },
    "urgent":  { "type": "noul",   "instructions": "Does this convey urgency?" },
    "anger":   { "type": "score",  "instructions": "How frustrated is the writer?",
                 "criteria": ["calm", "frustrated", "depressed"] }
  }
}

Hay exactamente tres tipos de pregunta, y todos son, por dentro, “elegir entre opciones con probabilidad”:

Los números de la tabla son la salida real del CLI de Strands Decider para esa frase. Observa el score: el modelo no dice “frustrado” sino “1.03 en una escala de 0 a 2”, el promedio ponderado \sum_i i\,p_i. La diferencia entre choice y score es el orden: equivocarse por un nivel no es lo mismo que equivocarse por cuatro, y los modelos lo tienen en cuenta al entrenarse.

Dos propiedades prácticas

• Las preguntas son independientes y se responden en paralelo. Jev lo documenta explícitamente: si una pregunta depende de la respuesta de otra, necesitas dos llamadas en secuencia. En Strands, el texto se lee una vez y cada pregunta añade solo sus propios tokens, así que preguntar muchas cosas sobre el mismo texto es casi gratis.
• Las opciones las defines tú, en cada llamada. No hay un conjunto fijo de etiquetas “horneado” en los pesos. Puedes cambiar las categorías mañana sin reentrenar (con límites: Jev admite hasta 255 opciones, y Laya empeora cuando son muchas, como veremos).

Confianza: un número, tres definiciones

Cada modelo devuelve probabilidades y casi todos añaden un número de confianza por pregunta. Aquí está la primera trampa: no significan lo mismo.

Jev y Strands Decider usan, para choice, la probabilidad máxima normalizada para que 0 sea “uniforme” y 1 “certeza total”:

Laya, según el post de presentación de su autor, usa la entropía normalizada de la distribución:

Veamos qué pasa con la misma distribución, la del ejemplo de soporte: (0.773,\ 0.121,\ 0.106), con n = 3.

Misma distribución, 0.66 contra 0.37. Si fijas un umbral de “actuar solo cuando la confianza sea ≥ 0.9” con un modelo y cambias a otro, no estás pidiendo lo mismo. Y para score hay todavía otras fórmulas: Jev usa la desviación absoluta media alrededor de la moda, Strands la desviación estándar normalizada (porque repartir masa entre dos niveles contiguos de una escala no es duda, es precisión: “algo así como 2.5”).

Calibración: el meteorólogo honesto

Una probabilidad solo sirve si es honesta. Piensa en un meteorólogo: si de todos los días en que anuncia “70% de lluvia” llueve en siete de cada diez, está calibrado. Si llueve en cuatro, es un charlatán con buena voz. Un modelo que dice “0.90” y acierta el 60% de esas veces produce un número que se parece a una probabilidad pero no lo es, y cualquier umbral que pongas encima (“actuar solo con ≥ 0.9”) se vuelve una ilusión.

La medida estándar es el ECE (expected calibration error): agrupas las predicciones por nivel de confianza, comparas en cada grupo la confianza media con la tasa real de acierto y promedias las diferencias ponderadas:

Y esto no es teórico. En el Decision Index (un leaderboard comunitario), Jev tiene confianza media 0.81 frente a una exactitud de 0.74, es decir, un ECE de 0.074; en el grupo de confianza 0.7–0.8 acertó el 59% de las veces, en 0.8–0.9 el 71% y por encima de 0.9, el 93%. Esos datos los reporta un resumen del ecosistema y no los medí yo, pero la lección es coherente con el resto: la mayoría de estos modelos sale sobreconfiada. Laya lo dice en su propia ficha: sin ajustar, su ECE es 0.466 y baja a 0.081 al refitar una temperatura con datos del dominio.

La temperatura: el botón que cambia la confianza y no la respuesta

La herramienta de calibración más simple es dividir los logits por una temperatura T antes del softmax:

Con T > 1 la distribución se aplana (menos seguro); con T < 1 se afila. La opción ganadora nunca cambia, porque dividir todos los logits por el mismo número positivo conserva su orden. Por eso una temperatura calibra la confianza sin tocar la exactitud. Aplicada al ejemplo de soporte (tratando \ln p como los logits, que es equivalente al softmax):

En la práctica, la temperatura se ajusta minimizando la log-verosimilitud negativa sobre un conjunto de validación, a menudo una por tipo de pregunta (el paper de Harvard que veremos ajusta una para choice, otra para noul y otra para score; Gemma 4 31B sin entrenar necesita temperaturas de 6.0 y 7.2: está muy sobreconfiado de fábrica).

Cuatro maneras de construir un modelo de decisión

Hasta aquí vimos qué hacen. Ahora, cómo. El problema de ingeniería es siempre el mismo: tengo un texto, una pregunta y K opciones; necesito K números que sumen 1, en una sola pasada. Hay cuatro soluciones y cada una explica a un modelo concreto.

B. Strands Decider: el jurado que levanta la mano

Analogía. Un jurado lee un expediente completo con tres candidatos. Al terminar, la persona que preside (<answer>) hace una pregunta general: “¿quién encaja?”. Cada candidato ya leyó su propia ficha, y lo que importa es qué tanto coincide la pregunta de la presidencia con lo que cada candidato entendió de sí mismo. Quien más coincide, levanta más la mano. (La analogía se rompe en que aquí nadie vota: lo que hay es un producto punto, no un recuento.)

Técnicamente, Strands Decider toma Qwen3.5-2B-Base, un decoder preentrenado de 24 capas (18 de atención lineal tipo Gated DeltaNet y 6 de atención completa), le quita la LM head y pone en su lugar una pointer head de aproximadamente un millón de parámetros. El prompt tiene siempre esta forma:

<state>Help! My payouts have been failing for 3 days.</state>
<question type="choice">
Select exactly one option.
Which team should handle this?
<options>
1. billing — payments, invoices, payouts
2. technical — bugs, outages, API errors
3. sales — pricing and upgrades
</options>
</question>
<answer>

El torso lo procesa una vez. Luego la cabeza toma el estado oculto en <answer> como query y el estado oculto del último token de cada opción como keys. Con atención causal, ese último token ya leyó toda su opción, y <answer> ya leyó todo el prompt. El logit de cada opción es un producto punto escalado:

Ese diseño tiene una virtud elegante: la cabeza no tiene ningún parámetro por opción. Por eso (1) no puede aprender “la primera opción suele ser la correcta”, (2) no hay tope de opciones en la arquitectura y (3) las etiquetas pueden ser nuevas en cada llamada, porque el prompt sola establece qué significa cada opción. Los tres tipos de pregunta salen del mismo softmax: noul con dos opciones, choice con N y score con L niveles ordenados.

También hay una decisión de diseño que muestra mentalidad de ingeniería: los autores mantienen la atención causal en lugar de convertir el modelo en bidireccional. Convertir un decoder a bidireccional exigiría reentrenar mucho para recuperar lo que se rompe, y su presupuesto era una sola RTX 3090. A cambio aceptan un defecto medido: invertir el orden de las opciones mueve la distribución unos 0.016, porque las opciones siguen atendiendo a las anteriores.

C. Laya: la mesa redonda con solapas

Analogía. Ahora todos los participantes se sientan en una mesa redonda y todos oyen todo a la vez, antes y después de su turno. Cada candidato lleva una solapa numerada ([MASK]). Al final, en lugar de preguntar al presidente, simplemente se mira qué piensa cada solapa. (Se rompe en que las solapas no “votan”: un MLP convierte el estado de cada una en un número.)

Laya sigue la tradición de BERT. El checkpoint en inglés es ModernBERT-large (395M parámetros, 28 capas, bidireccional, ajustado por completo) más una cabeza propia de 2 capas transformer, un option scorer y una cabeza act/escalate: 421M en total. El multilingüe usa mmBERT-base (322M en total, vocabulario de 256k, 100+ idiomas). El prompt es:

[CLS] choice question: ¿Qué equipo? [SEP]
[MASK] billing: pagos [MASK] tech: errores [MASK] other: general [SEP]
{"subject": "Reembolso", "body": "Me cobraron dos veces..."} [SEP]

Cada [MASK] es la “ventanilla” de una opción. El encoder deja un estado en cada una, el scorer lo convierte en un número y el softmax se hace solo entre los [MASK] de esa pregunta. Todas las preguntas de una llamada se apilan en un batch y se responden en una pasada, por eso Laya reporta unos 33–40 ms por pregunta en una GPU T4 y menos por pregunta cuando agrupas varias.

Lo que Laya hace bien… y los límites que su propia ficha admite

• Es pequeñísimo y corre en CPU, con pesos Apache 2.0.
• No es un modelo zero-shot. En el benchmark typed-decisions, los checkpoints base sacan ~0.35 de acierto, por debajo incluso de predecir siempre la clase mayoritaria (0.461). Con fine-tuning sobre ese dominio sube a 0.766. Su ficha lo dice sin rodeos: es “una base rápida para especializar”.
• Muchas opciones lo rompen. Las opciones comparten un presupuesto fijo de tokens (192 o 256). Con 77 opciones quedan 3–4 tokens por opción y la exactitud en Banking77 cae a 0.425 frente al 0.870 de Jev.
• El checkpoint en inglés colapsa fuera del alfabeto latino y lo hace con mucha confianza (Khmer: 0.000 de exactitud con 0.952 de confianza). Por eso existe el Router que detecta el script antes de la pasada.
• Sale sobreconfiado y su cabeza act/escalate aún no aporta señal fiable (según la misma ficha).

D. Jev: lo que se sabe y lo que no

Jev es la referencia, pero hay una asimetría que conviene tener presente: casi todo lo que se afirma sobre cómo funciona es una suposición.

Sí hay evidencia externa: una evaluación independiente (nibzard/decision-model-benchmark) midió latencias p50 de 264–316 ms desde la API, con 79.2% en Banking77 y 88.6% en CLINC150. Eso es rápido comparado con un LLM, pero no respalda por sí solo el “40–200x” que TypeSafe obtiene con sus propios flujos de trabajo (y que ellos mismos describen como posiblemente sesgados a su favor).

El giro (método A): un LLM normal, leído con cuidado, ya casi lo hace

Aquí viene lo más instructivo del ecosistema. Un grupo de Harvard y el Kempner Institute (Geuter, Cheng y Alvarez-Melis, arXiv 2610.17205) se preguntó: ¿hacen falta arquitecturas o métodos de RL especiales?. Su receta es casi ofensivamente simple. Le presentas la pregunta a un LLM instruct con opciones etiquetadas A, B, C… y respuesta de una sola letra, y lees los logits de esas letras en la siguiente posición:

donde h es el estado final y W_0 son las filas de la LM head que corresponden a las letras. No hay entrenamiento: solo se ajusta una temperatura. Resultado en su set OpenDecisions: Gemma 4 31B sin entrenar saca 79.6 y Jev 80.1. Con un LoRA corto (400 pasos, unas cinco horas de GPU, solo cross-entropy), sube a 84.4.

Dos ablaciones merecen quedar grabadas: entrenar solo la cabeza con el modelo congelado no mejora nada (78.9), mientras que entrenar el LoRA con la cabeza fija en su inicialización da 84.9. El beneficio viene de adaptar los estados ocultos, no de aprender una cabeza nueva. Y la instrucción importa: sobre el modelo base (sin instruct) la misma receta solo llega a 70.3.

Cómo se entrenan

Hay dos filosofías. La primera es la de toda la vida en deep learning: aprendizaje supervisado con mucha atención a los datos y la calibración final (Strands, y el paper de Harvard). La segunda es la que da nombre a la categoría: aprendizaje por refuerzo con recompensas que premian la honestidad (RLCD). Veamos las dos.

Receta supervisada: la de Strands

La pérdida de Strands tiene tres términos y cada uno responde a un riesgo:

• CE con suavizado ordinal. Cross-entropy contra la etiqueta correcta. En las preguntas score se mueve el 10% de la masa de la etiqueta a los niveles vecinos: equivocarse por uno es mejor que equivocarse por cuatro, y la cross-entropy pura no sabe eso.
• KL hacia el propio torso. El mismo modelo, con el adaptador apagado, produce una distribución sobre los tokens de número que él emitiría tras <answer>. Mantenerse cerca de ella actúa como ancla: “no olvides lo que ya sabías”. Cuesta una pasada extra y ningún parámetro nuevo.
• KL hacia un tutor, solo donde el tutor sabe más. Un modelo más grande congelado (en la v1, gemma-4-31B-it) da distribuciones objetivo, pero solo en las filas donde es medidamente mejor que el alumno. Donde no lo era (clasificación corta), destilar no movió nada en el benchmark; donde sí (documentos de varios pasos), ayudó.

El detalle que vale más que cualquier término de la pérdida

Los autores lo subrayan: el orden de las opciones se baraja en cada ejemplo y en cada época, y la etiqueta se reasigna. Sin eso, la cabeza aprende en silencio que “la ranura 0 suele ser la clase positiva” y pierde generalidad. Con barajado, la única estrategia que sobrevive al descenso de gradiente es leer el texto de la opción. (Las escalas ordinales solo se invierten, nunca se permutan, porque su orden es parte del significado.) Esta es una lección general de cualquier entrenamiento: elimina los atajos que tus datos permiten.

Otras decisiones de higiene: se descartan (nunca se truncan) los ejemplos que no caben en la ventana, porque cortar una lista de opciones haría que una opción se puntúe desde la representación de su vecina; el checkpoint final es una “sopa” (promedio exacto de los LoRA y las cabezas de tres corridas con la misma receta), calibrada después; y todo corre en aproximadamente 11 horas en una sola RTX 3090 (una hora y diez minutos en ocho H100).

Hay una práctica poco común que explica por qué es tan confiable la documentación de Strands: desde su versión 9, cada corrida declara sus predicciones y sus condiciones de fallo antes de entrenar, y el resultado se añade después sin editar lo anterior. La mayoría de las corridas no alcanzó su umbral, y el repositorio lo cuenta. Si estás investigando, copia esa disciplina.

RLCD: premiar la honestidad

Ahora la otra filosofía. Aquí necesitamos primero entender un problema que parece contraintuitivo.

El juego de las apuestas

Analogía. Eres un pronosticador y te pagan según tu predicción. Sabes que, en realidad, un evento ocurre el 70% de las veces. ¿Qué probabilidad deberías declarar? Depende de cómo te pagan. Si el premio es “la probabilidad que le diste a lo que ocurrió”, lo mejor es declarar 100%: apuestas todo a lo más probable y esperas ganar 0.70 por ronda. El sistema te empuja a la exageración. Pero si el pago está diseñado de manera que el valor esperado se maximiza solo cuando declaras tu creencia verdadera, la honestidad se vuelve la mejor estrategia. A eso se le llama regla de puntaje estrictamente propia.

Con un evento que ocurre el 70% de las veces, estos son los valores esperados de tres reglas al declarar distintas probabilidades q (calculados con las fórmulas de cada regla; mayor es mejor):

Mira las columnas. La lineal sigue subiendo hasta 1.00: premia mentir. Brier y logarítmica tienen su máximo exactamente en 0.70. Pruébalo tú: mueve los controles y comprueba dónde está el óptimo de cada regla.

Esto es lo que ataca el RL ingenuo con recompensa binaria (+1 si aciertas, 0 si no): maximizar exactitud empuja la probabilidad de la ganadora hacia 1 y la del resto hacia 0, y destruye la calibración. La idea de RLCD (Reinforcement Learning for Calibrated Decisions) es usar como recompensa una regla propia. TypeSafe acuñó el nombre y no ha publicado su método. Convai lo reimplementó para Laya y lo documenta en su ficha, y es esa receta la que describo a continuación (el nombre es el mismo; no sé si es el mismo método).

El bucle de Laya, paso a paso

1. Exploración. La política produce logits z. Para explorar se suman perturbaciones gaussianas de media cero y suma nula (sumar una constante a todos los logits no cambia el softmax) y se obtienen G = 8 distribuciones ruidosas; la desviación del ruido baja de 1.0 a 0.3 durante el entrenamiento.
2. Recompensa. Cada variante q se puntúa contra la etiqueta y con una combinación de reglas propias: logarítmica, esférica y, para escalas ordinales, la RPS (ranked probability score), que mide la distancia entre distribuciones acumuladas.
3. Ventaja de grupo. A cada variante se le resta la media del grupo y se divide por su desviación, al estilo GRPO. Sin red de valor.
4. Actualización. REINFORCE con esa ventaja. No hay término de cross-entropy supervisada.
5. Cabeza de decisión de actuar. Una cabeza adicional recibe +1 si actúa y acierta, −3 si actúa y falla, −0.5 si escala. La matriz hace que actuar solo convenga cuando p\cdot 1 + (1-p)(-3) > -0.5, es decir, p > 0.625. Los símbolos: p es la probabilidad de acertar si actúa; p\cdot 1 es lo que gana cuando acierta (+1); (1-p)(-3) es lo que pierde cuando falla (−3); y -0.5 es el costo seguro de escalar. Despejando, 4p-3 > -0.5. Ejemplo: con p=0.7, actuar vale 0.7-0.9=-0.2, mejor que -0.5, así que actúa; con p=0.5, vale -1, así que escala. Analogía: un cajero que decide si aprueba un cheque: ganar 1 por cada acierto no compensa perder 3 por cada error, salvo que esté bastante seguro (más de 62.5%). (Aunque, como vimos, esa cabeza hoy no aporta señal útil según la propia ficha.)
6. Conversaciones. Para varios turnos, entrena sobre prefijos con TD(\lambda=1), así que cada turno aprende contra el desenlace real.

Los datos

Fíjate en el patrón: sin importar el método, la ingeniería de datos hace el trabajo pesado (mezclas balanceadas, etiquetas suaves, barajado, tutores solo donde son mejores). El detalle que más se repite en estas fichas es el mismo: el modelo aprende lo que baratamente predice la etiqueta, y tu trabajo es no dejarle atajos.

Medir: qué dicen (y qué no) los benchmarks

La categoría nació con benchmarks propios porque los clásicos no la miden bien. JevBench (una evaluación comunitaria; su split público tiene 231 preguntas) puntúa Capability = (Inteligencia + Calibración) / 2. El Decision Index pondera ítems públicos (20%), ítems privados de las mismas habilidades (50%) y privados de dominios nuevos (30%) precisamente para detectar modelos afinados contra el set público. S1MB reúne más de cien benchmarks. Y hay evaluaciones independientes como las de nibzard y Red Hat.

Aprender a leer estas tablas es parte del oficio. Cuatro reglas:

1. Mira quién midió. En el ranking de 20 alternativas que publicó Marktechpost casi todas las cifras son de los propios autores, y la única tabla con varios modelos viene de Respan, que vende un competidor.
2. Mira el set privado. En el Decision Index (snapshot del 10 de octubre), Clef de Cloudflare saca ~61.7 en ítems públicos y ~41.9 en dominios nuevos: casi 20 puntos de caída. Jev cae solo ~3.
3. Mira los pesos del compuesto. JevBench pondera inteligencia, calibración, velocidad y costo al 25% cada uno; un modelo de 27B pierde posiciones porque su costo se estima al precio del modelo base. El “número 1” depende de tus pesos.
4. Mira la versión y la fecha. Jev puntuaba ~57.9 en el Decision Index 0.2.1 y 60.11 en la 0.3.1; el top cambia casi cada semana.

Algunos números para orientarse

Hay dos ideas de fondo detrás de esa tabla. La primera: los modelos de decisión son excelentes si no tienes datos de tu tarea, y los clasificadores pequeños entrenados con tu tarea suelen igualarlos o ganarles (Red Hat llegó a esa conclusión con guardrails en inglés: un clasificador de ~200M de parámetros en CPU igualó a Jev). La segunda: los números de un modelo no se transfieren entre dominios ni entre prompts; Red Hat vio que un prompt afinado para Laya le subió 17.8 puntos y le bajó 3.7 a Jev.

Usarlos bien en producción

La política de las tres bandas

La forma más útil de consumir una confianza es una política de tres bandas: actúa solo cuando la confianza es alta, confirma cuando es media y escala a una persona cuando es baja. Las bandas de ejemplo de la documentación de Jev son 0.9 y 0.5; Strands reporta que, en tareas cortas de clasificación que no había visto, las respuestas con confianza ≥ 0.9 acertaron alrededor del 95%. Son puntos de partida, no leyes.

Para elegir los umbrales de verdad, usa cobertura a un nivel de error más que el ECE: “¿qué fracción de los casos puedo automatizar si acepto un 5% de error?”. En un benchmark de nibzard con Banking77, un umbral de 0.96 sobre la confianza de Jev automatizaba el 51% de los casos con un 3.7% de error entre los aceptados; en NLU++, con varias etiquetas por mensaje, ningún umbral alcanzó el 5% de error. El mismo método en dos tareas distintas produce resultados muy distintos: por eso hay que medirlo con tus datos.

Cómo se ve en código

Strands Decider, desde la línea de comandos, con una pregunta de cada tipo:

pip install strands-decider

strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 \
  --state "Help! My payouts have been failing for 3 days!" \
  --choice "Which team should handle this?=billing,sales,retail" \
  --noul   "Does this convey urgency?" \
  --score  "How frustrated is the writer?=calm,frustrated,depressed"

Laya, con el Router que elige el checkpoint según el alfabeto del texto:

from laya import Router

router = Router(preload=True)
result = router.predict(
    "Hi, we were billed twice for March. Please refund the duplicate.",
    {"department": {"type": "choice", "instructions": "Which department?",
                    "criteria": {"billing": "invoices, refunds", "technical": "bugs", "other": "else"}},
     "churn_risk": {"type": "noul", "instructions": "Does the user threaten to leave?"}},
)
print(result["answers"]["department"]["choice"], result["routing"]["model"])

Y un ejemplo de verdad útil: el repositorio de Strands incluye un agente que, antes de ejecutar una herramienta, hace dos preguntas noul sobre la llamada propuesta. Si los argumentos no están fundamentados en lo que dijo el usuario, devuelve la jugada al agente para que pregunte en lugar de adivinar. Es un hybrid agent: el LLM hace el razonamiento difícil y el modelo de decisión toma las decisiones rápidas de rutina.

QUESTIONS = {
    "args_grounded": Decider.noul(
        "Are the tool's argument values grounded in facts the user actually provided?",
        {"true":  "every argument value traces back to something the user said",
         "false": "an argument value was guessed or invented, not stated by the user"}),
    "premature": Decider.noul(
        "Is it premature to call this tool now, before clarifying with the user?",
        {"true":  "the assistant should ask a clarifying question before calling the tool",
         "false": "there is nothing left to clarify; calling now is appropriate"}),
}

Cuando el servidor corre localmente, cualquier cliente de Jev funciona cambiando la URL base, porque el endpoint es /v1/systemone en ambos.

Lista de comprobación antes de ponerlo en un flujo

1. Fija la versión. En APIs alojadas, un ID versionado (jev-latest es un alias móvil; un benchmark vio cambiar 20 respuestas entre corridas). En pesos abiertos, el commit y el formato de cuantización: cuantizar o cambiar precisión puede cambiar respuestas.
2. Construye tu propio conjunto. Unos cientos de ejemplos de tráfico real, con casos difíciles estratificados y una porción de “dominio nuevo”.
3. Pon tres referencias. Reglas o palabras clave, un clasificador pequeño entrenado (si tienes datos) y un LLM como juez. El modelo de decisión debe ganar al menos en una dimensión.
4. Calibra tú. Una temperatura por tipo de pregunta, ajustada con tus etiquetas.
5. Prueba el orden. Baraja las opciones y mide cuántas respuestas cambian (en Strands, ~0.016 de movimiento; en un estudio con preguntas de 16 opciones, Jev cambió el 7.0% de sus respuestas y dos modelos destilados de Jev, entre 7.4% y 11.5%). Una mitigación barata: ordenar las opciones por texto.
6. Verifica que existan las tres bandas. Algunos modelos casi nunca producen probabilidades intermedias; entonces tu banda “confirmar” jamás se usa.
7. Mide la latencia de extremo a extremo, con red. Un modelo de 30 ms en tu GPU y uno de 300 ms por una API no compiten en el mismo plano.
8. Deja rastro de auditoría: hash del estado, preguntas, la distribución completa, versión del modelo, umbral vigente y acción final.

Cuándo no usarlos

Un buen criterio de ingeniería es saber por qué no elegir una herramienta.

Y un camino intermedio: etiquetar con un modelo de decisión y luego entrenar un clasificador pequeño. La ficha de Laya muestra un caso donde afinar un checkpoint pasa de 0.362 a 0.766 de exactitud.

El mapa del ecosistema

La velocidad de este campo es llamativa: en cuatro semanas pasó de una API cerrada a una categoría con pesos abiertos, leaderboards y un endpoint genérico en vLLM. Un mapa útil se divide por si puedes ejecutarlo tú:

Repaso: ¿lo entendiste de verdad?

Intenta responder cada pregunta antes de abrirla. Si dudas en alguna, vuelve a la sección correspondiente: esa duda es exactamente lo que más te sirve estudiar.

Glosario mínimo

System One / modelo de decisión

Modelo que recibe un estado y preguntas cerradas y devuelve probabilidades, sin generar texto.

noul / choice / score

Sí/no, elección entre N y escala ordinal.

Logit

Puntaje sin normalizar de una opción; el softmax lo convierte en probabilidad.

Temperatura

Divisor de los logits para reescalar la confianza sin cambiar la ganadora.

ECE / Brier

Medidas de calibración y de calidad probabilística.

LoRA

Ajuste de baja dimensión que añade pocos parámetros entrenables a un modelo congelado.

RLCD

Nombre de TypeSafe para entrenar con recompensas que premian probabilidades honestas (su método no es público; Laya publica una versión).

Regla propia

Función de puntaje cuyo valor esperado solo se maximiza declarando la distribución verdadera.

Sopa de modelos

Promedio de pesos de varias corridas de la misma receta.

Fuentes y límites de lo que aquí se afirma

Todo lo que sigue se consultó entre el 24 y el 25 de octubre de 2026 y el campo cambia semana a semana. Cuando una cifra viene de un autor sobre su propio modelo, lo he dicho; cuando la vi solo en un resumen secundario, también.

• Strands Labs, Introducing Strands Decider 2B y el repositorio strands-labs/strands-decider (README y docs/architecture.md).
• Convai Innovations, fichas de Hugging Face convaiinnovations/laya y laya-multilingual, y el post de Nandakishor M en dev.to.
• TypeSafe AI, Introducing System One Models & Jev; Wikipedia, Jev (AI model); TechCrunch, 18 de septiembre de 2026.
• J. Geuter, A. Cheng, D. Alvarez-Melis, Releasing the Inner Jev: A Simple Recipe for Open Decision Models, arXiv 2610.17205.
• nibzard, decision-model-benchmark (evaluación independiente de Jev).
• Remy, One Month After Jev (resume el Decision Index, JevBench, el estudio de Red Hat y el artículo de Alex Molas); Marktechpost, 20 Jev Alternatives.

Lo que no pude verificar: cómo es Jev por dentro, qué tan cerca está el RLCD de Laya del de TypeSafe, y el contenido del paper JevOut (solo vi su resumen). Si lo vas a usar en algo que importe, mide con tus datos.