Modelos pequenos, alavanca grande

Quando um time me mostra um pipeline de IA, a primeira coisa que conto é quantas chamadas vão para um frontier model. Normalmente a resposta é todas. Classificação, extração, roteamento, reformatação, resumo de um parágrafo, tudo enviado para o maior e mais lento modelo disponível, porque foi isso que funcionou no protótipo. O protótipo tinha um usuário. Produção tem uma conta, um orçamento de latência e uma fila. O jeito mais rápido de resolver os três é perceber que a maioria dessas chamadas não precisa de frontier model nenhum.

Onde modelos pequenos ganham

Um modelo pequeno é bom em tarefas estreitas, bem especificadas e com saídas claras. Este ticket é sobre cobrança ou sobre login. Extraia o número do pedido deste e-mail. Este parágrafo menciona um efeito colateral. Reescreva isto no estilo da casa. Para tarefas assim, um modelo pequeno com um bom prompt ou um fine-tuning leve atinge a barra de qualidade, roda numa fração do tempo e custa uma fração por chamada. Nos pipelines que reestruturei, a maioria das chamadas em volume caía nessa categoria. O frontier model estava fazendo o equivalente a usar um data center para somar dois números.

Onde eles perdem

Modelos pequenos falham em tarefas que exigem conhecimento amplo de mundo, raciocínio longo em várias etapas, ou robustez a instruções bagunçadas. Seguem bem um prompt preciso e mal um prompt vago. São mais sensíveis a tamanho e formatação da entrada. E são piores em saber quando não sabem, o que importa quando uma resposta errada e confiante custa caro. Então o design não é "substituir o modelo grande". É "rotear por tarefa": o modelo pequeno cuida das etapas estreitas e de alto volume, e o frontier model cuida das abertas ou de alto risco, com um critério explícito para saber qual é qual.

Cascatas

O padrão que mais uso é a cascata. O modelo pequeno tenta primeiro. Se a saída passa na validação e a confiança, do jeito que você a mede, está acima de um limiar, pronto. Se não, a entrada vai para o frontier model. Para a maioria das distribuições de entradas reais, o modelo pequeno resolve a maioria e o frontier model só vê a cauda difícil. Custo e latência caem mais ou menos na proporção do que o modelo pequeno resolve, e a qualidade nos casos difíceis não muda porque eles continuam chegando ao modelo grande. O limiar é um parâmetro ajustável, e você ajusta com o conjunto de evals, não com intuição.

O conjunto de evals torna isso seguro

Nada disso é responsável sem um jeito de medir qualidade por tarefa. Antes de mover uma etapa para um modelo pequeno, rodo o conjunto de evals daquela etapa contra os dois e olho onde eles discordam. Às vezes o modelo pequeno está bem. Às vezes está bem em noventa por cento e catastrófico em uma categoria específica, e a cascata precisa de uma regra que mande essa categoria direto para o frontier. O conjunto de evals transforma uma migração assustadora em uma tarde lendo tabela.

Propriedade

Modelos pequenos também mudam quem controla o sistema. Um modelo que você consegue rodar por conta própria, em hardware que você escolhe, é uma dependência que dá para fixar, versionar e manter quando o provedor descontinua. Para pipelines que processam dados sensíveis, rodar as etapas estreitas localmente significa que esses dados nunca saem da sua infraestrutura nessas etapas, o que reduz a superfície de compliance. Só isso já justificou a engenharia em mais de um sistema que projetei. O modelo grande é uma ótima ferramenta. Usá-lo para tudo não é uma decisão, é a ausência de uma.