Por que o Jev pode ser muito mais rápido que um LLM

Principais destaques

• Eles não precisam escrever: modelos de decisão trabalham com respostas previamente delimitadas, como escolhas, pontuações ou probabilidades.
• Jev aposta nessa lógica: o modelo da TypeSafe foi projetado para entregar resultados estruturados que podem ser usados diretamente pelo software.
• Velocidade tem um preço: quanto mais limitado o espaço de respostas, mais eficiente pode ser a inferência. Mas isso também reduz a flexibilidade.

Um cliente escreve: “Fui cobrado duas vezes pela assinatura e quero meu dinheiro de volta”.

O sistema precisa realmente escrever uma resposta completa para entender o que fazer?

Talvez não.

Se a próxima ação for simplesmente encaminhar o chamado para Billing, tudo o que o software precisa é dessa decisão.

É justamente nesse espaço que entram os chamados modelos de decisão, uma categoria de sistemas de IA construída para resolver problemas mais estreitos do que aqueles enfrentados por grandes modelos de linguagem.

A diferença começa antes da resposta 🤖

Um LLM é construído para gerar linguagem. Ele recebe uma entrada e, normalmente, produz uma sequência de tokens até chegar à resposta final.

Um modelo de decisão começa com uma pergunta diferente: qual é o resultado que o software precisa obter?

Pode ser uma categoria, uma pontuação ou uma probabilidade.

A partir daí, o espaço do problema já está delimitado.

	Modelo de decisão	LLM
Saída principal	Escolha, score ou probabilidade	Texto ou geração estruturada
Espaço de resposta	Definido pela aplicação	Muito amplo
Geração	Não precisa produzir texto token a token	Normalmente autoregressiva
Uso típico	Roteamento, triagem, scoring	Escrita, explicação, raciocínio
Flexibilidade	Mais limitada	Muito ampla

Essa diferença parece pequena. Na prática, muda bastante a quantidade de trabalho que o sistema precisa fazer.

O que o Jev está tentando fazer 🔎

O Jev, da TypeSafe, é um exemplo atual dessa abordagem.

A documentação do produto trabalha com três primitivas principais:

• Choice: escolher uma opção entre alternativas definidas.

• Score: posicionar uma entrada em uma escala, como urgência ou risco.

• Noul: produzir uma probabilidade para uma afirmação binária.

A própria TypeSafe descreve o Jev como um modelo “System One” para software. Nesse caso, porém, “System One” é uma nomenclatura utilizada pela empresa, e não um padrão geral da indústria.

A ideia é tratar o resultado da IA como parte do código.

Em vez de perguntar a um modelo:

“Explique como devemos lidar com este chamado.”

o software pode perguntar algo muito mais específico:

“Qual departamento deve receber este chamado?”

O resultado pode ser usado imediatamente para decidir o próximo passo.

E por que isso pode ser mais rápido? ⚡

Aqui está a parte mais interessante.

Um LLM generativo normalmente produz sua resposta de maneira autoregressiva. Um token é gerado, depois outro, depois outro. Uma resposta mais longa exige mais etapas de geração.

Um modelo de decisão não precisa produzir esse texto.

Ele pode avaliar a entrada e devolver diretamente o resultado estruturado necessário.

💡 A velocidade não vem de um “atalho mágico”. Vem, em grande parte, do fato de o sistema ter menos coisa para fazer.

Se o software só precisa saber se um chamado pertence a Billing, Technical Support ou General Support, gerar um parágrafo explicando a decisão é trabalho adicional.

É como pedir para um atendente escrever um relatório inteiro quando você só precisava que ele apontasse para uma das três portas.

Mas um JSON não resolve isso?

Até certo ponto.

Um LLM pode ser instruído a responder em JSON, por exemplo:

{
  "department": "billing"
}

Isso torna a saída muito mais fácil de consumir por um programa.

Mas existe uma diferença fundamental.

O modelo continua sendo generativo. Ele está produzindo tokens que precisam obedecer a uma estrutura determinada. A aplicação ainda precisa lidar com validação, parsing e eventuais respostas que não estejam de acordo com o formato esperado.

Um modelo de decisão começa com o espaço de respostas delimitado.

A diferença não é apenas estética. É arquitetural.

Menos liberdade, mais previsibilidade 🎯

Imagine um sistema de moderação que só pode retornar três resultados:

• permitido
• revisão humana
• bloqueado

Um modelo de decisão não precisa inventar uma quarta categoria.

Isso é útil porque o software já sabe o que fazer com cada resultado.

O mesmo princípio pode ser aplicado a sistemas de atendimento, avaliação de risco, priorização de tarefas e roteamento de modelos.

O resultado deixa de ser uma conversa e passa a ser um sinal para o sistema.

Só que existe uma pegadinha importante

Uma resposta estruturada pode estar perfeitamente formatada e ainda assim estar errada.

Se o sistema só pode escolher entre A, B ou C, ele pode retornar “B” corretamente do ponto de vista do formato e incorretamente do ponto de vista do conteúdo.

Essa é uma distinção fundamental.

Limitar as respostas não garante que a decisão esteja certa.

Uma probabilidade também não é uma prova. Ela é um sinal que pode alimentar regras de software, thresholds ou uma etapa de revisão humana.

