RLCD explicado: por qué TypeSafe entrena a Jev para ser honesto sobre la confianza en lugar de caer bien

Jev 1.13 (typesafe/jev-1.13) está entrenado con un método que su creador llama Reinforcement Learning for Calibrated Decisions — RLCD —, y ese acrónimo es una acuñación de TypeSafe, no un término de la industria que se supone que ya conoces. La publicación de lanzamiento lo dice con todas las letras: la compañía construyó «una nueva arquitectura de modelo, un muestreador paralelo para máxima eficiencia, y un método de entrenamiento que llamamos Reinforcement Learning for Calibrated Decisions (RLCD)». Es una tercera respuesta a una pregunta que solía tener dos, y la razón de que exista es un desajuste con el que la mayoría de los equipos se topa la primera vez que intenta poner un modelo de lenguaje dentro de una decisión. Antes de entrar en ello, dos fechas importan, porque esta página no es un artículo de lanzamiento. TypeSafe publicó el modelo en sí el 2026-09-15, lo que queda fuera de la ventana de siete días sobre la que escribe este blog, y nada de lo que hay aquí debería leerse como que presenta a Jev como nuevo. El evento con fecha es el 2026-09-24, cuando OrcaRouter añadió typesafe/jev-1.13 a su propio catálogo y abrió la ficha del modelo — la primera vez que Jev se puede invocar a través de una pasarela de terceros en lugar de solo a través del endpoint propio de TypeSafe. Ese es el cambio en el que se basa esta página, y la consecuencia práctica es que la técnica que sigue ahora es algo que puedes probar en código con una clave que quizá ya tengas, en lugar de una idea de investigación sobre la que has leído.

Lo que sigue es el concepto, no el modelo. El primer tercio de esta página trata de los dos métodos de entrenamiento contra los que se diseñó RLCD, porque RLCD solo resulta inteligible como reparación de lo que esos dos hacen cuando la tarea deja de ser una conversación y se convierte en un juicio. Si ya sabes para qué optimizan RLHF y RLVR, la sección que buscas es la tercera, donde la propia tabla de tres vías de TypeSafe hace el trabajo.

RLHF optimiza para la respuesta que prefiere una persona

El aprendizaje por refuerzo a partir de retroalimentación humana es el método que convirtió los modelos de lenguaje preentrenados en asistentes. El propio manual de TypeSafe enuncia el objetivo sin rodeos, en una tarjeta titulada RLHF: «convirtió los modelos preentrenados en chatbots. Entrena a los modelos para producir respuestas que la gente prefiere». InstructGPT y ChatGPT se entrenaron con él, y el manual añade un detalle que es relevante aquí por un motivo distinto: el enfoque fue coinventado por Diogo Almeida, cofundador de TypeSafe y autor del artículo de lanzamiento de Jev. La empresa no está descartando el método; fue fundada por alguien que ayudó a construirlo. Sostiene que el objetivo es incorrecto para una tarea concreta.

La manera clara de ver el desajuste es preguntarse qué mide en realidad la señal de recompensa. Bajo RLHF, mide la preferencia de un evaluador entre dos respuestas candidatas. Eso es un indicador indirecto excelente cuando el producto es una conversación, porque el criterio de éxito de una conversación es realmente si a una persona le parece buena la respuesta. Es un indicador indirecto defectuoso cuando el producto es una decisión, porque allí el criterio de éxito es si la confianza declarada coincide con la realidad, y un evaluador que compara dos párrafos plausibles no tiene forma de ver la diferencia entre un 0.6 bien calibrado y un 0.95 que suena seguro. Dos respuestas pueden ser igualmente preferidas y diferir enormemente en cuánto debería confiar en ellas un programa.

Los modos de fallo que TypeSafe menciona en el primer se derivan directamente de eso:

• Sicofancia — el modelo aprende a producir lo que el evaluador quiere oír, que es un objetivo distinto de lo que es verdadero.

