Porque é que um Jev que não conversa serve um Agent

A um Agent falta muitas vezes um juízo que entre num ramo, não mais um trecho de texto longo. Este texto explica as três perguntas, o que a avaliação de workflow compara, e porque um caminho quente não pode esperar um chat.

Folkbench folkbench.com

Coautor: folkbench.com (Folkbench é uma plataforma de avaliação e seleção que se pode rever, para APIs de IA, serviços de modelos e sites relacionados. Apoia-se em informação publicada sobre o serviço, preços, disponibilidade, latência e janelas de evidência para ajudar os utilizadores a comparar e a escolher um caminho.)

Dez textos nesta série:

O que a um Agent muitas vezes falta não é mais um trecho de texto longo. É um juízo que possa entrar direto no fluxo de controlo. Os casos habituais são se este alerta fica fechado, se esta fatura se paga, se esta trace precisa de uma pessoa, e se a próxima frase de apoio ao cliente deve ser escalada. Estes nós não estão ali para o modelo escrever uma análise. O código precisa de um valor que possa comparar e em que possa ramificar. É isso que o Jev faz.

A formulação da TypeSafe quer dizer uma chamada de função de inteligência de fronteira. O state entra. Sai uma decisão probabilística com tipo. Não gera strings. A frase para uma pessoa, e o juízo para um programa, não são a mesma saída.

Fixe primeiro a saída

A saída dos modelos grandes atuais é uma string. O software que precisa de continuar ainda tem de a analisar, de a validar, e de se guardar do desvio. Aparece um campo a mais. O parágrafo parece completo, e o enum não bate certo. Uma pessoa numa caixa de chat repara e volta a perguntar. O código não repara, e segue com o erro. Enterrado várias chamadas abaixo, um modelo mais inteligente não o repõe.

O Jev fixa o espaço de saída de antemão. Você diz o que lhe é permitido devolver, e ele só atribui probabilidade dentro desse espaço. Um erro de tipo não pode acontecer, matematicamente. Não consegue devolver uma forma que você não definiu. Isso não é o mesmo que o juízo estar correto. A probabilidade pode inclinar-se para o lado errado, e a opção pode ser a errada. A segurança de tipos fecha a forma, não o certo e o errado. Fixa a forma, e os ramos a seguir já se podem escrever. Você não tem de ir primeiro pescar um valor de dentro de um parágrafo.

Há só três perguntas.

Noul é sim-não. O modelo dá uma probabilidade de 0 a 1. Perto de 1 é sim. Perto de 0 é não. Perto de 0.5 é incerteza. Não junta uma confiança à parte. A probabilidade é o sinal. Choice é escolha única. Você lista primeiro as opções, com um teto de 255. O que é devolvido é a opção escolhida, a distribuição sobre cada opção, e uma confiança. O código usa essa distribuição para decidir se age ou se entrega o caso a uma pessoa. Score é níveis. Os níveis vão de 2 a 10, e você escreve o que cada nível significa. O que é devolvido é uma pontuação, a distribuição sobre os níveis, e uma confiança. A pontuação pode cair entre dois níveis, como uma posição na escala.

Um sim-não escreve-se como uma condição. A escolha única e os níveis são diferentes: a primeira olha para a opção em que caiu, os segundos aplicam um limiar à pontuação. Uma boa pergunta continua estreita. Um juízo que uma pessoa que conhece o domínio faz num segundo depois de ler o material é o tipo a dar-lhe. Se o cliente está a pedir um reembolso, é esse tipo de pergunta. Ler a carta inteira e só depois decidir a melhor ação, não é. A segunda frase quer raciocínio lento. Divida, e depois pergunte. As perguntas divididas olham para o mesmo state, independentes umas das outras, e voltam juntas num só pedido. Os pesos ficam no código. Quando a política muda, você muda os números. Você não reescreve o prompt inteiro.

O que trava as pessoas é a bifurcação

O que de facto trava as pessoas é muitas vezes um nó com esta forma. Um alerta chega com registos que a máquina já tem, e a conclusão é fechá-lo, enviá-lo a um analista, ou isolar já. Uma fatura fica presa a uma encomenda e a um registo de entrega, e alguém tem de decidir pagar, reter, ou mandá-la de volta. Um Agent de apoio ao cliente acabou, as chamadas de ferramentas estão todas na trace, e alguém tem de decidir se esta trace é vista, e quão cedo. O cliente escreve outra vez, e o fio e o state da conta estão ambos lá. Como a frase seguinte deve continuar, e se deve escalar, é a mesma forma de pergunta.