Pesquisas recentes citadas no material-base ajudam a ilustrar esse ponto. Um estudo sobre o uso do Jev como juiz encontrou custos de inferência muito baixos, mas também diferenças maiores em tarefas que exigiam verificar uma derivação ou resistir a uma resposta cuidadosamente construída e incorreta.

Outro estudo, sobre julgamentos de documentos jurídicos, encontrou menor custo e menor tempo mediano de resposta para o Jev em determinadas configurações, enquanto modelos de linguagem apresentaram maior acurácia de referência.

São resultados específicos de tarefas e configurações testadas. Não significam que uma arquitetura seja superior à outra em todos os trabalhos.

É aqui que os dois modelos começam a trabalhar juntos 🤝

Talvez essa seja a consequência mais interessante dessa arquitetura.

A discussão não precisa ser Jev versus LLM.

Os dois podem ocupar posições diferentes dentro da mesma aplicação.

Um agente poderia utilizar um LLM para interpretar uma solicitação complexa, produzir uma explicação ou conversar com o usuário.

Depois, um modelo de decisão poderia cuidar de tarefas mais delimitadas:

• escolher a fila de atendimento;

• determinar um nível de urgência;

• decidir se é necessário encaminhamento humano;

• verificar se determinada ação deve prosseguir;

• escolher qual modelo de IA deve receber a próxima etapa.

O LLM fica responsável pelo que exige linguagem e flexibilidade.

O modelo de decisão fica responsável por aquilo que precisa virar uma decisão operacional.

E isso pode mudar a arquitetura dos agentes 🧩

Hoje, é tentador usar um LLM para praticamente tudo.

Quer classificar? LLM.

Quer escolher uma ferramenta? LLM.

Quer decidir se deve escalar para um humano? LLM.

Quer determinar a prioridade? LLM.

Funciona. Mas nem sempre é a forma mais eficiente de construir o sistema.

Se uma tarefa possui um conjunto conhecido de resultados possíveis, um modelo especializado nessa decisão pode ser mais adequado.

Isso também pode reduzir a quantidade de geração desnecessária.

A pergunta passa a ser menos “qual é o modelo mais poderoso?” e mais “qual é a menor quantidade de inteligência necessária para esta etapa?”

Onde os modelos de decisão fazem sentido?

Há um padrão comum entre os casos de uso.

O software já sabe quais são as próximas ações possíveis.

1️⃣ Roteamento: encaminhar um chamado para a equipe adequada.

2️⃣ Scoring: atribuir um nível de risco, urgência ou prioridade.

3️⃣ Moderação: classificar conteúdo em resultados previamente definidos.

4️⃣ Escalonamento: decidir quando uma pessoa precisa assumir o atendimento.

5️⃣ Roteamento de modelos: escolher entre uma opção mais rápida ou outra mais sofisticada.

6️⃣ Guardrails: verificar se determinada ação de um agente deve ser executada.

Em todos esses casos, o software não está procurando uma boa redação.

Está procurando uma decisão.

E quando o LLM continua sendo indispensável? ✍️

É justamente onde a resposta precisa ser criada.

Escrever um e-mail, resumir um documento, explicar um problema técnico, gerar código, conversar com alguém ou responder uma pergunta aberta são tarefas em que a flexibilidade de um LLM continua sendo central.

Um modelo de decisão poderia dizer que um documento é “urgente”.

Mas não necessariamente deveria ser responsável por explicar ao usuário por que ele é urgente.

Essa diferença parece óbvia quando colocada dessa maneira. Ainda assim, boa parte da arquitetura atual de IA nasceu em torno de uma ferramenta extremamente versátil sendo usada para resolver problemas que nem sempre precisam de geração de linguagem.

Afinal, o que está ficando mais rápido?

A afirmação “modelos de decisão são mais rápidos que LLMs” precisa ser lida com cuidado.

A latência real depende de vários fatores:

• hardware;

• carga do servidor;

• tamanho da entrada;

• rede;

• batching;

• implementação;

• modelo utilizado como comparação.

As métricas publicadas pela TypeSafe para o Jev são medições de servidor e não devem ser transformadas automaticamente em um multiplicador universal de velocidade no mundo real.

Ainda assim, existe uma lógica clara por trás da diferença.

Se um sistema precisa retornar apenas uma decisão, não faz muito sentido obrigá-lo a gerar uma resposta longa antes de chegar a ela.

A pergunta talvez esteja mudando

Durante anos, a evolução dos modelos de IA foi muito associada a uma corrida por modelos maiores, mais capazes e melhores em tarefas cada vez mais amplas.

Os modelos de decisão apontam para outra direção.

Em vez de perguntar apenas “o que o modelo consegue fazer?”, desenvolvedores podem começar a perguntar:

“O que exatamente eu preciso que ele devolva?”

Se a resposta for uma escolha, um score ou uma probabilidade, talvez não seja necessário pedir ao modelo uma conversa inteira.

💡 Às vezes, a melhor resposta de uma IA não é uma resposta. É um sinal que permite ao software decidir o que fazer em seguida.

É uma mudança sutil, mas importante.

O futuro dos sistemas de IA pode não ser composto por um único modelo gigantesco fazendo tudo. Pode ser uma combinação de modelos especializados, cada um responsável por uma parte diferente do trabalho.

E, nesse cenário, a velocidade do Jev não seria apenas uma questão de performance.

Seria consequência de uma pergunta mais simples: por que gerar linguagem quando o software só precisa tomar uma decisão?