---
term: 'RAG (Retrieval-Augmented Generation)'
seoTitle: 'RAG (Retrieval-Augmented Generation): Pipeline, ACLs e vs. Fine-Tuning'
headline: 'O que é RAG (Retrieval-Augmented Generation)?'
slug: rag
category: ai-modern-stack
shortDefinition: 'RAG é uma técnica que recupera documentos no momento da consulta e os adiciona ao prompt, para que o LLM responda a partir de dados, e não de memória.'
relatedTerms:
  - vector-database-embeddings
  - api-key-security
  - cloud-code-serverless-functions
  - access-control-lists-acl
contrastsWith:
  - vector-database-embeddings
aboutTerms:
  - 'Retrieval-Augmented Generation'
  - 'Chunking'
  - 'Grounding'
faq:
  - question: 'O que é RAG em IA?'
    answer: 'Uma técnica em que o seu app busca documentos relevantes numa base de conhecimento e os cola no prompt do LLM, para que a resposta se apoie em dados reais, atuais ou privados — e não na memória congelada do treinamento. É a prova com consulta, em contraste com a prova de livro fechado de um LLM puro.'
  - question: 'Para que serve o RAG?'
    answer: 'Ele corrige três lacunas do LLM de uma vez, sem retreinar nada: a alucinação (ancorando cada resposta em texto recuperado), o corte de treinamento (buscando dados atuais) e o fato de o modelo nunca ter visto seus documentos privados. E como as fontes são conhecidas, a resposta pode citá-las.'
  - question: 'Como o RAG funciona?'
    answer: 'Em duas fases. Offline: carregar os documentos, dividi-los em chunks, gerar o embedding de cada chunk e armazenar tudo num índice. Online: gerar o embedding da pergunta do usuário, recuperar os chunks mais similares, adicioná-los ao prompt e deixar o modelo gerar uma resposta fundamentada nesse contexto.'
  - question: 'Qual é a diferença entre RAG e fine-tuning?'
    answer: 'Eles mudam coisas diferentes. O RAG injeta conhecimento — fatos, atualidade, documentos privados — no momento da consulta. O fine-tuning muda comportamento — estilo, formato, raciocínio de domínio — fixado durante o treinamento. O fine-tuning ensina como responder; o RAG fornece sobre o que responder; assistentes especializados costumam usar os dois.'
  - question: 'Janelas de contexto longas tornam o RAG obsoleto?'
    answer: 'Não. Mesmo com janelas de milhões de tokens, enfiar tudo no prompt custa muito mais por consulta e roda mais devagar, e estudos mostram a acurácia degradando bem antes de a janela encher — o "context rot". Atualidade e controle de acesso continuam exigindo recuperação. O padrão de 2026 é híbrido: recuperar um subconjunto relevante e raciocinar sobre ele com um modelo de contexto longo.'
  - question: 'O que é chunking e por que importa?'
    answer: 'É dividir documentos em pedaços recuperáveis — e a qualidade da recuperação depende fortemente disso. Chunks grandes demais diluem a relevância e desperdiçam orçamento de prompt; pequenos demais perdem o contexto. Uma linha de base comum é algumas centenas de tokens com sobreposição, embora a divisão sensível à estrutura (por título, parágrafo ou bloco de código) costume superar tamanhos fixos.'
  - question: 'O RAG elimina as alucinações?'
    answer: 'Reduz; não elimina. O modelo ainda pode ler mal o contexto recuperado, misturar trechos antigos com novos ou responder com confiança a partir de recuperações ruins. E a maior parte das "alucinações de RAG" são falhas de recuperação disfarçadas — os chunks errados foram buscados, então a resposta fundamentada se fundamenta na coisa errada.'
  - question: 'Como impedir que o RAG vaze documentos que o usuário não deveria ver?'
    answer: 'Filtre a recuperação por permissões, não apenas por similaridade. A busca vetorial ranqueia por significado e não sabe nada sobre quem pode ler o quê; armazene metadados de controle de acesso junto de cada chunk e restrinja a consulta aos documentos que o usuário solicitante pode ver — antes da seleção top-k, não depois.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)'
    url: 'https://arxiv.org/abs/2005.11401'
  - name: 'Retrieval-Augmented Generation for LLMs: A Survey (Gao et al.)'
    url: 'https://arxiv.org/abs/2312.10997'
  - name: 'RAGAS — evaluation metrics'
    url: 'https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/'
  - name: 'Chunking strategies for RAG — Weaviate'
    url: 'https://weaviate.io/blog/chunking-strategies-for-rag'