• Alucinación que suena segura — la fluidez y la certeza se ven recompensadas por la preferencia incluso cuando no están respaldadas por nada.

• Pérdida de modos — la optimización de preferencias estrecha la distribución de salida, "favoreciendo un estilo particular, como el seguimiento de instrucciones, mientras reduce la probabilidad de otras salidas posibles". La pérdida de modos es la versión leve del clásico fallo de colapso de modos que aqueja a las redes generativas antagónicas, donde un generador converge en una salida que sigue engañando al discriminador.

El propio párrafo de advertencia del manual introductorio es la frase que vale la pena conservar: «Un resultado puede resultar convincente para una persona sin ser lo bastante fiable para una automatización sin supervisión. La preferencia humana y la fiabilidad de la máquina son objetivos de optimización distintos». Eso no es una crítica del RLHF como método. Es la observación de que a un modelo entrenado con preferencias nunca se le ha hecho la pregunta que la automatización necesita que se responda: con qué frecuencia, exactamente, acierta esto cuando dice que está seguro.

RLVR optimiza para resultados que un programa puede comprobar — y las decisiones rara vez tienen uno

El aprendizaje por refuerzo con recompensas verificables es la segunda adaptación, y es la que está detrás de los modelos de razonamiento. El manual introductorio de TypeSafe describe lo que produjo: modelos que «son fuertes en tareas como las matemáticas, pero más lentos y más costosos». El mecanismo es un verificador. Si una tarea tiene una respuesta que un programa puede comprobar —una prueba unitaria, un verificador de demostraciones, una respuesta numérica—, entonces se puede calcular una recompensa sin preguntarle nada a un humano, y el modelo se puede entrenar con esa señal a escala. Funciona, y es la razón por la que los modelos de razonamiento se volvieron buenos exactamente en los dominios donde existe una verificación automática barata.

La limitación es la forma de esa palabra, «verificable». Una recompensa verificable requiere un verificador, y un verificador requiere que haya una respuesta correcta que alguien pueda comprobar. Considera las preguntas que un sistema en producción realmente plantea: ¿este ticket de soporte debe ir a facturación o a técnico? ¿esta solicitud de reembolso está dentro de la política? ¿esta transacción parece fraudulenta? Cada una tiene una respuesta defendible la mayoría de las veces, ninguna tiene una respuesta que un programa pueda comprobar, y los casos que más importan son precisamente aquellos en los que discrepan humanos con experiencia. No hay ninguna función que ejecutar. RLVR no tiene nada que recompensar, así que no aporta nada.

La tentadora solución alternativa es fabricar un verificador etiquetando un conjunto de datos y entrenando con las etiquetas. Eso le da al método algo con lo que trabajar, pero cambia el objetivo de una manera que importa. Las etiquetas codifican una decisión, no la incertidumbre que la rodea. Un modelo entrenado para reproducir los juicios de un equipo en los casos difíciles aprende a tener la misma seguridad que tenían esas etiquetas; es decir, exactamente el mismo exceso de confianza que los humanos que las escribieron. E incluso cuando existe un verificador genuino, hay una segunda brecha. Un verificador puntúa la respuesta. No puntúa la confianza declarada. Un modelo que acierta en el 95 % de los casos e informa certeza en todos ellos obtiene una recompensa perfecta y, como componente de un pipeline automatizado, resulta inútil, porque ese 5 % es la única parte sobre la que había que avisar al pipeline. Los materiales de lanzamiento de TypeSafe plantean el mismo punto desde la dirección opuesta: «Si un modelo puede realizar una tarea el 95 % de las veces pero no dice cuándo está en el 5 %, no puede automatizar esa tarea».

Lo que hace RLCD, según el propio planteamiento de TypeSafe

