# Design Doc: Plataforma RAG Enterprise com Avaliação Contínua e Guardrails no Bedrock

Este documento descreve a arquitetura de uma plataforma RAG enterprise construída sobre Amazon Bedrock, cobrindo recuperação semântica, avaliação contínua de qualidade, guardrails de segurança e controle de custo. O design prioriza rastreabilidade, operabilidade e contenção de risco em ambientes regulados, sem abrir mão de latência aceitável para usuários finais.

- URL: https://fernando.moretes.com/studies/design-doc-enterprise-rag-guardrails

- Markdown: https://fernando.moretes.com/studies/design-doc-enterprise-rag-guardrails/study.md?lang=pt

- Type: Design Doc / RFC

- Company: Enterprise RAG (cenário)

- Domain: IA

- Date: 2026-02-05

- Tags: RAG, Bedrock, guardrails, evaluation, enterprise-ai, AWS, cost-control, security

- Reading time: 10 min

---

Construir um sistema RAG que funcione em produção num ambiente enterprise não é o mesmo que fazer um notebook funcionar. Latência, custo, alucinação, vazamento de dados e auditoria são problemas de engenharia reais — e cada um deles exige uma decisão arquitetural deliberada.

## O Problema

Organizações enterprise estão sob pressão para disponibilizar capacidades de linguagem natural sobre suas bases de conhecimento internas — documentos regulatórios, manuais técnicos, políticas de RH, contratos. A abordagem mais direta é Retrieval-Augmented Generation (RAG): dado uma pergunta do usuário, recuperar fragmentos relevantes do corpus e fornecê-los como contexto para um Large Language Model (LLM) gerar a resposta.

O problema é que essa abordagem, na sua forma mais simples, falha em pelo menos quatro dimensões críticas para o enterprise:

**1. Qualidade não mensurável.** Sem avaliação sistemática, não há como saber se o sistema está respondendo corretamente, se está degradando ao longo do tempo conforme o corpus muda, ou se determinadas categorias de perguntas têm desempenho consistentemente ruim. A equipe de engenharia fica cega.

**2. Ausência de guardrails.** LLMs podem vazar informações de contexto indevido, gerar conteúdo fora de escopo, ou ser induzidos por prompt injection a ignorar restrições. Em ambientes com dados sensíveis — financeiros, jurídicos, de saúde — isso é um risco de compliance, não apenas de qualidade.

**3. Custo não controlado.** Cada chamada a um LLM de fronteira tem custo por token. Sem controle de contexto, caching e roteamento inteligente, o custo escala de forma não linear com o volume de uso. Em produção, isso se torna um problema de orçamento rapidamente.

**4. Rastreabilidade insuficiente.** Auditores e times de segurança precisam saber: qual documento embasou qual resposta, qual modelo foi invocado, qual versão do prompt estava ativa, e quem fez a pergunta. Sistemas RAG naive não registram nada disso de forma estruturada.

Este documento propõe uma arquitetura que trata esses quatro problemas como requisitos de primeira classe, não como adições posteriores.

## Objetivos e Não-Objetivos

- ✅ OBJETIVO: Fornecer respostas fundamentadas em documentos internos com latência P95 < 4s para consultas síncronas
- ✅ OBJETIVO: Avaliar continuamente a qualidade das respostas usando métricas automáticas (faithfulness, relevance, answer correctness) com pipeline assíncrono
- ✅ OBJETIVO: Aplicar guardrails de conteúdo e de acesso a dados via Amazon Bedrock Guardrails antes de cada resposta ao usuário
- ✅ OBJETIVO: Controlar custo via caching semântico, roteamento por complexidade e limites de token por sessão
- ✅ OBJETIVO: Produzir trilha de auditoria completa e imutável de cada interação (usuário, query, chunks recuperados, modelo, resposta, guardrail outcome)
- ✅ OBJETIVO: Suportar múltiplos corpora com isolamento de acesso por grupo de usuários (RBAC sobre os índices vetoriais)

## Ficha Técnica do Cenário

