Cómo usar Jev para enrutar correos y tickets: de una demostración de clasificación a un flujo de negocio completo

Clasificar rápidamente 500 correos en unas pocas categorías es una demostración de Jev fácil de entender.

El autor de un ejemplo comunitario informó que Jev podía clasificar por lotes 500 correos en pocos segundos por un coste aproximado de 0.035 dólares. Sin embargo, la demostración no publicó la composición de los correos, la definición de las categorías, las etiquetas humanas, la precisión ni la matriz de confusión. Por eso resulta más apropiada para ilustrar una posible forma de llamar al modelo que para demostrar que el enfoque ya puede sustituir el enrutamiento de atención al cliente en producción.

En un sistema real de correo y tickets, la dificultad tampoco se limita a decidir «¿a qué departamento debe ir este mensaje?».

Un mismo ticket puede incluir un cobro duplicado, una solicitud de reembolso, una amenaza de contracargo y varias reclamaciones sin resolver. Enviarlo a la cola billing puede ser una clasificación correcta y, aun así, el sistema puede pasar por alto las señales de riesgo que requieren mayor prioridad.

Jev encaja mejor no como una herramienta que «resuelve todo el flujo de soporte con una sola clasificación», sino como una capa de decisión: descomponer un correo en varias preguntas con límites claros y entregar después los resultados estructurados al código de negocio para combinarlos, enrutar y ejecutar acciones.

Correo o ticket de soporte
   ↓
Preprocesamiento: extraer asunto, cuerpo y el contexto histórico necesario
   ↓
Jev: selección de cola, detección de reembolso, detección de riesgo y puntuación de urgencia
   ↓
Reglas de negocio: combinar probabilidades, umbrales, datos del cliente y políticas de la empresa
   ↓
Enrutamiento automático / revisión humana / escalado de alto riesgo / generación de un borrador de respuesta

La división de responsabilidades más importante es esta: Jev realiza juicios semánticos, el código controla el flujo y el personal de soporte o un modelo generativo prepara la respuesta final.

Por qué Jev encaja en esta capa de decisión

Jev no es un modelo conversacional diseñado para generar textos largos. Recibe un state y responde typed questions definidas previamente por el desarrollador. Estas preguntas adoptan principalmente tres formas:

Tipo	Pregunta adecuada	Resultado devuelto
Choice	¿Cuál es la cola más adecuada para este ticket?	Una opción, las probabilidades de cada opción y confidence
Noul	¿El usuario solicita explícitamente un reembolso?	Una probabilidad de «sí» entre 0 y 1
Score	¿En qué nivel de urgencia se encuentra este ticket?	Una puntuación, las probabilidades de cada nivel y confidence

Se pueden evaluar varias preguntas en paralelo dentro de una misma solicitud. En lugar de pedir al modelo que lea el ticket, redacte un análisis y obligar después al programa a interpretar ese texto, suele ser más limpio formular varias preguntas atómicas cuyos resultados ya puedan usarse directamente en el código posterior.

Pero una respuesta tipada solo garantiza que el resultado se ajusta a una interfaz predefinida. No garantiza que el juicio de negocio sea correcto. El sistema sigue necesitando umbrales, rutas de reserva, revisión humana y evaluación fuera de línea.

Un ticket no debería reducirse a una sola pregunta

Supongamos que un usuario envía este correo:

Después de pasarme al plan Pro me cobraron dos veces. Me puse en contacto con ustedes hace tres días y nadie ha resuelto el problema. Devuélvanme el dinero hoy o presentaré un contracargo ante mi banco.

Si la única pregunta es «¿a qué departamento pertenece este correo?», la respuesta probablemente será billing. Sin embargo, un sistema de producción necesita conocer al menos otras cuatro cosas:

Decisión	Tipo de pregunta	Opciones o criterios recomendados	Finalidad
¿Qué cola principal debe recibirlo?	Choice	billing / shipping / technical / account / sales / legal / none	Enrutamiento inicial
¿Existe una solicitud de reembolso?	Noul	Considerar «sí» una petición explícita de devolver, revertir o reintegrar un cargo	Activar el flujo de reembolso
¿Existe riesgo de contracargo, reclamación regulatoria o acción legal?	Noul	Mención de chargeback, queja ante el banco, organismo regulador o acción legal	Escalado de alto riesgo
Urgencia	Score	Consulta general sin plazo / el servicio ya está afectado o el usuario ha contactado varias veces / pérdida económica, contracargo o plazo explícito	Prioridad de la cola
¿Hace falta intervención humana?	Noul	Dinero, asuntos legales, reclamaciones repetidas sin resolver o una decisión incierta del modelo	Decidir si se permite el tratamiento automático

