Matheus Persch

Posted on Sep 25 AI-assisted

Jev e System One Models: quando o LLM é a ferramenta errada

#ai #llm #machinelearning #braziliandevs

Muitas aplicações usam modelos de linguagem para tomar decisões que serão consumidas pelo código. Um exemplo comum: uma mensagem de cliente chega e, antes de qualquer outra etapa, o sistema precisa saber se ela trata de cobrança, de um defeito ou de outro assunto. A resposta esperada é um valor de um conjunto pequeno e conhecido. Uma solução recorrente consiste em enviar a mensagem a um LLM, solicitar a resposta em JSON, aguardar a geração token por token e consumir o resultado estruturado. Quando a integração não impõe um schema à geração, também é necessário tratar categorias inesperadas e falhas de formato.

Essa abordagem funciona, mas utiliza um mecanismo de geração de texto para uma tarefa que, em essência, é de classificação. O custo aparece na latência e no preço por chamada. A necessidade de validação adicional depende das garantias oferecidas pela API e pelo modo de geração escolhido.

Em 15 de setembro de 2026, a TypeSafe AI apresentou o Jev, primeiro modelo de uma categoria que a empresa denomina System One Models. A proposta é um modelo que não gera texto e se limita a produzir decisões estruturadas. Este artigo descreve o funcionamento do Jev, as diferenças em relação ao uso de saídas estruturadas em LLMs, os casos de uso para os quais ele foi projetado, suas limitações documentadas e os resultados das avaliações independentes citadas nesta análise, com informações de referência de 25 de setembro de 2026.

Definição

O Jev pode ser descrito como um classificador zero-shot com schema definido em tempo de execução.

Neste contexto, zero-shot significa realizar uma tarefa sem fornecer exemplos rotulados dela na requisição ou ajustar os pesos especificamente para ela: as perguntas e as respostas possíveis são descritas em linguagem natural a cada requisição. O schema é definido em tempo de execução porque o conjunto de respostas válidas faz parte da própria requisição, e o modelo só pode devolver elementos desse conjunto. A entrada é um estado, que pode ser um texto, um objeto JSON ou uma lista; a saída é, para cada pergunta, uma distribuição de probabilidade sobre as opções definidas.

Essa descrição ajuda a entender a interface, mas não revela a arquitetura interna do modelo. A alegação da empresa de desempenho comparável ao de LLMs de fronteira em tarefas desse tipo precisa ser examinada separadamente, por meio de avaliações com rótulos e condições de comparação bem definidos.

Uma requisição mínima tem a seguinte forma:

{
  "model": "jev-latest",
  "state": {
    "mensagem": "Fui cobrado duas vezes no pedido 4821. Quero o dinheiro de volta."
  },
  "questions": {
    "departamento": {
      "type": "choice",
      "instructions": "Qual equipe deve tratar `mensagem`?",
      "criteria": {
        "financeiro": "Cobranças, faturas, reembolsos",
        "tecnico": "Erros, falhas, problemas de integração",
        "outro": "Qualquer assunto fora das categorias acima"
      }
    },
    "pede_reembolso": {
      "type": "noul",
      "instructions": "O cliente pede a devolução do dinheiro?"
    }
  }
}

Um recorte ilustrativo da resposta tem o seguinte formato. Os números abaixo não foram obtidos em uma execução real e não representam o cálculo exato de confidence:

{
  "answers": {
    "departamento": {
      "type": "choice",
      "choice": "financeiro",
      "probabilities": { "financeiro": 0.96, "tecnico": 0.02, "outro": 0.02 },
      "confidence": 0.93
    },
    "pede_reembolso": { "type": "noul", "noul": 0.98 }
  }
}

O campo answers.departamento.choice só pode assumir um dos três valores definidos, e ambas as perguntas são respondidas na mesma chamada. A decisão sobre o que fazer com o resultado permanece no código da aplicação.

Diferenças em relação a saídas estruturadas em LLMs

Restringir a saída de um LLM a um formato não é uma técnica nova. Bibliotecas de geração guiada limitam os tokens possíveis a uma gramática, e APIs de saídas estruturadas podem restringir a resposta a um schema, inclusive a opções enumeradas. Isso é diferente de apenas pedir JSON no prompt. Para comparar essas soluções com o Jev, convém separar três aspectos.