- **Cenário:** Enterprise RAG — base de conhecimento interna (regulatório + técnico)
- **Plataforma de IA:** Amazon Bedrock (modelos: Claude 3.5 Sonnet, Titan Embeddings V2)
- **Armazenamento vetorial:** Amazon OpenSearch Serverless (coleções vetoriais)
- **Escala estimada:** ~500 usuários ativos, ~10k queries/dia, corpus de ~200k documentos
- **Região AWS:** us-east-1 (primária), com replicação de artefatos para us-west-2
- **Guardrails:** Amazon Bedrock Guardrails (PII, topic denial, grounding check)
- **Avaliação:** Pipeline assíncrono com RAGAS-style metrics via Lambda + DynamoDB + QuickSight
- **Controle de custo:** Semantic cache (ElastiCache), roteamento por complexidade, token budget por sessão
- **Conformidade:** Trilha imutável via S3 + Athena; RBAC via IAM + Cognito

## Design Proposto — Visão Geral

A arquitetura é organizada em cinco planos funcionais que operam de forma relativamente independente, comunicando-se via eventos e APIs bem definidas:

**Plano de Ingestão.** Documentos chegam via S3 (upload manual ou integração com sistemas de gestão documental). Um pipeline orientado a eventos (S3 Event → EventBridge → Step Functions) executa: extração de texto (Textract para PDFs escaneados, parsing nativo para DOCX/HTML), chunking com estratégia híbrida (fixed-size com overlap + sentence boundary detection), geração de embeddings via Bedrock Titan Embeddings V2, e indexação no OpenSearch Serverless. Metadados de acesso (qual grupo pode ver qual documento) são persistidos junto ao vetor e usados no momento da recuperação para filtrar resultados.

**Plano de Recuperação e Geração.** O caminho crítico de latência. A query do usuário passa primeiro por um verificador de cache semântico (ElastiCache + comparação de embedding com threshold configurável). Cache hit retorna diretamente, sem invocar o LLM. Cache miss segue para: (1) geração de embedding da query, (2) busca híbrida no OpenSearch (kNN + BM25 com Reciprocal Rank Fusion), (3) reranking dos top-K chunks com um modelo de cross-encoder leve, (4) montagem do prompt com contexto filtrado por RBAC, (5) invocação do LLM via Bedrock com Guardrails aplicados inline. O roteamento por complexidade decide entre Claude 3 Haiku (queries simples, factual lookup) e Claude 3.5 Sonnet (queries complexas, síntese multi-documento) — a classificação de complexidade é feita por um classificador leve antes da chamada principal.

**Plano de Guardrails.** Bedrock Guardrails é configurado com três camadas: (a) detecção e redação de PII na resposta gerada, (b) topic denial para tópicos fora do escopo do sistema (ex: aconselhamento jurídico direto, diagnóstico médico), (c) grounding check — o Bedrock verifica se a resposta é suportada pelos chunks de contexto fornecidos, bloqueando respostas que introduzem fatos não presentes no contexto (principal vetor de alucinação em RAG). Quando um guardrail é acionado, a resposta é substituída por uma mensagem de fallback padronizada e o evento é registrado com severidade e categoria.

**Plano de Avaliação Contínua.** Cada interação completa é publicada num stream Kinesis. Um consumer Lambda executa métricas assíncronas: faithfulness (a resposta é suportada pelo contexto?), context relevance (os chunks recuperados são relevantes para a query?), e answer relevance (a resposta endereça a pergunta?). Essas métricas são calculadas usando um LLM juiz (Claude 3 Haiku, mais barato) via prompts estruturados — abordagem LLM-as-judge. Resultados são persistidos no DynamoDB e agregados em dashboards QuickSight. Alertas CloudWatch disparam quando métricas caem abaixo de thresholds configurados.

**Plano de Auditoria.** Toda interação — query, chunks recuperados (com IDs e scores), prompt montado, resposta bruta, guardrail outcome, modelo invocado, latência, custo estimado em tokens — é serializada em JSON e escrita em S3 (prefixo por data/usuário/sessão). O bucket tem Object Lock habilitado (WORM) para imutabilidade. Athena provê consultas ad-hoc para investigações de compliance. CloudTrail registra todas as chamadas à API Bedrock.

