# RAG Agêntico com OpenSearch Serverless: Anatomia de um Padrão O padrão RAG agêntico com OpenSearch Serverless promete escala elástica e recuperação semântica sem gestão de infraestrutura — mas esconde armadilhas sérias de latência, custo e consistência que sistemas financeiros não podem ignorar. Neste artigo, desmonto a anatomia do padrão, mapeio quando ele funciona, quando falha e como configurá-lo com rigor de produção. - URL: https://fernando.moretes.com/blog/opensearch-serverless-agentic-rag-escala - Markdown: https://fernando.moretes.com/blog/opensearch-serverless-agentic-rag-escala/article.md?lang=pt - Published: 2026-05-28T08:05:00.000Z - Category: Dados & Plataformas - Tags: opensearch, rag, agentic-ai, vector-search, serverless, bedrock, financial-grade, aws - Reading time: 8 min - Source: [Next generation Amazon OpenSearch Serverless for agentic AI](https://aws.amazon.com/blogs/aws/) --- Quando a AWS anuncia uma nova geração do OpenSearch Serverless voltada para IA agêntica, o sinal técnico que importa não está no press release — está nas implicações de design que a maioria dos arquitetos vai descobrir tarde demais: cold starts que destroem SLOs de latência, custos de OCU que explodem com workloads de embedding em lote, e a ilusão de que "serverless" elimina a necessidade de modelagem de partição e controle de concorrência. Tenho 16 anos construindo sistemas financeiros sobre infraestrutura AWS e sei o que acontece quando um padrão arquitetural promissor encontra a realidade de um ambiente regulado. Este artigo desmonta o padrão RAG agêntico do zero: o problema que ele resolve, sua anatomia interna, os números que importam e, principalmente, quando você não deveria usá-lo. ## O Problema Real: Por Que RAG Clássico Quebra em Workflows Agênticos RAG clássico é um padrão de duas fases: você recupera k documentos relevantes via busca vetorial e os injeta no contexto de um LLM para geração. Funciona bem para Q&A estático sobre uma base de conhecimento estável. O problema aparece quando você adiciona agência — ou seja, quando o LLM decide iterativamente quais ferramentas chamar, quais consultas reformular e como compor a resposta final a partir de múltiplas fontes heterogêneas. Em um workflow agêntico real, a cadeia de recuperação não é linear. Um agente financeiro que responde "qual é o risco de crédito consolidado desta contraparte considerando todas as exposições dos últimos 90 dias?" pode emitir 4 a 8 chamadas de recuperação em sequência ou em paralelo, cada uma com um vetor de query diferente, cruzando índices de contratos, notícias de mercado, histórico de ratings e dados regulatórios. O índice vetorial passa a ser um componente de hot path com requisitos de latência P99 abaixo de 200ms por chamada e throughput de dezenas de queries por segundo por sessão de agente. O OpenSearch Serverless clássico tinha um problema bem documentado aqui: o modelo de OCU (OpenSearch Compute Units) escala por collection, não por query, e o cold start de uma collection inativa pode chegar a 2-3 minutos — inaceitável para qualquer agente interativo. A nova geração promete escala mais granular e menor latência de provisionamento, mas o arquiteto ainda precisa entender o modelo de capacidade para não ser surpreendido na fatura do mês. ## Anatomia do Padrão RAG Agêntico com OpenSearch Serverless Fluxo completo: ingestão de documentos, indexação vetorial, ciclo agêntico de recuperação e geração, com plano de controle e observabilidade ### 📥 Ingestão & Embedding - S3 Documentos brutos (storage) - AWS Glue Chunking + ETL (compute) - Bedrock Titan Embedding v2 (ai) ### 🔍 OpenSearch Serverless - OpenSearch Serverless Vector Collection (data) - k-NN Index HNSW / FAISS (data) - Reranker Cross-encoder (ai) ### 🤖 Camada Agêntica - Bedrock Agent Orchestrator (ai) - Tool Registry Lambda Actions (compute) - Session Memory DynamoDB (storage) ### 🔐 Segurança & Controle - IAM + ABAC Data Access Policy (security) - KMS CMK Encryption at rest (security) ### 📊 Observabilidade - CloudWatch SLO / Alarms (compute) - OpenTelemetry Trace propagation (compute) ### Fluxos - s3raw -> glue: trigger S3 event - glue -> embed: chunks de texto - embed -> oss: vetores + metadados - oss -> knn: índice HNSW - agent -> tools: tool call - tools -> knn: query vetorial - knn -> rerank: top-k candidatos - rerank -> agent: contexto rerankeado - agent -> mem: sessão / histórico - iam -> oss: data access policy - kms -> oss: CMK encryption - agent -> otel: trace span - otel -> cw: métricas / logs ## Anatomia Técnica: Cada Componente e Suas Configurações Críticas **Indexação Vetorial no OpenSearch Serverless** O coração do padrão é o índice k-NN. No OpenSearch Serverless, você escolhe entre HNSW (Hierarchical Navigable Small World) e IVF (Inverted File Index). Para workloads agênticos com alta taxa de leitura e baixa latência, HNSW com `ef_construction=512` e `m=16` oferece o melhor trade-off entre recall e latência — espere P50 de 15-30ms e P99 de 80-150ms para coleções de até 10M vetores de 1536 dimensões (Titan Embedding v2). Acima disso, o custo de memória por OCU começa a pressionar o orçamento: cada OCU suporta aproximadamente 8GB de índice em memória. **Chunking e Estratégia de Embedding** A qualidade da recuperação começa no pipeline de ingestão. Para documentos financeiros — contratos, prospectos, relatórios regulatórios — uso chunking hierárquico: chunks de 512 tokens com overlap de 64 tokens, preservando metadados estruturais (seção, página, data de vigência) como campos de filtro no índice. Isso permite hybrid search: busca vetorial + filtro por metadados, reduzindo o espaço de busca e melhorando a precisão sem aumentar k. **Reranking: O Componente Mais Subestimado** Recuperar os top-20 candidatos via k-NN e rerankeá-los com um cross-encoder (Cohere Rerank ou Bedrock Rerank) antes de injetar no contexto do agente é a diferença entre um sistema que alucina e um que cita fontes corretas. O custo de reranking é baixo (< $0.002 por 1000 documentos no Cohere) e o ganho de precisão em domínios especializados é consistentemente 15-25% em MRR@10 nos benchmarks que rodei internamente. ## Números que Importam para Dimensionamento - **~8 GB** — Índice por OCU. Capacidade de índice HNSW em memória por OpenSearch Compute Unit; planeje para 70% de utilização máxima - **< 150ms** — P99 de busca vetorial. Latência P99 realista para coleções de até 10M vetores de 1536 dims com HNSW ef_search=256 em OCUs quentes - **2–3 min** — Cold start de collection. Tempo de provisionamento de uma collection inativa; a nova geração reduz isso, mas não elimina — mantenha collections quentes via heartbeat queries ## Quando Usar Este Padrão: Os Critérios Honestos O padrão RAG agêntico com OpenSearch Serverless se encaixa bem em um conjunto específico de condições. Primeiro, **workloads com variabilidade de tráfego alta e previsibilidade baixa**: se você tem picos de uso diurno com valleys noturnos, o modelo serverless amortiza o custo de capacidade ociosa que você pagaria com um cluster OpenSearch provisionado. Para um sistema de atendimento a analistas financeiros com pico das 9h às 17h e tráfego residual à noite, a economia pode ser de 40-60% em relação a um cluster m6g.2xlarge de 3 nós. Segundo, **bases de conhecimento que crescem de forma não uniforme**: documentos regulatórios, atas de reuniões, relatórios de risco — corpora que crescem em sprints (fim de trimestre, eventos de mercado) e ficam estáveis por semanas. O modelo de ingestão assíncrona do OpenSearch Serverless, com Glue ou Lambda para processar filas SQS de novos documentos, se adapta naturalmente a esse ritmo. Terceiro, **multi-tenancy com isolamento de dados**: o OpenSearch Serverless suporta data access policies por collection com condições IAM baseadas em tags (`aws:ResourceTag/tenant`). Para uma plataforma SaaS financeira com múltiplos clientes, você pode ter uma collection por tenant ou usar namespaces de índice com políticas de acesso granulares — sem precisar operar clusters separados. O critério negativo mais importante: **não use este padrão se você tem SLOs de latência end-to-end abaixo de 500ms para a resposta completa do agente**. Um ciclo agêntico com 3-4 rounds de recuperação, reranking e geração de LLM dificilmente fica abaixo de 3-8 segundos no P50. Isso é aceitável para análise assíncrona, inaceitável para trading ou decisões de crédito em tempo real. ## Anti-Padrões: O Que Vai Quebrar em Produção - **Índice único para todos os tenants sem filtro de metadados**: Colocar documentos de múltiplos clientes no mesmo índice sem campo `tenant_id` como filtro obrigatório em todas as queries é uma falha de isolamento de dados. Em ambientes financeiros regulados, isso é um achado de auditoria, não apenas um bug de produto. - **Embeddings gerados no momento da query sem cache**: Chamar Bedrock Titan para gerar o embedding da query do usuário a cada requisição sem cache de embeddings de queries frequentes adiciona 50-100ms desnecessários e custo de API. Use ElastiCache com TTL de 5 minutos para queries recorrentes em sessões de agente. - **k muito alto sem reranking**: Recuperar top-50 ou top-100 documentos e injetar tudo no contexto do LLM sem reranking enche a janela de contexto com ruído, aumenta o custo de tokens e degrada a qualidade da resposta. O padrão correto é k=20 com reranking para top-5. - **Ignorar o modelo de custo de OCU em workloads de ingestão em lote**: OCUs de indexação e OCUs de busca são cobrados separadamente. Um job de ingestão em lote que processa 1M documentos pode provisionar 10+ OCUs de indexação por horas e gerar uma fatura inesperada. Sempre use throttling no pipeline de ingestão e monitore `IndexingOCUs` no CloudWatch. - **Ausência de idempotência no pipeline de ingestão**: Reprocessar documentos sem verificação de hash de conteúdo cria duplicatas no índice vetorial, aumenta o custo de armazenamento e degrada a precisão da busca com chunks redundantes. Use um hash SHA-256 do conteúdo como `document_id` e faça upsert, não insert. - **Confiar em retry automático do SDK sem idempotência no agente**: Workflows agênticos com Step Functions ou Bedrock Agent que fazem retry de tool calls de recuperação sem garantia de idempotência podem emitir queries duplicadas ao índice e acumular contexto inconsistente na sessão. Cada tool call deve ter um `call_id` rastreável. ## Segurança e Governança em Ambientes Financeiros Regulados Em sistemas financeiros, o índice vetorial não é apenas um componente de performance — é um repositório de dados potencialmente sensíveis. Embeddings de documentos confidenciais podem, em teoria, ser revertidos parcialmente com ataques de inversão de embedding. Isso não é ficção científica: pesquisas recentes demonstraram reconstrução parcial de texto a partir de vetores de modelos populares. **Controles obrigatórios que implemento em produção:** 1. **KMS CMK com rotação anual**: Toda collection OpenSearch Serverless deve usar uma CMK gerenciada pelo cliente (`aws/opensearchserverless` não é suficiente para ambientes regulados). Configure `kms:ViaService` condition na key policy para restringir uso exclusivo ao serviço. 2. **Data Access Policies com princípio do menor privilégio**: Separe roles IAM para ingestão (`aoss:CreateIndex`, `aoss:WriteDocument`) e para busca (`aoss:ReadDocument`). Nunca dê ao agente permissão de escrita no índice. 3. **VPC Endpoint para OpenSearch Serverless**: Em ambientes financeiros, todo tráfego para o índice deve passar por `vpce-opensearchserverless` com policy de endpoint que rejeita requests fora da VPC. Isso elimina o vetor de exfiltração via internet pública. 4. **Auditoria de queries via CloudTrail**: Habilite `aoss:APICall` no CloudTrail para registrar todas as queries ao índice. Em ambientes LGPD/GDPR, isso é necessário para demonstrar que dados pessoais não estão sendo acessados fora do contexto autorizado. 5. **Classificação de dados nos metadados do chunk**: Adicione campos `data_classification` (PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED) e `retention_date` em cada documento indexado. Use esses campos como filtros obrigatórios nas data access policies para garantir que o agente nunca recupere documentos acima do seu nível de autorização. ## Observabilidade: O Que Monitorar e Por Quê Um sistema RAG agêntico sem observabilidade adequada é uma caixa preta que falha silenciosamente. A degradação de qualidade — respostas menos precisas, alucinações crescentes — não aparece em métricas de infraestrutura. Você precisa de uma estratégia de observabilidade em três camadas. **Camada 1 — Infraestrutura (CloudWatch):** - `SearchOCUs` e `IndexingOCUs`: alertas quando > 80% da capacidade máxima configurada - `SearchLatency` P99: SLO de 150ms; alarme em 120ms para dar margem de reação - `IndexingRate` (documentos/segundo): queda súbita indica problema no pipeline de ingestão - `SearchRequestRate` vs `SearchErrorRate`: taxa de erro > 0.1% dispara investigação **Camada 2 — Aplicação (OpenTelemetry + CloudWatch Logs Insights):** Instrumento cada ciclo do agente com um trace span que inclui: número de rounds de recuperação, k efetivo por round, latência do reranker, tokens de contexto injetados no LLM e score de confiança da resposta. Isso permite correlacionar degradação de qualidade com mudanças de tráfego ou de dados. **Camada 3 — Qualidade de Recuperação (offline):** Implemento um pipeline de avaliação assíncrono com RAGAS (Retrieval Augmented Generation Assessment) que roda diariamente sobre uma amostra de 5% das queries de produção. As métricas `context_precision`, `context_recall` e `faithfulness` são publicadas no CloudWatch como custom metrics e integradas ao dashboard de SLO do produto. Uma queda de 10% em `faithfulness` em 7 dias é um indicador de drift na base de conhecimento que precisa de reindexação. > **Mantenha Collections Quentes com Heartbeat Queries:** O cold start de collections OpenSearch Serverless inativas é o maior risco operacional deste padrão. Configure um EventBridge Scheduler para disparar uma query de heartbeat leve (`GET /_cat/indices`) a cada 10 minutos nas collections críticas. O custo é desprezível (< $0.50/mês em OCUs) e elimina o risco de um cold start de 2-3 minutos no primeiro acesso do dia — que em sistemas financeiros pode ser exatamente quando um analista precisa de uma resposta urgente antes da abertura do mercado. ## OpenSearch Serverless vs Alternativas para RAG Agêntico | Critério | Critério | OpenSearch Serverless | OpenSearch Provisionado | pgvector (Aurora) | | --- | --- | --- | --- | --- | | Latência P99 (10M vetores) | 80-150ms (quente) | 20-60ms | 200-500ms | — | | Cold Start | 2-3 min (mitigável) | Nenhum | Nenhum | — | | Custo base mensal (idle) | ~$700 (2 OCU mínimo) | ~$400 (3x r6g.large) | ~$200 (Aurora Serverless v2) | — | | Escala automática | Sim, por collection | Manual / UltraWarm | Sim (ACU) | — | | Multi-tenancy nativo | Data Access Policies por IAM | Index-level RBAC | Row-level security (RLS) | — | | Hybrid search (vetor + BM25) | Sim, nativo | Sim, nativo | Não nativo (workaround) | — | > **Minha Nota de Curadoria:** Depois de implementar variações deste padrão em três ambientes financeiros distintos — gestora de ativos, banco digital e seguradora —, a lição mais dura que aprendi é que a qualidade do RAG é determinada 70% pelo pipeline de ingestão e 30% pela configuração do índice. Arquitetos que passam semanas ajustando parâmetros HNSW enquanto têm chunks mal estruturados e metadados ausentes estão otimizando o lugar errado. Minha recomendação prática: antes de qualquer tuning de índice, invista em um golden dataset de 200-300 pares (query, documento relevante) específicos do seu domínio e use-o para medir `context_recall` — se estiver abaixo de 0.75, o problema é no chunking ou no embedding, não no k-NN. O OpenSearch Serverless é uma boa escolha para este padrão quando o custo mínimo de ~$700/mês é justificável e o tráfego é genuinamente variável; fora disso, um cluster provisionado pequeno com UltraWarm entrega melhor TCO. ## Veredicto: Use com Critério, Configure com Rigor O padrão RAG agêntico com Amazon OpenSearch Serverless é tecnicamente maduro e operacionalmente viável para sistemas financeiros — desde que você aceite suas restrições com clareza. O custo mínimo de ~$700/mês em OCUs não é negociável e o cold start ainda é um risco operacional real que exige mitigação ativa. Em contrapartida, o modelo de data access policies baseado em IAM é genuinamente superior para multi-tenancy regulado, o suporte nativo a hybrid search (vetor + BM25) é uma vantagem concreta sobre pgvector, e a ausência de gestão de cluster libera capacidade de engenharia para o que realmente importa: qualidade do pipeline de ingestão e avaliação contínua de retrieval. Minha recomendação: adote este padrão se você tem workloads agênticos com tráfego variável, base de conhecimento de domínio especializado e requisitos de multi-tenancy com isolamento de dados. Evite se você precisa de latência P99 sub-100ms, tem tráfego previsível e constante, ou se o custo base não é justificável pelo volume de uso. Em qualquer caso, invista primeiro no golden dataset de avaliação — sem ele, você está voando cego. **Rating:** Recommended with conditions ## Referências Técnicas - [Amazon OpenSearch Serverless Developer Guide](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless.html) - [Amazon OpenSearch Service k-NN Plugin Documentation](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/knn.html) - [Amazon Bedrock Agents — Knowledge Bases Integration](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html) - [RAGAS: Evaluation Framework for RAG Pipelines](https://docs.ragas.io/en/latest/) - [OpenSearch Serverless Security — Data Access Policies](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-data-access.html) - [AWS Well-Architected Framework — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html) - [Embedding Inversion Attacks: Vec2Text Research](https://arxiv.org/abs/2310.06816) - [Cohere Rerank API Documentation](https://docs.cohere.com/reference/rerank)