Avaliação paralela em vez de geração sequencial

Para produzir {"departamento": "financeiro"}, um LLM gera cada token condicionado aos anteriores. Segundo a documentação, o Jev avalia todas as perguntas de uma requisição em paralelo, de forma independente, contra o mesmo estado, e devolve diretamente as distribuições de probabilidade.

Segundo a TypeSafe, acrescentar perguntas independentes tem baixo custo marginal: o estado é enviado uma vez, e as novas perguntas acrescentam seus próprios tokens de entrada, com pequeno impacto na latência. Dez decisões sobre um documento podem ser expressas como dez entradas em questions. Um LLM também pode responder várias perguntas em uma única chamada; o diferencial anunciado é a forma de avaliação e seu custo, não a possibilidade de agrupá-las.

A arquitetura do modelo não foi divulgada. A empresa menciona uma nova arquitetura, um amostrador paralelo e um método de treinamento próprio, mas não publicou artigo técnico, pesos nem número de parâmetros. A ideia de abandonar a geração autoregressiva tem antecedentes na literatura, em especial nos modelos não autoregressivos de tradução automática, mas não há informação pública suficiente para afirmar que o Jev emprega alguma dessas técnicas.

Probabilidade como parte da saída

Quando um LLM é instruído a informar um nível de confiança, ele produz uma estimativa verbalizada. Esse número não deve ser confundido com as probabilidades internas de geração nem presumido como calibrado. Estudos sobre confiança verbalizada identificam superconfiança em diferentes condições de avaliação.

A má calibração de redes neurais modernas é um problema documentado há quase uma década. Um dado particularmente relevante para o caso do Jev aparece no relatório técnico do GPT-4: o modelo pré-treinado apresentava boa calibração, que foi parcialmente perdida após o pós-treinamento com RLHF.

Esse é o argumento central da TypeSafe. Seu fundador, Diogo Almeida, é coautor do artigo sobre o InstructGPT, trabalho que aplicou RLHF ao seguimento de instruções e serviu de base para o ChatGPT. A tese da empresa é que otimizar modelos para a preferência de avaliadores humanos produz bons assistentes conversacionais, mas também modelos superconfiantes. O Jev é treinado com um método chamado Reinforcement Learning for Calibrated Decisions (RLCD), cujo objetivo declarado é que respostas atribuídas a uma probabilidade de 0,9 estejam corretas em aproximadamente 90% dos casos.

A calibração pode ajudar a definir quando automatizar. Uma acurácia global de 95%, por exemplo, não informa quais casos têm maior risco de erro. Estimativas de incerteza úteis permitem selecionar casos para revisão, mas não identificam individualmente todas as respostas erradas. A necessidade de supervisão também depende do impacto dos erros e das demais verificações do sistema.

Há uma distinção importante na documentação de confiança: probabilities contém a distribuição sobre as alternativas, enquanto confidence é uma estatística calculada a partir dessa distribuição. Portanto, confidence = 0.9 não significa, por definição, 90% de chance de acerto. A relação entre esse indicador e a taxa de acerto deve ser medida na tarefa de interesse. Noul, por sua vez, retorna a probabilidade estimada de uma resposta afirmativa e não possui esse campo de confiança.

Garantia de tipo

A TypeSafe divulga uma taxa de 0% de alucinação para o Jev. A própria empresa esclarece que esse número não é empírico: ele decorre da construção do modelo. Como a saída é uma distribuição sobre opções previamente definidas, não é possível que o modelo devolva uma categoria inexistente ou uma estrutura malformada.

A formulação mais precisa seria, portanto, uma garantia de conformidade da saída ao schema, segundo a empresa. Essa garantia elimina uma classe relevante de falhas, como campos inventados, falhas de parsing e respostas acompanhadas de texto explicativo no lugar do valor. Ela não elimina, contudo, a resposta incorreta: o modelo pode escolher tecnico quando a classificação correta seria financeiro. Essa é uma falha semântica, que pode ser avaliada por métricas como acurácia, precisão e revocação. A garantia de formato também não elimina falhas operacionais, como timeouts e erros de autenticação.