Estas preguntas están relacionadas, pero no deberían condensarse en una sola petición como «decide en conjunto cómo debe gestionarse este ticket».

La guía oficial de diseño de Jev recomienda descomponer las tareas complejas en juicios atómicos. Una vez separadas las preguntas, el código de negocio puede decidir de manera independiente a qué cola enviar el ticket, si debe aumentar su prioridad, si hay que detener una respuesta automática y si es necesario avisar a la persona de guardia.

Una pregunta Choice también debería incluir una opción como none, other o unclear. Si la respuesta correcta no aparece entre las opciones, el modelo no puede inventar una cola nueva; solo puede forzar el ticket hacia la alternativa disponible más cercana.

Entre la salida del modelo y la acción de negocio sigue haciendo falta una capa de reglas

El siguiente pseudocódigo de control de flujo muestra la división de responsabilidades entre Jev y el sistema que lo rodea. No es una solicitud literal del SDK oficial:

const decision = await evaluateTicket(ticket, ticketQuestions)

if (decision.transportFailed) {
  return moveToQueue("manual_triage", {
    reason: "decision_service_unavailable"
  })
}

if (
  decision.chargebackRisk >= T_CHARGEBACK ||
  decision.legalRisk >= T_LEGAL
) {
  return moveToQueue("risk_escalation", {
    priority: "highest",
    requireHuman: true
  })
}

if (
  decision.teamTopProbability < T_ROUTE ||
  decision.teamProbabilityMargin < T_MARGIN
) {
  return moveToQueue("manual_triage", {
    reason: "uncertain_route"
  })
}

moveToQueue(decision.team)

if (decision.refundIntent >= T_REFUND) {
  attachWorkflow("refund_review")
}

if (decision.urgency >= T_URGENCY_HIGH) {
  raisePriority()
}

Constantes como T_ROUTE y T_REFUND no son valores universales incorporados en Jev, sino políticas de negocio. Deben calibrarse con los propios datos de tickets y pueden variar según el nivel de riesgo, el idioma, la versión del modelo y la definición de las colas.

Para consultas ordinarias de bajo riesgo, el sistema puede aceptar umbrales más flexibles de enrutamiento automático. Para reembolsos, contracargos, suspensiones de cuenta o reclamaciones legales, conviene aplicar umbrales más estrictos y mantener la revisión humana.

Las llamadas por lotes son adecuadas para enrutar, pero las puertas de alto riesgo requieren más cautela

Una característica de la interfaz oficial de Jev es que una solicitud puede responder varias preguntas en paralelo. No se debe asumir que agrupar varios tickets produzca resultados que se alineen con las llamadas individuales; los lectores deben comparar mediante benchmarks el comportamiento por lotes frente al procesamiento elemento por elemento con sus propios datos.

Frente al patrón «una solicitud por correo y otra por cada pregunta», agrupar las decisiones necesarias en el menor número de llamadas posible suele reducir los viajes de red y facilitar el control del rendimiento al seleccionar colas, asignar etiquetas temáticas o determinar prioridades ordinarias.

Sin embargo, no debe asumirse la equivalencia en las probabilidades Noul, sino validarla con los propios datos, gestionando de forma separada los tickets de alto riesgo o con decisiones inciertas.

Por eso, un diseño más prudente en dos fases sería:

1. En la primera fase, evaluar por lotes decisiones de bajo riesgo como la cola principal, el tema y si el mensaje es claramente spam.
2. Para tickets relacionados con reembolsos, contracargos, riesgo legal o probabilidades dentro de una zona de incertidumbre, hacer una revisión individual o enviarlos directamente a una cola humana.

El objetivo no es hacer que el modelo vote repetidamente, sino dar a las acciones de alto riesgo un contexto más claro y una ruta de tratamiento más estricta.

No interpretes confidence como «precisión»

Choice y Score devuelven confidence, pero este campo describe lo concentrada que está la distribución de probabilidades. No constituye una probabilidad de corrección directamente validada para el negocio del lector.

