Fine-tuning vs harness: quando o retreino vale a pena (e quando não)
O reflexo de jogar fine-tuning em toda tarefa que o modelo erra é compreensível, mas raramente é a melhor saída. A maioria do que parece exigir retreino (regras de negócio, consulta a dados proprietários, formato de saída) cabe no harness: contexto via RAG, guardrails de domínio e orquestração de ferramentas. Parte do motivo é matemática: o prompt age como uma atualização de pesos em tempo de execução, um fast weight de baixo rank, estruturalmente idêntico a um LoRA, só que sem retreino. No caso de uma empresa B2B com 5 mil peças, regras de desconto e prazos de entrega, 90% do comportamento do agente se resolve nessa camada. A fatia que sobra (tom de voz formal e jargão proprietário) é real, mas estreita, e ainda pode encolher antes do treino. Este post traz quatro perguntas para decidir antes de retreinar, e mostra que a abordagem híbrida entrega mais consistência com menos custo, sem te tirar do controle da sua própria infraestrutura.
Toda vez que o agente erra uma pergunta, o primeiro instinto é jogar fine-tuning nele. Retreinar os pesos, ensinar de novo, de forma mais profunda. A intuição é compreensível, mas, na prática, é o caminho mais caro e muitas vezes o menos eficaz.
A gente já viu nos posts anteriores que o harness é o que transforma um protótipo frágil em sistema de produção: são as seis funções em volta do modelo (grounding, guardrails, memória, observabilidade, resiliência e orquestração) que decidem o que ele vê, o que ele pode fazer e como ele se comporta. O modelo, sozinho, só faz uma coisa: gerar a próxima palavra. Todo o resto é harness. A pergunta agora é outra: quando o harness não basta? Onde mora o território do fine-tuning, e como saber se você está nele antes de gastar uma semana de GPU?
Por que o reflexo de retreinar é compreensível, mas quase sempre errado
Uma empresa de componentes industriais (B2B Co.) quer um agente de atendimento que conheça o catálogo de 5 mil peças, as regras de desconto por volume, os prazos de entrega por região e o tom de voz formal. O time testa um modelo médio com um prompt simples, e ele tropeça: erra o desconto de um lote de 200 unidades, cita o prazo de uma região errada e responde num tom coloquial que não combina com o cliente corporativo. O reflexo é imediato: precisamos fine-tunar o modelo no catálogo, nas regras e nos exemplos de atendimento.
Esse reflexo é compreensível. O fine-tuning promete o que o prompting parece não conseguir: uma correção profunda, gravada nos pesos, que não depende de o contexto ser bem montado a cada chamada. Para alguns problemas, ele é mesmo a ferramenta certa. Mas, na pressa de corrigir, o time pula o diagnóstico: o modelo não sabe o desconto porque o conhecimento nunca esteve nos pesos; errou o prazo porque não recebeu a tabela certa no contexto; e o tom coloquial é problema de instrução, não de conhecimento. Três causas diferentes, três soluções diferentes, e só uma delas mora nos pesos.
O preço real do fine-tuning, e o que o harness resolve sem ele
O custo mais óbvio do fine-tuning é financeiro: GPU, gente para montar e limpar dados, rodadas de validação. Mas esse não é o problema principal. O custo decisivo é o tempo de iteração. A cada ajuste de regra (um novo desconto, uma nova região, uma nova categoria), você refaz o ciclo de dados, treino e validação. Uma regra nova no harness é testada em minutos; uma regra nova nos pesos leva horas ou dias. A diferença não é de grau, é de natureza: o harness muda comportamento na velocidade de um deploy, o fine-tuning na velocidade de um experimento.
O dinheiro gasto em GPU não é o verdadeiro gargalo. O gargalo é o ciclo de iteração.
Há um segundo custo, mais sutil. Fine-tuning introduz risco de esquecimento catastrófico: ao aprender dados novos, o modelo degrada o desempenho em tarefas antigas, como se o conhecimento anterior fosse sobrescrito. Por isso quem usa fine-tuning a sério raramente o usa sozinho: combina com um harness que ancora o que muda, porque cada abordagem cobre o que a outra perde.
E há o custo que ninguém calcula antes de começar: o de ignorar o harness. No caso da B2B Co., as regras de desconto e os prazos são fatos que o modelo nunca viu, não estão nos pesos dele. Fine-tunar para ensinar esses fatos é gravar informação que muda (preços, prazos, regiões) em pesos que não mudam sem outro treino. É um descasamento estrutural: dados voláteis em parâmetros estáticos.
Fine-tuning é bom para ensinar comportamento que não muda: um estilo de saída, uma voz de marca, um formato de tool-calling. É péssimo para ensinar fatos que mudam.
O que o harness já resolve sozinho
Volte ao caso da B2B Co. As regras de desconto, os prazos por região, o catálogo: tudo isso são fatos que vivem num banco, não nos pesos do modelo. A função de grounding do harness é montar, a cada pergunta, o contexto certo: um RAG que recupera as peças relevantes, os descontos aplicáveis e o prazo da região do cliente, e injeta esses trechos no prompt. O modelo nunca precisa decorar os 5 mil itens; precisa receber o trecho certo e responder com base nele. (No nosso caso, esse RAG navega um knowledge graph em vez de só buscar trechos parecidos, o que deixa as relações do catálogo explícitas, mas o princípio vale para qualquer grounding bem feito.)
Por que isso funciona tão bem? Quando o contexto é montado com as instruções certas, o prompt não é só texto informativo: ele age como uma atualização de pesos em tempo de execução. Na self-attention, a saída para uma query é uma soma ponderada dos values do contexto; reagrupando essa soma, ela vira uma matriz que multiplica a query e desloca as ativações em baixo rank, estruturalmente idêntica a um LoRA, só que sem nenhum passo de gradiente. Ou seja, o harness não apenas informa o modelo, ele instala um delta de baixo rank nos pesos efetivos. Um modelo bem aterrado se comporta como se tivesse sido adaptado porque, matematicamente, ele foi.
O grounding resolve o conhecimento; a orquestração e os guardrails resolvem o resto. Para perguntas de logística, o harness obriga o modelo a chamar a API de prazos real em vez de adivinhar, e uma regra fixa garante que o prazo sempre venha da API, nunca da memória do modelo. A mesma lógica ensina o agente a recusar o que está fora do escopo (não atendemos peças automotivas) em vez de inventar. O erro de prazo some, o agente para de alucinar, e o fine-tuning não precisou entrar na jogada.
No fim, as regras de desconto e os prazos se resolvem inteiros no harness. O tom coloquial também, em boa parte: uma instrução clara de tom formal, com exemplos few-shot, empurra a consistência bem para cima. Mas chega num platô. E o que sobra depois desse platô é o estilo muito particular de linguagem que o prompt sozinho não captura.
Quando o fine-tuning é mesmo a resposta certa
O fine-tuning não é um erro; é a ferramenta certa para o que o harness não alcança: comportamentos que dependem de uma sensibilidade distribucional que o prompt não induz. Na B2B Co., o tom formal exigido não é só evitar gíria. É um jargão técnico do setor, com termos próprios, abreviações consagradas e um estilo de frase que passou anos sendo lapidado no manual da empresa. O prompt imita esse estilo com exemplos, mas a consistência que o cliente cobra (praticamente toda resposta no mesmo tom, sem deslize) fica além do que o contexto garante.
Antes de qualquer LoRA, o harness ainda tem uma carta nesse tom: quando a camada de prompt é escrita por um modelo de fronteira, a competência do professor migra para o aluno pelo próprio contexto, sem retreino. É a destilação online, e ela empurra o platô mais para cima, estreitando a fatia que sobra. Só quando nem esse prompt refinado fecha a conta é que o treino se justifica.
A intuição que importa é de escala. Poucos pontos percentuais de consistência parecem pouco no papel, mas num agente que processa dezenas de milhares de chamadas por dia, cada ponto vira centenas de respostas fora do tom todo dia. É esse erro residual, multiplicado pelo volume, que paga o custo do treino. O fine-tuning não compra um salto de qualidade; compra os últimos pontos de consistência que o contexto não garante.
O outro território legítimo são os esquemas de tool-calling muito rígidos, com formato de saída fixo. Se o prompt acerta o JSON quase sempre, mas não sempre, cada falha quebra o pipeline (uma vírgula a mais, um campo fora de lugar, e a chamada falha). Aqui um LoRA de rank baixo (a técnica que escreve a atualização de pesos como o produto de duas matrizes pequenas, em vez da matriz inteira, o que barateia muito o treino) empurra a acurácia de formato para perto de zero erro. Mas repare: ele não está ensinando o prazo, que continua vindo da API, está ensinando a forma de chamar a API. É comportamento, não conhecimento.
Quatro perguntas antes de retreinar
Antes de qualquer fine-tuning, responda a quatro perguntas. Elas formam um funil que separa o que o harness resolve do que pede pesos de verdade.
1. O comportamento cabe em instruções ou exemplos? Se o que você quer é que o modelo siga uma regra (aplique o desconto X, consulte a API Y, fale no tom Z), a resposta é quase sempre sim. Instruções claras e alguns exemplos few-shot bastam. Essa pergunta sozinha filtra 90% dos reflexos de retreinar.
2. O conhecimento muda com frequência? Se a informação que o modelo precisa (preços, prazos, disponibilidade) muda em semanas ou dias, fine-tuning é o pior dos mundos: cada mudança exige novo treino, enquanto o harness incorpora a próxima na busca seguinte. É o que evita gravar dados voláteis em parâmetros estáticos.
3. O custo de iterar é maior que o custo do treino? Se a regra muda todo mês e cada ciclo de treino custa dois dias, o custo de iteração explode. O harness itera em minutos. Só vale fine-tunar se o comportamento é estável e o volume de chamadas compensa a economia por chamada.
4. Mesmo com o melhor prompt possível, a consistência ainda falta? Essa é a pergunta final. Se o prompt, testado à exaustão, ainda deixa passar deslizes acima do que o cliente tolera, o fine-tuning é a ferramenta certa. O harness vai até um platô; o treino empurra esse platô para cima. O segredo é saber onde está o platô antes de gastar com GPU: só a fatia que sobra depois dele é trabalho legítimo de fine-tuning.
Na B2B Co., as quatro perguntas convergem. As regras de desconto e prazos mudam (pergunta 2: sim) e cabem em instruções (pergunta 1: sim), então ficam no harness. O tom formal é estável (pergunta 2: não), o prompt chega perto mas estaciona abaixo do alvo (pergunta 4: falta consistência), então pede um LoRA de rank baixo. O jargão proprietário é estável e não cabe em prompt, porque são dezenas de termos raros cuja distribuição o contexto não induz. Resultado: um LoRA cobre tom e jargão; todo o resto, todas as regras de atendimento, fica com o harness.
A primeira pergunta sozinha filtra 90% dos reflexos de retreinar.
Onde a gente entra
A Pumpkin constrói o harness que cobre os 90% que não pedem fine-tuning. Na B2B Co., a gente começa pelo que o harness resolve: o RAG sobre o catálogo (no nosso caso, um knowledge graph que torna explícitas as relações de categoria, subcategoria e exceção de desconto), a orquestração das APIs de prazo, os guardrails que mantêm o agente fiel ao catálogo e a camada de instrução de tom formal com exemplos. Isso já cobre a maioria dos erros. Depois, a gente mede: onde o prompt ainda erra? No jargão e no tom muito específico. E mesmo aí, quando a camada de prompt é escrita por um modelo de fronteira, o harness já está destilando a competência do modelo grande sem retreino. Só se a consistência ainda não chegar ao alvo é que entra um LoRA de rank baixo, no seu próprio modelo, de forma justificada e estável, nunca como primeiro passo.
A lição vale para a B2B Co. e para qualquer time com um agente em produção: o fine-tuning não é o plano A. É o plano B, reservado ao resíduo que o harness, mesmo bem feito, não alcança. Um harness bem engenheirado resolve a esmagadora maioria dos problemas com muito menos custo, muito mais velocidade de iteração e controle total sobre o que a sua IA responde. Saber a diferença, e construir o harness que torna essa escolha possível, é o que separa um agente que escala de um que trava no primeiro mês.
A maioria dos times pula direto para o fine-tuning, sem saber que o harness bem engenheirado já resolve a maior parte dos problemas, com muito menos custo e sem abrir mão do controle.