Clasificación de emails con IA: reglas, prompts LLM o una API de decisión tipada para el correo entrante

Un ticket de soporte suele llegar como una descripción limpia. Un email llega como un sobre: cabeceras From, To y Reply-To, un asunto que puede decir “Re: Fwd: Factura”, la respuesta nueva arriba, varios mensajes citados debajo, una firma, un pie de confidencialidad y a veces adjuntos. La ruta depende sobre todo del último párrafo escrito por una persona y de unas pocas cabeceras: a qué alias se envió, si el dominio del remitente es de un cliente o de un proveedor, y si es una respuesta automática o un rebote. Si envías el mensaje en bruto, el modelo lee el historial citado y el pie como evidencia y a menudo clasifica por el tema de un correo de hace tres semanas. La clasificación de intención pregunta qué quiere quien escribe; la de emails primero decide qué parte del correo es lo que esa persona dice ahora. Para el diseño de colas, ver support-triage; para labels de intención entre canales, intent-classification.

La mayoría de buzones en producción acaban con las tres capas: reglas para hechos conocidos, un modelo para la prosa y código que aplica umbrales. La tabla compara mantenimiento y modos de fallo; no es un benchmark y ninguna opción sustituye un set etiquetado con tu propio correo.

Haz el parseo del email en tu propio código y envía un state JSON pequeño. Conserva: el asunto sin prefijos “Re:” y “Fwd:”, el alias destinatario (billing@, sales@), el dominio del remitente y si está en tu lista de clientes o proveedores, y el cuerpo del mensaje más reciente. Elimina: respuestas citadas (líneas con “>” y bloques tras “On … wrote:”), firmas, pies de confidencialidad, píxeles de seguimiento y HTML. En una cadena reenviada, conserva la nota de quien reenvía más un extracto corto del primer párrafo del remitente original, marcado como reenviado. De los adjuntos pasa solo nombre y tipo: JevModel acepta texto o JSON, no archivos ni imágenes, así que “invoice.pdf adjunto” es una pista, no evidencia de lo que dice el PDF. En JevModel el state serializado y la petición completa deben caber cada uno en 8.000 caracteres, algo que un email recortado casi siempre cumple. El ejemplo hace una pregunta Choice para la ruta y una Noul para saber si una persona debe mirarlo ya.

{
  "state": {
    "subject": "Invoice 2291 charged twice",
    "to_alias": "billing@",
    "sender_domain": "customer-example.com",
    "sender_known_as": "customer",
    "latest_message": "Hi, our card was charged twice for invoice 2291 this morning. Can you refund the duplicate?",
    "attachments": [
      "receipt.png (not read)"
    ]
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Which team should own the newest message in this email? Ignore attachment names as evidence.",
      "criteria": {
        "support": "Product questions, bugs, how-to or account access problems.",
        "sales": "Pricing, plans, demos, procurement or purchase questions from prospects.",
        "billing": "Charges, refunds, invoices, receipts or payment method changes.",
        "vendor": "Messages from suppliers or partners about their own services or invoices to us.",
        "low_value": "Cold outreach, newsletters, automatic notifications needing no action."
      }
    },
    "needs_person_now": {
      "type": "noul",
      "instructions": "Should a person read this email today instead of waiting in a queue?",
      "criteria": {
        "true": "Money, access, legal or a clear deadline is at stake today.",
        "false": "It can wait in the normal queue."
      }
    }
  }
}

Usa tres bandas por ruta, fijadas con tu propio correo reservado. Banda alta: mueve el email a la carpeta o cola del equipo y añade un label—acciones de bajo riesgo y reversibles. Banda media: a una vista de revisión compartida con las dos rutas sugeridas principales; aquí caen los emails mixtos (“gracias por la demo, además la factura está mal”). Banda baja o casi empate entre dos rutas: déjalo en la bandeja general. Nunca dejes que un label de ruta dispare por sí solo un paso irreversible como un reembolso, una respuesta contractual o borrar el mensaje; exige una comprobación aparte en código y usa una pregunta Noul como needs_person_now para adelantar el correo urgente sea cual sea su ruta. Reajusta las bandas por alias, porque billing@ e info@ reciben mezclas muy distintas. El patrón general está en confidence-and-abstention.

Construye fixtures con correo real anonimizado y congélalos. Cubre las formas que rompen el enrutado de emails: una respuesta cuyo historial citado trata otro tema, una cadena reenviada donde quien reenvía solo escribe “ver abajo”, una respuesta de fuera de oficina, un rebote de entrega, una factura de proveedor enviada a billing@ (vendor, no billing), un cliente que escribe desde una dirección personal, un mensaje en un segundo idioma y una petición mixta que debe caer en la banda media. Ejecuta parser y clasificador juntos, porque la mayoría de regresiones vienen de cambios en el recorte, no del modelo. En Console → Batch de JevModel puedes subir filas CSV, TXT o JSONL con una pregunta fija, exportar respuestas por fila y unirlas a tus labels con un script; Batch no calcula la precisión por ti. Rechaza el cambio si las rutas doradas cambian o si los fixtures de banda media dejan de abstenerse. Ver evaluation y batch-text-classification-api.

JevModel es una API de decisión alojada: haces POST a /api/v1/systemone con el email recortado como state y 1–8 preguntas con nombre, y llama al modelo fijo typesafe/jev-1.13 vía OpenRouter. Encaja cuando varios servicios—un worker de correo, un help desk, una sincronización con el CRM—deben compartir una definición de rutas con probabilidades, y cuando quieres que la banda media llegue a personas en vez de adivinar. Choice admite 2–12 rutas, Score evalúa niveles ordenados como urgencia y Noul responde sí/no con probabilidad. No encaja como filtro de spam o phishing: mantén delante los filtros de spam y la autenticación de remitente de tu proveedor de correo. No lee adjuntos, imágenes ni PDFs escaneados, no es open source ni tiene pesos descargables, y las cuentas gratuitas verificadas tienen 5 ejecuciones exitosas por día UTC, así que un buzón compartido con mucho tráfico necesita un plan de pago o planificación por lotes. Para help desks, ver zendesk-ai-ticket-classification.