RLCD cambia el contrato de salida en lugar de la calidad de la respuesta. La tarjeta del texto introductorio dice: «El aprendizaje por refuerzo para decisiones calibradas entrena a TypeSafe para devolver decisiones y probabilidades calibradas en lugar de texto generado». La versión concisa de la publicación de lanzamiento es «decisiones calibradas: respuestas con probabilidades epistémicamente honestas en tareas de System One». Ambas describen un mismo movimiento: entrenar al modelo en función de si su probabilidad declarada coincidía con la frecuencia con la que esa respuesta resultó ser correcta, en lugar de en función de si a una persona o a un verificador le gustaba la respuesta.

La publicación de lanzamiento pone los tres métodos uno al lado del otro, y el contraste es la declaración más clara de la idea que existe. Léelo como un conjunto de contrastes en lugar de una tabla:

• Para qué optimiza — RLHF optimiza la preferencia humana, "textos y respuestas de chat que prefieren los evaluadores humanos"; RLVR optimiza "resultados que se pueden verificar programáticamente"; RLCD optimiza la calibración, "respuestas con probabilidades epistémicamente honestas en tareas de Sistema Uno."

• Qué entra — los dos más antiguos toman datos no estructurados "con un énfasis en mensajes secuenciales"; un modelo de decisión calibrado toma datos no estructurados "con un énfasis en el estado estructurado del programa".

• Lo que sale — cadenas generadas que "deben parsearse + validarse", con "siempre algún riesgo de que la IA se desvíe", frente a valores estructurados con seguridad de tipos, donde "las posibles salidas y la estructura se definen de antemano", el modelo "nunca comete errores de tipo" y "todas las respuestas van acompañadas de probabilidades calibradas y puntuaciones de confianza".

• Cómo se muestrea — un token a la vez, cada uno condicionado por el anterior, frente a todas las salidas generadas en una sola consulta. Esta es la razón mecánica por la que el tercer método es barato: no hay ningún bucle de decodificación que pagar.

• Cuánto cuesta — tokens de entrada desde $0.20 hasta $10 por millón para los modelos de comparación, con la salida aproximadamente cinco veces el precio de la entrada, frente a $0.042 por millón de tokens de entrada con salida facturada a cero para Jev.

• Qué rápido responde — de 3 a 329 segundos de extremo a extremo en el caso de los modelos de frontera, frente a 70 ms a 500 ms, lo que el proveedor describe como entre 40 y 200 veces más rápido en consultas con la forma de System One.

• Lo que dice sobre su propia confianza — los dos más antiguos «tienden a ser demasiado confiados e inconsistentes» incluso cuando se les pide una estimación de confianza; RLCD «siempre comunica confianza e incertidumbre con cada salida», donde «una mayor confianza significa una mayor precisión».

La última línea es la afirmación real sobre el producto, y es refutable de una manera en que las otras no lo son. "Una mayor confianza implica una mayor precisión" es una afirmación sobre una curva: agrupa las respuestas de un modelo por la probabilidad que les asignó, y los grupos deberían ser correctos aproximadamente a la tasa que las probabilidades afirman. La documentación de confianza de TypeSafe detalla el contrato con números inusualmente concretos:

• Los resultados a los que se asigna una probabilidad de 0,2 deberían ocurrir aproximadamente el 20 % de las veces.

• Los resultados a los que se les asigna una probabilidad de 0.8 deberían ocurrir aproximadamente el 80% de las veces.

• Los resultados a los que se asigna una probabilidad de 1.0 deberían ocurrir el 100% de las veces.

Y luego está la frase que mantiene honesta la afirmación, en palabras del propio proveedor: "Estas tasas describen grupos de predicciones, no una garantía sobre ninguna respuesta individual". Eso no es una salvedad añadida por razones legales. Es todo el significado de la calibración. Un modelo bien calibrado que dice 0,8 no promete acertar esta vez; promete que, a lo largo de todas las respuestas que etiquetó como 0,8, alrededor de cuatro de cada cinco eran correctas. Una respuesta no te dice nada. Mil respuestas a lo largo de una semana te dicen si la curva es real.

