Fine-tuning, RAG e Modelfile: guia prático para decidir em produção

A pergunta certa antes de escolher a técnica

Antes de falar de ferramentas, responda mentalmente:

1. Você quer mudar comportamento ou conhecimento?
2. O conhecimento precisa estar atualizado e auditável?
3. Você precisa de consistência rígida de formato/estilo?
4. Sua equipe tolera infraestrutura extra (index, ingestão, avaliação)?
5. Você consegue manter um dataset de treino com qualidade e governança?

Quando você clareia isso, as escolhas ficam quase óbvias.

---

Modelfile: a personalização mais barata e a mais subestimada

O que é Modelfile na prática

No ecossistema do Ollama, um Modelfile é um "blueprint" para criar e compartilhar modelos customizados, definindo:

• FROM: modelo base
• PARAMETER: parâmetros de execução (contexto, temperatura, stops etc.)
• TEMPLATE: template do prompt
• SYSTEM: instrução de sistema padrão
• ADAPTER: aplicação de adapter LoRA/QLoRA quando disponível

Ou seja: Modelfile não é só "prompt fixo". Ele é a camada que define como o modelo roda e como o prompt é montado a cada inferência.

O que ele resolve muito bem

1) Consistência de comportamento e tom: Você padroniza a persona do assistente, regras de segurança internas e estilo de resposta.

2) Formato recorrente sem treino: Você pode impor um template para sempre responder em um formato estável, sem pagar o custo de treinar.

3) Controle fino de parâmetros: Contexto máximo, penalidades de repetição e limites de geração podem ser travados no "pacote do modelo".

4) Empacotar adapters como parte do produto: Se você já tem um LoRA/QLoRA, o Modelfile vira o "instalador mental" do seu modelo: base + adapter + regras.

Ponto de atenção: precedência e override

Se o seu Modelfile define TEMPLATE/SYSTEM de um jeito, ele pode "puxar" o modelo para um comportamento que contradiz o que um ajuste anterior tentava fazer. Na API do Ollama, parâmetros como template podem sobrescrever o que está no Modelfile. Isso é útil em runtime, mas também é uma fonte clássica de confusão em times grandes. (GitHub)

Quando Modelfile não é suficiente

Modelfile não resolve bem quando o problema é "o modelo não sabe X" e X é grande, mutável e cheio de detalhes, ou quando você precisa de citações e rastreabilidade.

---

Fine-tuning: quando você quer consistência que prompt nenhum segura

O que fine-tuning realmente faz

Fine-tuning altera a capacidade do modelo de reproduzir padrões: estilo, estrutura, decisões de classificação, e até "jeitos de explicar" um domínio.

Em 2026, a forma mais comum de fazer isso sem explodir custo é com adaptação eficiente:

• LoRA: congela o modelo base e treina matrizes de baixa dimensão. (arXiv)
• QLoRA: treina adapters em cima de um modelo quantizado (4-bit) para reduzir memória. (arXiv)

O que fine-tuning resolve melhor que RAG e Modelfile

1) Formato extremamente consistente: Se você precisa que a saída seja sempre validável (esquema rígido), fine-tuning costuma ganhar.

2) Classificação e extração estáveis: Quando a tarefa é reconhecer padrões recorrentes, fine-tuning é mais previsível do que prompt engineering.

3) Linguagem de domínio e taxonomia: Se o "jeito certo" de falar no seu domínio é estável, o modelo internaliza o estilo sem depender de prompt gigante.

Onde fine-tuning dá ruim

1) Quando o problema é atualização: Se o conteúdo muda toda semana, fine-tuning vira manutenção eterna.

2) Quando o dataset não tem governança: Treinar com dados ruins dá um modelo inconsistente. Existe risco real de envenenamento de dados como ameaça reconhecida em segurança de LLMs. (OWASP)

3) Quando você espera "memória infinita": Fine-tuning aprende padrões, não vira uma enciclopédia auditável.

---

RAG: quando a fonte da verdade não cabe nos pesos do modelo

O que é RAG em termos práticos

RAG (Retrieval-Augmented Generation) conecta o modelo a uma memória externa: você recupera trechos relevantes de um corpus e injeta no contexto para gerar a resposta.

O paper que popularizou o termo propôs combinar um modelo seq2seq com um índice denso, melhorando desempenho em tarefas intensivas de conhecimento. (arXiv)

O que RAG resolve melhor

1) Atualização sem retreinar: Mudou a documentação? Você reindexa. Não precisa mexer nos pesos.

2) Auditabilidade e redução de alucinação: Você consegue responder "com base" no material recuperado.

3) Flexibilidade de fontes: Trocar a base ou filtrar por versão é mais simples do que re-treinar.

O que ninguém te conta: RAG falha de maneiras específicas

RAG não "garante verdade". Ele depende de recall, precision, ranking, janela de contexto e controle de injeção.

Em 2024 e 2025 surgiram trabalhos fortes sobre auto-correção:

• CRAG (Corrective RAG): adiciona avaliador de qualidade e aciona estratégias corretivas. (arXiv)
• Self-RAG: ensina o modelo a decidir quando recuperar e refletir sobre evidências. (arXiv)
• RAGAS: avaliação automatizada de pipelines RAG. (arXiv)

Segurança: o calcanhar de Aquiles do RAG

RAG amplia a superfície de ataque porque coloca conteúdo externo dentro do contexto. O OWASP lista Prompt Injection como ameaça principal, e o NCSC do Reino Unido alerta que não é equivalente a SQL injection: é uma classe diferente de falha. (NCSC)

---

Tabela de decisão: escolha a técnica pelo tipo de necessidade

---

Casos reais

Caso 1: Suporte com manuais que mudam

Solução: RAG com base versionada. Não faz sentido re-treinar a cada mudança de política.

Caso 2: Triagem de tickets e classificação

Solução: Fine-tuning com LoRA/QLoRA. Tarefa repetitiva onde consistência importa mais do que citar fontes.

Caso 3: Assistente local padronizado para o time

Solução: Modelfile para travar template, tom e limites. Adicionar adapter via ADAPTER quando precisar de estilo mais específico.

Caso 4: Pesquisa técnica com exigência de evidência

Solução: RAG com citações. Self-RAG mostra a direção de tornar a recuperação mais adaptativa.

---

Checklist de implementação

Modelfile

1. Defina modelo base (FROM)
2. Trave parâmetros críticos (num_ctx, temperature, stop)
3. Escreva SYSTEM curto e testável
4. Versione o arquivo como artefato do produto

Fine-tuning

1. Defina tarefa com outputs bem definidos
2. Monte dataset com revisão humana
3. Comece com LoRA e só depois considere QLoRA
4. Meça regressões: melhora numa coisa, piora em outra?

RAG

1. Defina fonte e escopo (o que entra e o que nunca entra)
2. Faça chunking com sobreposição e metadados
3. Adicione reranking se recall/precision estiver ruim
4. Registre evidências usadas (observabilidade)
5. Adote defesas contra prompt injection desde o início

---

A regra que evita 80% da confusão

• Modelfile governa comportamento e execução
• Fine-tuning governa consistência internalizada de padrões
• RAG governa conhecimento externo com evidência e atualização

Você não escolhe uma "religião". Escolhe uma base inicial, mede e evolui.

---

Leia também

• Engenheiro de IA
• Líder de IA
• O Flutter vai morrer?