RAG: how a model answers with things it was never trained on
Retrieval-Augmented Generation is the mechanism behind "ask your documents" chatbots and most enterprise AI assistants. It doesn't make the model smarter — it changes what the model gets to read before it answers.
A language model's knowledge is frozen at training time and limited to whatever fit in its training data. Ask it about a company's internal policy document, a codebase it never saw, or news from after its cutoff, and it either says it doesn't know or — worse — confidently makes something up. Retraining the model every time new information shows up is slow and expensive, and it still wouldn't give a clean way to point at exactly which document an answer came from.
Retrieval-Augmented Generation (RAG) takes a different approach: instead of trying to bake the knowledge into the model's weights, it searches a separate collection of documents for the most relevant pieces of text right when a question comes in, and hands those pieces to the model as part of the prompt. The model then answers using both what it already knows and what it was just handed — with the added benefit that it can cite where the answer came from.
2. The three stages: indexing, retrieval, generation
Indexing (done ahead of time). Source documents — PDFs, wiki pages, support tickets, whatever the knowledge base is — get split into smaller chunks, and each chunk is converted into a vector representation (an embedding) that captures its meaning. These vectors get stored in a searchable index, often a dedicated vector database.
Retrieval (happens per query). The incoming question also gets converted into a vector using the same embedding model, and the system searches the index for the chunks whose vectors are closest to the question's vector — meaning, closest in meaning, not just keyword overlap.
Generation. The retrieved chunks get inserted into the prompt alongside the original question, and the language model generates its answer grounded in that retrieved text instead of purely from memory.
3. Where embeddings fit in
Embeddings are the piece that makes the "search by meaning" part of retrieval possible — the same idea covered in an earlier AI Watch lesson on embeddings. A RAG pipeline is essentially: embeddings for search, plus a generation step layered on top of whatever the search returns. If the embedding model is weak or mismatched to the domain (say, using a general-purpose embedding model on dense legal text), retrieval quality suffers no matter how good the language model itself is — the model can only answer as well as the material it was actually given.
4. Why not just fine-tune or use a bigger context window?
Approach
What it does well
Where it falls short
Fine-tuning
Teaches the model a style, format, or behavior pattern well.
Expensive and slow to update; poor fit for facts that change often, and doesn't give a clean citation trail.
Larger context window (stuffing everything into the prompt)
Simple, no separate retrieval system needed for small knowledge bases.
Doesn't scale to large document collections; costs more tokens per query; models can still lose track of details buried in the middle of a very long context.
RAG
Scales to large, frequently-updated knowledge bases; answers stay traceable to a source document; no retraining needed when documents change.
Only as good as the retrieval step — irrelevant or missing chunks lead to wrong or incomplete answers regardless of how good the model is.
5. Pros, cons, and failure modes
Pros
Keeps answers grounded in an actual, inspectable source instead of the model's internal (and sometimes wrong) memory.
Updating the knowledge base just means re-indexing documents — no retraining.
Reduces hallucination on domain-specific or fast-changing information, when retrieval works well.
Cons / failure modes
Garbage in, garbage out: if the retrieval step returns irrelevant chunks, the model will often still try to answer using them, producing a confidently wrong response.
Chunking strategy matters — split documents too small and you lose context, too large and irrelevant text dilutes what actually matters in the prompt.
It doesn't eliminate hallucination entirely; the model can still misread or misapply retrieved text, especially when multiple retrieved chunks conflict.
6. A generic example
Imagine an internal support assistant for a generic software product. Instead of fine-tuning a model on every help article ever written, the team indexes all the help articles as embeddings. When a user asks "why does my export keep failing," the system embeds that question, retrieves the two or three help articles whose content is closest in meaning to it (maybe one about file size limits, one about permissions), and passes those into the model's prompt. The model answers using those specific articles and can point back to them — instead of guessing from whatever it happened to learn about "export errors in general" during training.
7. The actual takeaway
The core idea: RAG doesn't make a model more knowledgeable in general — it makes the model's answer only as good as what gets retrieved for that specific question. The quality of a RAG system lives almost entirely in the retrieval step (chunking, embedding quality, search relevance), not in swapping to a smarter language model.
Sources
Databricks — "What is Retrieval Augmented Generation (RAG)?" (accessed August 2026)
IBM — "What is RAG (Retrieval Augmented Generation)?" (accessed August 2026)
Medium (Sahin Ahmed) — "What is Retrieval-Augmented Generation (RAG) in LLM and How it works?" (accessed August 2026)
Share:
Newsletter
Learn what AI is creating for you. Don't get lost.
Get notified when a new deep dive or lesson goes up. No spam, just new posts.
IA Watch · Conceitos fundamentais de LLMs
RAG: como um modelo responde com coisas que ele nunca aprendeu
Retrieval-Augmented Generation é o mecanismo por trás de chatbots do tipo "pergunte aos seus documentos" e da maioria dos assistentes de IA corporativos. Ele não torna o modelo mais inteligente — muda o que o modelo tem pra ler antes de responder.
O conhecimento de um modelo de linguagem fica congelado no momento do treinamento e é limitado ao que coube nos dados de treino. Pergunte a ele sobre o documento de política interna de uma empresa, uma base de código que ele nunca viu, ou notícias depois do seu corte de conhecimento, e ele ou diz que não sabe ou — pior — inventa algo com confiança. Retreinar o modelo toda vez que uma informação nova aparece é lento e caro, e ainda assim não daria uma forma limpa de apontar exatamente de qual documento uma resposta veio.
Retrieval-Augmented Generation (RAG) usa uma abordagem diferente: em vez de tentar embutir o conhecimento nos pesos do modelo, ele busca numa coleção separada de documentos os trechos mais relevantes no momento em que a pergunta chega, e entrega esses trechos ao modelo como parte do prompt. O modelo então responde usando tanto o que ele já sabe quanto o que acabou de receber — com o benefício extra de poder citar de onde a resposta veio.
2. As três etapas: indexação, busca, geração
Indexação (feita com antecedência). Os documentos de origem — PDFs, páginas de wiki, chamados de suporte, seja o que for a base de conhecimento — são divididos em pedaços menores, e cada pedaço é convertido numa representação vetorial (um embedding) que captura seu significado. Esses vetores ficam armazenados num índice pesquisável, geralmente um banco de dados vetorial dedicado.
Busca (acontece a cada pergunta). A pergunta recebida também é convertida num vetor usando o mesmo modelo de embedding, e o sistema busca no índice os pedaços cujos vetores estão mais próximos do vetor da pergunta — ou seja, mais próximos em significado, não só em sobreposição de palavras-chave.
Geração. Os pedaços recuperados são inseridos no prompt junto com a pergunta original, e o modelo de linguagem gera sua resposta ancorada nesse texto recuperado em vez de puramente na memória.
3. Onde os embeddings entram
Embeddings são a peça que torna possível a parte de "busca por significado" da recuperação — a mesma ideia coberta numa lição anterior de IA Watch sobre embeddings. Um pipeline de RAG é essencialmente: embeddings pra busca, mais uma etapa de geração em cima do que a busca retornar. Se o modelo de embedding for fraco ou mal ajustado ao domínio (por exemplo, usar um modelo de embedding genérico em texto jurídico denso), a qualidade da busca sofre não importa quão bom seja o modelo de linguagem em si — o modelo só consegue responder tão bem quanto o material que de fato recebeu.
4. Por que não simplesmente fazer fine-tuning ou usar uma janela de contexto maior?
Abordagem
O que faz bem
Onde falha
Fine-tuning
Ensina bem um estilo, formato ou padrão de comportamento ao modelo.
Caro e lento pra atualizar; se ajusta mal a fatos que mudam com frequência, e não dá um caminho limpo de citação.
Janela de contexto maior (colocar tudo no prompt)
Simples, não precisa de sistema de busca separado pra bases de conhecimento pequenas.
Não escala pra coleções grandes de documentos; custa mais tokens por pergunta; modelos ainda podem perder detalhes enterrados no meio de um contexto muito longo.
RAG
Escala pra bases de conhecimento grandes e atualizadas com frequência; respostas continuam rastreáveis até um documento de origem; não precisa retreinar quando documentos mudam.
Só é tão bom quanto a etapa de busca — pedaços irrelevantes ou ausentes levam a respostas erradas ou incompletas, não importa quão bom seja o modelo.
5. Prós, contras e modos de falha
Prós
Mantém respostas ancoradas numa fonte real e inspecionável em vez da memória interna (e às vezes errada) do modelo.
Atualizar a base de conhecimento significa só reindexar documentos — sem retreinar.
Reduz alucinação em informação específica de domínio ou que muda rápido, quando a busca funciona bem.
Contras / modos de falha
Lixo entra, lixo sai: se a etapa de busca retorna pedaços irrelevantes, o modelo frequentemente ainda vai tentar responder usando eles, produzindo uma resposta errada com confiança.
A estratégia de divisão em pedaços importa — divida demais e você perde contexto, divida muito grande e texto irrelevante dilui o que de fato importa no prompt.
Não elimina a alucinação por completo; o modelo ainda pode ler mal ou aplicar mal o texto recuperado, especialmente quando pedaços recuperados diferentes se contradizem.
6. Um exemplo genérico
Imagine um assistente de suporte interno pra um produto de software genérico. Em vez de fazer fine-tuning de um modelo em cada artigo de ajuda já escrito, o time indexa todos os artigos de ajuda como embeddings. Quando um usuário pergunta "por que minha exportação continua falhando", o sistema transforma essa pergunta em embedding, recupera os dois ou três artigos de ajuda cujo conteúdo está mais próximo em significado (talvez um sobre limite de tamanho de arquivo, outro sobre permissões), e passa isso pro prompt do modelo. O modelo responde usando esses artigos específicos e pode apontar de volta pra eles — em vez de chutar a partir do que ele por acaso aprendeu sobre "erros de exportação em geral" durante o treinamento.
7. O ponto principal
A ideia central: RAG não torna um modelo mais conhecedor em geral — ele torna a resposta do modelo só tão boa quanto o que foi recuperado pra aquela pergunta específica. A qualidade de um sistema de RAG vive quase inteiramente na etapa de busca (divisão em pedaços, qualidade do embedding, relevância da busca), não em trocar pra um modelo de linguagem mais inteligente.
Fontes
Databricks — "What is Retrieval Augmented Generation (RAG)?" (acessado em agosto de 2026)
IBM — "What is RAG (Retrieval Augmented Generation)?" (acessado em agosto de 2026)
Medium (Sahin Ahmed) — "What is Retrieval-Augmented Generation (RAG) in LLM and How it works?" (acessado em agosto de 2026)
Compartilhar:
Newsletter
Saiba o que a IA está criando pra você. Não fique por fora.
Seja avisado quando eu postar uma imersão ou lição nova. Sem spam, só posts novos.