Knowledge Bases e RAG gerenciado na AWS
Como montar o pipeline RAG da aula 06 com serviços gerenciados, incluindo busca vetorial.
5 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Na aula 06 você entendeu o que é RAG. Na aula 04 você viu como embeddings transformam texto em vetores pesquisáveis. Agora vamos fechar o ciclo: montar esse pipeline inteiro na AWS sem gerenciar servidor de embedding, índice vetorial ou orquestrador, usando Amazon Bedrock Knowledge Bases como peça central.
O que o Bedrock Knowledge Bases faz por você
Uma Knowledge Base (KB) no Bedrock é o pipeline RAG da aula 06 empacotado como serviço gerenciado. Você aponta uma fonte de dados, um bucket S3, por exemplo, e o serviço cuida de tudo: lê os documentos, divide em chunks, gera embeddings com o modelo que você escolher (Titan Embeddings, Cohere, etc.), armazena os vetores num vector store e expõe um endpoint de recuperação semântica.
O fluxo tem quatro etapas internas:
- Ingestão: o serviço lê os arquivos da fonte (PDF, DOCX, HTML, CSV, Confluence, SharePoint…).
- Chunking: o texto é dividido em pedaços, tamanho fixo, por sentença, hierárquico ou semântico. Você escolhe a estratégia.
- Embedding: cada chunk vira um vetor usando o modelo de embedding configurado.
- Indexação: os vetores são gravados no vector store escolhido.
Na hora da consulta, a KB recebe a pergunta do usuário, gera o embedding da pergunta com o mesmo modelo, faz a busca por similaridade no índice e devolve os chunks mais relevantes, prontos para serem injetados no prompt do LLM. Você não escreve nenhum desse código.
Pipeline RAG gerenciado: da fonte ao agente
Fluxo completo de ingestão e recuperação com Bedrock Knowledge Bases. Setas sólidas = caminho de ingestão (offline). Setas tracejadas = caminho de consulta (runtime).
- Amazon S3 · PDF, DOCX, HTML
- Confluence / SharePoint · conectores nativos
- Ingestão · lê e divide em chunks
- Embedding · Titan / Cohere
- Knowledge Base · endpoint de recuperação
- OpenSearch Serverless · padrão recomendado
- Aurora PostgreSQL · (pgvector)
- Pinecone / Redis · options externas
- Bedrock Agent · ou chamada direta
- LLM (Claude, Llama…) · gera resposta final
Onde os vetores ficam: escolhendo o vector store
O Bedrock Knowledge Bases suporta múltiplos backends de vetores. A escolha impacta custo, latência e operação.
OpenSearch Serverless (AOSS) é a opção padrão e a que a AWS mais integra. Você não provisiona shards nem instâncias, paga por OCU (OpenSearch Compute Unit) consumida. Para a maioria dos projetos com volume moderado de documentos, é o caminho de menor atrito. O ponto de atenção: o custo mínimo por collection pode surpreender em ambientes de dev/test que ficam ociosos.
Aurora PostgreSQL com pgvector faz sentido quando você já tem dados relacionais na mesma base. A busca vetorial fica ao lado dos seus dados transacionais, sem hop extra. A desvantagem é que você gerencia o cluster e o pgvector tem limites de escala comparado a engines dedicadas.
Pinecone, Redis Enterprise e MongoDB Atlas são opções externas suportadas via conector. Úteis se você já tem contrato ou time familiarizado com esses serviços, mas adicionam uma dependência fora da AWS.
Minha recomendação padrão: comece com OpenSearch Serverless. É o caminho de menor configuração e tem boa integração com o restante do Bedrock. Migre para pgvector se o custo do AOSS não fechar ou se você precisar de joins com dados relacionais.
Na prática, o maior erro que vejo é criar uma collection AOSS para cada ambiente (dev, staging, prod) sem pensar no custo mínimo por collection. O AOSS cobra mesmo quando não há queries. Para dev, considere usar uma única collection com namespaces separados por índice, ou trocar por pgvector local com Docker enquanto desenvolve. Reserve o AOSS para staging e prod, onde o custo se justifica pela escala e pela integração nativa com o Bedrock.
Como o agente consome a Knowledge Base
Na aula 07 você viu tool calling: o modelo decide quando chamar uma ferramenta externa. Uma Knowledge Base no Bedrock é exatamente isso para um Bedrock Agent, ela aparece como uma ferramenta nativa, sem você precisar escrever a função de recuperação.
Quando você associa uma KB a um agente no Bedrock, o agente ganha automaticamente a capacidade de fazer perguntas à base durante o loop ReAct (aula 11). O orquestrador interno decide quando a pergunta do usuário exige busca na KB, dispara a consulta, recebe os chunks e os injeta no contexto antes de chamar o LLM.
Você também pode chamar a KB diretamente via API: RetrieveAndGenerate ou Retrieve separados, sem precisar de um agente completo. Retrieve devolve os chunks brutos; RetrieveAndGenerate faz a busca e já chama o LLM, entregando a resposta final. Use Retrieve quando quiser controlar o prompt você mesmo ou quando precisar pós-processar os chunks antes de enviar ao modelo.
Essa separação entre recuperação e geração é importante: ela permite que você avalie (aula 09) cada etapa de forma independente, qualidade da recuperação separada da qualidade da geração.
Gerenciado vs. RAG próprio: quando usar cada um
| Critério | Bedrock KB (gerenciado) | RAG próprio (LangChain, LlamaIndex…) |
|---|---|---|
| Tempo para funcionar | Horas (console ou IaC) | Dias a semanas |
| Controle de chunking/embedding | Limitado às opções do serviço | Total, qualquer estratégia |
| Manutenção operacional | Quase zero | Alta (infra, versões, patches) |
| Portabilidade (multi-cloud) | Baixa, acoplado à AWS | Alta, roda em qualquer lugar |
| Custo em escala | Previsível, mas com mínimos por recurso | Otimizável, mas exige engenharia |
FinOps: os principais drivers de custo
Dúvidas frequentes
Preciso de um agente para usar Knowledge Bases?
Não. Você pode chamar a KB diretamente via API (Retrieve ou RetrieveAndGenerate) de qualquer aplicação. O agente é opcional, ele só adiciona orquestração automática e o loop ReAct.
O que acontece quando atualizo um documento no S3?
A KB não sincroniza automaticamente por padrão. Você precisa disparar uma operação de sync (manual, agendada via EventBridge, ou via API). Durante o sync, os documentos alterados são re-ingeridos e os vetores antigos substituídos.
Posso usar múltiplas Knowledge Bases num mesmo agente?
Sim. Cada KB aparece como uma ferramenta separada para o agente. Você pode ter uma KB para documentação técnica e outra para políticas internas, por exemplo. O agente decide qual consultar com base no contexto da pergunta.
Qual a diferença entre chunking fixo e semântico?
Chunking fixo divide o texto em blocos de N tokens com overlap configurável, simples e previsível. Chunking semântico usa um modelo para identificar fronteiras naturais de significado, gerando chunks mais coerentes mas com custo de processamento maior. Para a maioria dos casos, chunking fixo com overlap de 20% é um bom ponto de partida.
Quando usar o gerenciado, e quando não usar
Bedrock Knowledge Bases é a escolha certa para a maioria dos projetos que já rodam na AWS e precisam de RAG sem montar pipeline do zero. O ganho em velocidade de entrega é real. O custo de flexibilidade também é real: se você precisar de chunking customizado, re-rankers, ou lógica de recuperação híbrida complexa, vai bater no teto do serviço gerenciado mais cedo do que espera. Minha regra: comece gerenciado, meça, e só construa o próprio quando tiver evidência concreta de que o gerenciado não resolve, não por antecipação.