Voltar para Biblioteca
Playbook·11 min·Jul 2026

RAG vs Fine-Tuning vs Contexto Longo: a Decisão de Build

RAG vs fine-tuning vs contexto longo decidido como uma decisão de build, não preferência. Uma árvore de decisão e o moat que de fato se acumula.

RAG vs fine-tuning vs contexto longo é uma decisão de build, não uma preferência, e as três opções não disputam a mesma vaga. A recuperação compra conhecimento fresco, auditável e trocável. O fine-tuning compra comportamento e formato a um custo por chamada menor, pago com um ônus de dados e de retreinamento. O contexto longo compra simplicidade para tarefas delimitadas e de uma passada só.

Este é o playbook que a Avante Ventures roda ao construir um produto de IA vertical. Comece pela recuperação, acrescente fine-tuning apenas quando o comportamento não puder ser resolvido por prompt nem por recuperação, e reserve o contexto longo para tarefas que cabem na janela. O moat nunca é o modelo. É o corpus de recuperação e os evals ao redor dele, um argumento que fazemos por inteiro no nosso texto sobre efeito de rede de dados na IA vertical.

RAG vs fine-tuning: o que cada um realmente te dá

A forma mais limpa de enquadrar RAG vs fine-tuning é parar de perguntar qual é melhor e começar a perguntar o que cada um compra. A OpenAI coloca isso como um diagnóstico. Trate cada resposta errada como um problema de memória em contexto ou de memória aprendida. A recuperação conserta o primeiro, quando o modelo não tem o conhecimento, precisa de dado atual ou precisa de algo proprietário. O fine-tuning conserta o segundo, quando o modelo precisa de comportamento ou formato consistente aprendido de exemplos. A OpenAI é direta ao dizer que fine-tuning não é a ferramenta para adicionar conhecimento novo. Isso é trabalho da recuperação.

A orientação da Microsoft chega ao mesmo lugar pelo outro lado. Você escolhe RAG quando o conteúdo é dinâmico, os temas são amplos ou você não tem dados e computação para treinar. Você escolhe fine-tuning quando a tarefa é estreita e estável e você tem dado de domínio limpo o bastante para não sofrer overfitting. Lido diante de um produto real, o trade-off deixa de ser abstrato.

  • Recuperação compra conhecimento fresco, auditável e trocável. Você atualiza o corpus quando quiser, cita o documento por trás de uma resposta e troca o modelo base por baixo sem retreinar.
  • Fine-tuning compra comportamento, aderência de formato e um custo por chamada menor depois de treinado. O preço é um ônus permanente de dados e retreinamento, e ele congela um modelo base dentro do produto.
  • Contexto longo compra simplicidade. Sem vector store, sem pipeline, é só colocar o material no prompt. Só se sustenta enquanto o material cabe na janela e a conta de tokens continua sã.

Uma árvore de decisão para recuperação, tuning e contexto

Os dois grandes laboratórios apontam para a mesma direção. Comece pelo prompt, recorra à recuperação antes de recorrer ao treinamento. A Anthropic até dá um limite de tamanho para a bifurcação do contexto longo. Se a sua base de conhecimento tem menos de 200.000 tokens, cerca de 500 páginas, você pode jogar tudo no prompt e pular o RAG por completo. Acima disso, a recuperação vira o caminho escalável, e ela compensa. A recuperação contextual da Anthropic corta a taxa de falha dos 20 primeiros trechos em 35% só com embeddings contextuais, em 49% combinada com BM25 contextual, e em 67% quando entra a reordenação, de uma taxa de falha de 5,7% para 1,9%.

Aqui está a árvore que um operador roda esta semana. São quatro perguntas, em ordem, e a maioria dos produtos nunca chega à quarta.

  • Um prompt melhor sobre um modelo base forte resolve? Se sim, pare. Não construa maquinário que você vai ter que manter.
  • A resposta depende de conhecimento proprietário, que muda, ou maior que a janela? Se sim, construa recuperação. Esse é o padrão para um produto vertical.
  • A base de conhecimento é delimitada, abaixo de uns 200.000 tokens, e a tarefa é de uma passada só? Use contexto longo e pule o pipeline.
  • O modelo ainda falha em comportamento ou formato que prompt e recuperação não resolvem? Só agora você faz fine-tuning, e mantém a camada de recuperação por baixo dele.