A parte que as regras conseguem congelar é código. O que é frágil são as exceções que não se conseguem acabar. O recibo bate certo, o motivo é vago, e um passo na trace parece estranho. A lógica escrita à mão estilhaça-se nestes casos. Você enfia a política inteira num só prompt e deixa o modelo pensá-la de uma vez, e escreve menos condicionais. A saída volta a ser um pedaço de texto. Para o texto entrar no fluxo de controlo, você escreve outra camada de análise. Essa camada pode errar por si.

A workflow eval da TypeSafe mede esta maneira de ligar. A avaliação parte uma tarefa em muitas perguntas estreitas. O que o código consegue decidir, o código decide. O modelo só responde aos juízos que o código não consegue assentar. Os quatro fluxos públicos são um incidente de segurança, observabilidade da trace de Agent, tratamento de faturas, e apoio ao cliente. Sob o mesmo fluxo, um modelo no workflow é mais exato do que enfiar a política inteira num só prompt, e custa menos e leva menos tempo. Na média das quatro tarefas, os modelos em teste movem-se nessa direção.

As ações a seguir acompanham a probabilidade, não um rótulo batido até se fechar. O resultado que sai do sistema continua a ser uma ação discreta. A engenharia do meio tem de ser feita da mesma maneira todas as vezes.

A avaliação mede a proximidade

Esta avaliação não discute consigo se o próprio fluxo foi mal escrito. Assume que o harness está certo. A resposta de referência não é um rótulo de ouro marcado à mão, pergunta a pergunta. O GPT-6 Astra e o Claude Fable 5.1 respondem a cada pergunta em high thinking, e faz-se a média das duas respostas. Os outros modelos usam o raciocínio predefinido do fornecedor. Só com o fluxo já fixo é que se podem comparar. A avaliação compara quão perto um modelo chega dos juízos desses dois modelos grandes, mais a velocidade e o custo.

Portanto o gráfico não prova que o Jev perceba o negócio melhor do que o Astra. O Astra e o Fable são aqui a régua. O Jev tem de se aproximar dos juízos deles, e também tem de abrir um intervalo na latência e no custo. Se as perguntas foram mal divididas, uma régua mais próxima não ajuda. Dividir as perguntas é trabalho de quem escreve o fluxo.

O Jev fica muito para fora na fronteira do «rápido e barato». Os múltiplos mais altos no sítio oficial, cerca de 193.6 vezes mais rápido e 444.6 vezes mais barato, são o extremo alto desta avaliação. Esse múltiplo não é cada chamada. As chamadas aqui estão mais perto da carga de automação que você de facto poria a correr.

Aquilo de que se aproxima é a probabilidade nessas perguntas estreitas depois da divisão, não a escrita de uma análise longa. O Jev não escreve essa análise longa.

Um caminho quente não pode esperar

A latência é dura para um Agent. Uma pessoa ainda consegue esperar três segundos. Quando as camadas se embrulham umas nas outras, já não. A mesma cadeia também tem uma pesquisa, uma escrita na base de dados, e a chamada seguinte, e cada salto gasta o mesmo tempo. Entre 70 e 500 milissegundos, um juízo pode ficar num caminho quente. Fora desse intervalo, a pilha de chamadas trata-o como bloqueio.

A falar com uma pessoa, os modelos de fronteira atuais levam muitas vezes de 3 segundos a mais de 300 segundos, de ponta a ponta. Essa velocidade faz sentido num copilot, ou num Agent de programação com uma pessoa a ver. Como condição num caminho quente, essa velocidade não faz sentido. O Jev não emite uma frase token a token. As probabilidades que devem ser devolvidas chegam juntas. A velocidade vem daí.

A TypeSafe também usa o Jev para verificar. Prompts, rastos de raciocínio e saídas de outros modelos, o Jev pontua-os, e também serve de guardrail e procura jailbreaks. A geração fica com o modelo de chat. Se este portão se passa, quem o decide é um modelo que não gera strings. Isso é uma articulação num Agent, não é chat. Se o aceno e a revisão ainda assentam em texto longo, você tem de encontrar outro programa que o leia. O Jev fecha o resultado em probabilidades e níveis, e a revisão pode escrever-se como código.

A frase escrita para o utilizador continua a ser trabalho do modelo de chat. O Jev não toma essa frase. Toma o encaminhamento à frente, e a verificação atrás. O que a um Agent aqui falta não é mais uma explicação, mais longa. É um juízo cujo tipo já está fixo, para o código poder seguir com ele.

Fontes

Série