Quando não usar o Jev: a lista honesta

Esta é a página mais útil da seção e a mais fácil de não escrever. Ela existe porque a própria TypeSafe mantém uma lista de arestas conhecidas do jev-1.13, com nove modos de falha e o remédio recomendado de cada um. O que fazemos aqui é traduzir essa lista em decisões de arquitetura, e dizer com clareza qual ferramenta entra no lugar.

Vale o enquadramento: nada disto é defeito escondido. É especificação. Um modelo com fronteira publicada é mais fácil de usar do que um que promete tudo.

A tarefa

Decidir, antes de escrever código, se o Jev é a ferramenta errada para o que você tem em mãos.

Os seis casos de não usar

1. A saída precisa ser texto

Se o produto da tarefa é uma frase, um resumo, um e-mail, um parecer ou código, o Jev não serve. A documentação é direta: ele não é treinado para gerar texto, e forçar por encadeamento de escolhas funciona mal e fica muito lento. Ela mesma sugere usar um modelo generativo.

Use no lugar: um LLM. E, se houver decisão antes da escrita, use os dois — o Jev classifica, o LLM escreve, como em roteamento de intenção.

2. A resposta é um cálculo exato

Contagem e aritmética estão fora. O modelo não conta de forma confiável — caracteres, ocorrências, itens de lista longa — porque reconhece a forma de uma resposta em vez de somar, e o erro cresce com o tamanho do que é contado. A documentação também desaconselha usar a nota de um Score para reconstruir um valor exato entre dois níveis, porque os níveis do jev-1.13 são fracos em calibração numérica.

Use no lugar: código. E o conselho oficial, quando a contagem depende de um critério: itere sobre os candidatos no seu código, faça uma pergunta por item e some você mesmo.

3. A resposta depende de comparar datas

Qual data vem antes, quantos dias separam duas datas, se uma data cai dentro de uma janela: tudo isso é pouco confiável, porque o modelo lê data como texto e não como quantidade ordenada. Piora com formatos misturados, referências relativas e limites de domínio como trimestres e janelas de liquidação.

Use no lugar: divisão de trabalho. Extração é julgamento e fica com o modelo; aritmética não é e fica no código. A receita de extrair datas mostra a versão trabalhada, com a data virando uma escolha entre opções enumeradas e uma opção explícita de “não informado”.

4. A pergunta exige vários saltos de indireção

Propriedade de uma propriedade, dupla negativa, conclusão que depende de três inferências encadeadas: a documentação lista indireção entre os modos de falha e recomenda reduzir os saltos e apontar as partes do state pelo nome.

Use no lugar: ou um modelo de raciocínio, ou a decomposição em perguntas literais combinadas no seu código — que é o que a própria documentação sugere quando a interpretação é inevitável.

5. O state é grande e cheio de coisa irrelevante

A acurácia cai conforme o state cresce com conteúdo que a decisão não usa. O detalhe irrelevante age como distrator e ainda esconde qual parte da entrada gerou a resposta errada. A documentação chama o efeito de context rot, e ele tem página própria em context rot.

Use no lugar: filtre em código antes. Quando não dá para filtrar antes, use uma pergunta de relevância como primeiro passo, como em classificar passagens de RAG. E note que este é um caso de “não use assim”, não de “não use”.

6. O conteúdo foi escrito para enganar o modelo

O state é tratado como dado, não como hostil por padrão. Instrução injetada, enquadramento enganoso ou texto que argumenta a própria classificação podem mover a resposta. A recomendação oficial é ser explícito nos critérios e testar casos de borda antes de expor a muitos usuários.

Use no lugar: nada sozinho. Isso é arquitetura: nenhuma ação irreversível deve depender de uma única resposta do modelo, e a defesa é ter um segundo controle — regra determinística, verificação cruzada ou pessoa.

Três razões que não estão na lista oficial, e contam

Não existe destino para a incerteza. Se o seu fluxo não tem fila humana nem caminho alternativo, a confiança baixa não tem para onde ir, e o valor principal do modelo se perde. Antes de integrar, defina o destino — o assunto está em revisão humana.

A regra é estável e verificável. Se uma expressão regular resolve, use a expressão regular: ela é determinística, gratuita e testável até o fim. A fronteira está em Jev vs regex.

O volume é pequeno. Com poucas decisões por dia, a diferença de custo não paga o custo de integrar mais um fornecedor. Isso não é argumento técnico, é argumento de engenharia, e vale.

Quando cada alternativa é a resposta certa

Como escolher

A regra curta que resume a página inteira: se a resposta cabe em uma opção de um conjunto, um nível de uma régua ou um sim e não, e você quer saber o quanto o modelo está seguro, é Jev. Caso contrário, quase certamente não é.

Vale a frase que este site repete em todo comparativo: esses outros modelos escrevem texto, e o Jev só decide. Escolher pela forma da saída acerta mais do que escolher por preço.

Para conferir o texto original dos nove modos de falha, veja limites do Jev. Para testar a fronteira com um caso seu, use o playground. O índice desta seção fica em comparativos.