O que é RAG (Retrieval-Augmented Generation)?

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, é 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

As duas fases

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 — 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 — 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.

// 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.

// 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.

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

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). 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: 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 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

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 para os originais; os vetores dos chunks vivem como campos de array ao lado deles, indexados para busca por similaridade; as ACLs 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 chamando a API do modelo com a chave mantida no servidor, 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.