El mismo contraste de tres tarjetas aparece en la propia documentación de TypeSafe, que es la fuente de la comparación anterior y el lugar más claro para comprobar la redacción en lugar de fiarse de lo que dice un resumen. La captura de abajo es esa página tal como está hoy: tres tarjetas para los tres enfoques de post-entrenamiento, y la tercera nombra RLCD completo.

Dos detalles adicionales en la documentación del proveedor muestran hasta qué punto el método llega a calar en el producto. El primero es que la confianza se deriva en lugar de generarse: el modelo devuelve una distribución de probabilidad completa sobre las opciones o niveles que usted proporcionó, y el valor de confianza es un estadístico calculado a partir de la forma de esa distribución. Por eso la documentación puede decirle que la definición no es determinante: en cualquier caso obtiene la distribución sin procesar y puede calcular su propio estadístico si el suyo se ajusta mejor. El segundo es que RLCD es lo único que da forma a los pesos. La página de modelos de TypeSafe afirma: «Jev no se ajusta ni se adapta con LoRA usando datos de clientes. Se entrena con RLCD para devolver decisiones calibradas, y los mismos pesos sirven para todas las cuentas». La adaptación al dominio ocurre en la solicitud —su estado, sus criterios—, no en un checkpoint por cliente. Cualquiera que sea la calibración que haya producido el método, es la calibración que recibe cada cliente.

¿Por qué la calibración es lo que hace que un modelo de decisión barato sea utilizable?

Una probabilidad calibrada no resulta interesante por sí sola. Se convierte en la arquitectura en el momento en que tu código se ramifica a partir de ella, y la documentación de confianza de TypeSafe describe exactamente ese patrón como tres rangos, cada uno de los cuales produce un comportamiento distinto del sistema.

• Alta confianza — actúa automáticamente. El modelo tiene una lectura clara y puedes proceder sin intervención humana.

• Confianza media — proceda con cautela. El modelo tiene una respuesta razonable, pero no está seguro, así que confirme con el usuario, márquelo para revisión o reúna más información antes de actuar.

• Baja confianza — no actúes. Deriva a un humano, solicita aclaración o recurre a un sistema diferente, porque el modelo te está diciendo que no tiene suficiente información para continuar.

La documentación es explícita en que los límites los trazas tú y deben diferir según las consecuencias: "Un umbral de confianza no es un solo número. Distintas acciones dentro del mismo sistema deben condicionarse en niveles distintos según las consecuencias de equivocarse." Su ejemplo práctico establece un piso estricto en 0.5 —todo lo que el modelo reporte por debajo de eso se deriva a una persona sin más inspección— y luego aplica un estándar más alto para una acción destructiva que para una de solo lectura. Tu código codifica la tolerancia al riesgo; el modelo proporciona la entrada honesta para ello.

Ese patrón es todo el argumento a favor de un flujo de trabajo de dos modelos, y vale la pena enunciarlo como un argumento en lugar de como una lista de características. Supongamos que quieres una canalización automatizada que gestione la mayoría de los casos con confianza y escale el resto a un modelo más grande o a una persona. La decisión de escalado tiene que venir de algún sitio. Si el modelo barato informa 0,98 en todo, incluidos los casos en los que está adivinando, entonces la bifurcación no tiene nada que probar y o bien automatizas todo —incluidas las llamadas que debería haber escalado— o no automatizas nada. Un modelo cuya confianza es informativa es el único tipo que te permite automatizar un subconjunto de forma segura, porque es el único que puede decirte en qué subconjunto no es seguro. La documentación plantea el mismo punto en una línea que vale la pena citar por su contundencia: «Si un sistema inteligente, ya sea humano o máquina, no puede expresar incertidumbre honesta, no se puede confiar en el sistema».

