RAG, contexto longo ou fine-tuning: qual usar para o seu LLM responder com os seus dados?

O modelo não sabe NADA da sua empresa

Não conhece seu manual interno, sua base de suporte, nem aquele repositório que só você entende haha

E existem três jeitos de resolver isso, com custos e riscos bem diferentes

Se você quer que o LLM responda com os seus documentos, sua base de atendimento ou seu código, provavelmente está travado entre três opções: montar um RAG, colar tudo no contexto ou treinar o modelo (fine-tuning)

Neste post eu comparo as três por custo, esforço de manutenção, frescor da informação e risco de resposta errada

E no final tem um guia de decisão por cenário, da base que muda toda semana até o tom de voz fixo 🙂

Bora?

RAG vs contexto longo vs fine-tuning: comparação lado a lado

Antes de entrar em cada um, se liga no quadro geral

Onde não existe dado verificado, a célula fica qualitativa, sem número inventado

Resumo da ópera: as três resolvem problemas DIFERENTES

Agora bora ver cada uma com calma

Quando RAG é a melhor escolha para o seu LLM

RAG é a sigla de Retrieval-Augmented Generation: antes de responder, o sistema busca os trechos relevantes na sua base e entrega eles pro modelo junto com a pergunta

A ideia foi formalizada no artigo Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, de Patrick Lewis e coautores, publicado na NeurIPS 2020

No artigo original, o RAG junta uma memória paramétrica (um modelo seq2seq pré-treinado) com uma memória não paramétrica: um índice vetorial denso da Wikipedia, consultado por um recuperador neural

Traduzindo: o modelo continua sabendo escrever, e o índice é quem sabe os fatos

É como um atendente bom que não decorou o manual, mas sabe exatamente em qual página procurar 😀

Por que RAG vence quando a base muda toda semana?

Porque você atualiza o índice, não o modelo

Entrou documento novo? Indexa

Mudou uma política? Reindexa aquele trecho e pronto, a próxima pergunta já sai com a versão nova

Outro ponto massa: como a resposta nasce de trechos recuperados, fica fácil mostrar de onde veio a informação

Qual o principal risco do RAG?

Recuperar o trecho errado

Se a busca traz o pedaço errado (ou não traz o certo), o modelo responde com confiança em cima de um material que não tem a resposta

E aqui mora o problema clássico do chunk solto: um trecho que diz "o prazo é de 30 dias" sem dizer prazo DE QUÊ

Como reduzir as falhas de recuperação?

A Anthropic publicou uma técnica chamada Contextual Retrieval, que junta Contextual Embeddings com Contextual BM25

A sacada é simples: cada chunk recebe um pequeno texto de contexto, em geral de 50 a 100 tokens, gerado antes de virar embedding e de entrar no índice BM25

Assim o chunk deixa de ser um pedaço órfão e passa a carregar de onde veio e do que trata

Os números divulgados:

• até 49% menos recuperações que falham
• até 67% menos quando combinada com reranking

E o custo? A Anthropic estimou um custo único de US$ 1,02 por milhão de tokens de documento pra gerar esses chunks contextualizados, usando prompt caching

Tome cuidado com esse número: é uma estimativa da própria Anthropic, feita com o modelo da época, então trate como ordem de grandeza e não como preço de tabela

Quando colocar tudo no contexto longo resolve (e quando não)

Aqui a coisa mudou bastante em 2026

Em 13/03/2026 a Anthropic tornou geral a janela de 1 milhão de tokens no Claude Opus 4.6 e no Sonnet 4.6, com preço padrão e sem sobretaxa de contexto longo

E o Opus 5.5 (lançado em 22/09/2026) e o Sonnet 5.5 também têm janela de 1M

Na prática, desde o Claude 4.6 a cobrança por token é a mesma em toda a janela: um pedido de 900 mil tokens paga a mesma taxa por token de um pedido pequeno

Pra comparar, na regra antiga (já extinta) a entrada do Sonnet subia de cerca de US$ 3 para cerca de US$ 6 por milhão de tokens quando o prompt passava do limite de contexto longo

Ou seja, colar o manual inteiro deixou de ser luxo de PC da Nasa haha

Prompt caching: o que torna isso viável no dia a dia

Mandar a mesma base gigante a cada pergunta sairia caro

É aí que entra o prompt caching da Anthropic:

• leitura do cache: 0,1x o preço base de entrada
• gravação com TTL de 5 minutos: 1,25x
• gravação com TTL de 1 hora: 2x

A comparação é com mandar a mesma base SEM cache: sem caching, duas chamadas pagam o preço base cheio duas vezes; com caching, você paga 1,25x na primeira (a escrita) e 0,1x na segunda (a leitura)

Ou seja, um único acerto de cache já compensa o custo extra da escrita (no TTL de 5 minutos)

Então se a mesma base é consultada várias vezes, o caching faz o contexto longo ficar MUITO mais barato do que parece

