Amazon Bedrock Knowledge Bases: RAG gerenciado
O pipeline RAG como serviço gerenciado, você liga a fonte e ganha ingestão e recuperação.
6 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.
Montar um pipeline RAG do zero é instrutivo, mas em produção você vai querer delegar a infraestrutura de ingestão, chunking e indexação para focar no que realmente diferencia seu produto. O Amazon Bedrock Knowledge Bases faz exatamente isso: você conecta uma fonte de dados, escolhe o modelo de embedding e o vector store, e a AWS cuida do resto. Nesta aula vamos dissecar o que o serviço entrega, onde ele brilha e onde você ainda precisa das mãos na massa.
Fluxo: fonte de dados → Knowledge Base → app / agente
Dois caminhos de consumo: chamada direta da aplicação (Retrieve / RetrieveAndGenerate) e uso como ferramenta por um Bedrock Agent.
- Amazon S3 · PDFs, DOCX, HTML, MD
- Confluence / SharePoint · conectores nativos
- Web Crawler · URLs públicas
- Ingestão gerenciada · parse + chunk + embed
- Knowledge Base · configuração central
- Vector Store · OpenSearch / Aurora / etc.
- Retrieve API · retorna chunks + scores
- RetrieveAndGenerate · retrieval + LLM inline
- Bedrock Agent · usa KB como ferramenta
- Seu app / Lambda · consume resposta
O que o serviço entrega, e o que ele abstrai
O Bedrock Knowledge Bases gerencia quatro etapas que na aula 04 você montou manualmente: parse do documento, chunking, geração de embeddings e upsert no vector store. Você dispara um sync job (via console, SDK ou EventBridge) e o serviço processa os arquivos novos ou modificados no S3, ou nas outras fontes conectadas.
Para parsing, o serviço usa o Amazon Bedrock Data Automation (BDA) ou parsers nativos. O BDA consegue extrair texto de PDFs com tabelas e imagens usando modelos multimodais, útil quando seus documentos não são texto limpo. Para arquivos simples (Markdown, HTML, texto puro), o parser padrão é suficiente e mais barato.
Os embeddings são gerados pelos modelos disponíveis no Bedrock: Amazon Titan Embeddings, Cohere Embed e outros. Você escolhe o modelo uma vez na configuração da KB, e não muda depois sem reindexar tudo. Isso é uma decisão de arquitetura, não de operação: escolha com cuidado considerando dimensão do vetor, custo por token e suporte a múltiplos idiomas (relevante para conteúdo em português).
O resultado fica em um vector store que você provisiona: OpenSearch Serverless, Aurora PostgreSQL com pgvector, Redis Enterprise Cloud, MongoDB Atlas ou Pinecone. A aula 10 cobre cada opção em detalhe; aqui o ponto é que o Knowledge Bases não é um vector store, ele é a camada de orquestração acima dele.
Como a aplicação consome a Knowledge Base
Há duas APIs principais e um modo agêntico.
Retrieve retorna os chunks mais relevantes com scores de relevância e metadados (fonte, página, seção). Você usa esse modo quando quer controlar a geração, montar o prompt você mesmo, aplicar reranking adicional (aula 05), filtrar por metadados (aula 06) ou gerar com um modelo fora do Bedrock. É o modo mais flexível.
RetrieveAndGenerate faz tudo em uma chamada: busca os chunks, monta o prompt internamente e retorna a resposta gerada junto com as citações. Conveniente para protótipos e casos onde você não precisa customizar o prompt de sistema. A desvantagem é que você tem menos visibilidade e controle sobre o que acontece entre a busca e a geração.
Bedrock Agents podem usar uma Knowledge Base como ferramenta nativa. O agente decide quando consultar a KB com base na intenção do usuário, isso é o RAG agêntico que a aula 07 detalha. Na prática, você registra a KB no agente com uma descrição em linguagem natural ("use esta base para responder perguntas sobre políticas internas") e o modelo decide quando acionar a busca.
Os três modos suportam filtros de metadados: você pode restringir a busca por atributos como departamento, data_publicacao ou idioma sem alterar a query semântica. Isso é o mesmo mecanismo da aula 06, só que configurado via API em vez de diretamente no vector store.
Opções de chunking gerenciado
Na minha experiência, o Bedrock Knowledge Bases resolve bem 70-80% dos casos de RAG corporativo: documentos em S3, chunking padrão ou hierárquico, embedding Titan ou Cohere, OpenSearch Serverless como store. O tempo de setup cai de dias para horas. O problema aparece quando você precisa de chunking muito específico (ex.: processar código-fonte respeitando funções), quando quer reranking com modelo próprio, ou quando a latência do sync job não serve para documentos que mudam em tempo real. Nesses casos, o modo Custom Lambda ou um pipeline próprio (aulas 03/04) ainda é a escolha certa. Use o gerenciado como padrão e saia dele só quando tiver uma razão concreta.
Gerenciado vs. pipeline próprio
| Critério | Knowledge Bases (gerenciado) | Pipeline próprio |
|---|---|---|
| Tempo de setup | Horas | Dias a semanas |
| Controle de chunking | 4 estratégias + Lambda custom | Total, qualquer lógica |
| Reranking | Não nativo (use Retrieve + Lambda) | Qualquer modelo/serviço |
| Ingestão em tempo real | Sync job assíncrono (minutos) | Possível com pipeline streaming |
| Observabilidade | CloudWatch básico; menos granular | Você instrumenta, controle total |
| Custo operacional | Baixo, sem infra para manter | Alto, você opera tudo |
Onde os vetores vivem, e o que vem na próxima aula
O Knowledge Bases não armazena vetores internamente. Ele delega para um vector store que você escolhe e provisiona antes de criar a KB. As opções suportadas hoje são: OpenSearch Serverless (padrão mais comum na AWS), Aurora PostgreSQL com pgvector, Redis Enterprise Cloud, MongoDB Atlas e Pinecone.
Cada opção tem trade-offs diferentes em latência, custo, capacidade de filtro e operação. O OpenSearch Serverless é conveniente porque a AWS gerencia a escala, mas tem um custo mínimo mesmo sem tráfego. O Aurora com pgvector é uma boa escolha se você já usa RDS e quer consolidar infraestrutura. Redis é excelente para latência muito baixa em datasets menores.
A aula 10 cobre cada vector store em detalhe, capacidades de busca híbrida, modelo de custo, limites de escala e quando escolher cada um. Por ora, o ponto importante é: a escolha do vector store é separada da escolha de usar o Knowledge Bases. Você pode usar o serviço gerenciado para ingestão e ainda ter controle sobre qual store e qual configuração de índice usar.
Se você está começando um projeto novo, minha recomendação é: comece com Knowledge Bases + OpenSearch Serverless, meça, e só migre para um pipeline próprio se encontrar um limite concreto. A complexidade operacional de manter um pipeline RAG customizado tem um custo real que não aparece no benchmark inicial.
Configurando uma Knowledge Base: sequência mínima
- 1
Provisione o vector store
Crie a collection no OpenSearch Serverless (ou o cluster Aurora com pgvector). O KB vai precisar do ARN e das credenciais de acesso.
- 2
Crie a Knowledge Base no console ou via IaC
Escolha o modelo de embedding (ex.: Titan Embeddings V2), aponte para o vector store e defina a estratégia de chunking. Essa configuração não muda depois sem reindexar.
- 3
Conecte a fonte de dados
Para S3: informe o bucket e prefixo. Configure a IAM role com permissão de leitura no bucket e escrita no vector store.
- 4
Dispare o sync job
Via console, StartIngestionJob no SDK ou EventBridge Scheduler para sincronizações periódicas. O job é incremental, processa só o que mudou.
- 5
Teste com Retrieve antes de expor ao usuário
Use a API Retrieve com queries representativas do seu caso de uso. Verifique os scores, os chunks retornados e os metadados de fonte. Só depois integre o RetrieveAndGenerate ou o agente.
Perguntas frequentes
Posso usar o Knowledge Bases com modelos fora do Bedrock?
Sim, use a API Retrieve para buscar os chunks e passe o resultado para qualquer LLM. O RetrieveAndGenerate é que exige um modelo Bedrock, pois a geração acontece dentro do serviço.
O sync job é em tempo real?
Não. É um job assíncrono que você dispara manualmente ou agenda. Para documentos que mudam com frequência alta (segundos), um pipeline de ingestão próprio com upsert direto no vector store é mais adequado.
Posso ter múltiplas fontes na mesma KB?
Sim. Uma KB suporta múltiplas data sources (S3 buckets diferentes, Confluence, web crawler). Todos os documentos são indexados no mesmo vector store e ficam disponíveis na mesma busca, use filtros de metadados para separar por origem se necessário.
O que acontece se eu trocar o modelo de embedding?
Você precisa reindexar todo o conteúdo. Vetores gerados por modelos diferentes não são comparáveis, misturar embeddings de modelos distintos no mesmo índice produz resultados incorretos. Planeje essa decisão antes de ir para produção.