A recuperação contextual cortou a taxa de falha dos 20 primeiros trechos em 67%, de 5,7% para 1,9%, ao combinar embeddings contextuais, BM25 contextual e reordenação. Qualidade de recuperação é um problema de engenharia com soluções conhecidas, não motivo para fazer fine-tuning.

— Anthropic, Contextual Retrieval, 2024

Quando a recuperação é o padrão certo

A recuperação é o padrão certo para quase todo produto de IA vertical, porque as duas coisas de que um produto de domínio mais precisa são frescor e rastro de papel. Um copilot jurídico tem que mostrar a peça por trás da resposta. Uma ferramenta de precificação de seguro tem que apontar a regra que aplicou. Um produto de setor público tem que ser auditável por alguém que ainda não confia nele. O fine-tuning não te dá nada disso. Ele assa o conhecimento em pesos que você não consegue inspecionar nem citar.

A outra razão é econômica, e é a que os times subestimam. A recuperação mantém o modelo base trocável. Quando um modelo mais barato ou melhor sai, e um sai a cada poucos meses, um produto que nasce da recuperação migra para ele sem reconstrução. Um produto com fine-tuning fica preso ao modelo contra o qual treinou até alguém pagar para retreinar. Num mercado onde a curva de custo se move tão rápido, ser trocável não é um luxo. É a estratégia inteira.

Quando o fine-tuning vale o custo

O fine-tuning vale o custo quando o problema é comportamento, não conhecimento, e prompt e recuperação de fato falharam em resolver. Formato de saída consistente ao longo de milhares de chamadas. Um tom da casa que o prompt não segura. Uma tarefa de classificação ou extração em que um modelo pequeno ajustado empata com um grande genérico por uma fração do preço por chamada. Esses são ganhos reais, e para tarefas estreitas de alto volume a economia por chamada é grande o bastante para mudar a economia unitária.

O custo é um ônus permanente, e você deveria nomeá-lo antes de se comprometer. Você precisa de um conjunto de dados grande, limpo e rotulado. Um pequeno sofre overfitting. O domínio se move, então o modelo precisa de retreinamento periódico. E no momento em que você faz fine-tuning, congelou o seu modelo base. Trocar pela opção mais barata do próximo trimestre passa a significar retreinar, não mudar uma configuração. Faça fine-tuning quando o ganho de comportamento pagar essa conta. Não faça fine-tuning porque parece mais sério que recuperação.

Como seu corpus de recuperação vira o moat

O corpus de recuperação é onde uma venture AI-native defensável de fato se acumula, e esse é o verdadeiro prêmio da decisão de build. Um modelo com fine-tuning é um retrato que envelhece no dia em que é treinado. Um corpus de recuperação é um ativo que cresce a cada interação. Cada consulta respondida, cada documento ingerido, cada correção de especialista registrada vira dado proprietário que um concorrente começando hoje não tem e não pode comprar.

Este é o flywheel copilot, dado, capital, e é o padrão por trás de toda venture da Avante. Construa um copilot de IA para gerar dado proprietário, depois use esse dado para captar e alocar capital. O copilot cria o corpus. O corpus mais os evals de domínio ao redor dele viram o moat. E porque a qualidade é agnóstica de modelo e protegida por esses evals, o produto fica melhor e mais barato toda vez que os modelos de base melhoram, sem custo para você. O modelo base é alugado e todo concorrente aluga o mesmo. O corpus e os evals são propriedade sua. Fazemos o argumento completo no flywheel copilot, dado, capital.

Modos de falha: fine-tuning para esconder um problema de dados

O erro mais caro deste espaço inteiro é fazer fine-tuning para tapar um corpus fino ou mal rotulado. A recuperação funciona mal porque o dado por baixo está bagunçado, então o time faz fine-tuning para forçar o comportamento em vez de consertar o dado. Parece progresso. É o contrário.

  • Assa um retrato velho do domínio dentro do produto, então o conhecimento fica congelado no momento do treino enquanto o mundo segue em frente.
  • Esconde o problema real, que é qualidade de dado, atrás de um artefato de modelo difícil de inspecionar e mais difícil ainda de corrigir.
  • Congela o modelo base, então quando os preços de inferência caírem cerca de 10x no ano seguinte, o time não consegue capturar a queda sem pagar para retreinar.
  • Contexto longo abusado do mesmo jeito é a sua própria armadilha. Empurrar tudo para o prompt para fugir de construir recuperação funciona até o corpus estourar a janela, a conta de tokens explodir e a memória degradar em entradas longas.

