IA que escolhe ou IA que escreve: onde cada uma entra no seu sistema, e o que o Jev mudou na conversa

Decisão fechada (classificar, rotear, validar) pede modelo que escolhe e erro que se mede. Texto livre pede revisão humana. Como decidir e testar, com o caso Jev.

Na triagem de ticket, o erro do modelo é a fila errada, e fila errada se conta

Antes de pôr IA dentro de um sistema, responda a uma pergunta: ela vai escolher entre opções que você já definiu, ou vai escrever a resposta do zero? Classificar um ticket em uma de oito filas, mandar um pedido para o estoque certo, dizer se o CNPJ bate com a razão social: isso é escolha. Cabe num modelo que só aponta a opção. Resumir uma reclamação, redigir a resposta ao cliente, explicar uma fatura: isso é escrita, e aí o modelo de linguagem continua sendo a ferramenta.

A diferença aparece no dia em que o modelo erra. Na escolha fechada, o erro é a fila errada, e fila errada se conta: de 400 tickets rotulados à mão, quantos o modelo acertou, e em qual fila ele mais tropeça. No texto livre, o erro é uma frase plausível com um fato torto no meio, e alguém precisa ler para achar. O primeiro erro vira número. O segundo vira revisão humana, linha por linha, enquanto o fluxo existir.

O barulho em torno do Jev, e o que dá para conferir

O teste com limiar por fila é o expect que a IA de escolha aceita

Nos últimos dias o Jev, da TypeSafe, apareceu em quase toda conversa de desenvolvedor sobre IA. Um post no TabNews resumiu o anúncio assim: de 20 a 200 vezes mais rápido, de 40 a 400 vezes mais barato, tokens de saída grátis, "não alucina", "não gera texto". Segundo o mesmo relato, o anúncio passou de 1,8 mil pontos no Hacker News.

Trate esses números pelo que eles são: afirmação do fornecedor, repassada por terceiros. Eu não testei o Jev e não sei como ele se comporta no domínio da sua empresa. O que vale guardar é a leitura do autor do post. A TypeSafe não fez um GPT duzentas vezes mais rápido. Ela mudou o problema que o modelo resolve. Um modelo que só precisa apontar uma opção de uma lista não gasta tempo nem dinheiro montando parágrafo. A velocidade e o custo saem dessa troca, e a troca serve para qualquer ferramenta, com ou sem Jev.

As objeções que circularam na discussão ("é só um classificador", "isso já existe com structured output") têm fundo de verdade, e o próprio post admite. Para quem decide onde pôr IA no produto, essa briga de gaveta rende pouco. A pergunta útil é a que dá nome ao post: onde a IA deveria entrar no código.

"Não alucina" é a promessa errada

O argumento de venda mais repetido é o que menos ajuda na hora de decidir. Um modelo que escolhe não inventa uma quarta opção quando você deu três, certo. Só que escolher a opção errada continua sendo erro. O ticket de cobrança que caiu na fila de suporte técnico não ficou menos atrasado porque o modelo não escreveu nada.

O que muda é o formato do erro. Numa escolha fechada, ele cabe numa tabela de três colunas: entrada, opção esperada, opção devolvida. Dá para medir antes de ligar, medir de novo a cada troca de modelo e escrever um teste que quebra quando a taxa cai. No texto livre, cada resposta é única, e "certo" depende de quem lê e do humor de quem lê.

Isso encosta numa implicância antiga minha: teste sem expect. É o teste que roda, fica verde e não afirma nada. Já escrevi sobre como cobertura de teste alta vira o disfarce favorito do bug em produção, e IA gerando texto em produção sem régua de acerto é a mesma casca podre: o fluxo existe, a garantia não. A escolha fechada é o lugar onde a IA aceita um expect de verdade.

Três lugares onde o modelo não precisa escrever nada

Enxada ou betoneira, a massa sai ruim se o traço estiver errado

Três padrões aparecem em quase todo sistema de empresa, e nos três a saída certa é uma opção, não uma frase:

• Classificar: o ticket, o e-mail ou o documento cai em uma de N categorias que já existem no seu sistema, e a categoria errada tem custo conhecido, seja atraso no atendimento ou retrabalho de um analista.
• Rotear: o pedido vai para um estoque, uma transportadora ou uma fila de aprovação, e a lista de destinos é fechada porque o seu backend só sabe tratar esses destinos.
• Validar: o dado informado bate ou não com a regra, e a resposta possível é sim, não ou "manda para uma pessoa olhar".