## Arquitetura da Plataforma RAG Enterprise

Fluxo completo desde a ingestão de documentos até a resposta ao usuário, incluindo guardrails, avaliação assíncrona e trilha de auditoria.

### 👤 Usuários / Users

- Usuário User (user)
- Admin / Auditor (user)

### 🌐 Frontend / API Layer

- API Gateway (REST + Auth) (edge)
- Amazon Cognito (RBAC / JWT) (security)

### ⚙️ Retrieval & Generation

- RAG Orchestrator (Lambda) (compute)
- Semantic Cache (ElastiCache Redis) (data)
- OpenSearch Serverless (Vector + BM25) (data)
- Reranker (Lambda / cross-encoder) (compute)
- Complexity Router (Lambda classifier) (compute)

### 🤖 Amazon Bedrock

- Bedrock Guardrails (PII / Topic / Grounding) (ai)
- Claude 3 Haiku (simple queries) (ai)
- Claude 3.5 Sonnet (complex queries) (ai)
- Titan Embeddings V2 (query + ingest) (ai)

### 📥 Ingestão / Ingestion

- S3 Bucket (documentos brutos) (storage)
- EventBridge (S3 events) (messaging)
- Step Functions (ingest pipeline) (compute)
- Amazon Textract (OCR) (ai)

### 📊 Avaliação & Auditoria / Evaluation & Audit

- Kinesis Data Stream (interaction events) (messaging)
- Eval Pipeline (Lambda / LLM-as-judge) (compute)
- DynamoDB (eval metrics) (data)
- S3 Audit Bucket (WORM / Object Lock) (storage)
- Athena (compliance queries) (data)
- QuickSight (eval dashboards) (frontend)
- CloudWatch (alarms / metrics) (security)

### Fluxos

- user -> apigw: query HTTP
- apigw -> cognito: validar JWT
- apigw -> rag_lambda: query + claims
- rag_lambda -> cache: cache lookup
- rag_lambda -> embeddings: embed query
- rag_lambda -> opensearch: hybrid search (RBAC filter)
- opensearch -> reranker: top-K chunks
- reranker -> complexity: ranked chunks
- complexity -> llm_haiku: rota simples
- complexity -> llm_sonnet: rota complexa
- llm_haiku -> guardrails: resposta bruta
- llm_sonnet -> guardrails: resposta bruta
- guardrails -> rag_lambda: resposta filtrada
- rag_lambda -> kinesis: evento de interação
- rag_lambda -> s3_audit: log imutável
- kinesis -> eval_lambda: stream consumer
- eval_lambda -> llm_haiku: LLM-as-judge
- eval_lambda -> dynamodb: métricas eval
- dynamodb -> quicksight: dashboards
- dynamodb -> cloudwatch: alertas
- s3_audit -> athena: queries compliance
- admin -> athena: investigação
- admin -> quicksight: monitoramento
- s3_docs -> eventbridge: S3 event
- eventbridge -> stepfn: trigger ingestão
- stepfn -> textract: OCR (se PDF)
- stepfn -> embeddings: embed chunks
- stepfn -> opensearch: indexar vetores

## Decisões Críticas de Design

**Por que busca híbrida e não apenas kNN?**
Busca puramente vetorial (kNN) tem viés para similaridade semântica, mas falha em queries que requerem correspondência exata de termos técnicos, siglas, números de norma ou identificadores. BM25 complementa exatamente esses casos. Reciprocal Rank Fusion (RRF) combina os rankings sem requerer normalização de scores — uma escolha pragmática e bem estabelecida na literatura de IR. OpenSearch Serverless suporta ambos nativamente, o que evita a necessidade de um serviço adicional de busca.

