Opinião

Jev e a Nova Camada de Decisão para Agentes de IA

mm
Adicione Unite.AI às suas fontes preferidas no Google

Por que os modelos System One podem separar julgamentos rápidos de raciocínio lento

Muitos agentes de IA utilizam um modelo de linguagem para quase todas as suas decisões. O modelo de linguagem escolhe uma ferramenta, avalia os resultados, determina se precisa continuar e, finalmente, gera respostas. Flexível; porém, esse processo pode ser caro quando decisões de sim ou não são repetidas em escala. A Unite.AI já discutiu anteriormente como fluxos de trabalho agenticos aumentam chamadas ao modelo, contexto e tentativas. Cada decisão adicional pode acrescentar tempo e dinheiro antes de fornecer aos usuários informações úteis.

Jev sugere dividir a tarefa de forma diferente. Utilize um modelo construído para julgamentos limitados nos quais o conjunto de respostas está definido. Utilize um modelo generativo para raciocínio aberto e linguagem. Jev sugere que a ideia principal aqui não é que todos os agentes precisem adquirir um novo produto. O conceito chave é que um agente não precisa do mesmo tipo de inteligência em todos os momentos.

O Que o Jev Realmente Faz

A TypeSafe lançou o Jev em setembro de 2026, o primeiro de seus novos modelos System One. Jev não escreve textos. Em vez disso, você envia a ele um estado (como uma mensagem de suporte e dados do usuário). Você também envia uma ou mais perguntas que têm tipos de resposta predefinidos. Então o Jev responde com respostas tipificadas e probabilidades.

De acordo com a documentação oficial da empresa, há três primitivas para fazer julgamentos:

  • Choice permite que você escolha entre opções predefinidas.
  • Score permite que você avalie algo em relação a um critério ordenado.
  • Noul estima a probabilidade de que uma afirmação seja verdadeira.

Você pode fazer várias perguntas independentes sobre o mesmo estado em uma única solicitação.

Por exemplo, digamos que você esteja lidando com um problema de atendimento ao cliente. Um sistema pode querer descobrir qual equipe deve tratar este caso. Também pode determinar quão rapidamente alguém precisa responder e verificar se o cliente solicitou um reembolso.

Um modelo de chat poderia potencialmente executar todas as três tarefas. No entanto, ele precisará devolver os resultados ao seu aplicativo como uma resposta estruturada. Em contraste, o Jev fornece apenas essas decisões limitadas. Seu aplicativo então decidiria qual ação tomar a seguir com base nessas decisões.

A Mudança Arquitetônica Importa Mais do que o Modelo

A maioria desses debates compara modelos grandes com pequenos. Jev propõe uma fronteira alternativa. Algumas etapas envolvem geração de linguagem. Outras são julgamentos restritos que o software pode consumir.

Isso cria uma camada de decisão no agente. O modelo fará estimativas. O software aplicará políticas. Se a probabilidade estimada exceder um limiar testado e a ação for de baixo risco e reversível, o fluxo de trabalho pode continuar. Se houver incerteza nos resultados ou se a ação puder ter implicações graves, o sistema pode buscar supervisão humana. Um modelo de raciocínio pode ajudar a investigar a incerteza, mas não substitui a aprovação humana necessária.

Figura 1. Um caminho de decisão limitado mantém limites, permissões e escalonamento no código.

Existem semelhanças com o roteamento de modelos, mas há uma diferença crítica. RouteLLM faz decisões sobre qual dos dois modelos de linguagem escolher. Ele seleciona entre um modelo mais forte e um modelo mais fraco para equilibrar qualidade e preço. Um modelo System One produz julgamentos limitados que o código pode usar diretamente. Esses julgamentos podem apoiar o roteamento de modelos, bem como outras decisões dentro de um agente.

Por que Loops de Agente São um Ajuste Natural

A natureza dos loops de agente os torna particularmente adequados para fazer inúmeros julgamentos em níveis muito pequenos. Esses julgamentos ajudam a alcançar o resultado final. Em outras palavras, os agentes precisam fazer muitos julgamentos \”pequenos\” depois que um usuário envia sua pergunta ou solicitação. Esses julgamentos ocorrem antes que a resposta ou saída seja devolvida.

Um exemplo seria decidir quais ferramentas utilizar, classificar registros recuperados e avaliar risco. O sistema também determina se há evidências suficientes e se o processo deve continuar. Muito provavelmente tudo isso ocorrerá repetidamente. Além disso, atrasos entre cada loop podem se acumular ao longo do tempo.

Esse papel dos loops de agente é exemplificado por integração do Jev da LangChain, onde o Jev pode executar tanto o roteamento de modelos quanto verificações de chamadas de ferramentas. Enquanto o Jev se integra nas bordas do modelo generativo, o próprio modelo generativo continua a planejar e gerar conteúdo. Isso representa um caso de uso muito mais realista para o Jev. Ele complementa um modelo de linguagem de uso geral ao invés de substituí-lo.

