Por que tantas chamadas de LLM são na verdade classificação
Boa parte do tráfego de LLM em produção devolve uma palavra só. Escalar esse ticket ou não. Spam ou não spam. Qual dos seis handlers processa esse evento. Para conseguir essa palavra, você manda o prompt inteiro para um modelo de propósito geral, espera ele decodificar uma resposta token por token, e extrai um objeto JSON do resultado. Você paga o preço e a latência de geração de texto, e o que volta é uma decisão que cabe em um enum.
“Modelo system one” é o nome que a TypeSafe AI dá a um modelo construído para esse segundo formato: ele recebe um pedaço de estado mais um conjunto de perguntas tipadas e devolve uma resposta para cada uma em um único passo, sem gerar texto. O termo pega emprestada a divisão de Daniel Kahneman entre o pensamento “Sistema 1”, rápido e automático, e o “Sistema 2”, lento e deliberado. O Jev, a implementação da TypeSafe, é o exemplo trabalhado aqui. O rótulo pertence ao fornecedor, mas a ideia por trás dele é mais antiga: se a saída se limita a um conjunto conhecido de respostas, o modelo pode escolher uma em vez de escrever uma. A pergunta para o seu sistema é se esse formato bate com um gargalo real.
Por que um modelo system one pode pular a decodificação token a token
Um LLM generativo produz uma saída que ainda não viu. Cada token depende de todo token anterior, então o modelo prevê um, o anexa à entrada e prevê o seguinte. Essa dependência é o motivo de a geração ser lenta. O token 40 não pode começar antes de o token 39 existir.
Um modelo desse tipo remove a dependência fixando o espaço de saída antes da chamada. Você não pede que ele escreva uma resposta. Para cada pergunta você dá a ele um menu (escolha um destes rótulos, posicione isso numa escala de 1 a 10, responda sim ou não), e ele pontua cada opção de cada menu em um único passo paralelo. Não há sequência para decodificar, porque toda resposta possível já é conhecida de antemão.
Esse é todo o truque, e também é o limite. Fixar a saída é o que permite pular a autoregressão, e qualquer coisa fora da saída fixa desaparece: você não recebe texto livre nem raciocínio escrito para inspecionar. A própria documentação do Jev diz que o modelo tem desempenho ruim em aritmética, contagem e comparação de datas, tarefas que exigem cálculo em várias etapas em vez de uma escolha entre opções. Se a tarefa exige que o modelo produza algo em vez de selecionar algo, use outra ferramenta.
O que você envia a um modelo system one e o que recebe de volta
Toda chamada tem duas partes. O estado é o que o modelo precisa olhar: um e-mail, um ticket de suporte, um frame de jogo, uma linha de dados de aplicação. As perguntas são tipadas e limitadas, usando os três tipos acima. Para cada pergunta você recebe de volta a resposta escolhida mais uma distribuição de probabilidade sobre as alternativas.
Construa em cima dessa distribuição. “Escalar” com 0.52 e “escalar” com 0.98 têm o mesmo rótulo e significam coisas bem diferentes. A segunda você pode agir automaticamente. A primeira pertence a um caminho mais lento e cuidadoso, seja uma pessoa ou uma chamada completa a um LLM.
Você consegue um sinal parecido de um modelo generativo lendo as log-probabilities dos tokens de uma resposta restrita, se o seu provedor expõe isso. A diferença é que um modelo system one devolve a distribuição como a própria resposta, para cada pergunta, sem essa engenharia extra.
Quando usar um modelo system one num pipeline de LLM
O padrão que funciona é servir de portão, não substituir. Um modelo tipado e rápido decide se a chamada generativa cara sequer precisa acontecer.
- Roteamento. Classifique a requisição antes de escolher qual modelo ou handler a processa, em vez de pedir a um único modelo geral que classifique e responda na mesma chamada. Um pipeline de RAG pode usar o mesmo portão para decidir se uma pergunta precisa de retrieval.
- Moderação e triagem. Pontue conteúdo por spam ou urgência antes que ele chegue a uma pessoa ou a um modelo mais caro, de modo que o caminho caro só rode no que realmente precisa dele.
- Guardrails. Depois da geração, confira a resposta contra restrições tipadas (ela contém um padrão de dado específico, ela cai numa categoria proibida) como um passo separado e barato, em vez de embutir a checagem no prompt de geração.
- Loops de controle em tempo real. Um game loop ou o controlador de um robô que precisa de uma decisão a cada frame não pode esperar geração. Um modelo de passo único cabe dentro desse loop. Um modelo token a token estruturalmente não cabe.
As coisas quebram quando você trata a resposta do modelo rápido como verdade absoluta. Mande respostas de baixa confiança para o caminho mais lento, e defina o limite a partir dos seus próprios dados rotulados, não de um número redondo que pareceu certo. Uma distribuição achatada com um rótulo em cima ainda é um chute.
Alternativas: saída estruturada e classificadores com fine-tuning
Times já resolviam esse problema antes de a categoria ter um nome, de duas formas principais.
Saída estruturada num LLM de propósito geral. As principais APIs de LLM conseguem restringir a geração a um schema JSON ou a um enum, o que te dá a mesma garantia de resposta tipada sem adotar um novo tipo de modelo. A decodificação ainda é autoregressiva, mas quando a resposta é um único valor de enum, a parte gerada é só um punhado de tokens. Boa parte da latência e do custo vai no processamento do prompt, e um modelo system one também precisa fazer isso. A TypeSafe posiciona o Jev como mais rápido e mais barato do que essa abordagem. Quanto disso se sustenta para as suas chamadas depende do tamanho do seu prompt e de quantas perguntas você faz por chamada, então é um número para medir, não para assumir. Saída estruturada também não exige infraestrutura nova se você já chama esse provedor.
Um classificador pequeno com fine-tuning. Para uma decisão estável, como esse escalonamento específico ou esse filtro de spam específico, um classificador treinado nos seus próprios dados rotulados costuma ser mais rápido e mais barato do que qualquer modelo de propósito geral, tipado ou não. O custo é que você precisa de dados rotulados e de uma rodada de retreinamento sempre que a tarefa muda. A vantagem de um modelo system one sobre ele é abrangência: um modelo só responde várias perguntas tipadas diferentes sobre tipos diferentes de estado, sem rodada de treinamento por decisão.
A escolha certa depende de quantas decisões distintas você tem e de quanto tráfego elas recebem. Se você tem uma decisão estável e de alto volume, use um classificador dedicado. Se você tem várias decisões relacionadas mas variadas ao longo de um pipeline, esse é o caso para o qual o formato system one foi pensado. Se você não está fazendo milhares dessas chamadas por minuto, comece com saída estruturada no modelo que você já usa.
Como encontrar as chamadas de LLM que deveriam ser decisões
Passe pelo que você já manda para um LLM de propósito geral e marque toda chamada cuja saída útil inteira poderia ser um valor de enum ou um número. Esses são seus candidatos. Mova duas delas para saída estruturada num modelo que você já usa, seja uma API hospedada ou um modelo local rodando com o Ollama, que aceita um schema JSON no parâmetro format. Meça latência e custo por chamada contra a versão atual.
Seja lá o que você trocar, continue mandando uma fração pequena do tráfego pelo caminho antigo também e compare as respostas. Se a saída estruturada já cabe no seu orçamento de latência e concorda com o caminho antigo, pare por aí. Avalie um modelo system one dedicado como o Jev só se ela não bater, e use essa amostra lado a lado para julgá-lo.