passei um tempo achando que escolher o modelo era uma decisão técnica, dessas que se resolvem olhando benchmark. Mudei de ideia observando os times que estão começando a colocar IA para dentro. O padrão que vejo é quase sempre o mesmo: para qualquer tarefa, pega o maior modelo disponível. Classificar um e-mail? Modelo de fronteira. Extrair um CNPJ de um PDF? Modelo de fronteira. Responder “sim” ou “não” a uma pergunta binária? Modelo de fronteira.

Funciona. E é aí que mora o problema, porque funcionar e ser a escolha certa são coisas diferentes. O maior modelo resolve quase tudo, então ninguém para para perguntar se precisava dele. A conta chega três meses depois, quando o volume sobe e a fatura de inferência começa a competir com a folha de um time pequeno.

A pergunta que quase ninguém faz na hora certa é simples: qual é o menor modelo que resolve esta tarefa dentro da qualidade que o negócio exige? Essa pergunta é de cabeça de negócio, não de tecnologia. E é ela que separa quem tem IA rodando de quem tem IA cara rodando.

§ 01 / DimensionamentoO que muda quando o modelo é pequeno.

SLM, sigla de small language model, é um modelo com ordens de magnitude menos parâmetros que um LLM de fronteira, treinado ou ajustado para fazer bem um conjunto estreito de coisas. Chamar de “LLM ruim” seria entender errado o que ele é. Ele perde em raciocínio aberto, em tarefas que exigem conhecimento amplo de mundo, em conversas longas e ambíguas. E ganha, com folga, em quatro frentes que costumam decidir um projeto:

  • Custo. Inferência de um modelo pequeno custa uma fração do modelo grande. Quando a tarefa roda milhares ou milhões de vezes por dia, seja triagem, classificação ou extração, essa diferença deixa de ser detalhe e vira a viabilidade do projeto.
  • Latência. Modelo menor responde mais rápido. Num fluxo síncrono, como um atendimento que o cliente está esperando ou uma etapa dentro de um pipeline que precisa fechar em milissegundos, a latência do modelo grande vira uma restrição de produto, e nenhuma engenharia contorna isso.
  • Privacidade e on-prem. Modelo pequeno cabe em hardware que você controla. Para quem tem dado que não pode sair de casa, como saúde, financeiro e jurídico, rodar on-prem ou em nuvem privada deixa de ser preferência e passa a ser requisito. Modelo de fronteira via API, nesses casos, simplesmente não está em jogo.
  • Tarefa específica e edge. Se o trabalho é estreito e bem definido, um modelo pequeno ajustado para ele costuma bater o modelo grande genérico. Sai mais barato e, com frequência, mais preciso, porque não carrega a ambiguidade de tentar servir a todos. E cabe onde o grande não cabe: no dispositivo, na borda, offline.

§ 02 / PadrõesOs padrões que fazem isso render.

Escolher entre grande e pequeno é falso dilema. Os sistemas que aguentam a operação real combinam os dois. Três padrões resolvem a maioria dos casos.

Routing (ou cascata). O modelo pequeno atende primeiro. Ele resolve o caso fácil, que costuma ser a maioria do volume, e escala para o modelo grande só quando a tarefa exige. A régua de escalonamento pode ser a confiança do próprio modelo pequeno, a complexidade da entrada, ou um classificador barato na frente de tudo. Na prática, você paga preço de modelo grande só na fração dos casos que realmente precisam dele. É o padrão de maior ROI e o primeiro a considerar.

Distillation. Você usa o modelo grande como professor para gerar exemplos de alta qualidade e treina um modelo pequeno para reproduzir aquele comportamento naquela tarefa. O resultado é um modelo enxuto que herda parte da competência do grande no recorte que interessa. Dá trabalho e exige dado, mas paga quando o volume é alto e a tarefa é estável.

Fine-tuning de SLM. Para uma tarefa estreita e recorrente, como o seu jeito de classificar tickets, o seu formato de extração ou o seu tom de resposta, ajustar um modelo pequeno com os seus próprios exemplos entrega consistência que prompt nenhum no modelo grande garante. Você troca flexibilidade por previsibilidade. Em produção, previsibilidade quase sempre vale mais.

