JEV - Por qué un Jev que no puede chatear encaja en un Agent

A un Agent le falta a menudo un juicio que pueda entrar en una rama, no otro tramo de texto largo. Este texto explica las tres preguntas, qué compara el workflow eval, y por qué una ruta caliente no puede esperar a un chat.

Folkbench folkbench.com

Coautor: folkbench.com (Folkbench es una plataforma revisable de evaluación y selección de API de IA, servicios de modelos y sitios relacionados. Se apoya en información de servicio publicada, precios, disponibilidad, latencia y ventanas de evidencia para ayudar a los usuarios a comparar y a elegir un camino.)

Diez textos en esta serie:

Lo que a un Agent le falta a menudo no es otro tramo de texto largo. Es un juicio que pueda entrar directo en el flujo de control. Los de siempre son si esta alerta se queda cerrada, si esta factura se paga, si esta traza necesita a una persona, y si la siguiente frase de atención al cliente debe escalarse. Estos nodos no están para que el modelo escriba un análisis. El código necesita un valor que pueda comparar y sobre el que pueda ramificar. Eso es lo que hace Jev.

La formulación de TypeSafe quiere decir una llamada a función de inteligencia de frontera. Entra el state. Sale una decisión probabilística tipada. No genera cadenas. La frase para una persona, y el juicio para un programa, no son la misma salida.

Fije primero la salida

La salida de los grandes modelos actuales es una cadena. El software que tiene que seguir aún debe analizarla, validarla y guardarse de la deriva. Aparece un campo de más. El párrafo parece completo, y la enumeración no casa. Una persona en un cuadro de chat se da cuenta y vuelve a preguntar. El código no se da cuenta, y sigue con el error. Enterrado a varias llamadas de profundidad, un modelo más listo no puede reponerlo.

Jev fija de antemano el espacio de salida. Usted dice qué se le permite devolver, y solo asigna probabilidad dentro de ese espacio. Un error de tipo no puede ocurrir, matemáticamente. No puede devolver una forma que usted no definió. Eso no es lo mismo que el juicio sea correcto. La probabilidad puede inclinarse al lado equivocado, y la opción puede ser la incorrecta. La seguridad de tipos cierra la forma, no el acierto y el error. Una vez fijada la forma, las ramas de después se pueden escribir. Usted no tiene que pescar primero un valor dentro de un párrafo.

Solo hay tres preguntas.

Noul es sí o no. El modelo da una probabilidad de 0 a 1. Cerca de 1 es sí. Cerca de 0 es no. Cerca de 0.5 es que no está seguro. No adjunta una confianza aparte. La probabilidad es la señal. Choice es opción única. Usted lista primero las opciones, con un tope de 255. Lo que vuelve es la opción elegida, la distribución sobre cada opción, y una confianza. El código usa esa distribución para decidir si actúa o entrega el caso a una persona. Score son niveles. Los niveles van de 2 a 10, y usted escribe qué significa cada nivel. Lo que vuelve es una puntuación, la distribución sobre los niveles, y una confianza. La puntuación puede caer entre dos niveles, como una posición en la escala.

Un sí o no se escribe como una condición. La opción única y los niveles son distintos: la primera mira en qué opción cayó, y los niveles ponen un umbral a la puntuación. Una buena pregunta sigue siendo estrecha. Un juicio que una persona que conoce el dominio puede hacer en un segundo después de leer el material es el tipo que hay que darle. Si el cliente está pidiendo un reembolso es esa clase de pregunta. Leer la carta entera y luego decidir la mejor acción no lo es. La segunda frase quiere razonamiento lento. Divídala, y luego pregunte. Las preguntas partidas miran el mismo state, independientes entre sí, y vuelven juntas en una petición. Los pesos se quedan en el código. Cuando cambia la política, usted cambia los números. No reescribe el prompt entero.

Lo que atasca a la gente es la bifurcación

Lo que de verdad atasca a la gente suele ser un nodo de esta forma. Llega una alerta con registros que la máquina ya tiene, y la conclusión es cerrarla, enviarla a un analista, o aislar ahora. Una factura cuelga de un pedido y de un registro de entrega, y alguien tiene que decidir pagar, retener, o devolverla. Un Agent de atención al cliente ha terminado, las llamadas a herramientas están todas en la traza, y alguien tiene que decidir si esta traza se mira, y cuán pronto. El cliente vuelve a escribir, y el hilo y el state de la cuenta están los dos ahí. Cómo debe seguir la frase siguiente, y si debe escalar, es la misma forma de pregunta.

