¿Cómo se implementan el enrutamiento y las barreras de seguridad de LLM? Un ejemplo de colaboración entre Jev y los grandes modelos de lenguaje

Divulgación de intereses y evidencia: PandaNpc está desarrollando una capa de decisión de Agent que usa Jev. A continuación se citan respectivamente la documentación oficial de TypeSafe, el cookbook oficial y llamadas reales a Jev y calibraciones con escenarios sintéticos de nuestro repositorio. Nuestra calibración usa un proveedor de LLM falso y scriptado, por lo que no puede representar el tráfico de usuarios reales ni el rendimiento de una cadena de producción completa.

El enrutamiento de LLM puede hacerse así: primero dejar que Jev determine a qué categoría pertenece la solicitud y qué riesgo tiene, y después que el código decida si se envía a una función normal, a un LLM especializado o a revisión humana. Jev también puede colocarse entre la recuperación y la generación para filtrar evidencia, o después de la salida del LLM para comprobar el resultado. Devuelve opciones cerradas, puntuaciones y probabilidades; las respuestas abiertas, la generación de código y el razonamiento largo siguen a cargo del LLM. La explicación de TypeSafe sobre los agentes de programación indica claramente que Jev no puede sustituir directamente al modelo de chat que hay detrás de Claude Code o Codex.

Este artículo usa unaitud de atención al cliente, una canalización de preguntas y respuestas RAG y nuestro propio registro de calibración de Agent para explicar dónde se relevan exactamente los dos tipos de modelos y por qué los resultados de baja confianza deben tener un destino claro.

¿Qué puede determinar Jev y de qué sigue encargándose el LLM?

A 23 de septiembre de 2026, el modelo estable que figura en la página de modelos de TypeSafe es jev-1.13.0. La API acepta un state y un conjunto de questions, y mediante POST /v1/systemone devuelve los answers estructurados correspondientes. jev-latest apuntaba a 1.13.0 ese día, pero el alias cambia con las versiones; conviene que los sistemas con umbrales calibrados fijen la versión y registren el ID de modelo real en la respuesta.

Noul no tiene un campo confidence independiente; no se puede escribir una probabilidad de Noul directamente como «confianza del modelo». Score tampoco debería usarse para calcular importes exactos. Los importes, la comparación de fechas, las cuotas y las comprobaciones de permisos deben permanecer en programas deterministas; la documentación oficial ya enumera estos límites de Jev 1.13.

La forma mínima de una llamada

La siguiente forma de solicitud coincide con la referencia oficial de la API; la pregunta de ejemplo es una configuración ilustrativa creada para este artículo y no se ha probado en línea para este artículo:

El JSON a continuación usa un mensaje de cliente en inglés; en español, el cliente diría “Se ha realizado un cargo duplicado en el pedido, por favor ayúdenme a obtener un reembolso.”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

Un sistema real también debería comprobar primero con código si los car pertenecen al mismo pedido y si se permite el reembolso. El ejemplo anterior solo sirve para interpretar la intención del usuario; que el usuario pida un reembolso no significa que se haya demostrado su derecho al reembolso, y mucho menos constituye autorización para ejecutar directamente el reembolso.

Usar Jev para el enrutamiento de LLM: tres rutas de relevo

El ejemplo oficial de enrutamiento por intención de TypeSafe entrega primero la solicitud de atención al cliente a Jev para determinar la intención y la complejidad, y luego el código deriva: la consulta del estado del pedido va a una función de base de datos; las preguntas de producto y las devoluciones y los cambios van a LLM especializados cargados con materiales distintos; las quejas complejas o los resultados de baja confianza entran en una cola de revisión humana. Esta es la colaboración más fácil de entender entre Jev y un LLM: el primero da una determinación estructurada y el segundo solo aparece cuando hay que generar una explicación o una conversación.

Al implementarlo, conviene diseñar en el siguiente orden, en lugar de dejar que el modelo decida libremente todas las acciones:

1. Definir primero las rutas: enumerar con claridad qué solicitudes pueden manejar las funciones normales, cada LLM especializado y la revisión humana, y dejar en Choice una opción de reserva como other o similar.
2. Poner los hechos en state: las palabras exactas del usuario, el estado de la cuenta y los registros de pedidos deben ser campos separados; no tratar texto web de origen desconocido como instrucción del sistema.
3. Hacer preguntas estrechas de una en una: usar Choice para la intención, Score para el riesgo o la urgencia y Noul para un hecho puntual que haya que confirmar. La documentación oficial recomienda que varias preguntas independientes sobre el mismo state se evalúen en paralelo en la misma solicitud.
4. Dejar que el código haga el enrutamiento final: comprobar primero los permisos y las reglas rígidas, y después mirar las probabilidades de Jev y los umbrales calibrados para este negocio; las solicitudes de baja confianza o sin evidencia van a revisión humana o a una pregunta adicional.
5. Registrar los resultados y revisarlos: guardar la versión del modelo, la versión de las preguntas las probabilidades, el destino final y las correccionesas para poder juzgar si los umbrales son adecuados.