Esses padrões se compõem. Um sistema maduro costuma ter um SLM ajustado na frente, routing para o modelo grande nos casos difíceis, e RAG trazendo o contexto próprio da empresa para dentro do prompt em qualquer um dos dois. A lógica aqui é dimensionar cada parte ao trabalho que ela faz.

§ 03 / Quando não economizarQuando o modelo grande ainda é a resposta.

Reduzir modelo por reflexo é o mesmo erro invertido. O modelo grande continua sendo a escolha certa, e economizar nele sai caro, quando a tarefa é:

  • Raciocínio aberto e de múltiplos passos, onde o caminho não é conhecido de antemão.
  • Conhecimento amplo de mundo, sem base própria para ancorar via RAG.
  • Baixo volume e alto valor por chamada. Uma análise que roda dez vezes por dia e embasa uma decisão cara. Aqui o custo de inferência é irrelevante diante do custo de errar.
  • Protótipo e descoberta. No início, antes de saber o formato da tarefa, use o modelo grande para aprender o problema. Otimizar para modelo pequeno antes de entender o trabalho é otimização prematura, porque você ajusta um modelo para uma tarefa que ainda vai mudar.

A regra: comece grande para entender, mude para pequeno para operar.

§ 04 / Anti-padrõesOs anti-padrões.

Três erros aparecem sempre, e os três custam dinheiro:

  1. Modelo grande em tarefa binária de alto volume. Usar um modelo de fronteira para dizer “spam / não spam” um milhão de vezes por dia é queimar orçamento por preguiça de medir.
  2. Fine-tuning antes de esgotar o prompt. Ajustar um modelo dá trabalho, cria dependência e envelhece. Boa parte do que o time quer resolver com fine-tuning se resolve com prompt melhor, poucos exemplos (few-shot) e RAG. Fine-tuning é a última alavanca, não a primeira.
  3. Otimizar custo sem medir qualidade. Trocar o modelo grande pelo pequeno e não medir se a qualidade caiu é como cortar custo demitindo sem olhar o que a pessoa fazia. Economia que degrada o resultado é dívida contraída sem que ninguém perceba.

§ 05 / DecisãoComo decidir.

A decisão de qual modelo usar é uma decisão de negócio disfarçada de decisão técnica. Ela se resume a cruzar três eixos: volume (quantas vezes a tarefa roda), valor por chamada (quanto custa errar uma vez) e restrição (latência, privacidade, hardware). Volume alto e valor baixo por chamada empurram para o modelo pequeno. Volume baixo e valor alto por chamada justificam o grande. Restrição dura de privacidade ou latência decide sozinha.

Antes de escolher o modelo de qualquer nova tarefa, passe por este checklist:

  • Qual é a tarefa, exatamente? Estreita e repetitiva favorece modelo pequeno; aberta e variável favorece grande.
  • Qual o volume por dia? Alto volume transforma diferença de custo por chamada em diferença de viabilidade.
  • Quanto custa errar uma vez? Erro caro justifica pagar mais por chamada.
  • Tem restrição de latência? Fluxo síncrono com usuário esperando pesa contra o modelo grande.
  • O dado pode sair de casa? Se não, o modelo pequeno on-prem é o único caminho, e a discussão acaba aqui.
  • Já tenho baseline de qualidade medido? Sem baseline, qualquer troca de modelo é aposta, não decisão.
  • Dá para começar com routing? Modelo pequeno na frente, grande no que sobra, quase sempre é o melhor primeiro passo.
  • Estou no estágio de entender ou de operar? Entender pede grande. Operar em escala pede o menor que resolve.
Padrão Noûs
A gente dimensiona o modelo à tarefa, não ao hype. Antes de escolher, mede volume, valor por chamada e restrição. Começa grande para entender o problema e migra para o menor modelo que sustenta a qualidade exigida, com routing na frente e o grande só onde ele é insubstituível.

O maior modelo é uma ferramenta excelente e cara. Tratar toda tarefa como se merecesse a ferramenta mais cara é o que acontece quando ninguém parou para decidir. Dimensionar o modelo ao trabalho é o que faz a IA caber na conta e sobreviver ao dia a dia. É engenharia com cabeça de negócio, que é onde a coisa toda deveria começar.

fim  ·  nota de campo nº 46  ·  noûs / ago 26