RAG em produção: custo, latência, operação + projeto
O que separa um demo de RAG de um sistema confiável e barato em produção.
7 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.
Um demo de RAG impressiona em dez minutos. Um sistema de RAG em produção precisa funcionar no décimo milésimo request, custar o que foi prometido e ser depurável quando algo der errado. Esta aula fecha o curso com o que realmente separa os dois mundos: FinOps, latência, operação contínua, observabilidade e segurança — e um projeto guiado para você sair daqui com uma arquitetura desenhada.
FinOps de RAG: onde o dinheiro vai e como controlá-lo
O custo de um pipeline RAG vive em dois lugares completamente diferentes: ingestão e consulta.
Na ingestão, você paga por embeddings. Você faz isso uma vez (ou poucas vezes, na reindexação). Use o modelo mais barato que ainda entrega qualidade suficiente para o seu domínio — Titan Embeddings V2 da AWS é uma escolha sólida para documentos em português e inglês. O custo aqui é proporcional ao volume de texto, não ao número de usuários.
Na consulta, o custo dominante é a geração (o LLM). Cada token no contexto custa. Por isso, o top-k importa: recuperar 20 chunks e jogar todos no prompt é até três vezes mais caro do que recuperar 5 chunks bem ranqueados. Reranking paga por si mesmo quando ele evita tokens desnecessários no contexto.
Dois mecanismos cortam custo de consulta de forma expressiva:
- Cache semântico: se a pergunta de hoje é semanticamente próxima de uma feita ontem, você devolve a resposta cacheada. Amazon ElastiCache (Redis) com busca vetorial ou uma camada simples de cache por hash de embedding resolvem isso.
- Cache de recuperação: os chunks recuperados para uma query frequente podem ser cacheados separadamente da geração — útil quando você quer regenerar a resposta com um prompt diferente sem pagar pela busca novamente.
Escolha o LLM pelo binômio qualidade/custo para o seu caso: Claude Haiku para respostas rápidas e baratas, Claude Sonnet quando fidelidade e raciocínio importam mais.
Onde a latência mora no pipeline RAG
Na prática, a primeira coisa que faço em qualquer RAG que vai para usuário final é ativar streaming na geração. A latência real não muda, mas a latência percebida cai drasticamente — o usuário vê tokens chegando em menos de um segundo em vez de esperar 5s por uma resposta completa. Só depois disso eu olho para o restante da cadeia. Otimizar embed e busca sem ter streaming é polir o motor de um carro com pneus furados.
Operação contínua: reindexação, versionamento e atualização de dados
Documentos mudam. Políticas são revisadas, produtos são descontinuados, preços são atualizados. Um índice vetorial desatualizado é pior do que nenhum índice — ele responde com confiança usando informação errada.
Estratégias de atualização:
- Incremental: para cada documento novo ou modificado, delete os chunks antigos pelo
doc_ide insira os novos. Funciona bem quando a taxa de mudança é baixa e os documentos são identificáveis por ID estável. - Full reindex: recrie o índice do zero em paralelo (índice B), redirecione o tráfego via alias (OpenSearch suporta aliases nativamente), delete o índice A. Zero downtime, custo mais alto.
- Versionamento de embeddings: se você trocar o modelo de embedding, todos os documentos precisam ser reindexados. Mantenha o nome do modelo como metadado em cada chunk para saber o que precisa ser reprocessado.
No Bedrock Knowledge Bases, a sincronização incremental é gerenciada pelo serviço — você aponta para um S3 e dispara um StartIngestionJob. Para pipelines customizados, um evento S3 → Lambda → fila SQS → worker de ingestão é o padrão mais confiável.
Um detalhe que custa caro ignorar: chunk overlap e chunking strategy devem ser fixos por versão do índice. Se você mudar a estratégia de chunking sem reindexar tudo, seus chunks antigos e novos terão distribuições de embedding diferentes e a busca vai degradar silenciosamente.
Observabilidade: o que logar, rastrear e medir em produção
RAG sem observabilidade é uma caixa preta que você não consegue melhorar. Você precisa de três camadas:
1. Logs estruturados por request
Para cada consulta, persista: a query original, os chunks recuperados (com scores e doc_id), o prompt final enviado ao LLM e a resposta gerada. Sem isso, você não consegue depurar uma resposta ruim nem alimentar um pipeline de avaliação offline.
2. Traces distribuídos
AWS X-Ray ou OpenTelemetry com spans para cada etapa (embed, busca, rerank, geração) dão visibilidade de latência por componente. Você vai descobrir que 80% do tempo está na geração — mas os 20% restantes revelam surpresas.
3. Métricas de qualidade em produção
Faithfulness e relevância (vistas na Aula 08) não são só para avaliação offline. Com uma amostragem de 5–10% dos requests, você pode rodar um LLM-as-judge assíncrono e publicar métricas no CloudWatch. Se o faithfulness médio cair após uma reindexação, você sabe que algo quebrou antes que os usuários reclamem.
Um padrão prático: use Amazon CloudWatch para métricas operacionais (latência, erros, custo estimado por request), AWS X-Ray para traces, e S3 + Athena para análise de logs de qualidade. O Bedrock Knowledge Bases já emite métricas nativas no CloudWatch — aproveite.
Segurança e privacidade: os não-negociáveis
tenant_id em toda query — nunca confie só no prompt.Ordene a jornada do RAG à produção
Do protótipo a um sistema operável.
- 1Operar: observabilidade, reindexação e melhoria contínua
- 2Otimizar custo/latência (modelo, top-k, cache) e adicionar guardrails
- 3Protótipo: ingestão + busca + geração funcionando
- 4Avaliar recuperação e geração (faithfulness, relevância)
Arquitetura RAG de produção na AWS — visão de referência
Fluxo completo: ingestão de documentos (esquerda), pipeline de consulta (centro) e camadas de operação (direita). Os números nas arestas indicam a sequência de uma consulta típica.
- S3 · Documentos fonte
- Lambda · Ingestão / chunking
- Bedrock · Titan Embeddings V2
- OpenSearch Serverless · Índice híbrido (kNN + BM25)
- API Gateway · + Lambda orquestrador
- ElastiCache (Redis) · Cache semântico
- Bedrock Reranker · Cross-encoder
- Bedrock · Claude (geração)
- Bedrock Guardrails · PII / tópicos / jailbreak
- X-Ray · Traces por etapa
- CloudWatch · Métricas + alertas
- S3 + Athena · Logs de qualidade
Projeto guiado: assistente RAG de documentos corporativos na AWS
Vamos esboçar a arquitetura de um assistente que responde perguntas sobre documentos internos de uma empresa (políticas de RH, manuais técnicos, contratos). Este é o tipo de sistema que você vai construir depois deste curso.
Decisões de design:
| Dimensão | Decisão | Justificativa |
|---|---|---|
| Chunking | Hierárquico (512 tokens, overlap 10%) | Documentos longos com estrutura clara |
| Embedding | Titan Embeddings V2 | Custo baixo, qualidade boa para pt/en |
| Índice | OpenSearch Serverless | Sem gestão de cluster, escala automática |
| Busca | Híbrida (kNN + BM25) | Termos técnicos exatos + semântica |
| Reranking | Bedrock Reranker | Melhora precisão sem código extra |
| Geração | Claude Haiku (rápido) / Sonnet (complexo) | Roteamento por tipo de query |
| Guardrails | Bedrock Guardrails | Bloqueia PII e tópicos fora do escopo |
| Isolamento | Filtro por dept_id em toda query | Cada departamento vê só seus docs |
| Cache | Redis (ElastiCache) por hash de embedding | Queries repetidas sem custo de LLM |
| Observabilidade | X-Ray + CloudWatch + S3/Athena | Traces, métricas e análise de qualidade |
O que avaliar continuamente: faithfulness (o LLM inventou algo?) e context precision (os chunks recuperados eram relevantes?). Use LLM-as-judge assíncrono em 10% dos requests e publique no CloudWatch como métrica customizada RAG/Faithfulness.
Este projeto sintetiza tudo que o curso cobriu. Cada linha da tabela é uma aula.
Perguntas frequentes sobre RAG em produção
Devo usar Bedrock Knowledge Bases ou construir meu próprio pipeline?
Knowledge Bases para começar rápido e quando o caso de uso é padrão. Pipeline customizado quando você precisa de chunking especializado, lógica de roteamento complexa ou integração com fontes de dados que o KB não suporta nativamente. Os dois são produção-ready — a escolha é sobre controle vs. velocidade.
Qual o top-k ideal?
Não existe um número universal. Comece com top-k=10 na busca e top-k=5 após reranking. Meça faithfulness e context precision. Se faithfulness cai, você está trazendo chunks irrelevantes — reduza. Se relevância cai, você está cortando demais — aumente. Deixe os dados decidirem.
Como lidar com documentos que mudam com frequência?
Use ingestão incremental por doc_id com eventos S3. Para documentos críticos (preços, regulatórios), considere TTL no cache semântico mais curto ou desabilitar o cache para aquelas categorias via metadado.
RAG resolve alucinação completamente?
Não. RAG reduz alucinação ao ancorar a resposta em contexto recuperado, mas o LLM ainda pode extrapolar além do que os chunks dizem. Por isso faithfulness em produção é inegociável — você precisa medir, não assumir.
Recapitulação do curso
Toque num cartão para virar.
O que você construiu ao longo deste curso
Você começou entendendo por que LLMs precisam de RAG, passou por embeddings, chunking, busca híbrida, reranking, metadados, RAG agêntico, avaliação, Knowledge Bases, vector stores, guardrails — e chegou aqui sabendo como operar tudo isso de forma confiável e econômica. Não é teoria: cada decisão que você tomaria em um projeto real foi discutida com trade-offs explícitos. O próximo passo é o exame final. Ele testa se você realmente entendeu — não se você memorizou. Boa sorte. Você está pronto.