Como usar o Jev para rotear e-mails e tickets: da demonstração de classificação a um fluxo de negócio completo

Separar rapidamente 500 e-mails em algumas categorias é uma demonstração do Jev fácil de entender.

O autor de um exemplo da comunidade relatou que o Jev conseguiu classificar 500 e-mails em lote em poucos segundos, por cerca de US$ 0.035. Porém, a demonstração não publicou a composição dos e-mails, a definição das categorias, os rótulos humanos, a acurácia nem a matriz de confusão. Por isso, ela serve melhor para ilustrar uma possível forma de chamada do que para provar que a abordagem já pode substituir o roteamento de atendimento em produção.

Em um sistema real de e-mail e tickets, a dificuldade não se resume a decidir “para qual departamento esta mensagem deve ir?”.

Um único ticket pode envolver cobrança duplicada, pedido de reembolso, ameaça de chargeback e várias reclamações sem solução. Encaminhá-lo para a fila billing pode estar correto do ponto de vista da classificação, mas o sistema ainda pode deixar passar os sinais de risco que deveriam receber a maior prioridade.

O Jev se encaixa melhor não como uma ferramenta que “resolve todo o fluxo de suporte com uma única classificação”, mas como uma camada de decisão: dividir um e-mail em várias perguntas com limites claros e entregar os resultados estruturados ao código de negócio para combinação, roteamento e execução.

E-mail ou ticket de suporte
   ↓
Pré-processamento: extrair assunto, corpo e o contexto histórico necessário
   ↓
Jev: seleção de fila, detecção de reembolso, detecção de risco e pontuação de urgência
   ↓
Regras de negócio: combinar probabilidades, limiares, dados do cliente e políticas da empresa
   ↓
Roteamento automático / revisão humana / escalonamento de alto risco / geração de rascunho de resposta

A divisão de responsabilidades mais importante é esta: o Jev faz julgamentos semânticos, o código controla o fluxo, e a equipe de suporte ou um modelo generativo prepara a resposta final.

Por que o Jev se encaixa nessa camada de decisão

O Jev não é um modelo de chat voltado à geração de textos longos. Ele recebe um state e responde a typed questions definidas previamente pelo desenvolvedor. Essas perguntas assumem principalmente três formas:

Tipo	Pergunta adequada	Resultado retornado
Choice	Qual é a fila mais adequada para este ticket?	Uma opção, as probabilidades de cada opção e confidence
Noul	O usuário está pedindo explicitamente um reembolso?	Uma probabilidade de “sim” entre 0 e 1
Score	Em qual faixa de urgência este ticket se encontra?	Uma pontuação, as probabilidades de cada faixa e confidence

Várias perguntas podem ser avaliadas em paralelo dentro da mesma solicitação. Em vez de pedir ao modelo que leia o ticket, escreva uma análise e depois obrigar o programa a interpretar esse texto, costuma ser mais claro fazer várias perguntas atômicas cujos resultados já sejam adequados ao código posterior.

Mas uma resposta tipada só garante que o resultado respeita uma interface predefinida. Ela não garante que o julgamento de negócio esteja correto. O sistema ainda precisa de limiares, caminhos alternativos, revisão humana e avaliação offline.

Um ticket não deveria ser reduzido a uma única pergunta

Suponha que o usuário envie este e-mail:

Depois que fiz upgrade para o plano Pro, fui cobrado duas vezes. Entrei em contato há três dias e ninguém resolveu o problema. Façam o reembolso hoje, ou vou abrir um chargeback no meu banco.

Se a única pergunta for “a qual departamento este e-mail pertence?”, a resposta provavelmente será billing. No entanto, um sistema de produção precisa saber pelo menos outras quatro coisas:

Decisão	Tipo de pergunta	Opções ou critérios sugeridos	Finalidade
Qual fila principal deve recebê-lo?	Choice	billing / shipping / technical / account / sales / legal / none	Roteamento inicial
Existe um pedido de reembolso?	Noul	Considerar “sim” um pedido explícito para devolver, estornar ou reembolsar uma cobrança	Acionar o fluxo de reembolso
Existe risco de chargeback, reclamação regulatória ou ação jurídica?	Noul	Menção a chargeback, reclamação ao banco, órgão regulador ou medida judicial	Escalonamento de alto risco
Urgência	Score	Dúvida geral sem prazo / serviço já afetado ou contato repetido / perda financeira, chargeback ou prazo explícito	Prioridade da fila
É necessário atendimento humano?	Noul	Dinheiro, questões jurídicas, reclamações repetidas sem solução ou decisão incerta do modelo	Decidir se a automação é permitida

Essas perguntas se relacionam, mas não devem ser condensadas em uma única solicitação como “decida, de forma geral, como este ticket deve ser tratado”.

A orientação oficial de design do Jev recomenda decompor tarefas complexas em julgamentos atômicos. Depois que as perguntas são separadas, o código de negócio pode decidir de forma independente para qual fila enviar o ticket, se deve aumentar sua prioridade, se precisa interromper uma resposta automática e se é necessário avisar a pessoa de plantão.

Uma pergunta Choice também deve incluir uma opção como none, other ou unclear. Se a resposta correta não estiver entre as alternativas, o modelo não poderá criar uma nova fila; ele só poderá forçar o ticket para a opção disponível mais próxima.

Entre a saída do modelo e a ação de negócio ainda existe uma camada de regras

O pseudocódigo de controle de fluxo abaixo ilustra a divisão de responsabilidades entre o Jev e o sistema ao redor. Ele não é uma solicitação literal do 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 e T_REFUND não são padrões universais do Jev, mas políticas de negócio. Elas precisam ser calibradas nos dados de tickets da própria organização e podem variar conforme o nível de risco, o idioma, a versão do modelo e a definição das filas.

Para dúvidas comuns de baixo risco, o sistema pode aceitar limiares mais flexíveis de roteamento automático. Para reembolsos, chargebacks, bloqueios de conta ou reclamações jurídicas, devem ser usados limiares mais rígidos, mantendo a revisão humana.

Chamadas em lote funcionam bem para roteamento, mas portas de alto risco exigem mais cuidado

Uma característica da interface oficial do Jev é permitir que uma única solicitação responda a várias perguntas em paralelo. No entanto, não se deve presumir que agrupar múltiplos tickets em uma única chamada produza resultados alinhados aos de chamadas individuais; os leitores devem avaliar e comparar (benchmark) o comportamento em lote versus chamadas de itens individuais com seus próprios dados.

Em termos de engenharia, agrupar as decisões necessárias no menor número possível de chamadas costuma reduzir as viagens de rede e facilitar o controle de throughput em comparação com uma solicitação por e-mail e por pergunta.

Da mesma forma, não se deve presumir equivalência nas probabilidades de Noul entre processamento em lote e individual; essa equivalência precisa ser validada na prática, com tickets de alto risco ou com probabilidades incertas tratados separadamente.

Por isso, um desenho mais prudente em duas etapas seria:

1. Na primeira etapa, avaliar em lote decisões de baixo risco, como fila principal, assunto e se a mensagem é claramente spam.
2. Para tickets relacionados a reembolso, chargeback, risco jurídico ou probabilidades dentro de uma faixa de incerteza, executar uma revisão individual ou enviá-los diretamente para uma fila humana.

O objetivo não é fazer o modelo votar repetidamente, e sim dar às ações de alto risco um contexto mais claro e um caminho de tratamento mais rigoroso.

Não trate confidence como “acurácia”

Choice e Score retornam confidence, mas esse campo descreve apenas o grau de concentração da distribuição de probabilidades. Conceitualmente, confidence não é uma probabilidade diretamente validada de acerto para o negócio do leitor e não deve ser interpretado como garantia de exatidão.

O indicador precisa ser calibrado nos dados da própria organização antes de definir gatilhos de automação, em vez de presumir que alta confiança seja equivalente a acerto. Isso torna insegura uma regra como a seguinte:

confidence = 1.0 → executar automaticamente

Um sistema real deve observar vários sinais em conjunto:

• a probability da opção mais bem classificada;
• a diferença de probability entre a primeira e a segunda opções;
• um Noul independente correspondente ao risco de negócio;
• se o ticket vem de uma distribuição não coberta pelos dados de treinamento ou validação;
• se a versão do modelo ou a redação da pergunta mudou.

“Para qual fila deve ir?” e “pode ser processado automaticamente?” também não devem ser resolvidos com um único Choice. Use Choice para escolher a fila e um Noul separado para verificar se as condições do tratamento automático foram atendidas.

A redação das perguntas precisa ser gerenciada como código

Em um fluxo com Jev, a redação das perguntas não é apenas texto de prompt. Ela faz parte da lógica de negócio.

Se o significado de instructions e criteria entrar em conflito, há o risco conceitual de o modelo retornar um resultado estruturalmente válido, porém semanticamente incorreto, sem lançar qualquer exceção. Por isso, a revisão cuidadosa contra contradições na definição das perguntas é essencial.

Por isso, um projeto de roteamento de e-mails deve gerenciar as definições das perguntas, no mínimo, com as seguintes práticas:

Item de gestão	Prática concreta
Versionamento	Criar uma nova versão sempre que a redação, as opções ou os critérios mudarem
Revisão de código	Guardar as definições das perguntas e as regras de roteamento no repositório para review, em vez de espalhá-las por campos de texto administrativos
Exemplos de teste	Manter exemplos positivos, negativos, limítrofes e com múltiplas intenções para cada pergunta
Verificação de conflito	Confirmar que instruction e true/false criteria apontam para a mesma direção semântica
Fixação da versão do modelo	Depois de calibrar os limiares, fixar uma versão específica em vez de depender diretamente de um latest alias variável

Cada faixa de Score deve descrever uma situação de negócio observável, em vez de apenas “baixo, médio, alto”. Por exemplo, “o usuário está apenas perguntando o preço” e “o usuário já entrou em contato várias vezes e o serviço está indisponível” tendem a ser avaliados de forma mais consistente do que “urgência média”.

O sistema precisa saber o que fazer quando a rede falha

Uma falha na resposta do modelo de classificação não deve ser interpretada como “sem risco” ou “liberar por padrão”.

Em ambientes distribuídos e sob alta concorrência, falhas de transporte, timeouts e oscilações de latência fazem parte da realidade operacional. Por isso, a engenharia de produção exige que a arquitetura não implemente apenas o caminho ideal.

São necessárias pelo menos quatro camadas de proteção:

1. Tentativas e backoff: prefira um SDK que suporte tentativas e retry-after, para que um erro de rede temporário não faça o ticket desaparecer.
2. Semântica explícita de fallback: decida antecipadamente se a indisponibilidade do serviço enviará o ticket à triagem humana, adiará o processamento ou executará somente regras determinísticas.
3. Idempotência e deduplicação: reentrega de e-mail, nova tentativa da fila ou repetição por timeout não podem criar tickets duplicados.
4. Registro completo: registre a versão do modelo, a versão das perguntas, probabilities, latência da chamada, uso e resultado final do atendimento humano.

Para tickets financeiros, de conta ou jurídicos, o fallback padrão mais seguro geralmente não é “aprovar automaticamente”, mas “pausar a ação automática e encaminhar para uma pessoa”.

Filas multilíngues não podem compartilhar um único conjunto de limiares de Score

Ao trabalhar com múltiplos idiomas, não presuma que limiares e regras de decisão se transfiram entre idiomas.

Os limiares de Score e os níveis de confidence não são universais: valide-os separadamente para cada idioma suportado, mesmo que o rótulo de roteamento base pareça o mesmo.

Por isso, um sistema de suporte multilíngue deve, no mínimo:

• criar um conjunto de validação separado para cada idioma;
• calibrar e validar separadamente os limiares de urgência e escalonamento humano por idioma;
• não presumir a transferibilidade direta de faixas de pontuação ou limiares calibrados em um único idioma de referência;
• aplicar uma política consistente sobre tradução, texto original e histórico da conversa.

O que deve ser avaliado antes do lançamento

