O pipeline RAG ponta-a-ponta
As duas metades, ingestão e consulta, e como elas se encaixam.
5 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Nas três aulas anteriores você aprendeu os ingredientes: por que RAG existe, como embeddings funcionam e como fazer chunking sem destruir o contexto. Agora vamos montar o prato inteiro, o pipeline ponta-a-ponta, com ingestão offline e consulta online lado a lado, para você enxergar onde cada decisão anterior encaixa e onde latência e custo aparecem na conta.
Pipeline RAG: ingestão (offline) e consulta (online)
Duas metades independentes. A ingestão roda sob demanda ou em schedule. A consulta roda em tempo real a cada pergunta do usuário.
- Fontes · S3, web, DB
- Loader · parse + clean
- Chunker · strategy + overlap
- Embedding Model · Titan / Cohere
- Vector Store · upsert + metadados
- Usuário · pergunta
- Embedding Model · mesmo modelo
- Vector Store · busca top-k
- Context Builder · rank + montar prompt
- LLM · Bedrock / Claude
- Resposta · + citações
A metade offline: ingestão
A ingestão não precisa ser rápida, ela precisa ser correta e reproduzível. O fluxo começa no loader, que lê a fonte (PDF, HTML, banco de dados, S3) e entrega texto limpo. O chunker divide esse texto usando a estratégia que você escolheu na Aula 03, tamanho, overlap, fronteiras semânticas. Cada chunk vira input para o modelo de embedding, que devolve um vetor de alta dimensão. Esse vetor, junto com os metadados do chunk (fonte, data, seção, ID do documento), é gravado no vector store.
Dois pontos críticos aqui:
Consistência de modelo. O modelo de embedding usado na ingestão deve ser exatamente o mesmo usado na consulta. Trocar o modelo significa reindexar tudo, sem exceção. Guarde o nome e a versão do modelo como parte do schema do índice.
Metadados não são opcionais. Sem metadados você não consegue filtrar, rastrear a origem de uma resposta nem fazer reindexação seletiva. Grave pelo menos: source_uri, chunk_index, doc_updated_at, section. Você vai agradecer na Aula 06 (filtros e roteamento) e na Aula 11 (citações).
Custo nessa etapa vem do modelo de embedding (por token) e do armazenamento no vector store. Latência não importa aqui, ingestão é assíncrona. O que importa é throughput e idempotência: se o job rodar duas vezes no mesmo documento, o índice não deve duplicar.
A metade online: consulta e o conceito de top-k
A consulta precisa ser rápida, o usuário está esperando. O fluxo começa com o embed da pergunta: o mesmo modelo de embedding transforma a query em um vetor. O vector store executa uma busca de vizinhos mais próximos e devolve os k chunks mais similares: esse é o top-k.
Por que top-k importa tanto? É um trade-off direto entre recall e ruído:
- k pequeno (ex: 3): contexto limpo, menor custo de tokens no LLM, mas você pode perder informação relevante que ficou fora.
- k grande (ex: 20): maior chance de capturar o chunk certo, mas o prompt fica enorme, o LLM pode se perder no meio do contexto, e o custo sobe.
Na prática, k entre 5 e 10 é um ponto de partida razoável. Você vai calibrar isso na Aula 08 (avaliação), medindo recall e faithfulness com conjuntos de teste reais.
Depois do top-k, o context builder monta o prompt: instrução do sistema + chunks recuperados (com suas referências) + pergunta do usuário. O LLM gera a resposta, idealmente citando as fontes dos chunks usados.
Latência nessa etapa se distribui assim: embed da query (~50–150 ms), busca vetorial (~20–100 ms), e geração do LLM (dominante, centenas de ms a segundos dependendo do modelo e do tamanho do output). Custo vem dos tokens de entrada (contexto + pergunta) e saída do LLM, mais a chamada de embedding.
Na prática, o erro que vejo mais em primeiros pipelines RAG é tratar ingestão e consulta como um único processo acoplado, rodar o embed da pergunta com o mesmo job que indexa os documentos, ou pior, reindexar tudo a cada consulta. Separe as duas metades desde o início: ingestão é um job assíncrono, consulta é um serviço síncrono. Essa separação não é só arquitetural, ela define como você escala, monitora e cobra cada parte de forma independente. Um bug na ingestão não pode derrubar a consulta.
Reindexação: quando os dados mudam
Documentos mudam. Políticas são atualizadas, preços mudam, produtos são descontinuados. Se o vector store não reflete o estado atual das fontes, o LLM vai gerar respostas desatualizadas com total confiança, e isso é pior do que não responder.
Existem três padrões para lidar com reindexação:
Full reindex: apaga e reconstrói o índice inteiro. Simples, confiável, mas caro e lento para bases grandes. Adequado para corpora pequenos ou mudanças estruturais (ex: troca de modelo de embedding).
Incremental upsert: detecta documentos novos ou modificados (via hash, updated_at ou event-driven via S3 notifications / EventBridge) e reprocessa só eles. Mais complexo, mas escala bem. Exige que cada chunk tenha um ID determinístico baseado na fonte e no índice do chunk, assim o upsert sobrescreve o chunk antigo sem duplicar.
Soft delete + versioning: mantém versões antigas marcadas como inativas, útil quando você precisa de auditoria ou rollback. Aumenta o custo de armazenamento, mas dá rastreabilidade.
Minha recomendação padrão: comece com full reindex em schedule (ex: diário), implemente incremental upsert quando o volume ou a frequência de mudanças tornar o full reindex proibitivo. Não otimize antes de medir.
Na AWS, S3 Event Notifications + Lambda ou EventBridge Pipes são o padrão natural para disparar reindexação incremental quando um documento é atualizado no bucket de origem.
Ordene a consulta RAG (online)
Da pergunta à resposta com fontes.
- 1Montar o contexto com os trechos
- 2Buscar os top-k trechos no vector store
- 3Gerar o embedding da pergunta
- 4Gerar a resposta com citações
O que fixar desta aula
Ingestão vs. Consulta: características de cada metade
| Característica | Ingestão (offline) | Consulta (online) |
|---|---|---|
| Quando roda | Schedule ou evento (S3, EventBridge) | A cada pergunta do usuário |
| Requisito principal | Throughput e idempotência | Baixa latência |
| Maior custo | Embedding por token (volume de docs) | Tokens de entrada/saída do LLM |
| Falha tolerável? | Sim, retry assíncrono, sem impacto ao usuário | Não, falha visível ao usuário imediatamente |
| Escala com | Volume e frequência de atualização dos docs | Número de usuários simultâneos |
Dúvidas frequentes sobre o pipeline
Posso usar modelos de embedding diferentes para documentos de domínios distintos?
Sim, mas cada modelo precisa de seu próprio índice separado no vector store. Na consulta, você precisa saber qual índice usar (roteamento por domínio, tema da Aula 06). Nunca misture vetores de modelos diferentes no mesmo índice; as distâncias não são comparáveis.
O que acontece se eu aumentar o top-k mas o LLM tiver uma janela de contexto pequena?
Você vai truncar o contexto ou receber erro. A solução é calcular o tamanho médio dos chunks em tokens e garantir que k × chunk_tokens caiba na janela do modelo com margem para a instrução e a resposta. Reranking (Aula 05) ajuda a selecionar os melhores k antes de montar o prompt.
Preciso reindexar tudo se mudar só um documento?
Não, se você implementou upsert com IDs determinísticos por chunk. Reprocesse só os chunks do documento alterado e faça upsert no índice. O restante do índice permanece intacto. Full reindex só é obrigatório quando você troca o modelo de embedding.
Fechando o Módulo 1
Com esta aula você tem o mapa completo do RAG: sabe o que acontece em cada etapa, onde o dinheiro vai, onde a latência aparece e o que quebra quando os dados mudam. O Módulo 1 foi sobre fundamentos, e fundamentos sólidos são o que separa um protótipo que impressiona numa demo de um sistema que funciona em produção. O Módulo 2 começa pela qualidade da recuperação: busca híbrida, reranking e filtros por metadados. Porque recuperar os chunks certos é a única coisa que o LLM não consegue consertar por você.