Fine-tuning vs RAG: quando treinar o modelo e quando injetar contexto

1. Introdução conceitual: duas abordagens para personalizar LLMs

1.1. O que é Fine-tuning: ajuste de pesos do modelo em dados específicos

Fine-tuning é o processo de continuar o treinamento de um modelo de linguagem pré-treinado (LLM) em um conjunto de dados específico do domínio. Durante o fine-tuning, os pesos internos do modelo são atualizados para aprender padrões, vocabulários e estilos próprios daquele contexto. O resultado é um modelo que "internaliza" o conhecimento, tornando-se especialista naquele domínio.

# Exemplo conceitual de fine-tuning com Hugging Face Transformers
from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer

model = AutoModelForCausalLM.from_pretrained("microsoft/phi-2")
tokenizer = AutoTokenizer.from_pretrained("microsoft/phi-2")

# Dataset jurídico proprietário
dataset = load_dataset("json", data_files="contratos_juridicos.json")
trainer = Trainer(model=model, train_dataset=dataset)
trainer.train()
model.save_pretrained("./phi2-juridico-finetuned")

1.2. O que é RAG (Retrieval-Augmented Generation): injeção de contexto via busca externa

RAG é uma arquitetura que combina um sistema de recuperação de informações com um LLM. Em vez de treinar o modelo, você mantém uma base de conhecimento externa (vector database) e, a cada consulta, recupera os documentos mais relevantes para injetar no prompt do modelo.

# Exemplo conceitual de pipeline RAG com LangChain
from langchain.vectorstores import FAISS
from langchain.embeddings import OpenAIEmbeddings
from langchain.llms import OpenAI

vectorstore = FAISS.load_local("kb_docs", OpenAIEmbeddings())
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

def rag_query(pergunta):
    docs = retriever.get_relevant_documents(pergunta)
    contexto = "\n\n".join([d.page_content for d in docs])
    prompt = f"Contexto:\n{contexto}\n\nPergunta: {pergunta}\nResposta:"
    return OpenAI().invoke(prompt)

1.3. O trade-off fundamental: memória interna do modelo vs. conhecimento externo dinâmico

A escolha entre fine-tuning e RAG depende de um equilíbrio: fine-tuning grava conhecimento nos pesos do modelo (memória permanente, mas cara de atualizar), enquanto RAG busca conhecimento externo sob demanda (memória volátil, mas fácil de atualizar). O fine-tuning é ideal quando o conhecimento é estável e profundo; o RAG, quando o conhecimento é dinâmico e extenso.

2. Quando escolher Fine-tuning: cenários de especialização profunda

2.1. Domínios com linguagem proprietária ou jargão técnico

Se seu domínio usa terminologia específica que o LLM base não conhece — como cláusulas contratuais, nomenclatura médica ou siglas financeiras — o fine-tuning é mais indicado. O modelo precisa "aprender" o significado desses termos para usá-los corretamente.

2.2. Tarefas com padrões fixos e repetitivos

Para tarefas como classificação de tickets de suporte em categorias predefinidas ou sumarização de relatórios com estrutura fixa, o fine-tuning permite que o modelo aprenda exatamente o formato de saída esperado, reduzindo variações indesejadas.

# Fine-tuning para classificação de tickets
dados_treino = [
    {"texto": "Meu cartão foi clonado", "categoria": "fraude"},
    {"texto": "Quero cancelar minha assinatura", "categoria": "cancelamento"},
]
# Após fine-tuning, o modelo retorna apenas a categoria no formato esperado

2.3. Necessidade de consistência em estilo e tom

Marcas que exigem um tom de voz padronizado (como um assistente de suporte que deve sempre responder de forma empática e formal) se beneficiam do fine-tuning para gravar esse estilo nos pesos do modelo.

3. Quando escolher RAG: cenários de conhecimento atualizado e mutável

3.1. Bases de conhecimento que mudam com frequência

Se sua documentação de produto é atualizada semanalmente ou suas FAQs mudam com o lançamento de novas versões, o RAG é a escolha natural. Basta adicionar novos documentos ao vector database sem precisar re-treinar o modelo.

# Atualização da base RAG com novo documento
vectorstore.add_documents([Document(page_content="Nova política de privacidade v2.1")])
# Pronto! O modelo já usa o novo conteúdo sem re-treino

3.2. Acesso a dados privados ou sensíveis

Dados de clientes, informações financeiras internas ou segredos comerciais não devem ser incorporados aos pesos do modelo (que podem vazar). O RAG permite que o modelo acesse esses dados apenas no momento da consulta, mantendo o controle de acesso.

3.3. Contexto muito grande ou fragmentado

Para bases com milhares de documentos, como livros técnicos, logs de sistemas ou artigos científicos, o RAG escala melhor. O fine-tuning teria dificuldade em memorizar todo esse volume, enquanto o RAG recupera seletivamente o que é relevante.

