Roteie o modelo barato primeiro

Um founder faz uma pergunta a um agent. O agent tem que decidir uma coisa antes de fazer qualquer outra: isso é um pedido para fazer algo, ou um pedido para saber algo? É um sim/não. E em muitos sistemas, esse sim/não é decidido pelo modelo mais caro do menu, aquele que você gostaria que escrevesse seu contrato, raciocinasse sobre seus livros, sustentasse um argumento difícil na cabeça. Ele acabou de responder a um cara-ou-coroa. Aí responde o próximo. E o seguinte.

A maior parte do que um agent faz o dia inteiro são caras-ou-coroas vestidos com a fantasia de problemas difíceis.

A ideia central deste post é simples: custo é uma decisão de roteamento que você toma por passo, não uma configuração que você escolhe por app. Escolha um modelo pequeno para triar, guarde o grande para os passos que de fato precisam de um grande, e deixe a maioria dos passos nunca chegar a ele. Essa frase é a arquitetura inteira. O resto deste post a desmonta, passo a passo.

O jeito ingênuo: um modelo, todo passo, toda vez

Aqui está como quase todo mundo começa, e é um lugar completamente razoável para começar. Você escolhe um modelo, geralmente o melhor que pode pagar, e aponta cada passo do agent para ele. Classificação: melhor modelo. Seleção de ferramenta: melhor modelo. Escrever a resposta: melhor modelo. Decidir se a resposta foi boa o suficiente: o melhor modelo de novo, avaliando a primeira.

Funciona. O demo é limpo. Toda resposta é afiada porque a coisa mais inteligente do prédio a tocou. Então você lança.

Aí a fatura chega, e é estranha. Você olha para onde o dinheiro foi, e ele não foi onde você esperaria. Não foi tudo para o raciocínio difícil. Uma fatia enorme foi para um modelo brilhante em direito, medicina e planejamento de múltiplos passos, gastando seu talento na pergunta “o usuário me pediu para fazer algo, sim ou não?” Você pagou tarifa de gênio por uma catraca.

A dor não é só dinheiro. É latência. O modelo grande é mais lento, e agora seu agent está lento em todo passo, incluindo os dez triviais que faz antes de chegar ao que é de fato difícil. O usuário espera o mesmo intervalo longo por “deixa eu verificar” e pela resposta. Você tornou as partes baratas caras e as partes rápidas lentas, e fez isso uniformemente, porque o modelo era uma propriedade do app em vez de uma propriedade do passo.

Essa é a armadilha: você escolheu uma altitude de inteligência e a aplicou a um problema que tem muitas altitudes.

A reformulação: um passo tem uma dificuldade, e dificuldade é barata de detectar

Acompanhe o que um agent de fato faz num único turno. Não é um ato único de pensar. É uma pequena linha de montagem, e as estações têm dificuldades muito diferentes.

Primeiro ele tem que entender o pedido, classificá-lo numa categoria. Pergunta ou comando? Sobre dinheiro, pessoas ou o calendário? Isso é reconhecimento de padrão. Um modelo pequeno e rápido faz isso quase tão bem quanto um grande, porque o espaço de respostas é minúsculo e o sinal está ali, nas palavras.

Depois, se for um comando, ele tem que planejar, escolher a ferramenta, preencher os argumentos, sequenciar os passos. Às vezes trivial (“registre esta despesa”), às vezes genuinamente difícil (“feche os livros, mas só depois de reconciliar os dois ledgers que divergem”). A dificuldade aqui é variável, e essa variabilidade é o ponto todo.

Então ele age, chama a ferramenta, recebe um resultado. O modelo mal pensa aqui; a ferramenta faz o trabalho.

Então alguém tem que julgar se o resultado é de fato bom, fundamentado, completo, não alucinado, seguro de mostrar. Esta é a estação onde você quer a mente cuidadosa. Julgar é mais difícil do que fazer, do mesmo jeito que revisar uma prova é mais difícil do que segui-la.

O jeito ingênuo roda as quatro estações no mesmo modelo. Mas olhe para elas. A primeira é trivial. As duas do meio são variáveis. A última é onde a inteligência real ganha o sustento. Cada estação tem uma dificuldade, e a dificuldade de um passo é muito mais barata de detectar do que o passo é de resolver. Um modelo pequeno quase sempre consegue te dizer “esse é fácil” ou “esse precisa do cérebro grande” sem ser o cérebro grande em si.

