Fine-tuning, retrieval ou prompt: uma decisão que tomo toda semana

Quase toda proposta de feature de IA que chega à minha mesa vem com uma técnica preferida já anexada. Alguém quer fazer fine-tuning porque soa sério. Alguém quer RAG porque leu que resolve alucinação. Alguém quer um prompt maior porque é o que conhece. A técnica raramente é escolhida a partir do problema. Então tenho um procedimento curto de decisão que rodo toda semana, e ele começa com uma única pergunta: o que o modelo precisa e ainda não tem, e com que frequência isso muda?

A árvore de decisão

Um modelo pode estar sem três coisas diferentes. Pode estar sem instruções: não sabe o que você quer, em que formato, com que tom. Pode estar sem conhecimento: fatos sobre o seu domínio, seus dados, seus clientes, a política desta semana. Ou pode estar sem comportamento: um jeito consistente de agir que instruções descrevem mal, como um estilo da casa, uma fronteira de classificação difícil de colocar em palavras, ou um formato tão específico que exemplos saem mais baratos que regras. Instrução se resolve com prompt. Conhecimento se resolve com retrieval. Comportamento se resolve com fine-tuning. A maioria dos problemas é dos dois primeiros tipos, e a maioria das propostas de fine-tuning que vejo são tentativas de resolver os dois primeiros com o terceiro.

Prompt primeiro

Prompt é por onde sempre começo, porque é o mais barato de mudar e o mais rápido de avaliar. Uma descrição clara da tarefa, um schema para a saída, alguns exemplos bem escolhidos e uma declaração explícita do que fazer em caso de dúvida levam um modelo de fronteira quase até o fim na maioria das tarefas. O erro é parar de iterar cedo demais ou tarde demais. Cedo demais é declarar o modelo incapaz depois de duas tentativas. Tarde demais é um prompt de quatro mil tokens que virou um livro de regras impossível de manter, o que é o sinal de que a coisa que faltava nunca foi instrução.

Retrieval quando os fatos mudam

Se o modelo precisa saber algo específico e esse algo muda, retrieval é a única opção sensata. Catálogos de produto, documentos internos, histórico de clientes, regulações, qualquer coisa com data. Colocar fatos num modelo via fine-tuning é caro, lento e fica desatualizado no momento em que os fatos mudam, e não dá citação. Retrieval dá citação, atualiza quando a fonte atualiza e pode ter permissão por usuário. O custo é que agora você é dono de um sistema de busca, o que é engenharia de verdade. Mas é engenharia bem compreendida, que falha de formas visíveis.

Fine-tuning quando o comportamento precisa ser moldado

Recorro ao fine-tuning quando tenho um conjunto grande e limpo de exemplos do comportamento exato que quero, quando o prompt estagnou com o conjunto de evals provando isso, e quando a tarefa é estável o bastante para o investimento se pagar. Casos típicos: um modelo pequeno que precisa igualar a qualidade de um modelo de fronteira numa tarefa estreita, por uma fração do custo e da latência. Um formato ou estilo que exemplos transmitem melhor que palavras. Um classificador sobre inputs específicos do domínio, onde mil rótulos vencem qualquer descrição. O que fine-tuning não faz é adicionar conhecimento de forma confiável ou consertar uma tarefa que nunca foi especificada com clareza. Quem decide é o conjunto de evals, não o entusiasmo.

O ritual semanal

Na prática a decisão não é uma vez por feature. Ela é revisitada conforme a feature amadurece. Uma feature começa com prompt, porque é assim que se aprende qual é a tarefa. Ganha uma camada de retrieval quando os evals mostram falhas causadas por fatos ausentes. Pode ganhar um modelo pequeno com fine-tuning por custo, quando o comportamento estabilizou e os exemplos se acumularam. E cada lançamento de provedor reinicia parte disso, porque um modelo base melhor pode tornar o fine-tune de ontem desnecessário. Tudo bem. A técnica nunca foi o ponto. O conjunto de evals é, e a técnica é o que fizer os números subirem nesta semana.