Um guia completo de arquitetura para sistemas de recuperação aumentada com múltiplos agentes, controle de tokens e observabilidade em ambientes produtivos.
Por que RAG simples não é suficiente em produção?
RAG (Retrieval-Augmented Generation) resolve um dos maiores problemas dos modelos de linguagem: a alucinação. Em vez de confiar apenas no conhecimento que o modelo carrega internamente, você recupera documentos relevantes em tempo real e os injeta no contexto antes de gerar a resposta. O resultado é mais preciso, rastreável e atualizado.
O problema começa quando você tenta colocar isso em produção de verdade — com volume, complexidade e custo para controlar.
Um agente único fazendo tudo ao mesmo tempo vira gargalo rapidamente. Ele busca, raciocina, valida e responde, tudo em uma cadeia linear. Quando a tarefa exige cruzar múltiplas fontes, validar dados, ou raciocinar em múltiplos passos, a qualidade cai, a latência sobe e o custo explode.
A solução é dividir responsabilidades. Especializar. Orquestrar. É aí que entra a arquitetura multi-agente.
Conceitos Fundamentais — Antes de Começar
Se você já conhece esses termos, pode pular esta seção. Se não, vale dois minutos aqui antes de mergulhar na arquitetura.
RAG (Retrieval-Augmented Generation) é a técnica de buscar informações externas antes de gerar uma resposta. Em vez de o modelo responder só com o que aprendeu no treinamento, ele primeiro consulta documentos reais e usa esse conteúdo como base. O resultado é mais preciso e rastreável.
Agente é um programa autônomo que recebe uma tarefa, decide como executá-la e age para completá-la — podendo chamar ferramentas, APIs ou outros agentes no processo. Em arquiteturas multi-agente, cada agente tem uma especialidade e trabalha de forma coordenada com os demais.
Chunk é um pedaço de um documento maior. Como modelos de linguagem têm um limite de quanto texto conseguem processar de uma vez, os documentos são quebrados em fragmentos menores antes de serem indexados. O tamanho do chunk afeta diretamente a qualidade da busca e o custo das chamadas ao modelo.
Embedding é a transformação de um texto em um vetor numérico — uma lista de números que representa o significado daquele texto. Textos com significados parecidos geram vetores parecidos. É essa propriedade que permite encontrar documentos relevantes para uma pergunta sem depender de palavras-chave exatas.
Banco Vetorial (Vector Store) é um banco de dados especializado em armazenar e buscar vetores por similaridade. Na AWS, o OpenSearch Serverless cumpre esse papel. Você passa o vetor da pergunta e ele retorna os vetores de chunks mais próximos semanticamente.
Token é a unidade de medida de texto para modelos de linguagem. Grosseiramente, um token equivale a três ou quatro caracteres em português. Modelos cobram por token consumido — tanto no input (o que você envia) quanto no output (o que o modelo responde). Controlar tokens é controlar custo.
Cache Semântico é um mecanismo que armazena respostas anteriores e as reutiliza quando uma nova pergunta tem significado parecido — mesmo que as palavras sejam diferentes. Diferente do cache tradicional, que exige igualdade exata, o cache semântico usa similaridade de vetores para decidir se pode reaproveitar uma resposta.
Orquestrador é o agente central que coordena os demais. Ele recebe a pergunta, decide quais agentes acionar, em qual ordem, e consolida o resultado final. Nenhum agente especialista se comunica com o usuário diretamente — tudo passa pelo orquestrador.
Action Group é um mecanismo do Bedrock Agents que mapeia uma intenção a uma função executável — geralmente uma Lambda. Permite que o agente acesse sistemas externos como bancos de dados, APIs e serviços internos de forma controlada.
Guardrails são filtros configuráveis que o Bedrock aplica antes e depois da chamada ao modelo. Eles detectam e bloqueiam conteúdo sensível, dados pessoais (PII) e tentativas de manipulação do modelo — tanto no que o usuário envia quanto no que o modelo responde.
Reranker é um modelo secundário que recebe os resultados da busca vetorial e os reordena com um critério mais refinado. A busca vetorial é rápida mas imperfeita — o reranker faz uma segunda passagem mais cuidadosa para garantir que os chunks mais relevantes chegam ao modelo.
A Visão Geral da Arquitetura
Antes de entrar em cada camada, é importante entender o fluxo completo de uma requisição:
Uma pergunta chega pelo API Gateway, que cuida de autenticação e rate limiting. Ela é recebida pelo Orquestrador, que classifica a intenção, define o orçamento de tokens e distribui o trabalho para os agentes especializados. Esses agentes buscam, processam e validam as informações, consultando o pipeline de RAG — composto pelo banco vetorial, pelos documentos e pelo modelo de embeddings. A resposta consolidada volta ao usuário.
Cada componente tem uma responsabilidade clara e isolada. Isso é o que permite escalar, depurar e otimizar cada parte de forma independente.
Camada 1 — Ingestão e Indexação de Documentos
Tudo começa antes dos agentes. Seus documentos precisam estar indexados de forma inteligente para que a busca funcione bem depois.
O pipeline de ingestão
Os documentos brutos ficam armazenados no Amazon S3. Um processo de ingestão — que pode rodar em Lambda para documentos pequenos ou em Fargate para processamentos mais pesados — lê esses arquivos e os quebra em pedaços menores chamados chunks.
O tamanho do chunk não é um detalhe cosmético. É uma decisão de arquitetura com impacto direto em qualidade e custo. Chunks muito pequenos perdem contexto. Chunks muito grandes inflam o custo de cada chamada ao modelo. O intervalo mais equilibrado em produção fica entre 256 e 512 tokens por chunk, com um overlap de 50 tokens entre chunks adjacentes para não perder continuidade de raciocínio.
Cada chunk é então transformado em um vetor de embeddings pelo Amazon Bedrock — usando Titan Embeddings ou Cohere — e armazenado no OpenSearch Serverless, que serve como banco vetorial com suporte a busca por similaridade (kNN). Os metadados de cada chunk — de qual documento veio, quantos tokens tem, data de ingestão, domínio — ficam no DynamoDB para rastreabilidade e controle.
Por que o chunking mal feito é a raiz de muitos problemas
Se você cortar o texto de forma ingênua — a cada X caracteres independentemente do conteúdo — um único chunk pode conter partes de assuntos completamente diferentes. Isso polui o vetor resultante e confunde a busca semântica. O agente de recuperação vai trazer chunks irrelevantes não por falha sua, mas porque o índice foi mal construído na origem.
O chunking semântico resolve isso: você respeita parágrafos, seções e marcações do documento antes de cortar. É mais trabalhoso de implementar, mas tem impacto direto na qualidade das respostas.
Camada 2 — Os Agentes e seus Papéis
A arquitetura multi-agente funciona como uma empresa bem estruturada. Cada agente tem uma função definida e nenhum deles faz tudo.
O Orquestrador — o gerente da operação
O Orquestrador é o único ponto de contato com o mundo externo. Quando uma pergunta chega, ele:
Classifica a intenção — é uma pergunta factual simples? Uma análise que exige múltiplas fontes? Uma consulta que precisa cruzar sistemas diferentes? Cada tipo de intenção tem um caminho diferente no fluxo.
Define o orçamento de tokens antes de qualquer chamada ao modelo, calculando quanto contexto pode ser passado sem estourar os limites ou o custo.
Distribui o trabalho para os agentes especializados e consolida as respostas antes de devolver ao usuário.
O Orquestrador nunca executa o trabalho diretamente. Ele coordena.
O Agente de Recuperação — só busca, nada mais
Este agente tem uma responsabilidade única: dado uma pergunta, trazer os trechos de documentos mais relevantes do banco vetorial. Ele transforma a pergunta em vetor, consulta o OpenSearch e retorna os resultados ranqueados por similaridade.
Ele não interpreta, não raciocina, não responde. Só recupera. Essa separação permite otimizar a busca de forma independente sem impactar o resto do sistema.
O Agente de Síntese — quem fala com o modelo
O Agente de Síntese recebe o contexto montado — a pergunta original mais os chunks selecionados — e chama o modelo de linguagem para gerar a resposta. É aqui que o orçamento de tokens definido pelo Orquestrador é aplicado: o contexto passado para o modelo nunca ultrapassa o limite estabelecido.
O Agente de Validação — a última linha de defesa
Antes de a resposta chegar ao usuário, o Agente de Validação a revisa. Ele verifica coerência com as fontes, detecta possíveis alucinações e garante que regras de negócio e compliance estão sendo respeitadas. Em ambientes regulados — financeiro, saúde, jurídico — esse agente não é opcional.
Agentes adicionais conforme o caso
Dependendo da complexidade do sistema, você pode adicionar um Agente de Sumarização para comprimir histórico de conversas longas, e Agentes de Domínio especializados em áreas específicas — financeiro, RH, técnico — com índices e prompts otimizados para cada contexto.
Camada 3 — Controle de Tokens: o coração da arquitetura
Este é o ponto que separa quem conhece RAG de quem colocou RAG em produção. O custo de um sistema baseado em modelos de linguagem é diretamente proporcional ao número de tokens consumidos. Sem controle, o custo é imprevisível e cresce sem relação com o valor entregue.
Budget de tokens por camada
A primeira decisão é definir quanto cada parte do sistema pode consumir. O system prompt reserva uma cota fixa. A pergunta do usuário ocupa uma parte variável. O contexto recuperado tem um limite máximo calculado dinamicamente. O Orquestrador gerencia esse orçamento e garante que nenhuma chamada ao modelo ultrapasse os limites definidos.
Seleção inteligente de chunks
O agente de recuperação pode trazer 20 chunks relevantes do OpenSearch, mas você não passa todos para o modelo. Você seleciona apenas os de maior score de relevância até atingir o limite de tokens disponível. Os outros são descartados antes de chegar ao modelo. Isso economiza tokens sem comprometer a qualidade, desde que a seleção seja bem feita.
Cache semântico — o maior alavancador de economia
O cache tradicional funciona por igualdade exata: a mesma pergunta recebe a mesma resposta sem chamar o modelo. O problema é que perguntas semanticamente idênticas raramente são escritas da mesma forma.
O cache semântico resolve isso com vetores. Quando uma pergunta chega, você a transforma em vetor e compara com os vetores das perguntas já cacheadas no ElastiCache com Redis. Se a similaridade for superior a um threshold — tipicamente entre 0.92 e 0.95 — você considera equivalente e retorna a resposta cacheada sem consumir nenhum token do modelo.
O threshold é um parâmetro que você calibra com o tempo baseado nos dados reais do seu sistema. Muito alto e o cache raramente acerta. Muito baixo e você retorna respostas incorretas para perguntas diferentes. Em ambientes corporativos com perguntas repetitivas, o cache semântico pode eliminar 30 a 40% das chamadas ao modelo.
O cache semântico fica antes de qualquer agente no fluxo. O Orquestrador consulta o Redis primeiro. Se houver hit, a resposta é devolvida imediatamente. Se não houver, o fluxo segue normalmente e ao final a nova pergunta e resposta são gravadas no Redis para as próximas chamadas.
Compressão de contexto
Antes de passar os chunks para o modelo, você pode comprimi-los sem perder o significado essencial. Técnicas de compressão de prompt — como o LLMLingua — conseguem reduzir o contexto em até quatro vezes mantendo a precisão das respostas. Isso é especialmente útil quando os documentos são longos e técnicos.
Sumarização de histórico de conversa
Em fluxos conversacionais, o histórico cresce a cada turno. Sem controle, você passa o histórico completo em cada chamada, e o custo cresce linearmente com a conversa. A solução é manter um resumo compacto e atualizado da conversa ao invés do histórico bruto. O Agente de Sumarização faz essa compressão periodicamente, mantendo o contexto relevante sem inflar o consumo de tokens.
Rastreamento granular por agente e por sessão
Cada chamada ao modelo deve registrar no DynamoDB: qual agente chamou, quantos tokens de entrada e saída foram usados, o custo estimado e o identificador da sessão. Isso permite análise de custo por usuário, por feature, por tipo de pergunta e por agente — essencial para identificar onde está o desperdício e onde otimizar.
Camada 4 — Acesso a Múltiplas Fontes de Dados
Em cenários corporativos, a resposta frequentemente exige informações de sistemas diferentes. Um funcionário perguntando se é elegível a um bônus, por exemplo, pode exigir dados do sistema financeiro e do sistema de RH ao mesmo tempo.
Action Groups e Lambdas especializadas
O Bedrock Agents permite configurar Action Groups que mapeiam intenções a funções Lambda específicas. Cada Lambda é responsável por acessar uma fonte de dados diferente — banco relacional via query SQL, API REST de um sistema legado, ou qualquer outro sistema de registro.
A chave aqui é minimização de dados: as Lambdas não devolvem o dado bruto completo para o modelo. Elas processam e devolvem apenas o que é necessário para responder a pergunta. Ao invés de passar o salário exato do funcionário, você passa uma classificação — elegível ou não elegível. O modelo recebe o insumo necessário sem ter acesso a informação sensível além do necessário.
Segurança em três camadas
A segurança em sistemas multi-agente com acesso a dados sensíveis precisa ser pensada em profundidade, não em um único ponto.
Na camada de infraestrutura, as Lambdas que acessam sistemas internos rodam dentro de uma VPC privada sem acesso à internet. As credenciais ficam no Secrets Manager, nunca em variáveis de ambiente. O acesso é controlado por IAM roles com privilégio mínimo — cada Lambda só pode acessar exatamente o que precisa.
Na camada do modelo, o Bedrock Guardrails atua em dois momentos: no input, bloqueando perguntas que tentam extrair dados sensíveis diretamente; e no output, detectando e mascarando informações como CPF, número de conta, dados pessoais antes de a resposta chegar ao usuário. Você configura políticas de PII e o Bedrock as aplica automaticamente.
Na camada de auditoria, o CloudTrail registra toda chamada feita a sistemas externos, criando uma trilha completa de quem perguntou o quê, quando, e quais sistemas foram consultados. Em ambientes regulados, isso não é opcional.
Camada 5 — Orquestração dos Fluxos
Para conectar os agentes e gerenciar fluxos complexos com retry, paralelismo e tratamento de erros, você tem duas opções principais na AWS.
AWS Step Functions
O Step Functions é a escolha para fluxos com lógica complexa. Você define estados, transições e condições de forma declarativa. Se a pergunta é simples, o fluxo vai direto para síntese. Se é complexa, passa por recuperação, validação e síntese em sequência, com retry automático em caso de falha. O histórico de cada execução fica visível no console, o que facilita muito o diagnóstico de problemas em produção.
Bedrock Agents
O Bedrock Agents oferece orquestração nativa com memória e integração direta com Action Groups e bases de conhecimento. É mais rápido de implementar e ideal para MVPs ou equipes menores. A contrapartida é menos transparência sobre o que acontece internamente — o que dificulta o controle fino de tokens e o diagnóstico de problemas de custo.
Para sistemas com SLAs definidos de custo e performance, a combinação de Lambda + Step Functions + Bedrock SDK direto oferece mais controle, mesmo exigindo mais esforço de construção.
Camada 6 — Observabilidade e Diagnóstico de Problemas
Em produção, se você não consegue ver o que está acontecendo, você não consegue otimizar — e quando algo quebra, você não consegue encontrar a causa.
AWS X-Ray para tracing distribuído
O X-Ray instrumenta cada chamada entre os componentes do sistema e monta um mapa visual do fluxo de cada requisição. Você consegue ver quanto tempo cada agente levou, onde está o gargalo, qual etapa falhou e em qual contexto. Quando o custo aumenta inexplicavelmente, o X-Ray é onde você começa: compare traces do período normal com traces do período problemático para identificar o que mudou.
CloudWatch para métricas e alertas
Além dos logs, você configura métricas customizadas no CloudWatch para tokens de entrada e saída por agente, latência por etapa e taxa de cache hit. Com essas métricas, você cria alarmes: se o custo diário ultrapassar um threshold, um SNS dispara um alerta e pode acionar throttling automático. Se a latência P99 ultrapassar dez segundos, a Lambda escala horizontalmente.
Cost Explorer e Cost Anomaly Detection
O Cost Explorer com filtragem por tag de agente permite ver exatamente onde o custo está sendo gerado. O Cost Anomaly Detection monitora o padrão de gasto e avisa automaticamente quando há desvios — essencial para pegar bugs que causam loops de chamadas ao modelo antes que o custo exploda.
O processo de investigação de anomalias de custo
Quando o custo aumenta sem explicação óbvia, o processo de investigação tem três passos em sequência. Primeiro o Cost Explorer, para isolar em qual agente ou modelo o custo está crescendo. Depois o X-Ray, para comparar os traces do período normal com os do período anômalo e identificar se o número de chamadas aumentou ou se as chamadas ficaram mais caras. Por fim o CloudWatch, para determinar se o problema está no input — contexto inflado — ou no output — respostas muito longas.
As causas mais comuns de custo inexplicado são: cache semântico parou de funcionar por alguma atualização ou falha no Redis; um loop entre agentes causado por um bug que faz o orquestrador chamar o mesmo agente múltiplas vezes; histórico de conversa crescendo sem controle porque a sumarização parou; ou chunks que ficaram maiores depois de uma mudança inadvertida no pipeline de ingestão.
Stack Completa Recomendada
Consolidando todas as camadas, a stack de referência para um sistema RAG multi-agente em produção na AWS fica assim:
Ingestão: S3 para armazenamento, Lambda ou Fargate para processamento, Bedrock Titan Embeddings para vetorização, OpenSearch Serverless para indexação vetorial, DynamoDB para metadados de chunks.
Cache: ElastiCache com Redis para cache semântico, consultado antes de qualquer agente.
Orquestração: API Gateway para exposição e rate limiting, Lambda Orchestrator para roteamento e controle de budget, Step Functions para fluxos complexos com retry e paralelismo.
Agentes: Lambda individuais por agente (Recuperação, Síntese, Validação, Sumarização) consumindo Bedrock SDK diretamente.
Acesso a dados: Action Groups do Bedrock Agents mapeando para Lambdas especializadas dentro de VPC privada, com credenciais no Secrets Manager e acesso controlado por IAM.
Segurança: Bedrock Guardrails para PII e controle de conteúdo, CloudTrail para auditoria de acesso a sistemas.
Observabilidade: X-Ray para tracing distribuído, CloudWatch com métricas customizadas de tokens e custo, Cost Explorer com tags por agente, Cost Anomaly Detection para alertas proativos.
Considerações Finais
Arquitetar RAG em produção é fundamentalmente diferente de construir um protótipo funcional. O protótipo responde perguntas. A arquitetura de produção responde perguntas de forma confiável, com custo previsível, com segurança auditável, e com capacidade de escalar sem surpresas.
Os três princípios que regem essa arquitetura são separação de responsabilidades — cada agente faz exatamente uma coisa bem feita; controle de custo como cidadão de primeira classe — tokens são o principal insumo e precisam ser gerenciados com a mesma seriedade que qualquer outro recurso de infraestrutura; e observabilidade desde o início — você não consegue otimizar o que não consegue medir.
A combinação desses princípios com os serviços certos da AWS produz um sistema que não apenas funciona, mas que você consegue operar, entender e evoluir com confiança ao longo do tempo.
Tem dúvidas sobre alguma camada específica ou quer aprofundar algum dos conceitos? Deixa nos comentários.
Top comments (0)