Então você para de perguntar “qual modelo roda o agent?” e começa a perguntar “qual modelo roda este passo?”, e deixa um triador pequeno e rápido decidir.

A cascata: o pequeno tria, o grande julga, a maioria dos passos nunca escala

Aqui está a forma que substitui “um modelo em todo lugar”. É uma ideia antiga emprestada de um lugar que não tem nada a ver com modelos de linguagem, e vale dizer de onde vem, porque a linhagem é o argumento.

Um filtro de spam não roda um modelo pesado em todo email. Ele roda um teste barato primeiro, algumas palavras-chave, uma reputação de remetente, um classificador rápido. A esmagadora maioria das mensagens é decidida ali mesmo, em microssegundos, por quase nada. Só as mensagens genuinamente ambíguas, aquelas que o teste barato não consegue julgar com confiança, são escaladas para a análise cara. O estágio barato não precisa estar certo sobre os casos difíceis. Ele só precisa estar certo sobre quais casos são difíceis.

Isso é uma cascata. E é exatamente a estrutura que um agent quer.

Numa cascata, o modelo pequeno vai primeiro em todo passo. Ele faz a triagem, o roteamento, o entendimento fácil, a escolha óbvia de ferramenta. Quando está confiante, e em trabalho rotineiro está confiante na maior parte do tempo, o passo está pronto, rápido e barato, e nada mais roda. Quando não está confiante, ou quando o passo é um que marcamos como de alto risco por sua própria natureza, ele escala: passe esse para cima, ao modelo grande. O modelo grande não é o padrão. É a exceção que você busca, de propósito, quando o estágio barato levantou a mão e disse não tenho certeza, e estar incerto aqui é caro.

O sistema ingênuo paga o preço do modelo grande em todo passo. A cascata paga só nos passos que escalam, e num dia normal de trabalho, a maioria dos passos não escala.

Tem uma objeção afiada aqui, e é a certa de levantar: isso não vai simplesmente ficar mais burro? Você está deixando um modelo pequeno tomar decisões. Não, e a razão é a segunda metade da cascata. O modelo pequeno nunca tem a palavra final em nada que importa. O modelo grande ainda julga. O estágio barato decide as coisas fáceis e tria as difíceis; o estágio caro decide as coisas difíceis e verifica as consequentes. Você não substituiu o modelo inteligente. Você parou de desperdiçá-lo em catracas, para que ele tenha orçamento sobrando para o tribunal.

O trabalho do modelo barato não é estar certo sobre os casos difíceis. É estar certo sobre quais casos são difíceis.

Onde quebra, e a regra que conserta

A versão honesta disso inclui o lugar onde dá errado, porque uma cascata tem um modo de falha e fingir que não tem é como você a lança mal.

A falha é um modelo pequeno confiante que está confiantemente errado. Ele olha um passo, decide que é fácil, lida com ele sozinho, e nunca escala, exceto que o passo não era fácil, ele só parecia fácil. Um pedido sutil mal lido como um simples. Uma ação de alto risco que casou por padrão com um template de baixo risco. A economia inteira da cascata depende de o estágio barato conhecer seus limites, e um modelo barato que não conhece seus limites vai rotear um caso de tribunal para a catraca.

Então a cascata precisa de uma regra, e é a regra que torna a coisa toda segura de rodar: escalação não é só sobre confiança, é sobre consequência. Alguns passos vão para o modelo grande não importa o quão confiante o pequeno se sinta, porque o custo de errar é alto demais para apostar na autoavaliação de um estágio barato. Qualquer coisa que gaste dinheiro. Qualquer coisa que toque um cliente. Qualquer coisa irreversível. Essas não são roteadas por confiança; são roteadas por categoria, direto para a mente cuidadosa e através do julgador, toda vez.

Isso te dá dois gatilhos de escalação, e você quer ambos. O primeiro é o modelo barato está inseguro, escale o ambíguo. O segundo é o passo é consequente, escale o perigoso, mesmo quando o modelo barato estava seguro. Confiança lida com o difícil-mas-inofensivo. Consequência lida com o que-parece-fácil-mas-é-caro. Juntos eles fecham a brecha onde a falsa confiança de um modelo rápido vazaria uma decisão ruim para o mundo.