Fuente de la imagen: TypeSafe AI, «Introducing System One Models & Jev», 2026-09-15. Los cuatro flujos de trabajo fueron creados por TypeSafe; las métricas se agregan con el mismo peso por flujo de trabajo; para el método de evaluación, véase Evaluaciones de flujos de trabajo de TypeSafe.

Este gráfico oficial ayuda a entender por qué se insiste en «meter varios juicios estrechos en un flujo de trabajo de programa». El eje vertical del gráfico mantiene el nombre «accuracy» del proveedor, pero su referencia de respuesta proviene del consenso de probabilidades predichas por dos grandes modelos, no de una única respuesta correcta verificada por humanos; los costes y las métricas también dependen de estos cuatro flujos de trabajo y del método de evaluación del proveedor, y no pueden convertirse en «cuánto se ahorra en cualquier escenario».

Generación aumentada por recuperación: Jev filtra la evidencia antes de que responda el LLM

El cookbook de TypeSafe sobre pasajes RAG ofrece un ejemplo multimodelo más concreto: OpenAI embedding recupera primero los pasajes, y Jev pregunta cuatro Noul para cada «pregunta + pasaje»: si es relevante, si contiene evidencia utilizable para responder, si refuta la premisa de la pregunta y si intenta dar instrucciones al modelo que responde. El código procesa las cuatro probabilidades en orden y decide si colocar el pasaje en la zona de evidencia, en la zona de evidencia en conflicto o descartarlo; por último, Claude Sonnet 5 escribe la respuesta.

Este paso resuelve un problema habitual: un pasaje con alta similitud vectorial no necesariamente es utilizable. Puede que solo use palabras parecidas, o puede ser un fragmento de foro que incluya una inyección de prompt como «ignora lo anterior». El ejemplo del cookbook coloca la comprobación de inyección al principio de las reglas de enrutamiento y advierte que el umbral es un punto de partida elegido para ese corpus, no el valor predeterminado de todas las aplicaciones RAG. Sus cifras de demostración provienen de jev-1.12 del 2026-08-27 y no deben tomarse como nuevos resultados de evaluación de jev-1.13.0.

Después la generación también se puede hacer una capa de verificación. El cookbook de verificación de citas de TypeSafe primero usa un programa para encontrar el texto citado y luego usa Jev para determinar si ese pasaje apoya, refuta o no menciona la afirmación generada. Puede señalar las citas que merecen revisión; el juicio del modelo en sí todavía puede fallar, y «pasar la comprobación» no debe presentarse como garantía de hecho.

Nuestra calibración de Agent: ¿dónde se atasca la escalada por baja confianza?

En el repositorio de PandaNpc, el cliente de Jev, el banco de preguntas y el orquestador usan Jev para el reconocimiento de intención Agent, la puntuación de modificaciones candidatas, la verificación de condiciones de finalización y la decisión de commit. El cliente también hace reintentos limitados ante timeout, 429 y 5xx, y limita el presupuesto de solicitudes y los resultados obsoletos; los permisos de ejecución los controlan el orquestador y la capa de herramientas restringidas, y no los concede directamente una sola determinación de Jev.

El 2026-09-22 usamos jev-1.13.0 para ejecutar 19 turnos sintéticos una vez en shadow y una vez en enforce, en total 38 ejecuciones, y registramos 165 decisiones reales de Jev. Este informe de calibración interno y las respuestas reales guardadas usan un proveedor de LLM falso y scriptado, por lo que estos datos solo describen el comportamiento de decisión en escenarios controlados. No pueden demostrar la tasa de éxito global, la proporción de ahorro ni la latencia de extremo a extremo con solicitudes de usuarios reales.

El hallazgo más valioso no fue la velocidad media, sino que un umbral «aparentemente seguro» causaba bloqueos: de los 19 turnos en enforce, 13 escalaron en Q2, «¿hay información suficiente para empezar a modificar?», porque la probabilidad de Noul caía en el intervalo de incertidumbre original de 0.15–0.85; el LLM Worker no tuvo oportunidad de ejecutar los pasos siguientes. El registro de calibración muestra que, de 34 decisiones Q2 etiquetadas como con información suficiente, muchas probabilidades estaban en la zona media. El informe recomienda dividir el Q2 complejo en juicios más atómicos o ajustar las reglas de escalada; estas son recomendaciones, no umbrales ya desplegados.

