Playbook: RAG em Produção: O Checklist de 15 Itens Antes de Ir pro Ar

A maioria dos times trata RAG como se fosse uma chamada de API com um passo extra. Não é. RAG é um pipeline de dados com pelo menos seis estágios sequenciais, e cada estágio tem seus próprios modos de falha silenciosa. Quando o sistema responde errado, a culpa instintiva vai para o LLM. Na prática, o LLM é frequentemente a parte mais confiável do sistema.

Pense assim: o LLM só pode responder com base no que você passou no contexto. Se os chunks recuperados estão errados, incompletos, duplicados ou fora de ordem, o modelo vai fazer o melhor que pode com lixo, e isso parece alucinação, mas é garbage-in, garbage-out clássico. A estimativa que circula na comunidade, e que bate com o que eu vejo em campo, é que cerca de 80% dos casos de resposta incorreta em RAG têm origem na fase de recuperação: chunk errado, threshold de similaridade mal calibrado, ausência de filtro por tenant, ou simplesmente embedding que não captura o domínio.

O modelo mental correto é: você está construindo um sistema de busca com um gerador de linguagem natural na ponta. Isso muda completamente as prioridades. Antes de ajustar temperatura, antes de trocar de modelo, antes de fazer prompt engineering sofisticado, conserte a busca. Meça recall. Meça precisão. Só depois suba na pilha.

No contexto AWS, isso significa tratar o Amazon OpenSearch Serverless (ou outro vector store) como um componente de dados de primeira classe, com o mesmo rigor que você aplicaria a um banco relacional em produção: versionamento de índice, estratégia de reindexação, monitoramento de deriva de distribuição, e testes de regressão quando você troca o modelo de embedding.

Organizo os 15 itens em cinco grupos porque cada grupo tem um perfil de falha diferente e um dono diferente dentro do time.

Grupo 1: Ingestão é onde a maioria dos problemas nasce e onde menos gente olha depois do deploy inicial. Chunking ruim contamina o índice inteiro. Metadados ausentes eliminam a possibilidade de filtros eficientes. Duplicatas inflam o índice e distorcem scores de similaridade. E sem versionamento de índice, você não consegue fazer rollback quando um novo modelo de embedding quebra a qualidade.

Grupo 2: Recuperação é o coração do sistema. A decisão entre busca puramente semântica e busca híbrida (semântica + BM25 + reranking) tem impacto direto e mensurável em recall e precisão. Top-k mal calibrado ou ausência de filtro por tenant são vetores de vazamento de informação em sistemas multi-tenant, um risco de segurança real, não teórico.

Grupo 3: Geração é onde o LLM entra, e onde as pessoas passam tempo demais. Os itens aqui são mais simples do que parecem: citar a fonte no output (rastreabilidade), ter uma resposta válida de 'não sei' quando o contexto não suporta a resposta (evitar confabulação), e usar structured output quando o downstream precisa parsear a resposta.

Grupo 4: Avaliação é o grupo mais negligenciado em projetos que conheço. Sem um dataset de avaliação com ground truth, você está voando cego. Sem testes de regressão, cada troca de modelo de embedding ou LLM é um salto de fé. O Bedrock Evaluation oferece métricas de faithfulness e relevância que podem ser integradas a um pipeline de CI/CD.

Grupo 5: Guardrails e Custo fecha o ciclo. PII no contexto recuperado é um problema de compliance, não de UX. Prompt injection via documentos maliciosos é um vetor de ataque real. E custo por consulta não medido é o caminho mais rápido para uma surpresa desagradável no fim do mês, especialmente com reranking e múltiplas chamadas de embedding somando tokens.

Quando você roda o dataset de avaliação e vê uma regressão, o instinto é ir direto para o LLM ou para o prompt. Na maioria das vezes, esse é o lugar errado para começar. Sigo um protocolo de diagnóstico em camadas:

Primeiro, isole o estágio. Meça context recall separadamente de faithfulness. Se context recall caiu mas faithfulness está estável, o problema é na recuperação, chunking, embedding, threshold de similaridade, ou filtros. Se faithfulness caiu mas context recall está ok, aí sim o problema pode ser no prompt ou no modelo.

Segundo, verifique se houve mudança de distribuição nos documentos. Documentos novos com estrutura diferente, terminologia nova, ou idioma diferente podem degradar a qualidade do embedding sem nenhuma mudança de código. Monitore a distribuição dos scores de similaridade ao longo do tempo, uma queda no score médio dos top-1 chunks é um sinal precoce.

Terceiro, antes de trocar de modelo, ajuste os parâmetros de recuperação. Mudar o threshold de similaridade mínima, ajustar os pesos de fusão híbrida, ou calibrar o top-k frequentemente resolve regressões sem o custo e risco de uma troca de modelo. Trocar de modelo de embedding implica reindexar tudo, é uma operação cara e que exige os testes de regressão do item #13.

Quarto, mantenha um log de decisões de avaliação. Cada vez que você aceita uma regressão em uma métrica em troca de melhora em outra, documente. Isso evita que a equipe reverta decisões já tomadas e cria um histórico de trade-offs que é valioso quando o sistema cresce.