Modelos System One como o Jev: Glean, UiPath e Workday embutem chamadas rápidas diretamente no código

Uma dor conhecida: o LLM no código de produto se comporta como uma loteria. Diogo Almeida, cofundador e CEO da TypeSafe AI, resumiu isso no AI Engineer Code Summit assim: em 95% dos casos você recebe Einstein, nos outros 5%, Mr. Bean. E se você não consegue distinguir um do outro, não há o que automatizar. A resposta dele para esse problema se chama System One.

O que são os modelos System One

São modelos não generativos. Eles não escrevem texto coerente nem raciocinam passo a passo. Devolvem um resultado estruturado: uma opção de uma lista, uma nota ou uma probabilidade. Por isso, em geral, são visivelmente mais rápidos e baratos do que os LLMs de raciocínio, chamados na conferência de System Two.

Um exemplo simples. Antes, você pedia ao LLM "avalie se este documento é relevante para a consulta", recebia um parágrafo de raciocínio e o processava com expressões regulares. Agora você chama um modelo que devolve de imediato um número ou um rótulo. Ele pode entrar em um laço, em uma condição if ou em uma ordenação, e vai se comportar de maneira previsível.

O Jev é o produto com o qual, segundo a Latent Space, essa onda começou. Ele foi lançado em setembro, e o podcast com Almeida se tornou o episódio mais popular do veículo no ano. A principal tese de Almeida para os engenheiros: o código é a linguagem da automação, portanto o modelo precisa ser embutido no código. O fundador da Latent Space, swyx, traduziu assim: espalhe generosamente chamadas System One dentro do aplicativo, em vez de "juntar strings e torcer para dar certo".

O que já está sendo construído

A Glean usa o System One ao lado de LLMs e de outros classificadores. Chinmay Goyal destacou a principal vantagem do Jev: a flexibilidade zero-shot. Quando a taxonomia de decisões muda, não é preciso retreinar o modelo de novo e de novo. Para os usuários da Glean tanto faz o que há por baixo do capô, e a empresa esconde deliberadamente essa diferença.

A UiPath mostrou o padrão do "torneio". O Jev escolhe os trechos de documentos mais relevantes dentro de pequenos grupos, os vencedores avançam para a rodada seguinte, e assim até a final. Todo o processo levou menos de um segundo, embora tenha envolvido milhares de chamadas ao Jev. A conclusão dos engenheiros da UiPath: isoladamente o modelo pode parecer pouco inteligente, mas, em um esquema bem montado, esses blocos formam um sistema mais inteligente.

O engenheiro da Workday Scott Roberts mostrou um protótipo em que a interface começa a preencher o cartão de férias enquanto o usuário ainda está digitando. Aqui, a chamada rápida ao modelo não apenas acelera o formulário, mas muda o comportamento do próprio software: de prever o que você quer dizer para prever o que você quer fazer.

Limitações

Isto é uma reportagem de conferência, não um benchmark. O material não traz números de precisão, e os "95% de Einstein" são uma piada de palco, não uma medição. O Jev existe há menos de dois meses, então é cedo para falar de operação de longo prazo. Além disso, Almeida comparou explicitamente o momento atual com os primórdios da internet, quando os experimentos eram valiosos só por serem possíveis. Isso inspira, mas não é uma justificativa de produto. Os LLMs de raciocínio também não vão desaparecer: a própria Glean os usa junto com o System One.

O que fazer na prática

1. Percorra o código e encontre os pontos em que o LLM é usado como classificador, ranqueador ou roteador. Esses são os primeiros candidatos à substituição por um modelo rápido.
2. Experimente o esquema de torneio para ranqueamento: muitas chamadas baratas em grupos pequenos, em vez de uma chamada cara sobre a lista inteira.
3. Meça com seus próprios dados a precisão, a latência e o custo, sem se basear em apresentações. Para uma automação confiável, importa não a precisão média, mas o quão previsível é o resultado.
4. Pense onde a resposta instantânea muda a interface. O preenchimento automático de um formulário durante a digitação é justamente um caso assim.

O principal nesta história não é um produto específico, mas uma mudança de arquitetura: nem toda decisão em um aplicativo precisa ser entregue a um grande modelo generativo.