Nuestro banco de preguntas clasifica la entrada como answer_only, inspect, modify o out_of_scope; en la ruta de escritura, las modificaciones candidatas propuestas por el Worker se ordenan primero con Score, y el contenido final y el resumen de cambios pasan después por la aceptación y la decisión de commit. Estos son solo puntos de decisión: que se pueda leer o escribir realmente un objeto sigue dependiendo de que el ejecutor restringido conceda permisos por etapas. Jev no tiene autoridad para ampliar por su cuenta la lista blanca de herramientas ni para saltarse la comprobación de consistencia previa al commit.

Los datos de calibración revelan otro compromiso. En el modo shadow, Jev da respuestas y la distribución completa, pero no cambia la ruta de ejecución original del Worker; en el modo enforce, la respuesta influye en si se continúa, se escala o se descarta. Tomar directamente la precisión de shadow como tasa de finalización de enforce haría malinterpretar el sistema: la escalada de Q2 intercepta la tarea de antemano, de modo que las preguntas posteriores de puntuación de candidatos, aceptación y commit no llegan ni a aparecer. Por eso este informe lee por separado la distribución de cada pregunta, la dirección de la escalada y el estado final.

En las modificaciones candidatas hay un contraste concreto: en el mismo turno, la candidata que modificaba con precisión el objetivo obtuvo 2.94 puntos, mientras que la candidata que sobrescribía todo el archivo obtuvo 0.38; se eligió la candidata de mayor puntuación. Este ejemplo solo muestra que, en ese escenario sintético, la pregunta de puntuación distinguió las dos opciones. A la inversa, una candidata cuya evidencia estaba truncada obtuvo 2.27 puntos, y no hay que ignorar su baja confianza y su marca de truncamiento porque el número parezca «bastante bueno». Nuestro código marca por separado la evidencia incompleta para evitar que el modelo tome una decisión de escritura determinista basándose solo en el prefijo conservado.

También separamos «qué candidata elegir» y «permitir que escriba» en dos pasos distintos. Después de que Jev puntúe las candidatas, el ejecutor restringido solo abre las herramientas de escritura en la fase ACT/modify; el ticket de un solo uso emitido vincula el ID de llamada a la herramienta, el número de revisión actual, el hash del objeto destino y el resumen de parámetros. Aunque el texto candidato induzca al modelo a «ignorar las restricciones», no obtiene permisos de herramienta que superen estas comprobaciones. Esta es la lección que sacamos de la integración a nivel de código: el juicio probabilístico decide qué camino merece seguirse, y los permisos de efectos secundarios los determinan condiciones de programa revisables.

Las rutas de fallo también deben diseñarse. El cliente solo reintenta de forma limitada ante timeout, errores de red, 429 o 5xx; las respuestas canceladas o que superan la fecha límite del turno se descartan directamente. Si Jev no está disponible en el modo enforce, no se puede continuar sin autorización de degradación; cuando se permite pasar a llm_only, el ejecutor se bloquea en solo lectura. Si la rama ya ha sufrido modificaciones y entonces se pierde Jev, el orquestador marca todo el turno como fallido, en lugar de dejar que los LLM posteriores hagan escrituras sin la capa de decisión. Estas rutas tienen un coste para la experiencia del usuario, pero evitan que «el modelo no está disponible temporalmente» se convierta en silencio en «los permisos de escritura siguen igual».

El informe de calibración también distingue entre «escalada por baja confianza» y «rechazo de ejecución». Por ejemplo, un discard correcto que no alcanza el umbral unificado de 0.85 se registra como que necesita entrada del usuario; eso no equivale a un permiso de paso erróneo. Sobre esta base, el informe recomienda separar los umbrales de commit y descarte, aunque por ahora sigue siendo una recomendación. Al escribir un flujo de trabajo hay que distinguir entre permiso de paso erróneo, rechazo erróneo y pendiente de revisión; de lo contrario, el mismo conjunto de datos llevará a conclusiones erróneas sobre los umbrales.

