Sua triagem não precisa de um modelo de chat

Conte as chamadas de modelo que seu produto faz numa semana e ordene por para que serviram. Na maioria dos produtos a cauda longa não é a parte impressionante — não é a resposta que o cliente lê nem o resumo da conversa. São decisões: para qual fila isso vai, se é um pedido de reembolso, quão urgente é, se essa mensagem precisa de uma pessoa, se esse anúncio quebra uma regra.

Esse trabalho tem três propriedades que fazem do modelo de chat uma escolha estranha: a resposta pertence a um conjunto que você já conhece, o volume é alto, e errar sai caro de um jeito sem graça.

O que você paga hoje§

Um modelo de chat responde uma classificação com uma frase. Então você paga os tokens de saída, e depois paga de novo em engenharia: um prompt implorando por JSON, um parser, um normalizador para "Billing." contra billing, uma retentativa para as vezes em que ele se desculpa em vez de responder, e uma "confiança" que o modelo escreveu em prosa porque nada no treinamento dele ligou aquele número à frequência com que ele acerta.

E aí você paga uma terceira vez, nas próprias decisões: sem uma medida honesta de incerteza, ou você manda tudo para uma pessoa (e não automatiza nada) ou automatiza tudo (e absorve os erros).

Quanto custa, em vez disso, um modelo System One§

O Jev, da TypeSafe, primeiro modelo dessa classe, não gera texto. Ele recebe um estado e perguntas tipadas e devolve respostas tipadas com probabilidades calibradas numa única passagem paralela. Os números que a TypeSafe publica são 70–500 ms ponta a ponta — 40–200× mais rápido que modelos de fronteira em tarefas comparáveis — a US$ 0,042 por milhão de tokens de entrada, com a saída de graça.

A nossa medição, pelo motor contra o jev-1.13.0, é sobre o formato da chamada mais do que sobre o preço: fazer oito perguntas em um bloco em vez de oito chamadas separadas foi 7,6× mais rápido e usou 4,9× menos tokens de entrada, e a latência ficou plana — cerca de 0,8 s tanto com uma pergunta quanto com quarenta. O estado é lido uma vez e as perguntas são respondidas contra ele em paralelo.

Junte as duas coisas para uma caixa de suporte com 50.000 tickets por mês, cada ticket com algumas centenas de tokens e seis perguntas feitas num bloco, e a linha do modelo nessa carga fica em dólares de um dígito por mês. O ponto não é o número exato — seus tickets são mais longos ou mais curtos que a minha suposição — e sim que o custo da decisão deixa de ser motivo para não automatizá-la, e a restrição volta para onde ela pertence: quão seguro você precisa estar antes de uma máquina agir.

O número que destrava a automação§

Essa é a mudança de verdade, e não é o preço. Toda resposta vem com uma probabilidade calibrada e, nas escolhas e escalas, uma confiança — quão concentrada está a distribuição:

when v.team.available and v.team.choice != nothing and confidence of v.team >= 0.9
    route(v.team.choice)
otherwise
    approve "Route to " + text(v.team.choice) + "?"

Essa única linha é o controle de negócio que você não conseguia escrever antes. Acima da linha a máquina age; abaixo dela uma pessoa olha. Você move o limiar com dados — meça que proporção dos 0,9 acertou — em vez de discutir se o modelo "parecia seguro".

Dois detalhes que medimos e que protegem essa mesma linha. Primeiro: uma escolha precisa escolher alguma coisa; uma pergunta sobre horário de atendimento, com apenas billing e technical como opções, respondeu technical a 0,69 — direto por um portão de 0,5. Acrescentar uma opção de escape explícita ("nenhuma destas serve") transformou isso em none a 1,00 e não custou nada nos casos claros. Segundo: quando o provedor está indisponível, a resposta volta com confiança 0 e sem valor algum, nunca com um número inventado, então uma queda manda a fila para as pessoas sozinha, em vez de decidir errado em silêncio e a toda velocidade.

O que fica com o modelo de chat§

A resposta que o cliente lê. O resumo de uma conversa longa. A explicação de por que algo foi recusado. Tudo cuja saída é prosa para uma pessoa. Os dois rodam lado a lado — o juiz decide, o modelo de linguagem escreve — e na Synsema Platform são duas configurações separadas, dois orçamentos e duas permissões, então um serviço pode ter permissão de classificar sem ter permissão de gerar.

Por onde começar§

Escolha a decisão de maior volume do seu produto — para a maioria dos times é o roteamento da caixa de entrada ou a etiquetagem de primeira linha. Faça a pergunta como um bloco com opção de escape, registre a resposta ao lado do que a pessoa acabou fazendo, e compare depois de uma semana. Você vai ter o limiar, e o argumento, em dados.

O lado operacional — chaves, orçamentos, o preflight, o que acontece durante uma queda — está em Colocando um modelo System One em produção. O código está em How to use Jev from Synsema, e roda contra um provedor mock determinístico sem conta nenhuma.