Como escolher o vector store certo para o Amazon Bedrock Knowledge Bases

O papel do vector store em soluções RAG

Ao construir uma solução de Geração Aumentada por Recuperação (RAG) com o Amazon Bedrock Knowledge Bases, a escolha do vector store tem impacto direto em desempenho e custo. O serviço oferece duas modalidades: uma opção totalmente gerenciada pela AWS e uma opção gerenciada pelo cliente, onde você escolhe o próprio vector store. A análise publicada pela AWS foca nessa segunda modalidade, comparando os três backends suportados: Amazon OpenSearch Service, Amazon Aurora PostgreSQL com pgvector e Amazon S3 Vectors.

Para entender por que essa escolha importa, vale relembrar como o RAG funciona. Numa arquitetura RAG, documentos são fragmentados em pedaços (chunks), convertidos em vetores por um modelo de embeddings e armazenados em um banco de dados vetorial. Quando um usuário faz uma pergunta, ela também é convertida em vetor e o sistema busca os chunks com maior similaridade semântica. Esses trechos são então fornecidos como contexto para o Modelo de Linguagem de Grande Escala (LLM), que gera uma resposta mais precisa e fundamentada.

O banco de dados vetorial é a peça central dessa arquitetura: ele transforma dados não estruturados em um espaço de conhecimento pesquisável e semanticamente significativo. Para isso, armazena os vetores em uma estrutura chamada índice vetorial, que viabiliza buscas semânticas de alta dimensionalidade com recuperação quase instantânea.

Os três backends disponíveis

O Amazon Bedrock Knowledge Bases na configuração gerenciada pelo cliente suporta três opções de vector store. Para uma visão do portfólio completo de soluções vetoriais da AWS, cobrindo seis serviços, a AWS recomenda consultar o post AWS vector solutions: Build agentic AI where your data lives.

• Amazon OpenSearch Service: entrega resultados de alta velocidade a partir de dados mantidos em memória. Suporta embeddings de alta dimensionalidade com opções de implantação em cluster gerenciado e serverless, além de busca k-NN e busca híbrida que combina abordagens lexicais e vetoriais.
• Amazon Aurora PostgreSQL com pgvector: combina as capacidades de banco de dados relacional de alto desempenho do Aurora com a funcionalidade de busca por similaridade vetorial do pgvector. Suporta múltiplos métodos de indexação (IVFFlat e HNSW), diferentes métricas de distância (L2, cosseno, produto interno) e vetores de até 2.000 dimensões em precisão simples.
• Amazon S3 Vectors: é o serviço de armazenamento de objetos da AWS com suporte nativo a vetores, projetado para armazenamento e consulta de embeddings em escala com custo reduzido. Oferece desempenho de consulta abaixo de um segundo e pode reduzir os custos de armazenamento vetorial em até 90% em comparação com bancos de dados vetoriais tradicionais.

Caso de uso 1: busca em catálogo de produtos

Por que o Amazon OpenSearch é a melhor opção aqui

Plataformas de e-commerce precisam ajudar clientes a encontrar produtos entre milhares de opções, com linguagem natural e sob alta concorrência de requisições. O Amazon OpenSearch Serverless se encaixa bem nesse cenário por suportar busca híbrida — combinando compreensão semântica com correspondência de palavras-chave — e por entregar latências na faixa de poucos milissegundos. Além disso, oferece suporte nativo a filtros complexos e agregações, que alimentam a navegação facetada (filtragem por preço, marca, cor, etc.).

Análise de desempenho e otimizações

O OpenSearch oferece diversas opções de configuração que afetam diretamente o desempenho do índice vetorial. As principais alavancas são:

• Dimensão dos embeddings: vetores maiores geralmente carregam mais informação semântica, mas aumentam o consumo de memória e o custo. Modelos como o Amazon Titan Text Embedding v2 permitem escolher entre dimensões de 1024, 512 ou 256.
• Tipo de dado dos embeddings: armazenar embeddings em tipos de dados de menor precisão, como embeddings binários, reduz significativamente o tamanho do índice.
• Armazenamento otimizado em disco: as coleções Classic do Amazon OpenSearch Serverless oferecem busca vetorial baseada em disco (modo on_disk), que aplica quantização binária 32× internamente e refaz o score contra vetores de precisão total lidos do disco. Preserva a qualidade com menor footprint em memória, ao custo de maior latência.

Para configuração dos parâmetros HNSW (ef_construction, m), a AWS disponibiliza um guia prático para seleção de hiperparâmetros HNSW. Após definir dimensão e tipo de dado, o recurso de auto-otimização pode eliminar o ajuste manual restante de HNSW e quantização em menos de uma hora.

Resultados dos benchmarks (busca semântica)

Os testes usaram o dataset “Shopping Queries Data Set” (ESCI), com 1.215.851 produtos únicos e 97.345 consultas avaliadas. Foram testadas sete configurações combinando dimensão (1024, 512, 256) e tipo de dado (float, binário), além do modo on_disk. Os principais achados foram:

• Reduzir dimensões nem sempre reduz qualidade: a configuração 512-float foi estatisticamente indistinguível da baseline 1024-float (NDCG 0,3628 vs 0,3627) com metade do tamanho do índice (2,79 vs 5,34 GiB) e latência menor (25 vs 31 ms p50).
• Binarização oferece grandes reduções de tamanho, mas com custo variável: embeddings binários de 1024 dimensões reduziram o índice em 13,4× (0,40 vs 5,34 GiB) com perda de 5,2% no Ganho Cumulativo Descontado Normalizado (NDCG). Em 256 dimensões, a perda subiu para 28,3%.
• Modo on_disk preserva qualidade ao custo de latência: com 1024 dimensões, o modo on_disk atingiu NDCG 0,3610 (−0,5% vs baseline) com o mesmo tamanho de índice do binário 1024, mas com latência aproximadamente 3× maior (99 ms p50 vs 31 ms em memória).

Resultados da busca híbrida

A busca híbrida (semântica + BM25, com ponderação 0,7/0,3) melhorou consistentemente a qualidade de recuperação. No dataset, a busca híbrida elevou o NDCG em +6,0% sobre a busca semântica pura, tanto para float (0,3633 → 0,3850) quanto para binário (0,3451 → 0,3658). Um resultado notável: embeddings binários de 1024 dimensões com busca híbrida (NDCG 0,3658) superaram embeddings float de 1024 dimensões com busca semântica pura (NDCG 0,3633), usando 13× menos memória. A busca híbrida adiciona latência — a etapa de fusão praticamente dobra a latência sequencial — e a diferença se amplia sob alta concorrência.

Caso de uso 2: agente de pesquisa profunda

Por que o Amazon S3 Vectors é a melhor opção aqui

Agentes de pesquisa profunda representam uma evolução significativa além dos sistemas RAG tradicionais. Eles lidam com tarefas complexas e de múltiplas etapas por meio de raciocínio dinâmico, planejamento adaptativo e recuperação iterativa de informações, podendo operar por minutos ou horas. Nesses cenários, eficiência de custo e escalabilidade importam muito mais do que velocidade de consulta.

Para esse perfil, o Amazon S3 Vectors é uma opção prática e eficiente. Ele reduz significativamente o custo de armazenamento e consulta de vetores em comparação com bancos de dados vetoriais tradicionais, tornando viável trabalhar com bilhões de embeddings. Escala elasticamente sem provisionamento de infraestrutura, suportando dezenas de milhões de vetores por índice e milhares de índices por bucket. Seu modelo de preço pay-as-you-go é especialmente adequado para cargas de trabalho de pesquisa com padrões de uso variáveis.

Resultados dos benchmarks

Os testes utilizaram um subconjunto da Wikipedia em inglês com mais de 6 milhões de artigos, fragmentados em segmentos de ~300 tokens e indexados com Amazon Titan Text Embedding v2 (1024 dimensões, similaridade de cosseno). Foram medidas latências de consulta em quatro tamanhos de índice (5K, 250K, 500K e 1M vetores), recuperando os 50 vetores mais similares por consulta.

Os principais achados foram:

• Escalonamento sub-linear: a latência cresce muito mais devagar que o tamanho do índice. De 5K para 1M vetores (aumento de 200×), a latência p50 cresceu apenas ~3,5× (82ms → 294ms).
• Cauda de latência estável em escala: a partir de 500K vetores, a diferença entre p50 e p95 se estabiliza em ~100–120ms, indicando desempenho previsível mesmo com crescimento do corpus.
• Consultas abaixo de 1 segundo em escala: mesmo com 1 milhão de vetores, a latência p99 fica abaixo de 510ms — aceitável para agentes que passam segundos raciocinando sobre o contexto recuperado.

Integração com Amazon OpenSearch para busca híbrida

Para cargas de trabalho de pesquisa que exigem capacidades avançadas de busca além da similaridade vetorial pura, o S3 Vectors se integra ao Amazon OpenSearch Service em dois padrões complementares. O primeiro usa o S3 Vectors como mecanismo de armazenamento dentro de clusters gerenciados do OpenSearch, permitindo usar busca híbrida e filtros complexos com baixo custo de armazenamento. O segundo padrão suporta exportações pontuais de índices S3 Vectors para coleções do OpenSearch Serverless quando subconjuntos específicos de dados exigem alta taxa de consultas ou latência abaixo de 100ms para aplicações em tempo real.

Caso de uso 3: chatbot RAG voltado ao cliente

Por que o Aurora PostgreSQL é a melhor opção aqui

Chatbots voltados ao cliente precisam responder com rapidez, com base em uma base de conhecimento interna que nem sempre usa as mesmas palavras que o cliente usa na pergunta. Para bases de conhecimento grandes, o Amazon Aurora PostgreSQL com pgvector equilibra capacidade e desempenho, e oferece a flexibilidade de alternar entre métodos de indexação para otimizar a recuperação para cada dataset.

O PostgreSQL oferece dois algoritmos principais para busca vetorial:

• HNSW (Mundo Pequeno Hierárquico Navegável): constrói um grafo multicamadas para busca aproximada de vizinhos mais próximos, oferecendo consultas mais rápidas ao custo de maior uso de memória e builds de índice mais lentos.
• IVFFlat (Arquivo Invertido com compressão Flat): particiona vetores em clusters para busca eficiente, usando menos memória mas exigindo reindexação periódica conforme os dados mudam.

