Nada en el ejemplo de triaje de soporte afirma estar validado con el modelo real. Eso es así a propósito: es un espacio reservado para un trabajo que todavía no se ha hecho. Este es el plan que de verdad seguiría antes de confiar en eso con tickets reales.
Define la decisión y el coste del error
Evaluar tiene que partir de qué cuesta una respuesta equivocada, no de un número de precisión genérico. En el ejemplo de triaje, dejar pasar un ticket genuinamente urgente y marcar uno rutinario como urgente no cuestan lo mismo. Uno demora a un cliente que necesitaba ayuda ahora. El otro le hace perder un par de minutos a un agente. Enrutar al equipo equivocado cuesta un reenrutamiento, molesto pero barato de arreglar. Equivocarse feo en el puntaje de impacto puede significar dejar sin prioridad a un cliente que de verdad está bloqueado.
Anota estos costes por rama antes de medir nada. Una sola regla de decisión aplicada igual a los tres juicios asume que son igual de riesgosos, y no lo son.
Construye un conjunto de evaluación útil
Un conjunto representativo significa tickets reales y desordenados. Los ejemplos limpios que usé antes para mostrar la forma de la API no cuentan. Necesita casos genuinamente ambiguos entre equipos, tickets con contexto incompleto, mensajes que declaran una urgencia que el cliente en realidad no tiene, solicitudes que intentan convencer al sistema de subir su propia prioridad, y, esto importa, tickets genuina e inequívocamente urgentes, para comprobar que el modelo tampoco los deja pasar como rutinarios.
Reserva una porción que no toques mientras ajustas los umbrales, la misma disciplina que necesita cualquier clasificador. Trata el idioma como una variable aparte: el idioma principal de entrenamiento de Jev es el inglés, y la propia documentación de TypeSafe es explícita en que otros idiomas, el español incluido, se aceptan pero con menor precisión. Un conjunto de evaluación en inglés no dice nada confiable sobre el rendimiento en tickets en español. Si los lectores en español de este sitio están construyendo el mismo tipo de flujo, esa es una evaluación aparte, nunca una suposición heredada de los resultados en inglés.
Mide el flujo completo
La precisión sobre las sugerencias que el sistema muestra no es, por sí sola, un número útil. Todo resultado que devuelve el código, incluida una sugerencia, sigue llevando requiresHumanReview: true, así que nada aquí es apto para automatizar, y ajustar un umbral no cambia eso. Lo que sí mueve un umbral más estricto es el reparto entre tres números, medidos juntos para cada política candidata: la cobertura de sugerencias, la proporción de tickets elegibles que vuelven como kind: "suggestion"; la proporción de casos sin sugerencia, la que vuelve como kind: "review"; y la tasa de error entre las sugerencias, que usa como denominador solo los casos sugeridos. Reporta aparte las respuestas inválidas y los fallos de servicio, para que no desaparezcan silenciosamente del número de cobertura. Si un nivel de cobertura dado realmente ahorra tiempo de revisión es una pregunta distinta, que necesita su propia medición de cuánto tarda una revisión con sugerencia y sin ella. No se deduce solo de la cobertura.
Fija la versión del modelo mientras mides. Al 21 de septiembre de 2026, jev-1.13.0 es lo que apuntan tanto jev-latest como jev-preview, pero un alias puede moverse a una versión nueva entre que ajustas un umbral y lo vuelves a revisar, y una versión nueva no está obligada a comportarse igual con el mismo valor de confianza. Registra la versión que reporta cada respuesta real, y vuelve a medir antes de confiar en un umbral viejo contra un modelo nuevo.
Nada de esto se ha ejecutado todavía para este proyecto. Este es el protocolo. Todavía no tengo resultados que reportar.
Decide qué se puede automatizar
La propia guía de TypeSafe sobre confianza describe tres franjas generales: confianza alta, donde actúas de forma automática; media, donde avanzas con cautela; baja, donde derivas a una persona y no adivinas. Eso se traduce directamente en lo que cambia una vez que existen números de evaluación reales. Ahora mismo, cada camino del ejemplo de triaje termina en requiresHumanReview: true, a propósito, porque todavía no se ha medido ninguna política.
Una vez que una rama concreta se evalúa, por ejemplo el enrutamiento de equipo de bajo riesgo con un piso de confianza medido, y la tasa de error medida en ese piso resulta aceptable para lo que realmente cuesta enrutar mal, esa rama puede graduarse a actuar de forma automática, y solo esa rama. La detección de urgencia es distinta: dado el coste desigual de dejar pasar algo genuinamente urgente, necesitaría evidencia medida mucho más sólida, una política probada sobre muchos más casos reservados, antes de que yo la dejara saltarse a una persona por completo, si es que alguna vez lo hago. Eso no es lo mismo que subir urgentYesMin sin más; mover ese número hacia arriba no reduce por sí solo los casos urgentes que se dejan pasar, y podría empeorarlos. No existe un número único y seguro que sirva para todo. El número tiene que salir de medir tus propios casos contra lo que de verdad te cuesta un error ahí.