RAG (Retrieval-Augmented Generation) une busca em documentos com geração de texto por LLM. O sistema recupera trechos relevantes de uma base (PDFs, wikis, tickets) e os coloca no contexto do modelo antes de responder. Assim o modelo se apoia em dados reais em vez de inventar.
O pipeline clássico tem quatro etapas: ingestão (chunking + embeddings), indexação em banco vetorial, retrieval na hora da pergunta e geração condicionada aos trechos recuperados. A qualidade do retrieval costuma importar mais do que trocar de modelo.
Onde RAG brilha
- Assistentes internos com políticas, runbooks e contratos.
- Suporte ao cliente que precisa citar FAQs e manuais atualizados.
- Busca em documentação técnica que muda toda sprint.
O que costuma dar errado
Chunks mal dimensionados, ausência de filtros por permissão ou data, e zero métrica de recall. Muitos times olham só a resposta final do LLM e descobrem tarde que o retriever está trazendo lixo. Avalie retrieval e geração separadamente.
No hub há artigos sobre avaliação de RAG, hybrid search e checklists para produção — use-os como ponto de partida antes de escalar.
Na prática, times que colocam RAG em produção separam a avaliação em duas partes: qualidade do retrieval (os trechos certos vieram?) e qualidade da geração (a resposta usou bem esses trechos?). Ferramentas de ranking híbrido (vetor + palavra-chave) costumam melhorar o recall em documentos técnicos e em português.
Outro ponto crítico é o ciclo de vida dos dados: quando um manual muda, o índice precisa refletir isso. Pipelines de reindexação incremental e versionamento de embeddings evitam respostas baseadas em política antiga. Se o seu caso envolve multi-tenant, filtre sempre por tenant_id no retrieval — similaridade semântica não substitui autorização.