Qual o risco de jogar tudo no contexto?

O modelo "ler" 1 milhão de tokens não quer dizer que ele presta atenção igual em tudo

O estudo Lost in the Middle (Liu et al., TACL) mostrou que o desempenho costuma ser maior quando a informação relevante está no início ou no fim do contexto, e cai bastante quando ela fica no meio

E isso vale mesmo pra modelos feitos pra contexto longo

Dica prática derivada do estudo: coloca o que mais importa no começo ou no fim do prompt (as instruções, a pergunta, os documentos mais críticos) e evita enterrar o essencial no meio do bolo

Se o seu caso é mais revisar material grande do que montar um sistema, também dá pra revisar textos longos sem perder contexto com outra abordagem

Quando o contexto longo não resolve?

• quando a base é maior que a janela (não tem mágica, não cabe)
• quando a base muda a cada minuto e você vive reenviando e regravando cache

Nesses dois casos, a conta e a manutenção começam a pender pro RAG

Pra quem quer começar do zero e ver como é trabalhar com uma janela de 1 milhão de tokens na prática, este vídeo do canal é uma boa introdução:

Fine-tuning em 2026: para que serve e por que ficou mais difícil

Primeiro, o porquê: fine-tuning ajusta o COMPORTAMENTO do modelo

Serve pra formato de saída, estilo, tom de voz fixo, aquele jeito específico de responder

Não serve bem pra fatos que mudam, porque o conhecimento fica congelado no momento do treino

Mudou o preço do produto? O modelo treinado continua respondendo o preço velho, com toda a convicção do mundo xD

O que mudou no fine-tuning da OpenAI?

A OpenAI está encerrando aos poucos o fine-tuning self-serve, em etapas que vão fechando a porta uma depois da outra:

• desde 07/05/2026, organizações que nunca rodaram fine-tuning não podem criar jobs de treino
• desde 02/07/2026, criar jobs deixou de estar disponível para organizações que não rodaram inferência em modelo fine-tunado nos últimos 60 dias
• em 06/01/2027, nem os clientes ativos poderão criar novos jobs

A inferência em modelos já fine-tunados continua até o modelo base ser descontinuado

No lugar do self-serve, a OpenAI está ampliando um programa de fine-tuning assistido, voltado a empresas

E no ecossistema do Claude?

O Claude 3 Haiku tinha fine-tuning no Amazon Bedrock, mas o modelo chegou ao fim de vida em 10/09/2026

O recado geral é claro: treinar o próprio modelo virou caminho mais estreito, e não dá pra contar com ele como plano A pra responder com os seus dados

Guia de decisão: qual estratégia usar em cada cenário

Agora a parte que importa, cenário por cenário:

• Base de documentos que muda toda semana: RAG, porque você atualiza o índice e não precisa mexer em mais nada
• Manual ou repositório que cabe na janela e é consultado muitas vezes no dia: contexto longo com caching, já que um único acerto de cache paga a escrita e as leituras saem a 0,1x
• Base enorme com perguntas pontuais: RAG com Contextual Retrieval e reranking, que é onde a Anthropic reporta até 67% menos falhas de recuperação
• Análise única de um material grande: contexto longo sem caching, porque não vai ter segunda leitura pra compensar a gravação do cache
• Respostas que precisam citar a fonte exata: RAG, já que cada resposta nasce de trechos recuperados que dá pra mostrar
• Tom de voz ou formato de saída fixo: instruções no prompt primeiro; fine-tuning só se ele estiver disponível pra você, lembrando que a OpenAI encerra a criação de jobs pra todos em 06/01/2027
• Fatos e estilo ao mesmo tempo: combina RAG pros fatos com um prompt fixo pro estilo, cada peça fazendo o que faz de melhor

Veredito: RAG, contexto longo ou fine-tuning?

Pra responder com os seus dados, a disputa real hoje é entre RAG e contexto longo

Fine-tuning virou ferramenta de nicho, pra comportamento, e ainda com acesso cada vez mais restrito

Regra de bolso:

• começa pelo contexto longo com caching se a base cabe na janela e é estável
• migra ou combina com RAG quando a base cresce, muda muito ou exige rastrear a fonte

E em qualquer um dos dois, a resposta errada continua sendo possível, seja por recuperação ruim, seja por informação perdida no meio

Se o erro custa caro no seu caso, vale colocar outro LLM como guardrail pra julgar a saída antes dela chegar no usuário

Próximo passo

Antes de escolher, mede duas coisas: o tamanho da sua base e com que frequência ela muda

Essas duas respostas decidem quase tudo 🙂

Depois separa uma amostra de perguntas reais (as que seus usuários fazem de verdade, não as que você inventou pra ficar bonito)

Roda essas perguntas com o material inteiro no contexto e depois com os trechos recuperados por busca, e confere onde cada abordagem erra

É esse teste que vai te dizer qual caminho serve pro SEU caso

Até o próximo post!