O que você pode realmente fazer com um modelo de linguagem pequeno (SLM)

A objeção mais comum (e por que ela está mal calibrada)

A crítica número um contra modelos de linguagem pequenos (SLMs, na sigla em inglês) é que “eles não sabem o suficiente”. É uma objeção mal calibrada. Na prática, nenhum modelo do mercado é um depósito confiável de fatos, e notas em benchmarks de capacidade não preveem a confiabilidade do conhecimento — as duas medidas não têm correlação.

Se capacidade não é o motivo para rodar um modelo no seu próprio hardware, então o motivo é outro. E há três candidatos: dados que não podem sair da empresa, volume que você já pagou e latência que é o próprio produto. Cada um pede um tipo específico de trabalho que um modelo pronto de 8 bilhões de parâmetros ou menos (o teto aproximado para hardware não especializado) já resolve bem hoje, sem fine-tuning.

Os três limites reais de um SLM

Antes de listar o que dá para fazer, vale registrar os limites:

• Contexto: material no meio de uma entrada longa é o que mais sofre — o problema do “lost in the middle” (perdido no meio). O início e o fim da janela de contexto tendem a sobreviver melhor.
• Precisão em casos difíceis: um SLM é um bom classificador de casos fáceis e um mau juiz dos difíceis.
• Falhas silenciosas: ao jogar um arquivo inteiro em vez de uma seleção, o modelo volta ao problema de contexto — e o erro é quieto.

Mas, mantendo esses limites em mente, dá para usar modelos pequenos locais em três grandes cenários operacionais.

Cenário 1 — Estruturação de documentos (o problema de conformidade)

Alguns dados simplesmente não podem transitar para terceiros: segredos operacionais, notas clínicas, arquivos de RH sob investigação ou documentos de clientes protegidos por privilégio ou regulação. Nesse caso, o argumento de capacidade deixa de importar — porque o modelo melhor (remoto) nem entra na conversa.

A tarefa que isso melhor sustenta é a estruturação de documentos: transformar uma pilha de texto não estruturado em registros que você pode consultar (tabela, planilha, linhas em banco). O que faz isso funcionar em hardware modesto é que a parte difícil saiu do modelo: a decodificação restrita por schema faz o trabalho estrutural. O que sobra para o modelo é a leitura — decidir qual trecho de texto pertence a qual campo — e leitura é algo em que modelos pequenos são genuinamente bons.

Cuidado com a complexidade do schema: um schema plano de uma dúzia de campos de texto é resolvido com facilidade, mas a conformidade degrada quando os schemas começam a aninhar. A resposta prática é manter schemas planos e rodar o documento duas vezes em vez de aninhar uma vez.

Cenário 2 — Rotulagem em massa (o problema de custo)

O custo por item de um modelo de fronteira é irrelevante quando você processa 40 documentos — e proibitivo quando processa 400 mil. A tarefa é rotulagem em lote: etiquetar uma fila de suporte por tópico, classificar um arquivo por tipo, rotear mensagens. A limitação real? O SLM ordena bem os casos fáceis e julga mal os difíceis.

O formato certo é em dois níveis: o modelo local assume a grande maioria da fila, e o que ele não tem certeza escala para um modelo maior (se permitido) ou para uma pessoa. Esse caminho de escalonamento não é uma concessão — é o design.

Cenário 3 — Latência (quando a velocidade é o produto)

Um modelo que responde em poucas centenas de milissegundos direto da memória local não é uma versão mais rápida de um modelo que responde em dois segundos pela rede. É outra categoria de ferramenta. A diferença aparece no que você está disposto a usar: tarefas individualmente triviais, invocadas dezenas de vezes por hora.

Repare no que não estamos pedindo ao modelo: saber algo. A entrada é curta, já está na sua frente, e você lê a saída no momento em que ela aparece — então erros aparecem imediatamente em vez de se propagar. As falhas virão quando você decidir jogar um arquivo inteiro em vez de uma seleção.

A regra de seleção

Os três cenários parecem não ter relação — um é problema de conformidade, outro de custo, outro de latência. O que compartilham é a característica que os faz funcionar: em cada caso, o conhecimento vive fora do modelo. O schema fornece a estrutura. O conjunto de rótulos fornece as opções. A tela fornece o texto. E cada um pode ser conferido contra a resposta.

Daí a regra prática que resume tudo: se a tarefa exige que o modelo forneça fatos dos próprios pesos, um modelo local pequeno é a ferramenta errada — o remoto grande é uma aposta melhor, ainda que não segura. Mas se a tarefa traz o próprio material, o modelo pequeno no seu hardware provavelmente resolve.