4. Comparação técnica e operacional

4.1. Custo computacional: treino vs. indexação

Aspecto Fine-tuning RAG
Custo inicial Alto (GPU/horas de treino) Baixo (indexação única)
Custo por consulta Baixo (apenas inferência) Médio (busca + inferência)
Atualização Re-treino completo Apenas re-indexar

4.2. Latência e escalabilidade

Fine-tuning oferece latência menor (resposta direta do modelo), enquanto RAG adiciona o tempo de busca no vector database (tipicamente 100-500ms extras). Para sistemas com milhares de requisições por segundo, o fine-tuning pode ser mais previsível.

4.3. Manutenção e versionamento

Com fine-tuning, você gerencia versões de modelos (v1, v2, v3). Com RAG, gerencia versões da base de conhecimento. Ambos têm complexidades, mas o RAG permite rollback mais granular (remover um único documento).

5. Estratégias híbridas: combinando Fine-tuning e RAG

5.1. Fine-tuning para compreensão de domínio + RAG para fatos atualizados

A abordagem mais poderosa é usar fine-tuning para ensinar ao modelo a "linguagem" do domínio e RAG para fornecer os fatos atualizados. O modelo entende o contexto, mas busca a informação correta externamente.

5.2. Exemplo prático: assistente de suporte técnico

# Abordagem híbrida
# 1. Fine-tuning do modelo em linguagem de produto (jargão técnico, tom de suporte)
# 2. RAG para acessar a base de conhecimento (KB) com soluções atualizadas

def assistente_hibrido(pergunta):
    # Modelo fine-tuned entende o contexto
    contexto_entendido = modelo_finetuned.analisar_intencao(pergunta)
    # RAG busca a solução mais recente
    docs = kb_retriever.get_relevant_documents(contexto_entendido)
    # Combina no prompt final
    return modelo_finetuned.gerar_resposta(docs, pergunta)

5.3. Cuidados com sobreposição e conflito de informações

Se o modelo foi fine-tuned com informações desatualizadas e o RAG fornece informações novas, pode haver conflito. A regra prática: sempre priorize o contexto injetado (RAG) sobre o conhecimento interno do modelo, instruindo explicitamente no prompt.

6. Métricas e validação: como decidir com dados

6.1. Testes A/B: comparar acurácia, relevância e taxa de alucinação

Implemente um conjunto de teste com 100-200 perguntas do domínio real. Meça:
- Acurácia factual (resposta correta?)
- Relevância (responde exatamente o que foi perguntado?)
- Taxa de alucinação (inventou informação?)

6.2. Métricas de recuperação para RAG vs. métricas de perplexidade para Fine-tuning

Para RAG, monitore recall@k e precision@k da recuperação. Para fine-tuning, acompanhe perplexidade e loss em validação. Se o recall do RAG estiver abaixo de 80%, melhore a indexação; se a perplexidade do fine-tuning não cair, talvez o dataset seja pequeno demais.

6.3. Feedback de usuários e logs de interação

Implemente um sistema de feedback (thumbs up/down) e analise logs de interação. Se usuários frequentemente corrigem respostas ou pedem mais informações, isso indica que a abordagem atual (seja fine-tuning ou RAG) precisa ser ajustada.

7. Conclusão e recomendações práticas

7.1. Checklist rápido: 5 perguntas para escolher a abordagem

  1. O conhecimento muda com frequência? Se sim → RAG. Se não → Fine-tuning.
  2. O domínio tem jargão técnico complexo? Se sim → Fine-tuning.
  3. A base de conhecimento é muito grande (>10k documentos)? Se sim → RAG.
  4. Preciso de latência muito baixa (<200ms)? Se sim → Fine-tuning.
  5. Os dados são sensíveis e não podem ser incorporados ao modelo? Se sim → RAG.

7.2. Comece com RAG, evolua para Fine-tuning quando necessário

Minha recomendação prática: comece sempre com RAG. É mais rápido de implementar, mais barato e mais flexível. Se você perceber que o modelo não está capturando bem o jargão do domínio ou que o estilo das respostas é inconsistente, então considere adicionar fine-tuning incremental.

7.3. Tendências futuras: modelos cada vez mais adaptáveis

Ferramentas como LoRA (Low-Rank Adaptation) e QLoRA tornaram o fine-tuning muito mais acessível, permitindo ajustar modelos grandes com pouca GPU. Paralelamente, sistemas de RAG estão ficando mais inteligentes com chunking semântico e re-ranking. A tendência é que a linha entre as duas abordagens se torne cada vez mais tênue, com frameworks que combinam ambas de forma automática.

A decisão final não precisa ser binária. Na prática, os melhores sistemas de produção usam uma combinação inteligente: fine-tuning para a alma do modelo (compreensão de domínio, estilo) e RAG para o corpo (conhecimento factual, atualizações). O segredo está em medir, iterar e ajustar continuamente.

Referências