Por ello, el campo confidence requiere calibración con los propios datos de negocio antes de utilizarse en decisiones operativas. Esto hace insegura una regla simplista como la siguiente:

confidence alto → ejecutar automáticamente

Un sistema real debería observar varias señales a la vez:

• la probability de la opción mejor situada;
• el margen de probability entre la primera y la segunda opción;
• un Noul independiente correspondiente al riesgo de negocio;
• si el ticket procede de una distribución no cubierta por los datos de entrenamiento o validación;
• si ha cambiado la versión del modelo o la redacción de la pregunta.

«¿A qué cola debe ir?» y «¿debe procesarse automáticamente?» tampoco deberían resolverse con un único Choice. Usa Choice para elegir la cola y un Noul separado para comprobar si se cumplen las condiciones de tratamiento automático.

La redacción de las preguntas debe gestionarse como código

En un flujo con Jev, la redacción de las preguntas no es un simple texto de prompt, sino parte de la lógica de negocio.

Si el significado de instructions y criteria entra en conflicto, el resultado puede ser estructuralmente válido pero semánticamente incorrecto sin que se produzca una excepción en la llamada. Por eso, las definiciones de las preguntas requieren un versionado estricto y una revisión de contradicciones antes de pasar a producción.

Por tanto, un proyecto de enrutamiento de correo debería gestionar las definiciones de las preguntas al menos con estas prácticas:

Elemento de gestión	Práctica concreta
Versionado	Crear una versión nueva cada vez que cambie la redacción, las opciones o los criterios
Revisión de código	Guardar las definiciones de preguntas y las reglas de enrutamiento en el repositorio para su review, en lugar de dispersarlas en campos de texto administrativos
Ejemplos de prueba	Conservar ejemplos positivos, negativos, limítrofes y con múltiples intenciones para cada pregunta
Comprobación de conflictos	Verificar que instruction y true/false criteria apunten en la misma dirección semántica
Fijar la versión del modelo	Una vez calibrados los umbrales, fijar una versión concreta en lugar de depender directamente de un latest alias cambiante

Cada nivel de Score debería describir una situación de negocio observable, no limitarse a «bajo, medio, alto». Por ejemplo, «el usuario solo pregunta por el precio» y «el usuario ha contactado varias veces y el servicio no está disponible» se evalúan de forma más estable que «urgencia media».

El sistema debe saber qué hacer cuando falla la red

Una respuesta fallida del modelo de clasificación no debe interpretarse como «no hay riesgo» o «permitir por defecto».

En escenarios reales de alta concurrencia o tráfico variable, las llamadas pueden experimentar fallos de transporte o aumentos de latencia. Por eso, un sistema de producción no puede implementar únicamente la ruta ideal y debe contemplar la resiliencia operativa.

Se necesitan al menos cuatro capas de protección:

1. Reintentos y espera progresiva: da prioridad a un SDK que admita reintentos y retry-after, para que un error de red transitorio no haga perder el ticket.
2. Semántica explícita de degradación: decide de antemano si la indisponibilidad del servicio envía el ticket a revisión humana, retrasa el procesamiento o ejecuta únicamente reglas deterministas.
3. Idempotencia y deduplicación: la nueva entrega del correo, los reintentos de la cola o los reintentos por timeout no deben crear tickets duplicados.
4. Registro completo: conserva la versión del modelo, la versión de las preguntas, probabilities, latencia de la llamada, uso y resultado final de la intervención humana.

Para tickets financieros, de cuenta o legales, la degradación predeterminada más segura no suele ser «aprobar automáticamente», sino «detener la acción automática y enviar a una persona».

Las colas multilingües no pueden compartir un único conjunto de umbrales de Score

Al evaluar entradas en distintos idiomas, no debe asumirse que los umbrales de Score o los niveles de confidence sean transferibles entre lenguas. Los umbrales no deben darse por sentados y deben validarse por separado para cada idioma.

Por tanto, un sistema de soporte multilingüe debería, como mínimo:

• crear un conjunto de validación independiente para cada idioma;
• calibrar por separado los umbrales de urgencia y escalado humano;
• no copiar directamente a otros idiomas los intervalos de puntuación calibrados con datos en una sola lengua;
• aplicar una política coherente sobre traducción, texto original e historial de conversación.