**Por que reranking após a busca?**
Recuperar top-20 chunks e rerankar para top-5 antes de montar o prompt tem dois efeitos: (1) reduz o tamanho do contexto enviado ao LLM, reduzindo custo e latência, e (2) melhora a precisão do contexto, o que é o principal driver de faithfulness. O cross-encoder é computacionalmente mais caro que o bi-encoder usado para indexação, mas opera sobre um conjunto pequeno (top-20), então o custo é aceitável. Modelos como `ms-marco-MiniLM-L-6-v2` são suficientes para a maioria dos casos enterprise e podem ser servidos via Lambda com container image.

**Por que LLM-as-judge para avaliação e não métricas determinísticas?**
Métricas determinísticas como ROUGE e BLEU medem sobreposição de n-gramas, não correção semântica. Para RAG, o que importa é: a resposta é factualmente suportada pelo contexto? A resposta é relevante para a intenção da query? Essas questões requerem compreensão semântica. LLM-as-judge com prompts estruturados e few-shot examples produz avaliações com correlação alta com julgamento humano, conforme demonstrado na literatura (RAGAS, G-Eval). O custo de usar Claude 3 Haiku para avaliação assíncrona é significativamente menor que Sonnet, tornando o pipeline economicamente viável.

**Por que Object Lock no bucket de auditoria?**
Em ambientes regulados, a integridade da trilha de auditoria não pode depender de controles de acesso — um administrador comprometido poderia deletar logs. Object Lock com modo COMPLIANCE garante que nem mesmo a conta root pode deletar ou modificar objetos dentro do período de retenção configurado. Isso é um requisito não-negociável para qualquer sistema que processe dados sujeitos a regulação (LGPD, SOX, HIPAA).

**Sobre o cache semântico: threshold é crítico.**
Um threshold de similaridade muito alto (ex: 0.99) resulta em taxa de hit próxima de zero — o cache não serve para nada. Um threshold muito baixo (ex: 0.80) resulta em respostas semanticamente incorretas sendo retornadas para queries diferentes. O valor correto é empírico e depende do domínio. Recomendo começar com 0.92-0.95 e ajustar baseado em análise de falsos positivos nas primeiras semanas de produção. O cache deve ter TTL configurável por categoria de documento — documentos que mudam frequentemente devem ter TTL curto ou serem excluídos do cache.

## Alternativas Avaliadas

### Bedrock Knowledge Bases (managed RAG)

**Pros**
- Setup rápido, integração nativa com Bedrock, menos infraestrutura para gerenciar
- Suporte nativo a guardrails e citações de fontes

**Cons**
- Menor controle sobre chunking, reranking e lógica de recuperação
- Sem suporte nativo a busca híbrida ou cache semântico customizado
- Dificulta avaliação contínua granular e roteamento por complexidade

**Verdict:** Adequado para MVPs e casos com requisitos simples. Insuficiente para os requisitos de avaliação e controle de custo deste design.

### LangChain + self-managed vector DB (Pinecone/Weaviate)

**Pros**
- Máxima flexibilidade, ecossistema rico de integrações
- Suporte a múltiplos providers de LLM sem lock-in

**Cons**
- Complexidade operacional alta: mais serviços externos para gerenciar, monitorar e proteger
- Guardrails precisam ser implementados manualmente — risco de gaps
- Custo de serviços externos pode superar Bedrock em escala

**Verdict:** Preferível quando há requisito de multi-cloud ou portabilidade de LLM. Neste cenário AWS-native, adiciona complexidade sem benefício proporcional.

### Design proposto (custom RAG + Bedrock Guardrails + eval pipeline)

**Pros**
- Controle total sobre recuperação, reranking, cache e roteamento
- Guardrails gerenciados pela AWS com auditoria nativa
- Pipeline de avaliação contínua e rastreabilidade completa

**Cons**
- Maior complexidade inicial de implementação e operação
- Dependência maior de serviços AWS (trade-off de portabilidade)

**Verdict:** Escolha correta para o cenário enterprise com requisitos de avaliação, compliance e controle de custo.

## Plano de Rollout

1. **Fase 0 — Fundação (Semanas 1-2)** — Provisionamento de infraestrutura base via IaC (CDK): VPC, IAM roles, S3 buckets (docs + audit com Object Lock), OpenSearch Serverless collection, ElastiCache Redis. Configuração de Cognito com grupos de usuários e mapeamento de claims para RBAC. Habilitação de CloudTrail para Bedrock API calls.