Além disso, paralelizar perguntas também altera a forma como as equipes pensam sobre a decomposição de tarefas. Especificamente, as equipes podem dividir uma instrução ambígua em múltiplas perguntas de avaliação discretas. Isso pode potencialmente resultar em uma sequência muito mais curta de chamadas ao modelo. Pode criar um fluxo de trabalho muito mais fácil de avaliar. Também permite que os desenvolvedores usem lógica de negócios explícita para combinar os julgamentos resultantes.

Modelos de linguagem de uso geral podem produzir saída estruturada e podem ser a escolha melhor em alguns casos. Por exemplo, uma determinação e uma explicação podem precisar ser fornecidas juntas. Portanto, Jev deve demonstrar mais do que apenas conformidade com o esquema para ser considerado eficaz.

A eficácia do Jev depende de alcançar reduções na latência geral do sistema. Também depende de produzir estimativas de probabilidade úteis e de apresentar estabilidade de desempenho em diferentes entradas. Caso o Jev não entregue esses benefícios, selecionar outro modelo apenas acrescentará desenvolvimento adicional e sobrecarga operacional.

Typed Significa Correto?

A linguagem usada ao fazer afirmações sobre o Jev também precisa ser cuidadosamente redigida. Como o espaço de saída é definido antecipadamente, o modelo não deve retornar um campo inventado ou um parágrafo não analisável. Isso elimina uma forma de falha; não elimina erro semântico. Não há nada que impeça um sistema de retornar um departamento incorreto, atribuir um nível de risco errado ou declarar certeza excessiva. Ele pode fazer tudo isso enquanto permanece totalmente type-safe.

TypeSafe’s own documentação do System One faz uma distinção importante. A calibração é medida em grupos de previsões; não garante a correção de uma previsão individual. Na produção, isso tem implicações. As equipes precisam testar se as probabilidades previstas correspondem aos resultados observados em seus próprios dados.

A evidência de desempenho ainda é incipiente

TypeSafe relata tempos de resposta de 70 a 500 milissegundos. Também faz referência a economias de custo substanciais e melhorias de velocidade em suas avaliações internas de fluxo de trabalho. Além disso, a TypeSafe indica que esses ganhos de destaque provavelmente estão próximos do limite superior dos ganhos no mundo real. TypeSafe’s testes de fluxo de trabalho publicamente disponíveis usa probabilidades de referência fornecidas por outros modelos de ponta em vez de rótulos de verdade de base. Os resultados são bons para formar hipóteses. Os resultados não podem substituir um teste independente contra uma carga de trabalho real.

Um Teste Prático Antes da Adoção

Quando você cria seu primeiro fluxo de decisão impulsionado por IA, não escolha suas decisões mais críticas (por exemplo, aprovações médicas ou suspensões de contas). Em vez disso, escolha algo que seja muito comum, reversível e fácil de revisar por outras pessoas da equipe. Isso inclui, mas certamente não se limita a, roteamento de tickets, categorização de documentos, seleção de modelo e garantia de qualidade de baixo risco.

Quatro perguntas ajudarão você a avaliar se isso funcionará:

  • A saída tem um número finito de respostas possíveis?
  • Você pode articular claramente os critérios para o julgamento?
  • Existem resultados mensuráveis?Rastreie a previsão, sua probabilidade, a ação e os resultados subsequentes. Verifique a calibração regularmente comparando as probabilidades previstas com os resultados observados.
  • Você tem um plano alternativo caso o processo de decisão automatizado falhe?Identifique um ponto específico para usar um modelo de raciocínio, solicitar mais informações ou envolver um humano.

Sua análise deve incluir todo o fluxo de trabalho, incluindo o processo de tomada de decisão. Use métricas como precisão da decisão, taxas de abstenção ou escalonamento, tempo total de processamento de ponta a ponta, custo por tarefa concluída com sucesso e impacto dos erros. Execute testes em condições adversas: variação de uso de palavras, omissão de dados relevantes, categorias raras e entradas adversariais. Um classificador otimizado que gera custos adicionais downstream não é uma otimização.

A Lição de Longo Prazo Aqui

Se o Jev for bem-sucedido, mudar significativamente ou for substituído rapidamente, uma coisa permanece constante. A questão arquitetural permanece. É necessário que toda decisão baseada em máquina seja renderizada como linguagem gerada?

Em muitos casos, a resposta é “não”. Em um ambiente de produção, um sistema que usa modelos generativos pode gerar interpretações, planos e explicações. Usando modelos de decisão limitados, o mesmo sistema pode rotear, pontuar e bloquear. O código pode continuar a definir valores de limiar aceitáveis e permissões. Os humanos devem permanecer responsáveis pelas decisões que afetam a vida de outras pessoas.

Embora isso represente uma perspectiva menos dramática do que ter um modelo autônomo executando todas as tarefas de forma confiável, reflete como sistemas confiáveis são criados. O próximo avanço de desempenho para agentes pode depender da seleção das áreas no sistema onde o pensamento leva mais tempo. Outras áreas precisam de decisões rápidas, e algumas não requerem ação alguma.

Himanshu Goel é um pesquisador de IA/ML especializado em geração aumentada por recuperação para domínios de alto risco, incluindo fluxos de trabalho de documentos biomédicos, financeiros e regulamentares.