Este caso nos dice que la colaboración entre Jev y un LLM no puede dibujarse solo como «Jev decide primero y el LLM trabaja después». Cada juicio debe preguntar: ¿qué ancho tiene el intervalo de incertidumbre? ¿Hará que los procesadores posteriores nunca reciban la tarea? Si la evidencia de entrada está truncada, ¿se puede escalar explícitamente en lugar de adivinar? En nuestra implementación, el constructor de state registra evidence_truncated y hace que quien llama trate la ruta sin evidencia como incierta; los cálculos deterministas, como conteos y ordenaciones, se hacen primero en el código; no se dejan para que Jev los adivine. Las limitaciones conocidas oficiales de Jev 1.13 también recomiendan dejar los conteos y la aritmética en el código.

¿Dónde deben colocarse las barreras de seguridad del LLM?

El cookbook de guardrails para LLM de TypeSafe coloca a Jev a ambos lados de la entrada y la salida del LLM. Usa un conjunto de Noul para identificar distintos riesgos, Score para medir la gravedad, y luego el código decide según la política si permite el paso, lo revisa humanamente, lo bloquea o lo deriva a soporte. La salida también debe comprobarse, porque una entrada normal todavía puede producir una generación inadecuada.

Los límites de este tipo de barreras también son claros: Jev puede comprobar contenido según preguntas escritas de antemano, pero no es una prueba de seguridad universal. La documentación oficial de limitaciones menciona explícitamente que el contenido malicioso puede influir en el juicio y exige redactar bien los criteria y probar los límites. En nuestras muestras sintéticas hicimos 16 sondas de inyección contra los parámetros candidatos y registramos 0 inversiones de ordenación; la muestra es demasiado pequeña para concluir que «la resistencia a la inyección de prompt está resuelta». Lo que realmente determina lo que una herramienta puede hacer siguen siendo la lista de permitidos, las puertas por fases y las comprobaciones previas al commit en el código.

¿Cuándo conviene usarlo y cuándo no?

Jev es adecuado cuando: el conjunto de candidatos es conocido, la pregunta puede dividirse en unos pocos juicios breves y el software necesita probabilidades para decidir entre procesamiento automático o escalada a una persona. Por ejemplo, enrutamiento de atención al cliente, filtrado de pasajes RAG, puntuación de acciones candidatas de un Agent y verificación de citas en resultados generados. Si la tarea exige escribir una respuesta, modificar un fragmento de código o explicar un razonamiento complejo, la asume el LLM. Si la tarea es calcular dinero con precisión, comparar fechas o comprobar control de acceso, el programa debe calcularlo directamente. La página de modelos también indica que Jev solo acepta texto y que el inglés es el idioma de entrenamiento con mejor rendimiento actual; los escenarios en chino necesitan evaluarse con datos propios y no pueden adoptar sin más los umbrales del cookbook en inglés.

Si quieres observar cómo un Agent real gestiona permisos y llamadas a herramientas, puedes empezar por Agent de PandaNpc; sobre los límites y casos de uso de los agentes de programación, también puedes consultar Comparación entre Claude Code y Codex.

El lector puede empezar con un conjunto de validación muy pequeño: preparar cuatro tipos de muestras, «claramente procesable de forma automática», «claramente rechazable», «semánticamente ambigua» y «con instrucciones maliciosas»; primero establecer las etiquetas humanas y después registrar las probabilidades de Jev para cada pregunta y los resultados de enrutamiento. El criterio de éxito no es que todas pasen automáticamente, sino que la tasa de error de la ruta de procesamiento automático y el volumen de escaladas humanas queden dentro de lo que puedes aceptar. Si muchas muestras ambiguas se atascan en la misma pregunta, comprueba primero si la pregunta mezcla varios juicios, si el state es demasiado largo o si los umbrales se han calibrado con datos locales.

FAQ

¿Jev puede sustituir a Claude Code, Codex o a un modelo de chat? No. TypeSafe lo posiciona como un modelo de decisión estructurada dentro del software; el chat, la escritura y la generación de código siguen necesitando un LLM.

¿Que el tipo de retorno sea fijo significa que no cometerá errores? No. Los tipos fijos reducen problemas de análisis y de salida fuera de rango, pero la clasificación, la puntuación y los juicios de hecho todavía pueden fallar. Las rutas de baja confianza y alto riesgo deben mantener revisión humana.

¿Cuántas preguntas se pueden hacer en la misma solicitud? Se pueden poner en una sola solicitud varios Choice, Score y Noul independientes que compartan el mismo state. Cada pregunta se evalúa por separado; los juicios complejos deben seguir dividiéndose y luego combinarse mediante código.

¿Se puede usar en chino? La documentación oficial afirma que admite lenguajes naturales, incluidos caracteres chinos, japoneses y coreanos, pero la precisión en inglés es actualmente la mejor. Las cargas de trabajo en chino necesitan validación y calibración por separado.