Empresas SaaS multilocatárias vivem o dilema entre extrair insights de grandes volumes de documentos e manter a conta de infraestrutura sob controle. Em arquiteturas tradicionais de Recuperação Aumentada por Geração (RAG), cria-se e mantém-se embeddings de tudo, inclusive de arquivos que nunca serão consultados.
O resultado é desperdício de armazenamento e processamento, queda de eficiência e, em cenários com muitos clientes de pequeno e médio porte, explosão de custo ou necessidade de implantações isoladas para preservar o isolamento de dados. Some a isso projetos temporários, com uso intermitente, que ocupam espaço em bases de conhecimento sem gerar valor. A resposta estratégica é uma base de conhecimento just-in-time: processar documentos apenas quando necessário, remover recursos não utilizados automaticamente e escalar a operação sem escalar a fatura — mantendo o isolamento entre tenants.
O que é (e por que importa) uma base de conhecimento just-in-time para RAG multi-tenant
A proposta é simples e poderosa: processar sob demanda. Documentos são ingeridos e vetorizados quando um usuário realmente precisa consultá-los; se deixam de ser acessados, expiram via TTL e saem do caminho, liberando recursos. Em uma arquitetura multilocatária, isso permite limites configuráveis por cliente (quantos arquivos pode subir, com que frequência pode consultar, quanto tempo o conteúdo fica “quente”) e isolamento rígido de dados por meio de metadados.
Com isso, provedores SaaS conseguem oferecer planos escalonados (durações de TTL diferentes, rate limits distintos, cotas por período) e manter a operação enxuta. Ao organizar documentos em grupos com filtros por metadados(usuário, tenant, projeto, tipo de arquivo), as consultas tornam-se mais contextuais e relevantes sem abrir mão da segurança.
Arquitetura de referência na AWS
A solução combina serviços gerenciados para reduzir sobrecarga operacional e ganhar elasticidade. Amazon Bedrockatua como base de conhecimento e orquestra ingestão/consulta, enquanto Amazon OpenSearch Serverless guarda os vetores para buscas sem servidor e com scale-out automático.
Amazon DynamoDB armazena o catálogo de projetos/arquivos e aplica Time-to-Live (TTL) para limpeza automática do que não é mais usado; Amazon S3 armazena os arquivos brutos com upload seguro por URLs pré-assinadas. Para ingestão just-in-time, a arquitetura usa o tipo de fonte de dados CUSTOM do Bedrock, acionando processamento somente quando um chat pede acesso àquele conjunto de documentos. A separação entre clientes acontece nos metadados e é respeitada ponta a ponta, do armazenamento à consulta, garantindo multilocação com isolamento.
Como o fluxo funciona na prática (de ponta a ponta)
O ciclo inicia no login: o sistema associa o usuário ao ID do cliente (tenant), que passa a acompanhar todas as chamadas à base de conhecimento — é o coração dos metadados e do isolamento. Em seguida o usuário cria um projeto, um contêiner lógico para os arquivos que deseja consultar; o sistema registra metadados e relações necessárias no DynamoDB para controle de acesso e uso por cliente/projeto. Com o projeto criado, o usuário envia arquivos via URLs pré-assinadas, que são armazenados no S3; a cada upload, o catálogo no DynamoDB relaciona arquivo ↔ projeto ↔ cliente, preparando o terreno para consultas eficientes.
Quando o usuário abre um chat vinculado ao projeto, a solução importa on-demand os arquivos usando a fonte CUSTOM do Bedrock e aplica um TTL definido pelo plano do cliente: o conteúdo fica disponível pelo período contratado, sem ocupar recursos além do necessário. Durante o chat, cada acesso renova o TTL dos arquivos utilizados; o que é relevante permanece “quente”, o que é pouco usado expira naturalmente.
Ao final, quando o TTL vence, o DynamoDB Streams dispara uma função AWS Lambda que remove documentos expirados da base de conhecimento e alivia o OpenSearch Serverless, mantendo o sistema enxuto e performático.
Governança por cliente: limites, preços e isolamento
O controle granular por metadados permite aplicar políticas por tenant: quantidade de arquivos que pode subir em um período, taxa de consultas permitida, duração do TTL por plano, além de filtros por usuário/projeto em tempo de busca.
Isso viabiliza modelos de preços escalonados sem multiplicar ambientes, preservando segurança entre clientes e permitindo personalizações sem reestruturar a arquitetura. Como tudo é serverless, a equipe foca em lógica de negócio (quem pode ver o quê, por quanto tempo, com qual prioridade) em vez de “cuidar” de servidores.
Implantação (CDK) em poucas etapas
Com os pré-requisitos prontos — conta AWS com permissões na us-east-1, AWS CLI, AWS CDK e Git — o caminho segue direto: clonar o repositório do projeto, instalar dependências com npm run install:all, implantar com npm run deploy e, após validar o e-mail, criar um usuário e fazer login. A partir daí, a aplicação já gerencia projetos, uploads e sessões de chat com RAG multi-tenant just-in-time e limpeza automática por TTL.
Conclusão
Ao processar documentos somente quando consultados e expirar o que não gera valor, esta arquitetura de RAG multi-tenant elimina consumo ocioso típico de bases de conhecimento tradicionais. Com Amazon Bedrock, OpenSearch Serverless e TTL do DynamoDB, você ganha um sistema enxuto e escalável, com isolamento rigoroso por cliente, limites configuráveis e custos previsíveis — um ajuste fino ideal para provedores SaaS que atendem muitos clientes com projetos e picos de uso diferentes. Em vez de administrar infraestrutura, sua equipe passa a extrair insights de negócio com governança e performance consistentes.
Quer ir do conceito à prática? A Fast Lane ajuda seu time a desenhar, implementar e operar essa arquitetura, além de capacitar seu time em Amazon Bedrock, OpenSearch, DynamoDB e arquiteturas serverless. Fale com a gente e avance da estratégia ao ROI com segurança e escala.
Confira matéria completa: Crie uma base de conhecimento just-in-time com o Amazon Bedrock