A distinção se relaciona com trabalhos recentes que atribuem parte das alucinações de LLMs ao fato de que o treinamento e os benchmarks recompensam respostas confiantes em detrimento da admissão de incerteza. O Jev restringe o espaço de respostas e fornece sinais de incerteza. Isso não impede uma distribuição concentrada na alternativa errada. Além disso, a restrição a categorias válidas também pode ser obtida com geração guiada em LLMs; ela não é, isoladamente, uma propriedade exclusiva do Jev.

Origem dos nomes

O termo System One faz referência à distinção proposta por Daniel Kahneman entre o Sistema 1, rápido e intuitivo, e o Sistema 2, lento e deliberativo. Na formulação da TypeSafe, o Jev corresponde ao primeiro, enquanto os modelos de raciocínio ocupam o papel do segundo.

O nome Jev homenageia o economista William Stanley Jevons, que observou em 1865 que o aumento da eficiência das máquinas a vapor elevou o consumo total de carvão, em vez de reduzi-lo. A aposta da empresa é que o mesmo ocorra com decisões automatizadas: à medida que o custo de cada decisão cai, surgem aplicações que antes não justificavam uma chamada a um LLM.

Interface

A avaliação é feita pelo endpoint POST /v1/systemone, que aceita três tipos de pergunta:

Noul: pergunta de sim ou não. Devolve um único valor entre 0 e 1, correspondente à probabilidade de a resposta ser afirmativa.
Choice: escolha de uma opção em um conjunto não ordenado de até 255 alternativas. Devolve a opção mais provável, a distribuição completa e um valor de confidence.
Score: posição em uma escala ordenada de 2 a 10 níveis, cada um descrito em linguagem natural. Devolve a média ponderada pelos níveis, a distribuição e a confiança.

O exemplo abaixo usa o SDK oficial em TypeScript, @typesafe-ai/sdk, cujas funções auxiliares permitem inferir os tipos das respostas. Ele pressupõe a configuração da variável de ambiente TYPESAFE_API_KEY:

import { choice, noul, score, TypeSafeClient } from '@typesafe-ai/sdk'

const client = new TypeSafeClient()
const textoDoTicket = "A integração parou de funcionar e não consigo finalizar pedidos."

const { answers } = await client.systemOne({
  state: { ticket: textoDoTicket },
  questions: {
    categoria: choice('Que tipo de solicitação é `ticket`?', {
      defeito: 'Algo não funciona ou se comporta de forma incorreta',
      cobranca: 'Cobranças, faturas, reembolsos, assinaturas',
      sugestao: 'Pedido de funcionalidade que ainda não existe',
      outro: null,
    }),
    severidade: score('Qual a gravidade do problema descrito em `ticket`?', [
      'Estético; sem impacto no funcionamento',
      'Funcionalidade degradada, mas existe alternativa',
      'Bloqueante; não existe alternativa',
    ]),
    tem_passos: noul('`ticket` descreve como reproduzir o problema?'),
  },
})

Em TypeScript, answers.categoria.choice é tipado como a união literal das opções definidas, o que permite verificação exaustiva em um switch e impede, em tempo de compilação, a comparação com uma categoria inexistente.

A documentação e os materiais publicados pela empresa enfatizam dois padrões de uso.

O primeiro é fazer, em uma única requisição, todas as perguntas independentes que possam ser necessárias, mesmo aquelas relevantes apenas para parte das entradas. No exemplo acima, a severidade só interessa quando a categoria é defeito, mas incluí-la na mesma chamada custa apenas seus próprios tokens, já que o estado é enviado uma única vez. A TypeSafe denomina esse padrão speculative fan-out e relata, em um de seus exemplos, que 13 perguntas em uma chamada saíram 12,2 vezes mais baratas e 10 vezes mais rápidas do que 13 chamadas sequenciais. Uma segunda requisição é necessária quando uma etapa depende do resultado da primeira, por exemplo quando é preciso buscar dados adicionais antes de formular a pergunta seguinte.

