RAG ARCHITECTURE
RAG não é retrieval.
E quanto mais trabalho nisto, mais isso fica óbvio.
No último post falei sobre isto — hoje deixo um breakdown da arquitetura completa (imagem em baixo).
A maioria dos sistemas RAG ainda funciona assim: recebe pergunta → faz search → mete no prompt → gera resposta.
Funciona para casos simples. Mas quando tens dados em SQL, grafos, documentos longos e APIs ao mesmo tempo… isto começa a partir.
O que muda numa arquitetura moderna? Primeiro, a ingestion deixa de ser “guardar embeddings e pronto.” O mesmo conteúdo é materializado em representações diferentes:
- BM25 para keyword
- dense vectors para semântica
- graph projections para relações
- temporal indexes para freshness 👉 porque diferentes perguntas precisam de formas diferentes de procurar
Segundo — e para mim o mais importante: O sistema decide antes sequer de fazer retrieval. Há uma camada de routing que analisa a query e escolhe a estratégia:
- preciso mesmo de retrieval?
- vou ao documento, ao SQL, ao grafo… ou a vários? 👉 esta decisão é o que separa um RAG básico de um que funciona em produção
Terceiro: evidence fusion. Quando tens resultados de múltiplas fontes, não podes simplesmente concatenar tudo. Tens de:
- pontuar relevância
- verificar freshness
- detectar conflitos
- garantir diversidade Este passo é provavelmente o mais subestimado em pipelines RAG. E, na prática, é onde muitas respostas falham.
Por fim, a resposta não sai às cegas. Há validação:
- groundedness
- cobertura
- detecção de alucinações
- confiança 👉 e às vezes a melhor resposta é mesmo não responder
O pipeline real é: understanding → routing → retrieval → fusion → validation → generation
RAG deixa de ser “search + LLM” e passa a ser um sistema de decisão sobre como construir contexto.
Estou a pensar transformar isto num artigo mais completo. 👉 Que parte gostavam de ver aprofundada?
- Routing? Fusion? Multi-backend?