Como treinar um modelo pequeno para obedecer à sua regra sem viver de prompt

A frase que mais importa nesta discussão é simples: nem toda regra merece ser resolvida com improviso.

Em muitos produtos, a empresa pede ao modelo grande que faça papel de especialista, fiscal, atendente e juiz ao mesmo tempo. Funciona por um tempo. Depois começa o problema conhecido de toda operação em IA: um dia o sistema entende a regra; no outro, repete uma resposta ruim com boa aparência. O erro não é barulhento. É repetível.

O artigo que inspirou esta matéria, publicado por Nir Diamant no DiamantAI, parte exatamente dessa frustração. Em vez de continuar remendando tudo com prompt, ele descreve uma saída mais séria: treinar um modelo pequeno, dedicado a uma tarefa específica, com dados gerados e verificados com cuidado. A ideia pode parecer técnica demais à primeira vista, mas a lógica é muito comum no mundo real.

Se um sistema sempre precisa checar a mesma política, detectar o mesmo tipo de abuso, reconhecer a mesma fronteira ou aplicar a mesma regra de atendimento, então a pergunta deixa de ser "como escrever um prompt melhor?" e passa a ser "não seria mais inteligente ensinar essa regra de forma direta?"

O princípio por trás da ideia

A lógica é a mesma de quase toda boa engenharia: quando a tarefa é estreita, o instrumento pode ser estreito também.

Um modelo geral é bom para conversar, resumir, comparar, explicar e improvisar. Mas ele não nasce para carregar, sozinho, a nuance de uma política interna de produto, uma regra específica de atendimento ou uma exceção que só existe dentro da operação. Quanto mais particular for a regra, maior a chance de um sistema genérico tropeçar em detalhes que importam.

Por isso o ganho de um modelo pequeno não é vaidade técnica. É controle. Ele responde com menos variação, custa menos para rodar e pode ser testado com métricas próprias. Para quem opera produto, isso vale ouro. Prompt é ótimo para explorar. Treino dedicado é melhor para estabilizar.

O erro que mais engana

O atalho mais comum é pedir para a IA gerar exemplos e achar que isso resolve o problema.

Resolve só pela metade.

Se os exemplos forem todos muito parecidos, o modelo aprende o caso fácil e ignora o resto. Ele fica bom no centro da pista e inseguro nas bordas. É aí que mora o problema real, porque o usuário não faz sempre a pergunta perfeita. Ele usa gírias, omite contexto, escreve mal, mistura assuntos e testa a regra justamente onde ela fica mais frágil.

O segundo erro é pior: o próprio sistema que gera os exemplos também os rotula. Quando isso acontece sem revisão, o modelo passa a aprender a confusão original. Em vez de corrigir o erro, o treino o consolida.

Esse é o ponto em que muita equipe acha que está acelerando, mas na prática só está multiplicando incerteza.

Um manual simples para aplicar

Não existe mágica aqui. Existe processo.

1. Escreva a regra em português claro. Antes de treinar qualquer coisa, a equipe precisa saber exatamente o que quer detectar, permitir ou bloquear. Se a regra não cabe numa frase humana, ela ainda está mal definida.

2. Liste as variações da regra. Pense nos casos óbvios e nos casos estranhos. Não basta dizer "isso é proibido". É preciso separar intenção, contexto, tom, exceção e ambiguidade.

3. Gere exemplos perto da fronteira. O valor não está no caso mais fácil. Está no caso em que uma pessoa razoável hesitaria. É ali que o modelo precisa aprender.

4. Desconfie do primeiro rótulo. Cada exemplo precisa ser revisado. Se a etiqueta estiver errada, o treino vai ensinar a coisa errada com muita convicção.

5. Teste contra casos difíceis. Não avalie só com exemplos limpos. Coloque frases truncadas, mensagens ambíguas, linguagem informal e situações limítrofes.

6. Ajuste, rode de novo e só então publique. O treino não termina quando o modelo passa no teste inicial. Termina quando ele continua estável no uso real.

O que o artigo original chama de debate assimétrico é, na linguagem de redação, uma revisão severa: alguém defende a decisão, outro alguém tenta derrubá-la e o sistema só aceita o resultado quando a dúvida cai. A Plurai usa essa lógica no BARRED, um método para transformar uma regra escrita em linguagem comum em um verificador treinado para aquela regra.

O que essa disciplina resolve

Esse caminho faz sentido porque ataca três dores ao mesmo tempo.

A primeira é consistência. Um modelo treinado para uma tarefa específica tende a responder do mesmo jeito em situações parecidas. Isso reduz surpresa operacional.

A segunda é custo. Se toda chamada depende de um modelo gigante, o sistema fica caro e lento. Um modelo menor, ajustado para uma função estreita, costuma ser mais barato e mais rápido.

A terceira é controle operacional. Quando a regra vira um objeto treinado e testado, fica mais fácil auditar, melhorar e corrigir. A equipe deixa de depender de boa vontade do prompt da vez.

É por isso que a discussão não é apenas sobre IA. É sobre maturidade de produto. Quem quer operar em escala precisa parar de tratar regra importante como texto de apoio.

Onde isso faz mais sentido

O uso mais natural está em tarefas repetitivas e sensíveis:

• checagem de política interna;
• moderação com regra específica;
• triagem de atendimento;
• validação de respostas de agentes;
• classificação de risco;
• checagem de regra contratual ou interna;
• detecção de repetição, abuso ou desvio de comportamento.

Em todos esses casos, a pergunta certa não é se o modelo é bonito. É se ele sabe dizer sempre a mesma coisa quando a situação se repete.

Onde não vale forçar

Nem tudo merece treino dedicado.

Se a tarefa é aberta, criativa, instável ou muda todo dia, o retorno pode ser fraco. Também não adianta tentar treinar uma regra que ninguém consegue explicar com clareza. A pressa em automatizar um entendimento mal definido só produz um sistema mais rápido para cometer o mesmo erro.

Há um limite que precisa ser respeitado: o modelo pequeno não substitui critério humano mal escrito. Ele só o executa melhor.

A lição maior

A tese por trás dessa matéria é a mesma que aparece em outros textos do Mirante sobre Software 2.0 e engenharia agêntica: o trabalho sério com IA não é deixar o modelo pensar sozinho. É decidir com precisão o que ele deve aprender, como ele deve ser testado e em que ponto ele pode errar.

Quem insiste em resolver tudo com prompt está montando uma operação dependente de improviso.

Quem treina uma regra pequena, mede de verdade e corrige os casos de borda está construindo um sistema.

No fim, a escolha é essa: remendar com texto ou transformar a regra em comportamento estável.

O futuro prático da IA, na maior parte dos produtos, vai ficar mais perto da segunda opção.

---

Igor Morais Vasconcelos é advogado, doutorando no IDP e fundador da INTEIA. Pesquisa agentes sintéticos, simulação social e inteligência artificial aplicada a sistemas institucionais.