La parte que las reglas pueden congelar es código. Lo frágil son las excepciones que no se pueden terminar. El recibo casa, el motivo es vago, y un paso de la traza se ve raro. La lógica escrita a mano se hace añicos con esto. Usted mete la política entera en un prompt y deja que el modelo lo piense de una vez, y escribe menos condicionales. La salida vuelve a ser un trozo de texto. Para que el texto entre en el flujo de control, usted escribe otra capa de análisis. Esa capa puede equivocarse por su cuenta.

El workflow eval de TypeSafe mide esta forma de conectar. La evaluación parte una tarea en muchas preguntas estrechas. Lo que el código puede decidir, lo decide el código. El modelo solo responde los juicios que el código no puede zanjar. Los cuatro flujos públicos son un incidente de seguridad, la observabilidad de la traza de un Agent, el manejo de facturas, y la atención al cliente. Bajo el mismo flujo, un modelo en el workflow es más preciso que meter la política entera en un prompt, y cuesta menos y tarda menos. Promediadas las cuatro tareas, los modelos bajo prueba se mueven en esa dirección.

Las acciones de después siguen la probabilidad, no una etiqueta que se ha cerrado de golpe. El resultado que sale del sistema sigue siendo una acción discreta. La ingeniería de en medio tiene que hacerse del mismo modo cada vez.

La evaluación mide la cercanía

Esta evaluación no discute con usted si el flujo en sí se escribió mal. Da por hecho que el harness es correcto. La respuesta de referencia no es una etiqueta de oro marcada a mano, pregunta por pregunta. GPT-6 Astra y Claude Fable 5.1 responden cada pregunta bajo high thinking, y las dos respuestas se promedian. Los demás modelos usan el razonamiento por defecto del proveedor. Solo después de fijar el flujo se pueden comparar. La evaluación compara cuánto se acerca un modelo a los juicios de esos dos grandes modelos, más la velocidad y el coste.

Así que el gráfico no demuestra que Jev entienda el negocio mejor que Astra. Astra y Fable son aquí la regla de medir. Jev tiene que acercarse a sus juicios, y también tiene que abrir una brecha en latencia y coste. Si las preguntas se partieron mal, una regla más cercana no ayuda. Partir las preguntas es trabajo de quien escribe el flujo.

Jev se sienta muy afuera en la frontera de «rápido y barato». Los múltiplos más altos del sitio oficial, unas 193.6 veces más rápido y 444.6 veces más barato, son el extremo alto de esta evaluación. Ese múltiplo no es cada llamada. Las llamadas de aquí se parecen más a la carga de automatización que usted pondría de verdad en producción.

A lo que se acerca es a la probabilidad de esas preguntas estrechas después del corte, no a la escritura de un análisis largo. Jev no escribe ese análisis largo.

Una ruta caliente no puede esperar

La latencia es dura para un Agent. Una persona aún puede esperar tres segundos. Cuando las capas envuelven capas, no pueden. La misma cadena tiene además recuperación, una escritura en base de datos, y la llamada siguiente, y cada salto gasta el mismo tiempo. Dentro de 70 a 500 milisegundos, un juicio puede sentarse en una ruta caliente. Fuera de ese intervalo, la pila de llamadas lo trata como bloqueo.

Hablando con una persona, los modelos de frontera actuales tardan de forma habitual de 3 segundos a más de 300 segundos de extremo a extremo. Esa velocidad tiene sentido para un copiloto, o para un Agent de programación con una persona mirando. Como condición en una ruta caliente, esa velocidad no. Jev no emite una frase token a token. Las probabilidades que deben volver llegan juntas. La velocidad sale de ahí.

TypeSafe también usa Jev para comprobar. Prompts, trazas de razonamiento y salidas de otros modelos, Jev los puntúa, y también hace de salvaguarda y busca jailbreaks. La generación se queda en el modelo de chat. Si se pasa esta puerta lo decide un modelo que no genera cadenas. Eso es una articulación en un Agent, no chat. Si el asentimiento y la revisión siguen sentados sobre texto largo, usted tiene que buscar otro programa que lo lea. Jev cierra el resultado en probabilidades y niveles, y la revisión se puede escribir como código.

La frase escrita para el usuario sigue siendo trabajo del modelo de chat. Jev no toma esa frase. Toma el enrutado de delante, y la comprobación de detrás. Lo que a un Agent le falta aquí no es una explicación más, y más larga. Es un juicio cuyo tipo ya está fijado, para que el código pueda caminar con él.

Fuentes

Serie