O segundo padrão é o uso da confiança para decidir o tratamento de cada resposta, em três faixas: confiança alta leva à ação automática, confiança intermediária leva a uma confirmação ou revisão, e confiança baixa leva ao encaminhamento para uma pessoa ou para um sistema mais lento. Os limiares dependem do custo de um erro em cada contexto e devem ser ajustados com dados reais.

Segundo a página de modelos, o Jev 1.13 aceita cerca de 64 mil tokens para o estado somado a todas as perguntas, sendo que o estado mais a pergunta mais longa devem caber em aproximadamente 32 mil. O modelo aceita apenas texto.

Casos de uso

A documentação da TypeSafe organiza os casos de uso por setor, mas uma classificação pelo formato da decisão é mais útil para identificar onde o modelo se aplica em um sistema existente. Os cinco formatos abaixo cobrem a maior parte das aplicações descritas.

Classificação e roteamento. Quando uma entre várias categorias conhecidas deve ser escolhida, e essa escolha determina o próximo caminho do código. Exemplos incluem triagem de tickets por equipe, classificação de intenção em atendimento e roteamento de modelos, em que o Jev estima a complexidade de uma solicitação e o código decide se ela vai para um modelo barato, para um modelo de raciocínio ou para uma pessoa.

Detecção. Quando interessa a probabilidade de uma propriedade estar presente. Aplica-se a spam, fraude, urgência, exposição de dados sensíveis e tentativas de prompt injection. Em sistemas com agentes de código, um uso proposto é classificar um comando de terminal como somente leitura, reversível ou irreversível antes de executá-lo.

Pontuação e ranqueamento. Quando a resposta pertence a uma escala ordenada ou quando itens precisam ser ordenados por relevância. Inclui gravidade de incidentes, adequação de currículos a uma vaga e reordenação de resultados de busca. Um padrão recorrente em projetos publicados é combinar uma busca por palavras-chave, que gera candidatos, com o Jev, que os reordena pela intenção da consulta, sem uso de embeddings.

Verificação. Quando um artefato precisa ser checado quanto a modos de falha específicos. Aplica-se à verificação de saídas de LLMs contra uma política, à checagem de se uma citação sustenta a afirmação a que está associada e à validação de chamadas de ferramentas em agentes. O custo reduzido torna viável aplicar essas checagens a todas as chamadas, e não apenas a uma amostra.

Extração com alternativas delimitadas. O modelo pode escolher valores entre candidatos já identificados ou recuperar componentes pertencentes a conjuntos limitados, como o mês de uma data. Para um nome, e-mail ou trecho arbitrário, uma etapa anterior pode identificar candidatos por regras, expressões regulares ou um modelo generativo; o Jev escolhe entre eles. Isso difere de gerar livremente o conteúdo de um campo. Suas probabilidades também podem servir como variáveis de entrada para outro modelo de aprendizado de máquina.

Os relatos de uso real ainda são poucos e, em sua maioria, autodeclarados. A Metaview, plataforma de recrutamento, afirma ter integrado o Jev a seus agentes e reduzido o tempo de buscas de candidatos de minutos para segundos, com a mesma acurácia, segundo a empresa. Desenvolvedores independentes relataram, entre outros, a classificação de cerca de mil artigos científicos em 24 tópicos por US$ 0,08 e ferramentas de busca de código com ganhos em métricas de recuperação. São resultados informados pelos próprios autores, sem verificação externa, e devem ser lidos como indicativos do tipo de problema que o modelo resolve, não como evidência de desempenho em produção.

Limitações

A TypeSafe publica, para cada versão do modelo, uma lista de tarefas em que o desempenho é fraco. As principais limitações da versão Jev 1.13 incluem:

Leitura literal das instruções. O modelo responde à pergunta como foi escrita, incluindo negações e condições implícitas. Ambiguidades na formulação se refletem diretamente nas respostas.
Aritmética e contagem. O modelo não realiza cálculos nem contagens de forma confiável. A recomendação é fazer a aritmética no código ou, para contar itens que satisfazem uma condição semântica, fazer uma pergunta do tipo Noul por item, aplicar um limiar e contar as decisões afirmativas no código. Somar diretamente as probabilidades produz uma estimativa de contagem esperada, não uma contagem inteira de itens classificados.
Datas. Datas são tratadas como texto, o que torna comparações e intervalos pouco confiáveis. O caminho recomendado é extrair componentes por meio de perguntas do tipo Choice e construir a data no código.
Indireção e excesso de contexto. Negações duplas, relações com múltiplos passos e estados com muito conteúdo irrelevante reduzem a precisão. Filtrar o estado antes da chamada é responsabilidade da aplicação.
Conteúdo adversarial. O estado é tratado como dado, mas textos escritos para manipular o modelo ainda podem influenciar as respostas.
Ausência de geração de texto. O modelo não produz resumos, explicações nem código. Quando uma resposta textual é necessária, o Jev pode ser combinado com um LLM, cabendo a ele a decisão e ao LLM a redação.

A avaliação do PriorBench relata um resultado adicional: quando os critérios das opções são descritos incorretamente, a acurácia no experimento caiu para 16,7%, abaixo dos 25% esperados por escolha aleatória em quatro opções. Na prática, o texto das perguntas e dos critérios funciona como o programa. Uma especificação errada não produz apenas respostas imprecisas, mas respostas sistematicamente incorretas.

Avaliações independentes

Os números mais divulgados sobre o Jev, de 193,6 vezes mais rapidez e 444,6 vezes menor custo, vêm das avaliações da própria TypeSafe. A empresa ressalta que esses valores devem estar no limite superior dos ganhos reais e que suas avaliações usam como referência a média das respostas de dois modelos de fronteira, e não rótulos verificados. Nessas mesmas avaliações, o Jev obteve 67,8% de concordância agregada, em nível semelhante ao do Claude Sonnet 5 e abaixo dos 74,1% do GPT-5.6 Sol. Em processamento de faturas, a diferença foi maior: 61,8% contra 79,1%. A empresa também optou por não publicar resultados em benchmarks públicos.

Os relatos de avaliação abaixo usam tarefas e procedimentos diferentes. Seus resultados devem ser lidos dentro dessas condições, sem tratá-los como uma classificação geral dos modelos.

Na avaliação da AY Automate, o Jev e quatro LLMs foram submetidos às mesmas 791 decisões rotuladas, a partir de dois conjuntos de dados públicos, em tarefas de roteamento de intenção e detecção de prompt injection. O Jev foi de 2 a 3,6 vezes mais rápido na mediana e de 4,7 a 7,5 vezes mais barato que os dois menores modelos testados, com acurácia próxima à desses modelos no conjunto das tarefas, embora com diferenças em testes específicos. Não superou o GPT-5.6 Terra, que ficou 5 pontos à frente no roteamento entre 77 intenções, diferença que se mostrou estatisticamente significativa. O resultado mais útil para aplicações foi o de uma cascata: quando o Jev respondeu apenas os itens com confiança igual ou superior a 0,80 e encaminhou os demais ao Terra, a acurácia observada ficou próxima à do Terra isolado, com 26% a 28% do custo e cerca de metade da latência média.

O PriorBench descreve uma avaliação pré-registrada, com 5.721 chamadas, 21 experimentos e 50 previsões registradas antes da coleta dos dados. Em um conjunto de 400 itens, o Jev atingiu 95,9% de acurácia sem exemplos, contra 77,2% de um classificador baseado em palavras-chave escritas manualmente e 66% de um modelo TF-IDF com regressão logística treinado com todos os rótulos. Os autores registraram que a maior parte de seus erros de previsão foi no sentido de subestimar o modelo. É também dessa avaliação o resultado sobre critérios mal descritos mencionado na seção anterior.

O projeto ejs-5/jev-benchmark relata uma avaliação com 868 decisões extraídas do histórico de commits de um repositório público, com rótulos obtidos mecanicamente a partir do que cada alteração de fato modificou. O relato aponta problemas de calibração que variam entre Choice, Score e Noul. A interpretação exige atenção à métrica: em Noul, o valor retornado estima a probabilidade de a resposta ser afirmativa, não a probabilidade de a decisão final estar correta. Uma análise de calibração precisa comparar probabilidades previstas e frequências observadas do mesmo evento. Diferenças entre tarefas e tipos de pergunta podem produzir resultados distintos sem contradição.