Qué debe evaluarse antes del lanzamiento

Un sistema de enrutamiento de correo no puede juzgarse solo por su precisión global. Los distintos errores tienen costes muy diferentes. Enviar una consulta de preventa a la cola de soporte quizá solo provoque una transferencia adicional; pasar por alto una amenaza de contracargo o una reclamación legal puede generar un riesgo financiero y de cumplimiento directo.

Como mínimo, conviene observar por separado estas métricas:

Métrica	Pregunta que debe responder
Precisión de la cola principal	¿Llegó el ticket a la primera cola de atención correcta?
Recall de alto riesgo	¿Cuántos tickets de contracargo, legales, regulatorios o de seguridad de cuenta quedaron sin detectar?
Cobertura del enrutamiento automático	¿Qué proporción de tickets evitó la clasificación manual inicial?
Tasa de tratamiento automático incorrecto	¿Cuántos tickets que debían requerir una persona avanzaron automáticamente?
Tasa de revisión humana	¿Son los umbrales tan conservadores que la cola humana pierde su utilidad?
Latencia y tasa de fallos	¿Es estable el sistema con la concurrencia, la longitud de los correos y las condiciones de red reales?
Coste total por ticket	Después de decisiones, reintentos, modelos posteriores y revisión humana, ¿sigue siendo rentable el flujo?

Al elegir referencias de comparación, no enfrentes Jev únicamente a modelos conversacionales de frontera y alto coste. Los sistemas de reglas, los modelos Flash con salida estructurada, embeddings más un clasificador y los modelos pequeños entrenados con datos propios etiquetados también pueden ser alternativas razonables.

Cuando se dispone de datos etiquetados para tareas específicas, se recomienda evaluar y comparar mediante benchmarks un clasificador especializado o un modelo ajustado a la tarea frente a la solución existente. Una evolución razonable consiste en usar Jev durante el arranque en frío y mientras las etiquetas cambien con frecuencia, y evaluar mediante benchmarks si una cola de gran volumen debe migrar a un clasificador local o especializado una vez que existan suficientes datos etiquetados.

Jev no redacta la respuesta final de soporte

Después del enrutamiento, el sistema todavía puede necesitar resumir el problema, recuperar el pedido, comprobar si procede un reembolso o generar un borrador de respuesta. No conviene asignar todas esas tareas a Jev.

Una división más clara del trabajo sería:

Etapa	Ejecutor más adecuado
Consulta exacta de pedidos, cálculo de importes y comparación de fechas	Código de negocio y bases de datos
Juicios sobre cola, riesgo, intención y urgencia	Jev u otro modelo de clasificación
Recuperación desde la base de conocimiento	Sistemas de búsqueda y RAG
Borrador de respuesta, explicación y comunicación en lenguaje natural	Una LLM generativa
Aprobación de reembolsos, suspensión de cuentas y gestión legal	Personas y políticas de la empresa

Esta arquitectura no convierte a Jev en un «agente automático de soporte». Solo añade una capa de decisión económica, estructurada y directamente consumible por el código antes de que cada correo llegue a un modelo costoso o a una cola humana.

Conclusión: la clasificación no es el producto; el flujo de control sí

Jev muestra una dirección útil: cuando el software solo necesita una cola, una probabilidad o un nivel, no es necesario llamar cada vez a un modelo generativo para que escriba un texto y obligar después al código a adivinar lo que quiso decir.

Pero pasar de una demostración de clasificación de correos a un flujo de negocio completo exige diseñar el control posterior a la clasificación: qué tickets pueden enrutarse automáticamente, qué señales deben detectarse por separado, cuándo debe intervenir una persona, cómo se degrada el sistema si falla el servicio y cómo comprobar continuamente los umbrales con datos realmente etiquetados.

Por tanto, un sistema de tickets con Jev no debería evaluarse solo preguntando «¿con qué rapidez clasificó 500 correos?». La pregunta más útil es:

¿Reduce de forma estable las transferencias innecesarias, las llamadas a modelos y la clasificación humana inicial sin dejar escapar tickets de alto riesgo?

Solo cuando esa pregunta recibe una respuesta positiva con los propios datos de negocio, el enrutamiento de correo pasa de ser una demostración de modelo a convertirse en un flujo de trabajo utilizable.