Como a Avante adota recuperação mais avaliações por padrão

A Avante Ventures adota recuperação mais avaliações por padrão porque é a única arquitetura que captura uma curva de custo em colapso em vez de brigar com ela. Um LLM na qualidade do GPT-3 caiu de cerca de 60 dólares por milhão de tokens no fim de 2021 para cerca de 0,06 dólar em 2024, perto de 10x ao ano para desempenho equivalente, segundo a a16z. A Epoch AI coloca a queda mediana perto de 50x ao ano entre benchmarks. Um produto que nasce da recuperação, sobre modelos trocáveis, desce junto com essa curva. Um com fine-tuning fica congelado acima dela.

Esse padrão encaixa no modelo de studio. A Avante Ventures lança 3-4 ventures por ano por um sistema de seis estágios, Research, Partner, Build, Traction, Revenue, Compound, empregando $500K-1.5M por venture e retendo economia de co-founder. Uma construção que nasce da recuperação mantém cada venture descendo a curva de custo, e resolver esse encanamento uma vez roteia cerca de $300K-500K de capital efetivo por venture para produto em vez de overhead. Também encaixa no mercado. O uso de IA entre empresas industriais brasileiras saltou de 16,9% em 2022 para 41,9% em 2024, segundo o IBGE, e serviços são cerca de 70% do PIB brasileiro com baixa penetração de software.

O teste honesto para qualquer time é uma pergunta. Se você removesse o fine-tune, o produto ainda funcionaria sobre recuperação e um modelo base forte? Se a resposta é não porque o dado não é bom o suficiente, você não tem um problema de modelo. Você tem um problema de dado fantasiado de modelo. Conserte o dado. O time que mantém seus modelos trocáveis é o time que continua podendo trocar.

Perguntas frequentes

Qual a diferença entre RAG e fine-tuning?
RAG vs fine-tuning se resume ao que cada um compra. A geração aumentada por recuperação dá ao modelo conhecimento fresco, auditável e trocável em tempo de inferência, e permite citar fontes. O fine-tuning muda o comportamento e o formato do modelo treinando-o com exemplos, a um custo por chamada menor mas com um ônus de dados e retreinamento. A OpenAI enquadra isso como memória em contexto, que é RAG, versus memória aprendida, que é fine-tuning.
Quando usar RAG ou fine-tuning?
Faça fine-tuning apenas quando o problema é comportamento ou formato que prompt e recuperação não resolvem, não quando você precisa adicionar conhecimento. Bons casos são um formato de saída consistente ao longo de milhares de chamadas, um tom da casa, ou uma tarefa estreita de alto volume em que um modelo pequeno ajustado empata com um grande por muito menos por chamada. Se você faz fine-tuning para adicionar fatos, use recuperação, porque fine-tuning não foi feito para adicionar conhecimento novo.
O contexto longo está substituindo o RAG?
Não. O contexto longo substitui o RAG apenas para tarefas delimitadas e de uma passada só que cabem na janela. A Anthropic recomenda colocar toda a base de conhecimento no prompt quando ela tem menos de cerca de 200.000 tokens, cerca de 500 páginas, e usar recuperação acima disso. Para um corpus que cresce ou qualquer coisa que precise de citações e frescor, a recuperação continua o padrão.
O que é mais barato, RAG ou fine-tuning?
Depende do volume e da frequência com que o seu dado muda. O RAG tem custo inicial menor e sem retreinamento, e mantém o modelo base trocável para você capturar os preços de inferência em queda, que caíram perto de 10x ao ano. O fine-tuning tem custo inicial alto de dados e treino, mas pode baixar o custo por chamada de uma tarefa estreita de alto volume, ao preço de congelar o seu modelo base.
Como decidir entre RAG, fine-tuning e contexto longo?
Rode uma árvore de decisão de quatro passos. Primeiro tente um prompt melhor. Se a resposta precisa de conhecimento proprietário, que muda ou grande, construa recuperação. Se o corpus é delimitado e abaixo de cerca de 200.000 tokens e a tarefa é de uma passada, use contexto longo. Só faça fine-tuning quando comportamento ou formato ainda falham depois de prompt e recuperação, e mantenha a camada de recuperação por baixo.
— Time Fundador da Avante
São Paulo + Vale do Silício · escrito de dentro do studio

Quer mais? Receba um ensaio por semana sobre venture building, negócios AI-native e a oportunidade Brasil.

Ver Biblioteca completa →