Um quarto resultado, divulgado em uma síntese do The D*AI*LY Brief, trata da detecção de phishing em 2.000 e-mails. Com uma única pergunta, o Jev obteve 62,6% de acurácia, contra 81,3% do Claude Haiku 4.5. Quando a tarefa foi decomposta em cinco perguntas específicas, com pesos ajustados em mil exemplos rotulados, a acurácia relatada chegou a 95% nos mil exemplos restantes. Essa segunda configuração inclui ajuste supervisionado dos pesos; por isso, o ganho não deve ser atribuído apenas à divisão da pergunta. Como a referência aqui é uma síntese, esse resultado exige consulta à avaliação original antes de sustentar comparações mais fortes.

Esses relatos sugerem vantagens de velocidade e custo em tarefas delimitadas, mas não sustentam uma equivalência geral com modelos de fronteira. Também não demonstram calibração consistente entre tarefas e tipos de pergunta. A decomposição do problema aparece como uma estratégia promissora, mas seus ganhos dependem da formulação, das regras de combinação e de eventual ajuste com dados rotulados.

O estudo da AY Automate, por exemplo, usou uma execução por modelo em conjuntos públicos e avaliou a cascata com os resultados já coletados. A latência da cascata é uma estimativa desse arranjo. Os números orientam um experimento, mas não substituem uma avaliação no ambiente de produção.

Uso atual

Na documentação consultada em 25 de setembro de 2026, o Jev 1.13 custa US$ 0,042 por milhão de tokens de entrada, sem cobrança pelos tokens de saída. As condições de acesso e os limites de uso podem mudar; consulte a página de modelos antes de integrar o serviço.

Uma forma de adoção apoiada pelo experimento da AY Automate é a cascata: o Jev responde as decisões em que tem confiança alta e encaminha as demais a um LLM mais capaz. Um esboço, supondo que client, INTENCOES, LIMIAR e classificarComLLM já estejam definidos na aplicação:

const { answers } = await client.systemOne({
  state: { mensagem },
  questions: { intencao: choice('Qual a intenção de `mensagem`?', INTENCOES) },
})

if (answers.intencao.confidence >= LIMIAR) {
  return answers.intencao.choice
}

return classificarComLLM(mensagem)

O valor de LIMIAR precisa ser escolhido com dados da própria aplicação. Uma abordagem é executar o Jev em paralelo ao sistema atual, sem que suas respostas afetem o comportamento, e registrar previsões, confiança e rótulos de referência. Use um conjunto de validação para escolher os limiares e outro conjunto separado para estimar o desempenho final.

Registre também a versão do modelo. O alias jev-latest pode mudar; depois de ajustar os limiares, fixe a versão avaliada e repita a validação antes de atualizar. Como os exemplos deste artigo estão em português, vale observar que a TypeSafe informa melhor desempenho em inglês: resultados em outros idiomas precisam ser medidos diretamente.

Considerações finais

O Jev não substitui LLMs. Ele oferece uma alternativa para as decisões semânticas curtas que o código precisa tomar muitas vezes, com baixa latência e saída previsível. A contribuição mais concreta do lançamento é a interface: um modelo com saída tipada por construção, probabilidades como parte da resposta, várias perguntas por requisição e custo de saída nulo.

As avaliações citadas não bastam para generalizar as alegações de desempenho de fronteira ou ganhos de duas ordens de grandeza. Há resultados favoráveis em custo e latência, mas a magnitude depende da tarefa, do modelo de comparação e da configuração. A conformidade ao schema é uma garantia distinta da correção semântica, e a utilidade da confiança precisa ser validada. Com cerca de dez dias desde o lançamento e uma arquitetura ainda não divulgada, a decisão de adoção deve se apoiar nos próprios dados e nas consequências dos erros.

Referências

As fontes abaixo incluem documentação do fornecedor, relatos independentes e fundamentação acadêmica; elas têm escopos e níveis de evidência diferentes.

Fontes primárias