Para uma comparação detalhada desses algoritmos, a AWS publicou o post Otimize aplicações de IA generativa com indexação pgvector: um mergulho profundo em IVFFlat e HNSW.

Resultados dos benchmarks

O ambiente de teste utilizou uma base de conhecimento com 500.000 chunks, 5.000 consultas aleatorizadas com embeddings de 1024 dimensões e Amazon Aurora v15.15. Os resultados de latência foram:

• HNSW: p50 = 31,91 ms | p95 = 38,20 ms | p99 = 89,00 ms
• IVFFlat: p50 = 35,94 ms | p95 = 42,38 ms | p99 = 94,08 ms

Ambos os tipos de índice entregam latências adequadas para respostas em tempo real em chatbots, com tempos medianos abaixo de 50ms. O HNSW foi 4ms mais rápido na mediana. A latência p95 ficou abaixo de 60ms para ambos, indicando desempenho previsível para a grande maioria das consultas.

Guia de seleção para o Amazon Bedrock Knowledge Bases

A AWS organiza a escolha em três passos. Para o framework completo de seleção cobrindo todos os seis serviços vetoriais, consulte o modelo de decisão em AWS vector solutions: Build agentic AI where your data lives.

Passo 1: identifique o perfil da sua aplicação

A maioria das aplicações se encaixa claramente em um destes três perfis:

• Busca em tempo real (ex: catálogo de produtos, autocompletar, navegação facetada): tolerância de latência <50ms, alto volume de consultas concorrentes, busca híbrida frequentemente crítica.
• IA conversacional (ex: chatbot de suporte, assistente de conhecimento interno): tolerância de latência <100ms, volume moderado com sessões, busca híbrida às vezes útil.
• Processamento em background (ex: agentes de pesquisa, análise em lote): tolerância de latência <1 segundo, baixa frequência de consultas complexas, custo-eficiência como prioridade.

Passo 2: mapeie o perfil para um banco de dados vetorial

• Baixa latência (<50ms) com busca híbrida → Amazon OpenSearch Service: latência de milissegundos com indexação HNSW em memória e suporte nativo à combinação de busca lexical e vetorial.
• Latência balanceada (~100ms) com necessidades relacionais → Aurora PostgreSQL com pgvector: consultas abaixo de 50ms, suporte a A/B testing de tipos de índice (HNSW vs IVFFlat) e integração natural com workflows PostgreSQL existentes.
• Armazenamento custo-eficiente em grande escala → Amazon S3 Vectors: reduz custos de armazenamento vetorial em até 90%, escala elasticamente para milhões de vetores sem infraestrutura a gerenciar.

Passo 3: considere o caminho de crescimento

A escolha inicial não precisa ser definitiva. Os serviços se complementam conforme as necessidades evoluem:

• Comece com o S3 Vectors para protótipos ou cargas de trabalho sensíveis a custo. Se precisar de consultas mais rápidas para um subconjunto dos dados, é possível exportar vetores para o OpenSearch ou Aurora sem precisar re-gerar embeddings.
• Comece com o Aurora PostgreSQL se precisar combinar resultados vetoriais com dados relacionais em uma única consulta — é a única opção aqui capaz de fazer isso. Também é a escolha natural para equipes que já operam PostgreSQL.
• Comece com o OpenSearch se latência abaixo de 20ms ou busca híbrida for um requisito desde o primeiro dia. O S3 Vectors pode ser usado como backing store de custo reduzido para o corpus completo, enquanto o OpenSearch serve as consultas em tempo real.

O padrão de armazenamento em camadas é especialmente poderoso para aplicações que crescem além de um único caso de uso: use o S3 Vectors para o corpus completo e o OpenSearch Service ou Aurora para subconjuntos críticos de desempenho.

Conclusão

A análise publicada pela AWS deixa claro que não existe uma opção universalmente superior — cada backend tem um perfil distinto. O Amazon OpenSearch Serverless brilha onde desempenho em tempo real e busca híbrida são requisitos. O Aurora PostgreSQL com pgvector oferece um meio-termo equilibrado para aplicações conversacionais, com familiaridade operacional do PostgreSQL e flexibilidade para iterar nas estratégias de indexação. O S3 Vectors atende cargas de trabalho em grande escala sensíveis a custo, permitindo armazenar e consultar milhões de embeddings sem overhead de infraestrutura dedicada.

Vale ressaltar que os exemplos e benchmarks do post original foram executados em cargas de trabalho separadas, adaptadas a cada banco de dados — não são comparações diretas em um dataset compartilhado. Os números ilustram o perfil de trade-offs de cada opção, não um ranking absoluto. A recomendação da AWS é usar as metodologias de benchmark apresentadas para avaliar as opções contra seus próprios dados e padrões de consulta.

Fonte

Selecting a vector store for Amazon Bedrock Knowledge Bases (https://aws.amazon.com/blogs/machine-learning/selecting-a-vector-store-for-amazon-bedrock-knowledge-bases/)