RAG Agêntico com OpenSearch Serverless: Anatomia de um Padrão

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.

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.

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.

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.

1. 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.

1. 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.

1. 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.

1. 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.

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.