Um sistema de roteamento de e-mails não pode ser julgado apenas pela acurácia geral. Erros diferentes têm custos muito diferentes. Enviar uma dúvida de pré-venda para a fila de suporte talvez gere apenas uma transferência extra; deixar passar uma ameaça de chargeback ou uma reclamação jurídica pode criar risco financeiro e de conformidade direto.

No mínimo, avalie separadamente as seguintes métricas:

Métrica	Pergunta que deve responder
Acurácia da fila principal	O ticket chegou à primeira fila de atendimento correta?
Recall de alto risco	Quantos tickets de chargeback, jurídicos, regulatórios ou de segurança de conta foram perdidos?
Cobertura do roteamento automático	Que proporção de tickets dispensou a triagem manual inicial?
Taxa de tratamento automático incorreto	Quantos tickets que exigiam uma pessoa avançaram automaticamente?
Taxa de revisão humana	Os limiares são tão conservadores que a fila humana perde sua utilidade?
Latência e taxa de falhas	O sistema é estável sob concorrência, tamanhos de e-mail e condições de rede reais?
Custo total por ticket	Depois de decisões, tentativas, modelos posteriores e revisão humana, o fluxo continua econômico?

Ao escolher as linhas de base, não compare o Jev apenas com modelos de chat de fronteira e alto custo. Sistemas de regras, modelos Flash com saída estruturada, embeddings combinados com classificador e modelos pequenos treinados em dados próprios rotulados também podem ser alternativas razoáveis.

Quando existirem dados rotulados, recomenda-se avaliar e comparar (benchmark) um classificador especializado com o Jev, sem presumir antecipadamente que ele seja mais preciso ou mais rápido. Um caminho de evolução sensato é usar o Jev no cold start e enquanto os rótulos mudarem com frequência, e realizar benchmarks comparativos com classificadores dedicados à medida que dados rotulados suficientes forem acumulados.

O Jev não escreve a resposta final do suporte

Depois do roteamento, o sistema ainda pode precisar resumir o problema, localizar o pedido, verificar a elegibilidade para reembolso ou gerar um rascunho de resposta. Essas tarefas não devem ser todas atribuídas ao Jev.

Uma divisão mais clara do trabalho seria:

Etapa	Executor mais adequado
Consulta exata de pedidos, cálculo de valores e comparação de datas	Código de negócio e bancos de dados
Julgamentos de fila, risco, intenção e urgência	Jev ou outro modelo de classificação
Recuperação na base de conhecimento	Sistemas de busca e RAG
Rascunho de resposta, explicação e comunicação em linguagem natural	Uma LLM generativa
Aprovação de reembolso, suspensão de conta e tratamento jurídico	Pessoas e políticas da empresa

Essa arquitetura não transforma o Jev em um “agente automático de suporte”. Ela apenas adiciona uma camada de decisão barata, estruturada e consumível diretamente pelo código antes que cada e-mail chegue a um modelo caro ou a uma fila humana.

Conclusão: classificação não é o produto; o fluxo de controle é

O Jev mostra uma direção útil: quando o software precisa apenas de uma fila, uma probabilidade ou um nível, não é necessário chamar um modelo generativo toda vez, pedir que ele escreva um texto e depois fazer o código adivinhar o que esse texto quis dizer.

Mas sair de uma demonstração de classificação de e-mails e chegar a um fluxo de negócio completo exige desenhar o controle posterior à classificação: quais tickets podem ser roteados automaticamente, quais sinais devem ser detectados separadamente, quando uma pessoa precisa assumir, como o sistema degrada quando o serviço falha e como verificar continuamente os limiares com dados realmente rotulados.

Por isso, um sistema de tickets com Jev não deve ser avaliado apenas pela pergunta “com que rapidez ele classificou 500 e-mails?”. A pergunta mais útil é:

Ele reduz de forma consistente transferências desnecessárias, chamadas de modelos e triagem humana inicial sem deixar passar tickets de alto risco?

Somente quando essa pergunta recebe uma resposta positiva nos próprios dados de negócio o roteamento de e-mails deixa de ser uma demonstração de modelo e se torna um fluxo de trabalho utilizável.