Tem uma segunda falha, mais silenciosa, que vale nomear: a tentação de tornar o roteador inteligente. Se seu triador precisa de um modelo grande para decidir para onde rotear, você reinventou o problema um nível acima, agora você está pagando tarifa de gênio para decidir se paga tarifa de gênio. O roteador tem que continuar barato. Seu trabalho é a meta-pergunta fácil “isso é fácil?”, e essa pergunta é, quase sempre, ela mesma fácil. Quando não é, a jogada segura é escalar, uma cascata que erra para o lado do modelo grande na dúvida ainda é muito mais barata do que uma que roda o modelo grande em tudo, e ela nunca fica mais burra, só ligeiramente menos econômica.

Por que “por passo” é a palavra que sustenta tudo

Seria fácil ler tudo isso como “use um modelo mais barato”. Não é essa a lição, e lê-la assim joga fora a ideia de verdade.

“Use um modelo mais barato” é uma decisão por-app, você escolhe um modelo, um menor, e agora você está mais barato e mais burro em todo lugar, inclusive nos passos que precisavam do inteligente. É o mesmo erro do jeito ingênuo, só apontado na outra direção. Você trocou um sobrepreço uniforme por uma subperformance uniforme. Uniforme nunca foi a resposta certa, em nenhuma direção.

A jogada toda é que custo deixa de ser uma propriedade do app e se torna uma propriedade do passo. O mesmo agent, no mesmo turno, pode rodar um modelo minúsculo para entender o pedido, um modelo médio para planejar a ação, nenhum modelo para chamar a ferramenta, e o maior modelo que você tem para julgar se a saída é segura de mostrar. Um turno, quatro altitudes de inteligência, cada uma casada com o que sua estação de fato exige. A fatura acompanha a dificuldade em vez do volume. E o usuário sente isso como velocidade: as partes fáceis retornam instantaneamente porque nada pesado rodou, e as partes difíceis valem a espera porque algo pesado deveria ter rodado.

Digamos que um turno típico toque uma dúzia de chamadas de modelo. Se onze delas são fáceis e uma é difícil, e em trabalho real a proporção é desequilibrada assim com muito mais frequência do que não, então rotear por passo significa que você paga a tarifa alta uma vez em vez de doze, e a paga na chamada que a mereceu. A economia não é um desconto. É a diferença entre gastar com pensar e gastar com catracas.

É também por isso que você não consegue acoplar isso no final. Roteamento por passo é uma decisão que o sistema toma, não o modelo, o que significa que o sistema tem que ser construído para tomá-la. Algo tem que ficar acima dos modelos, olhar cada passo, conhecer sua dificuldade e sua consequência, e escolher. Esse “algo” é a parte que falta na maioria das stacks de agents, porque elas foram construídas como um modelo com um prompt, e um modelo com um prompt não tem onde colocar uma decisão de roteamento.

A virada: economia é gosto, não mesquinhez

Tire os modelos e as cascatas e o que sobra é um hábito antigo de qualquer um que já tocou uma operação de verdade: você não coloca seu recurso mais caro no seu problema mais barato.

Você não manda o sócio sênior tirar xerox. Você não acorda o engenheiro de plantão por um erro de digitação. Você não pede à pessoa cujo julgamento você mais confia para passar a manhã ordenando quais emails são spam, não porque o julgamento dela seja desperdiçado nisso, mas porque cada minuto que ela gasta na catraca é um minuto que não gasta no caso que de fato precisa dela. Boas operações sempre rotearam trabalho para a altitude certa. Não é mesquinhez. É respeito por onde a coisa escassa deveria ir.

É isso que rotear o modelo barato primeiro de fato é. É a mesma disciplina, aplicada a uma força de trabalho feita de modelos em vez de pessoas. O modelo pequeno não é um rebaixamento que você tolera para economizar dinheiro. É a ferramenta certa para os onze passos que são genuinamente fáceis, e a razão pela qual o modelo grande tem o orçamento, a velocidade e a atenção sobrando para ser brilhante no único passo que é genuinamente difícil.

Os agents vão continuar ficando mais inteligentes e os preços vão continuar se movendo, e nada disso muda a forma. Sempre vai haver problemas baratos e caros no mesmo fôlego, e o sistema que vence é o que sabe a diferença antes de gastar, que encontra cada passo na sua própria altitude em vez de cobrar tarifa cheia pela stack inteira.

---

Isso é parte do que estamos construindo na Apollo Space, não um chatbot mais inteligente, mas um sistema operacional que decide, passo a passo, quanta inteligência um momento vale, e gasta de acordo. Da próxima vez que um agent responder a um sim/não para você, a pergunta interessante não é o quão inteligente foi a resposta. É o quão pouco deveria ter custado para sabê-la.