2. **Fase 1 — Pipeline de Ingestão (Semanas 3-4)** — Implementação do Step Functions workflow: S3 trigger → Textract (condicional) → chunking Lambda → Titan Embeddings → OpenSearch indexer. Testes com corpus piloto de 5k documentos. Validação de filtros RBAC na busca. Definição da estratégia de chunking (tamanho, overlap) baseada em análise do corpus.

3. **Fase 2 — RAG Core + Guardrails (Semanas 5-7)** — Implementação do RAG Orchestrator Lambda: busca híbrida, reranker, montagem de prompt, roteamento por complexidade, invocação Bedrock com Guardrails. Configuração de Bedrock Guardrails: PII entities, topic denial list, grounding check threshold. Implementação do semantic cache com threshold inicial 0.93. Testes de carga com k6 para validar P95 < 4s.

4. **Fase 3 — Pipeline de Avaliação (Semanas 8-9)** — Implementação do Kinesis consumer e eval Lambda com prompts LLM-as-judge para faithfulness, context relevance e answer relevance. Persistência no DynamoDB e dashboards QuickSight. Configuração de alarmes CloudWatch com thresholds iniciais (faithfulness > 0.80, context relevance > 0.75). Coleta de baseline de métricas nas primeiras 2 semanas.

5. **Fase 4 — Piloto com Usuários Reais (Semanas 10-12)** — Rollout para grupo piloto de 50 usuários. Monitoramento intensivo de métricas de qualidade, latência e custo. Ajuste de threshold do cache, parâmetros de chunking e configurações de guardrails baseado em feedback real. Análise de falsos positivos nos guardrails (respostas bloqueadas indevidamente).

6. **Fase 5 — GA e Ingestão Completa do Corpus (Semanas 13-16)** — Ingestão do corpus completo (~200k documentos). Rollout para todos os usuários com feature flags por grupo. Documentação operacional e runbooks. Treinamento da equipe de operações em análise de dashboards de avaliação e resposta a alertas de qualidade.

> **Riscos e Mitigações:** **Risco 1 — Prompt Injection.** Um usuário malicioso pode tentar injetar instruções no campo de query para contornar guardrails ou exfiltrar dados de outros usuários. Mitigação: sanitização de input no API Gateway (WAF), prompt templates que isolam a query do usuário em delimitadores explícitos, e Bedrock Guardrails como última linha de defesa. Importante: guardrails não são infalíveis — testes adversariais regulares são necessários.

**Risco 2 — Deriva de qualidade silenciosa.** O corpus muda (documentos atualizados, novos adicionados), mas o pipeline de avaliação pode não detectar degradação se os thresholds de alerta forem mal calibrados. Mitigação: golden dataset de perguntas com respostas esperadas, avaliado semanalmente de forma determinística. O golden dataset deve ser mantido e expandido pela equipe de domínio.

**Risco 3 — Custo de avaliação escalando com volume.** O pipeline LLM-as-judge invoca o modelo para cada interação. Em 10k queries/dia, isso é 10k chamadas adicionais ao Haiku. Mitigação: sampling — avaliar 20-30% das interações aleatoriamente, com avaliação completa apenas para interações que acionaram guardrails ou receberam feedback negativo explícito do usuário.

**Risco 4 — Falsos positivos nos guardrails.** Um grounding check muito agressivo pode bloquear respostas corretas que usam linguagem não presente literalmente no contexto (paráfrase, inferência). Isso degrada a experiência do usuário. Mitigação: monitorar taxa de bloqueio por categoria de guardrail; ajustar threshold de grounding check baseado em análise de casos bloqueados.

**Risco 5 — Latênc

> **Minha Perspectiva Senior:** O erro mais comum que vejo em projetos RAG enterprise é tratar avaliação como um item de backlog — algo que será feito 'depois que o sistema estiver em produção'. Isso é uma armadilha. Sem um pipeline de avaliação desde o início, você não tem como saber se suas otimizações de chunking, reranking ou prompt estão melhorando ou piorando a qualidade. Você está otimizando no escuro.