Hay una segunda razón por la que esto importa más para un modelo barato que para uno caro, y es la razón por la que la historia del enrutamiento y la historia de RLCD son la misma historia. Un modelo con un precio de $0.042 por millón de tokens de entrada y sin cargo por salida es lo suficientemente barato como para consultarlo constantemente — en cada turno de un bucle de agente, en cada registro de un lote, en cada ticket a medida que llega. Ser consultado constantemente es el escenario en el que los errores de un modelo se acumulan, porque nadie está leyendo su salida antes de que se actúe sobre ella. La confianza es lo que hace que eso sea seguro. La baratura es lo que hace que la rama de escalamiento sea asequible, ya que la ruta cara solo se ejecuta en la fracción de casos que el modelo barato rechazó. Ninguna de las dos mitades funciona sin la otra, y la decisión de enrutamiento que las une es un umbral en un número que RLCD es la razón para creer.

El límite honesto: estar calibrado no es ser correcto.

Lo más importante que hay que entender correctamente sobre RLCD es lo que no afirma. La calibración es una propiedad de las confianzas, no una garantía sobre las respuestas, y el proveedor lo dice en su propia documentación en lugar de dejarlo a los críticos. La página de System One: "Los modelos de System One están entrenados para decisiones calibradas: sus probabilidades se optimizan contra los resultados para reflejar la incertidumbre. La calibración se mide en grupos de predicciones; no garantiza que una respuesta individual sea correcta." Un modelo puede estar perfectamente calibrado y aun así equivocarse con tu ticket, porque 0,9 significa nueve de cada diez, y este podría ser el décimo.

Nuestras propias cifras de servicio son el contrapeso útil aquí, precisamente porque son mediciones del modelo en producción y no afirmaciones sobre lo que logra el método. Durante los siete días que terminaron el 2026-09-30, sobre el tráfico que pasa por el playground de OrcaRouter desde que el modelo se añadió al catálogo, la tarjeta de Jev 1.13 informa de una tasa de error del 0,49 % en 76,2 millones de tokens, junto con un tiempo hasta el primer token p50 de 151 ms, un p95 de 247 ms y unos 349 tokens de salida por segundo. Dos cosas sobre ese número merecen decirse sin rodeos. Es nuestro, no del proveedor, y es una ventana móvil en lugar de un conjunto de pruebas fijo; el mismo campo marcaba un 0,57 % en un punto anterior de la ventana, porque se recalcula sobre los siete días móviles de tráfico en vivo y las llamadas de ayer quedan fuera. Tampoco es una medición de calibración. Una tasa de error te dice con qué frecuencia algo salió mal en nuestro tráfico; no te dice si los valores de confianza eran honestos, que es una pregunta distinta y que requiere datos etiquetados para responder.

Cuál es la instrucción práctica que también da el proveedor, en una nota adjunta a su guía sobre umbrales: «Los valores de umbral correctos dependen de tu dominio y del rendimiento del modelo para tu caso de uso. Empieza con umbrales conservadores, prueba con tus propios datos y ajusta a medida que observes los resultados». RLCD es una afirmación sobre cómo se entrenó el modelo. Que la afirmación se sostenga con tus datos de entrada es una cuestión empírica, y es una de las pocas propiedades del modelo que puedes probar sin ninguna infraestructura de aprendizaje automático: toma unos cientos de casos para los que ya tienes etiquetas, agrupa las respuestas según la confianza que reportó el modelo y comprueba si los grupos aciertan a la tasa que afirman. Si el grupo de 0.9 acierta alrededor del 90 % de las veces en tu tráfico, el umbral es real y puedes automatizar por encima de él. Si todo se agrupa por encima de 0.9 y la exactitud no acompaña, habrás aprendido algo más útil que cualquier cifra de titular.