cta:
  title: 'RAG é trabalho comum de backend'
  text: 'Armazene documentos, indexe vetores ao lado dos seus dados, filtre a recuperação por ACL e chame o modelo a partir do Cloud Code com a chave no servidor — o Back4app fornece cada peça, menos o prompt.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-21'
translationKey: retrieval-augmented-generation-rag
---

**RAG é uma técnica que recupera documentos no momento da consulta e os adiciona ao prompt, para que o LLM responda a partir de dados, e não de memória.** Apresentado por [Lewis et al. em 2020](https://arxiv.org/abs/2005.11401), é a prova com consulta em contraste com a prova de livro fechado de um modelo puro: em vez de depender do que memorizou no treinamento, o modelo consulta o material que você fornece e responde a partir dele — fundamentado, atual, ciente do que é privado e, porque as fontes são conhecidas, *citável*. Para quem desenvolve backend, a verdade tranquilizadora por baixo do hype é que RAG não é um framework que você precisa adotar; é um for-loop que você já sabe construir.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| A jogada | Recuperar os chunks relevantes → adicionar ao prompt → gerar uma resposta fundamentada |
| As três lacunas que corrige | Alucinação · corte de treinamento · nenhum acesso aos seus dados privados |
| vs. fine-tuning | RAG fornece *conhecimento*; fine-tuning muda *comportamento* — muitas vezes os dois |
| O erro dominante | Falha de recuperação — chunks errados entram, resposta errada e confiante sai |
| A obrigação em produção | Filtrar a recuperação por [permissões](/glossary/pt/listas-de-controle-de-acesso-acl/), não só por similaridade |

## As duas fases

```text
INGESTÃO (offline, uma vez por documento)
  carregar → dividir em chunks (~centenas de tokens, com sobreposição)
       → gerar o embedding de cada chunk
       → armazenar vetor + texto + metadados de ACL num índice

CONSULTA (online, a cada pergunta)
  embedding da pergunta → busca por similaridade dos top-k chunks (em geral 5–10)
       → filtrar para o que ESTE usuário pode ler
       → aumentar o prompt com os chunks
       → o LLM gera uma resposta fundamentada neles (+ citações)
```

A fase online inteira, no servidor, em uma única função:

**JavaScript:**

```javascript
// JavaScript — Cloud Code (cloud/main.js): RAG is a for-loop, not a framework
Parse.Cloud.define('askDocs', async (req) => {
  // 1 · embed the question (LLM API key stays server-side)
  const qVec = await embed(req.params.question);

  // 2 · retrieve — similarity search, ACL-FILTERED to this user's docs
  const chunks = await vectorSearch('DocChunk', qVec, {
    limit: 6,
    aclUser: req.user, // never retrieve what the asker can't read
  });

  // 3 · augment + generate
  const context = chunks.map((c) => c.get('text')).join('\n---\n');
  return await complete(`Answer using ONLY this context:\n${context}\n\nQ: ${req.params.question}`);
  // Answer cites the retrieved chunks — grounded, and permission-safe.
});
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
final answer = await ParseCloudFunction('askDocs')
    .execute(parameters: {'question': 'What is our refund window?'});
print(answer.result); // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
let answer: String = try await Cloud.run(
    name: "askDocs",
    parameters: ["question": "What is our refund window?"])
print(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The client just asks — retrieval, grounding, and ACLs happen server-side
val params = mapOf("question" to "What is our refund window?")
val answer = ParseCloud.callFunction<String>("askDocs", params)
println(answer) // grounded in the user's own documents, with citations
// No embeddings, no vector math, no LLM key on the device — RAG's backend
// is ordinary backend work: store docs, index vectors, query, call the model.
```

```mermaid
flowchart LR
  accTitle: Pipelines de ingestão e consulta do RAG
  accDescr: Na fase de ingestão, os documentos são carregados, divididos em chunks, transformados em embeddings e armazenados com metadados de controle de acesso num índice vetorial. Na fase de consulta, a pergunta do usuário vira embedding, os chunks similares são recuperados e filtrados pelas permissões do usuário, o prompt é aumentado com eles e o modelo gera uma resposta fundamentada com citações.
  subgraph Ingest["Ingestão — offline"]
    D["Documentos"] --> CH["Chunk"] --> EM["Embedding"] --> IDX[("Índice vetorial<br/>+ metadados de ACL")]
  end
  subgraph Query["Consulta — online"]
    Q["Pergunta"] --> QE["Embedding"] --> R["Recuperar top-k"]
    IDX --> R
    R --> F["Filtrar pela ACL do usuário"] --> AUG["Aumentar o prompt"] --> G["Gerar resposta<br/>fundamentada"]
  end
```

## Por que RAG: as três lacunas

Um LLM puro tem três fraquezas estruturais, e o RAG ataca todas sem retreinar. **Alucinação** — modelos respondem com confiança sabendo ou não a resposta; ancorar cada afirmação em texto recuperado (o tal *grounding*) dá ao modelo algo verdadeiro para dizer. **O corte de treinamento** — o conhecimento do modelo congela na data do treinamento; a recuperação (*retrieval*) busca os dados de hoje. **Dados privados** — o modelo nunca viu seus documentos; a recuperação é a forma de ele lê-los no momento da consulta. O bônus que modelos de livro fechado não oferecem: como os chunks recuperados são conhecidos, a resposta pode **citar as fontes** como notas de rodapé — a maior vantagem de confiança que o RAG tem.

## RAG vs. fine-tuning

| | RAG | Fine-tuning |
| --- | --- | --- |
| Muda | *Conhecimento* — o que o modelo sabe | *Comportamento* — como ele responde |
| Velocidade de atualização | Instantânea — adicione um documento | Retreinar para mudar |
| Atualidade | Sempre atual | Congelado no treinamento |
| Citações | Sim — as fontes são conhecidas | Não |
| Formato do custo | Recuperação + tokens por consulta | Treinamento antecipado |
| Melhor para | Fatos, docs privados, mudança | Estilo, formato, raciocínio de domínio |

Eles não são rivais: o fine-tuning ensina ao modelo *como* responder, o RAG fornece *sobre o que* responder, e um assistente especializado de domínio frequentemente usa os dois — uma voz ajustada por fine-tuning respondendo a partir de uma base de conhecimento recuperada.

## O RAG morreu? A questão do contexto longo, respondida

O tratamento honesto que as páginas genéricas evitam. Janelas de contexto agora chegam a milhões de tokens, alimentando o argumento recorrente de "só enfiar tudo no prompt". Três fatos mantêm a recuperação viva. **Custo e latência:** pagar para processar um contexto gigante em *cada* consulta é dramaticamente mais caro e mais lento do que buscar a fatia relevante — ordens de magnitude, em escala. **Context rot:** estudos ao longo de 2025 encontraram a acurácia dos modelos degradando bem antes de a janela encher — fatos relevantes soterrados num contexto enorme passam despercebidos, então uma janela maior não é uma resposta confiavelmente melhor. **Atualidade e controle de acesso:** um mega-prompt estático fica obsoleto no instante em que os dados mudam e é cego para quem pode ler o quê. O consenso de 2026 não é "RAG ou contexto longo", e sim *os dois* — recuperar um subconjunto generoso, relevante e filtrado por permissões, e então raciocinar sobre ele com um modelo de contexto longo. Contexto longo puro só serve para corpora pequenos, estáveis e não sensíveis.

## A recuperação é onde o RAG falha

O enquadramento que reorganiza como você depura um sistema de RAG: **lixo recuperado é lixo gerado com confiança.** A maioria das falhas atribuídas ao modelo são falhas de recuperação fantasiadas de geração — os chunks errados foram buscados, então uma resposta perfeitamente fiel se fundamenta no material errado. Isso torna duas variáveis as que de fato movem a qualidade. **Chunking:** pedaços grandes demais diluem a relevância e queimam orçamento de prompt; pequenos demais perdem o contexto que lhes dava sentido — a divisão sensível à estrutura (por título, parágrafo, bloco de código) costuma superar tamanhos fixos ([as estratégias importam](https://weaviate.io/blog/chunking-strategies-for-rag)). **Recuperação híbrida:** combine busca por palavra-chave (termos exatos, nomes, IDs) com busca vetorial (significado) e depois *re-ranqueie* os candidatos mesclados com um modelo de relevância mais forte antes do prompt — recall dos dois lados, precisão do re-ranker. E meça as duas metades separadamente, no vocabulário do [RAGAS](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/): métricas de recuperação (buscamos os chunks certos?) versus fidelidade (cada afirmação é sustentada pelo que buscamos?) — porque elas falham de forma independente e se corrigem de formas diferentes.

## A lacuna de segurança que ninguém menciona

A similaridade vetorial ranqueia por significado e não sabe *nada* sobre permissões — o que torna um RAG ingênuo uma máquina de vazar dados. Coloque os documentos de uma empresa num índice único sem metadados de acesso e a pergunta de qualquer usuário pode recuperar qualquer documento, porque o relatório financeiro e a dúvida do estagiário são apenas pontos vizinhos no espaço vetorial. Filtrar depois da recuperação também não resolve: descartar os chunks proibidos após a seleção top-k tanto vaza a existência deles quanto quebra o contrato do top-k (você pediu seis e recebeu dois). O padrão correto: **armazenar metadados de [ACL](/glossary/pt/listas-de-controle-de-acesso-acl/) com cada chunk e restringir a recuperação ao conjunto permitido do usuário solicitante *antes* do ranqueamento por similaridade** — recuperação filtrada por permissão, não exibição filtrada por permissão. O parâmetro `aclUser` das abas de código é exatamente isso, e é a diferença entre uma demo e um sistema que você pode colocar em produção.

## Casos de uso comuns

- **Chat de suporte e conhecimento** — responder a partir dos docs reais da empresa, com citações, atualizado até a última ingestão.
- **Busca em corpora privados** — jurídico, médico, wikis internas: recuperação por significado que a caixa de palavras-chave nunca entregou.
- **Assistentes com escopo por cliente** — os dados de cada usuário, filtrados por ACL para que a recuperação nunca cruze a fronteira de um tenant.
- **Análises fundamentadas** — perguntas respondidas a partir de registros vivos, e não do chute desatualizado de um modelo.
- **Documentação e onboarding** — um modelo que cita o manual em vez de improvisá-lo.

## Você realmente precisa de RAG? Matriz de decisão

| Situação | Escolha |
| --- | --- |
| O conhecimento é público, estável e já está no modelo | Prompt puro — sem pipeline |
| O corpus cabe no prompt e raramente muda | Cole no prompt (com prompt caching) |
| Conhecimento grande, privado ou em mudança | RAG — a casa dele |
| O modelo precisa se *comportar* diferente | Fine-tuning (talvez junto de RAG) |
| As respostas precisam citar fontes | RAG — as citações vêm de graça |
| Dados multiusuário com permissões | RAG com recuperação filtrada por ACL — obrigatório |

## Limitações e trade-offs

- **RAG reduz a alucinação; não a remove.** A fidelidade precisa ser medida, não presumida — o modelo ainda pode ler mal um contexto bom.
- **A qualidade mora na recuperação.** A maior parte do esforço de engenharia — chunking, busca híbrida, re-ranking — fica antes do modelo, onde estão os ganhos.
- **Embeddings têm versão.** Troque o modelo de embedding e cada vetor armazenado precisa ser regenerado; re-embeddar um corpus grande é uma migração de verdade.
- **Ele adiciona partes móveis.** Pipelines de ingestão, um índice para manter, tokens e latência extras por consulta — custo real que um corpus pequeno e estável pode não justificar.
- **Permissões não vêm de graça.** A recuperação filtrada por ACL é o trabalho de segurança estrutural — a parte que as demos pulam e os incidentes redescobrem.

## RAG no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A afirmação de que "RAG é um for-loop" aqui é literal: documentos são objetos comuns, com [armazenamento de arquivos](/glossary/pt/api/) para os originais; os vetores dos chunks vivem como campos de array ao lado deles, [indexados](/glossary/pt/indice-de-banco-de-dados/) para [busca por similaridade](/glossary/pt/banco-de-dados-vetorial/); as [ACLs](/glossary/pt/listas-de-controle-de-acesso-acl/) que já governam cada consulta viram o filtro de permissão da recuperação *de graça* — a mesma regra que impede um usuário de ler os registros de outro impede o retriever de buscá-los; e a orquestração — embedding, recuperação, aumento do prompt, geração — é uma [função de Cloud Code](/glossary/pt/cloud-code-funcoes-serverless/) chamando a [API do modelo com a chave mantida no servidor](/glossary/pt/seguranca-de-chaves-de-api/), exatamente como as abas de código mostram. Sem framework, sem um serviço vetorial separado para proteger, sem chave de LLM no dispositivo — RAG deixa de ser um projeto de IA e vira engenharia de backend que você já sabe fazer.