Minha recomendação firme: o golden dataset e o pipeline de avaliação devem ser construídos em paralelo com o sistema de recuperação, não depois. Comece com 50-100 perguntas anotadas por especialistas de domínio. Isso é suficiente para ter um sinal de qualidade confiável nas primeiras semanas.

Sobre guardrails: Bedrock Guardrails é uma ferramenta boa, mas não é uma solução completa de segurança. Prompt injection sofisticada pode contornar guardrails baseados em classificação de conteúdo. Minha abordagem é defense-in-depth: WAF na borda, sanitização no orchestrator, guardrails no Bedrock, e monitoramento de anomalias no padrão de uso (ex: usuário fazendo 500 queries em 10 minutos é um sinal de abuso, independente do conteúdo).

Sobre custo: o roteamento por complexidade é o maior alavancador de redução de custo neste design. Na minha experiência, 60-70% das queries em sistemas enterprise são factuais simples — 'qual é o prazo para X?', 'quem é responsável por Y?' — que podem ser respondidas com Haiku a uma fração do custo de Sonnet. Investir tempo na calibração do classificador de complexidade tem retorno direto na conta de AWS.

Finalmente: documente o schema do audit log desde o dia zero. Quando o 

## Métricas de Sucesso e Targets

- **Latência P95 (caminho crítico):** < 4 segundos (cache miss); < 200ms (cache hit)
- **Faithfulness Score (LLM-as-judge):** > 0.82 média semanal (baseline a calibrar nas primeiras 4 semanas)
- **Context Relevance Score:** > 0.78 média semanal
- **Taxa de cache hit (semântico):** > 25% após 30 dias de produção (estimativa)
- **Taxa de bloqueio por guardrails (falso positivo):** < 2% das queries legítimas bloqueadas indevidamente
- **Custo por query (estimativa):** < USD 0.008 média ponderada (mix Haiku/Sonnet + embeddings + busca)
- **Cobertura de auditoria:** 100% das interações com log imutável em S3 dentro de 5 segundos
- **Disponibilidade do sistema:** > 99.5% (serverless + OpenSearch Serverless SLA)

## Veredicto

Este design resolve o problema central de sistemas RAG enterprise: a lacuna entre 'funciona no demo' e 'operável em produção com confiança'. Os quatro pilares — recuperação híbrida com RBAC, guardrails gerenciados, avaliação contínua e controle de custo — não são features opcionais; são requisitos de engenharia para qualquer sistema que processe informação sensível em escala.

A escolha de Amazon Bedrock como plataforma de IA é deliberada e defensável: Guardrails gerenciados, rastreabilidade nativa de invocações via CloudTrail, e a capacidade de trocar modelos sem reescrever infraestrutura são vantagens reais num ambiente enterprise onde o modelo 'melhor' muda a cada trimestre. O trade-off é dependência de vendor — aceitável aqui dado que o design isola a lógica de negócio (chunking, reranking, avaliação) em componentes que podem ser reaproveitados se a plataforma de IA mudar.

O risco mais subestimado neste tipo de projeto não é técnico: é a ausência de ownership da qualidade. O pipeline de avaliação só tem valor se alguém olha para os dashboards e age quando as métricas caem. Isso requer um acordo explícito sobre responsabilidades entre engenharia e o time de domínio — sem isso, 

## Referências

- [Amazon Bedrock — Product Page](https://aws.amazon.com/bedrock/)
- [Amazon Bedrock Guardrails — Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html)
- [Amazon OpenSearch Serverless — Vector Search](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html)
- [RAGAS: Automated Evaluation of Retrieval Augmented Generation](https://arxiv.org/abs/2309.15217)
- [Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)
- [Amazon Bedrock — Knowledge Bases](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html)
- [Amazon S3 Object Lock — Compliance Mode](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html)
- [G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment](https://arxiv.org/abs/2303.16634)

## Fontes do caso

- [AWS — Amazon Bedrock](https://aws.amazon.com/bedrock/)