Dos limitaciones adicionales deben mencionarse en la misma frase. La primera es que no existe una ficha de benchmark pública de este modelo con la que contrastar nada de esto: el proveedor no ha publicado ninguna, y ningún ranking de terceros incluye el modelo; la página de modelo de Artificial Analysis para él devuelve un 404 a fecha de 2026-09-30. Así que el argumento de calibración se basa en la descripción del entrenamiento, el contrato documentado y lo que midas tú mismo, no en una curva publicada. La segunda es que las afirmaciones de rendimiento del propio proveedor son suyas: la publicación de lanzamiento señala abiertamente que las evaluaciones de flujos de trabajo que respaldan el titular de velocidad y coste fueron elaboradas por su equipo de capacidades de modelos, que las respuestas de referencia con las que se comparan son el promedio de dos modelos externos y que las cifras están «en el extremo superior de las mejoras en el mundo real». También dice que no se puede demostrar que el precio no esté subvencionado. Nada de eso socava el método de entrenamiento, que es una afirmación distinta de la de velocidad, pero sí significa que el caso a favor de RLCD es un argumento sobre el diseño del objetivo más que un resultado empírico asentado. Trátalo como una hipótesis que puedes comprobar de forma barata, lo que es una posición mejor que la que te dejan la mayoría de las afirmaciones sobre métodos de entrenamiento.

Qué puedes hacer con esto hoy

Los dos términos del argumento se encuentran en un solo lugar. RLCD es la razón por la que la confianza de un modelo de decisión merece ser ramificada; un umbral en tu código es donde vive esa rama; y la escalación solo es costeable si la ruta común es lo suficientemente barata para ejecutarse en todas partes. Jev 1.13 se puede invocar como typesafe/jev-1.13 en OrcaRouter — una API para más de 200 modelos, 0 % de recargo, precio de lista del proveedor transferido sin cambios, así que un recorte de precio de un proveedor está vigente aquí el mismo día — lo que significa que la ruta de mayoría con confianza y la ruta de escalado se facturan con la misma clave en lugar de con dos contratos con proveedores. Sigues llamándolo en tu código, POST /v1/systemone, sin streaming, contra un contexto de 65,536 tokens, porque esa no es la ruta de chat-completions de OpenAI y no está integrada en el endpoint de chat. Dos notas de las versiones del SDK del proveedor vale la pena tenerlas en cuenta si lo estás integrando: la versión 0.7.1, publicada el 2026-09-21, añadió ejemplos para su uso con pasarelas de IA, y la versión 0.7.2, publicada el 2026-09-26, añadió un extra http2 al paquete de Python. La segunda es el tipo de detalle que solo aparece en las notas de la versión: un cliente HTTP/2 vale la pena tenerlo para un modelo cuya propuesta de valor completa son idas y vueltas de menos de 200 milisegundos.

Si te llevas una sola cosa de la página, que sea la forma de la pregunta que responde RLCD. No es «¿puede un modelo ser más inteligente?», sino «¿puede un modelo decirme cuándo no es lo bastante inteligente, con la suficiente frecuencia y precisión como para que yo pueda automatizar el resto?». Ese es un objetivo de investigación distinto de los dos a los que el campo dedicó los últimos años, y es el único que produce un número sobre el que tu código puede actuar. El valor de confianza es ese número. Pruébalo con tus propias etiquetas antes de confiar en él, y empieza con un umbral con el que te avergonzaría equivocarte en lugar de uno con el que te gustaría acertar.

Una última pieza del panorama merece acompañar todo lo demás, porque es el número al que apunta todo el argumento y está medido, no solo afirmado. La tarjeta que aparece a continuación es nuestro propio registro de servicio de siete días para typesafe/jev-1.13 —el modelo en producción, no el método de entrenamiento, y no un benchmark—. Léela como la segunda mitad de la pregunta de calibración: las puntuaciones de confianza te dicen en qué llamadas conviene actuar, y esto te dice qué tan cerca está el resto de la decisión de enrutamiento de un sistema que dejarías sin supervisión.