Nos três casos, o conjunto de respostas já está escrito no seu código, quase sempre como um enum ou uma tabela no banco. Se o modelo devolve um parágrafo e depois alguém faz parse para achar a categoria no meio dele, você pagou por escrita e usou escolha. Quando a lista é fechada, peça a escolha e mais nada.

Vale uma pergunta antes até dessa. Boa parte das decisões que hoje ganham um modelo era um if ontem. Num serviço de preço que abri, contei 1.043 ramificações. Só 34 tinham mudado no último ano, uns 3%. Regra estável que o código já resolve bem não precisa de modelo nenhum, nem do rápido. O dilema de onde deixar esse tipo de regra está em mil regras de negócio: no código, num motor de regras ou na planilha do financeiro. O modelo de escolha entra quando a entrada é bagunçada demais para if, como texto de cliente, foto de documento ou e-mail encaminhado três vezes, e a saída continua sendo uma lista curta.

Quanto custa conferir cada tipo de erro

Conferir se um ticket caiu na fila certa leva poucos segundos, e qualquer pessoa do atendimento faz. Conferir se uma resposta escrita ao cliente está correta, sem prometer prazo que ninguém deu e sem citar uma política que mudou em março, leva minutos. E exige alguém que conheça o produto de verdade.

Multiplique pelo volume. Um fluxo que gera 2 mil respostas por semana e precisa de amostra revisada consome horas de gente sênior. O mesmo volume de classificações se audita com uma amostra pequena e uma planilha. É o mesmo raciocínio que aparece em code review automatizado por IA: onde a saída é aberta, o humano segue na mesa, e o custo dele precisa entrar na conta desde o primeiro dia.

"Mas o meu caso precisa de texto"

Às vezes precisa mesmo. Resposta ao cliente, resumo de chamado longo, explicação de uma cobrança: ninguém quer receber um código de categoria no lugar de uma frase. Aqui o modelo de linguagem continua sendo a escolha certa, e fingir o contrário seria vender betoneira para quem precisa de pincel.

O que dá para fazer é separar as duas coisas dentro do mesmo fluxo. A decisão que muda o estado do sistema (reembolsa ou não, escala ou não, qual fila) sai como escolha, medida e testada. O texto em volta dela é gerado depois, já sabendo a decisão, e o estrago possível de um erro de redação fica bem menor do que o de um reembolso aprovado por engano. Quando a decisão e a redação vivem no mesmo prompt, o erro da primeira se esconde dentro da segunda, bem escrito.

Como medir acerto antes de ligar em produção

O trabalho chato é montar o conjunto de referência: umas trezentas a quinhentas entradas reais, rotuladas à mão por quem conhece o negócio. Sem isso, qualquer número de acerto é palpite. Com isso, a medição vira um teste comum, que roda no CI como qualquer outro.

Meça por categoria, e não só no total. Um modelo com 94% de acerto geral pode estar em 60% justamente na fila de cancelamento, que é pequena e cara. O teste abaixo quebra nos dois casos: quando a saída sai da lista e quando alguma fila fica abaixo do limiar.

from collections import Counter
from triagem import classificar  # sua chamada ao modelo

FILAS = {"cobranca", "suporte_tecnico", "cancelamento", "outro"}
LIMIAR = 0.9

def test_acerto_por_fila(casos_rotulados):
    acertos, total = Counter(), Counter()
    for caso in casos_rotulados:
        previsto = classificar(caso["texto"])
        assert previsto in FILAS, f"saiu da lista: {previsto}"
        total[caso["fila"]] += 1
        if previsto == caso["fila"]:
            acertos[caso["fila"]] += 1
    for fila, n in total.items():
        taxa = acertos[fila] / n
        assert taxa >= LIMIAR, f"{fila}: {taxa:.0%} em {n} casos"

Dois limites honestos. O conjunto de referência envelhece: produto novo, fila nova e tipo de reclamação novo pedem rótulos novos, e alguém precisa ser dono disso. E eu não sei se o esforço se paga para quem recebe vinte tickets por dia. Com esse volume, uma pessoa lendo tudo talvez saia mais barato que qualquer modelo.

Enxada ou betoneira

Uma frase que repito para founder que chega animado com IA: se você não sabe fazer massa de cimento, tanto faz na enxada ou na betoneira, vai sair ruim. Um modelo que escolhe é uma betoneira mais rápida e mais barata, se os números da TypeSafe se confirmarem. O traço continua sendo seu: a lista de opções, o conjunto rotulado, o limiar que decide quando a máquina passa a vez para uma pessoa.

É a primeira conta que a gente faz quando um projeto chega com IA dentro, antes de discutir fornecedor. Pegue o fluxo com IA que você já tem em produção e responda: se ele errar amanhã, quem avisa primeiro, um teste ou um cliente?