Calculadora de Dimensionamento e Seleção de Banco de Dados Vetorial
A questão prática por trás de um banco de dados vetorial auto-hospedado para RAG é qual mecanismo se adapta a um determinado servidor e qual deles a carga de trabalho descarta. A calculadora abaixo responde a ambas, a partir do nosso benchmark de sete bancos de dados vetoriais auto-hospedados executados com recall correspondente em embeddings idênticos.
Métricas da calculadora explicadas
Cinco caixas de seleção no topo da calculadora nomeiam cinco cargas de trabalho RAG comuns, e cada uma mapeia para um limite medido do benchmark, em vez de uma alegação de fornecedor. Marcar uma filtra a lista de mecanismos em relação a um número específico. Deixá-la desmarcada significa que a carga de trabalho não se aplica e nenhum mecanismo é filtrado por ela. O que cada interruptor pede, e a medição por trás dele:
Seleção e dimensionamento
Duas decisões precedem um índice em execução. A primeira é a seleção, porque alguns mecanismos não conseguem realizar um determinado trabalho. A calculadora verifica cada mecanismo em relação aos cinco interruptores de requisito acima e descarta os que falham. A segunda é o dimensionamento, ou seja, quais dos mecanismos sobreviventes cabem na máquina e com qual margem de folga. Para cada sobrevivente, ela relata se encaixa, apertado ou não encaixa, mais o número de vetores que o servidor comportaria. Nenhuma decisão depende da qualidade da recuperação, porque os sete mecanismos empatam dentro de uma dispersão de 0.014 nDCG em relação a um oráculo kNN exato.
Pegada em 2.25M vetores
Em 2.25M vetores, o benchmark mediu duas pegadas, divididas por onde o índice reside. Para os cinco mecanismos em memória, registrou o pico de RAM durante a construção e serviço, de 17.0 GB (Milvus) a 62.4 GB (Chroma). Para os dois mecanismos em disco, registrou o índice em disco, 12.0 GB para LanceDB e 18.4 GB para pgvector, que custa muito menos por gigabyte. Esses números são as medições brutas, não as entradas de dimensionamento da calculadora. A calculadora dimensiona o serviço em estado estacionário.
Para os mecanismos em memória, isso fica abaixo do pico de construção e serviço, e para os mecanismos em disco, adiciona a cópia da tabela e o texto dos chunks sobre o índice medido, de modo que para o mesmo corpus de 2.25M seus números resultam mais baixos em RAM e mais altos em disco do que as barras aqui. A divisão medida versus modelada abaixo reconcilia os dois. O benchmark completo por mecanismo por trás da calculadora, abrangendo precisão, velocidade, busca filtrada e híbrida, custo de construção e rotatividade ao vivo, comparação de banco de dados vetorial de código aberto.
O modelo de dimensionamento
As entradas são o tamanho do corpus, a divisão em chunks e o modelo de embedding, e a calculadora deriva os dois números que orientam o dimensionamento. O tamanho do corpus e a divisão em chunks fornecem a contagem de vetores. Um corpus de 2 GB (decimal, 2 bilhões de bytes) a 4 bytes por token é 500M tokens, e chunks de 512 tokens com 15% de sobreposição avançam um passo de 512 × 0.85 = 435.2 tokens, portanto a contagem é round(500M ÷ 435.2) = 1,148,897 vetores. O modelo de embedding fornece a dimensão, portanto a entrada é uma escolha de modelo, não um número bruto, e o bge-m3 a define em 1024.
A pegada de cada mecanismo é então um custo por vetor multiplicado pela contagem de vetores, mais um piso de processo fixo: footprint = base_gb + bytes_per_vector × N. O custo por vetor é onde os mecanismos divergem, pois um banco de dados vetorial armazena mais do que o vetor bruto. Ele também mantém o grafo de índice que torna a busca rápida e, para RAG real, o texto do chunk que deve retornar. A tabela abaixo é o custo por vetor que o layout de armazenamento de cada mecanismo produz em 1024 dimensões em float32.
Dois fatos de layout fazem a maior parte da separação. O Redis mantém uma segunda cópia de cada vetor (um hash de origem mais uma cópia no índice) e não pode descarregar o texto do chunk, portanto é o mais pesado em RAM. O pgvector também armazena cada vetor duas vezes em disco, uma vez no heap da tabela e outra dentro do índice HNSW, e seu índice arredonda para páginas de 8 KB do Postgres, portanto um vetor float32 de 1024 dimensões preenche uma página inteira por si só. Os outros quatro mecanismos em memória descarregam o texto do chunk para o disco, portanto seu custo de RAM é o vetor mais um pequeno grafo. O interruptor 'Store chunk text' controla essa carga, cerca de 2 KB por vetor em 512 tokens. O Redis a mantém em RAM, todos os outros mecanismos a mantêm em disco, e desligar o interruptor a remove em todos os lugares.
O piso do processo é adicionado uma vez por mecanismo: 2.0 GB para Milvus, 0.5 para Weaviate, 0.3 para Chroma, 0.2 para Qdrant, 0.05 para Redis, e 0 para os dois mecanismos em disco. Juntando para o corpus padrão de 2 GB (1.15M vetores) em um servidor de 16 GB, 200 GB, o Qdrant precisa de 5.1 GB de RAM, Milvus e Weaviate 6.9 GB, Redis 12.5 GB, enquanto pgvector precisa de 16.5 GB de disco e LanceDB 8.5 GB.
O veredito compara essa pegada com a máquina no recurso vinculante, e a linha de 80% é margem de folga deliberada. Em ou abaixo de 80% da RAM ou do disco, ele lê 'encaixa', o que deixa cerca de um quinto da máquina para cache de páginas do SO, buffers de consulta e crescimento. De 80 a 100% é apertado, e mais não encaixa. A figura é de serviço em estado estacionário, portanto construir ou reconstruir o índice na mesma máquina precisa de mais RAM durante esse período, mais próximo do pico medido. Executando a mesma fórmula de trás para frente obtém-se a capacidade, (box − base) ÷ bytes_per_vector: o mesmo servidor de 16 GB comporta nominalmente 1.47M vetores no Redis, 3.7M no Qdrant e, em seu disco de 200 GB, 14.0M no pgvector e 27.1M no LanceDB, cada um dentro da faixa de erro que a ferramenta mostra ao lado, em vez de um limite rígido. Ativar a quantização divide a parte do vetor (int8 por 4x, quantização de produto por 16x, binário por 32x) para os mecanismos que o suportam, e mudar o modelo de embedding reescala todos os números através da dimensão.
Medido versus modelado
A calculadora separa o que o benchmark mediu do que modela, pois os dois carregam confiança diferente. Os números de RAM que o benchmark registrou são um pico de construção e serviço, que é aproximadamente duas a três vezes maior que o serviço em estado estacionário, e para o Weaviate foi inflado por um alto limite de memória Go. A calculadora não dimensiona a partir desse pico. Ela dimensiona os cinco mecanismos em memória a partir da própria fórmula de serviço documentada de cada fornecedor, os custos aditivos de vetor mais grafo na tabela, e mantém o pico medido como uma verificação de limite superior. Portanto, a medição registra o que o benchmark observou, enquanto o dimensionamento fica abaixo disso propositalmente.
Os dois mecanismos em disco são o inverso. Seu índice em disco foi medido diretamente e manteve-se dentro de 1 a 2 por cento em um corpus de validação, portanto a calculadora os dimensiona a partir da medição. Cada capacidade carrega uma faixa de erro visível que reflete essa divisão: 25 a 30 por cento para as estimativas de serviço em memória modeladas, 15 por cento para pgvector, e 1 a 2 por cento para o disco medido do LanceDB. Duas entradas são rotuladas como suposições, em vez de medições. O cache de RAM para os mecanismos em disco é definido em 25 por cento do índice e é editável, porque sua RAM de serviço nunca foi medida, e as taxas de quantização vêm da literatura, não deste benchmark, portanto a perda real de recall varia com os dados.
O portão da capacidade
A metade de seleção da calculadora é um conjunto de fatos binários, não uma pontuação. A tabela abaixo é o lado por mecanismo dos interruptores acima. Para cada mecanismo, ela mostra as cargas de trabalho que o eliminam e aquelas que ele ainda realiza, mas a uma taxa sinalizada. Milvus e Weaviate não têm eliminação em nenhum interruptor, razão pela qual são lidos como os generalistas limpos.
O Redis é sinalizado em vez de eliminado em durabilidade porque pode ser tornado à prova de falhas com um arquivo append-only. Ele foi benchmarked com persistência desligada, portanto a sinalização indica que o limite é da nossa configuração, não do mecanismo.
Adicionar como fonte preferencialMetodologia do benchmark
Os números vêm de um benchmark em servidor único dos sete mecanismos, cada um executado em seu próprio contêiner Docker fixado em um Hetzner CCX53 (32 vCPU, 128 GB RAM, NVMe). Cada mecanismo indexou os mesmos vetores bge-m3 (1024 dim, cosseno em float32 normalizado L2) e foi lido com um Recall@10 correspondente de 0.95 alcançado por varredura de seu ef ou nprobe, com k=10 e semente 42. Os corpora foram MedRAG-50k e TechQA-28k para qualidade e uma camada MedRAG de 2.25M vetores para escala. As estatísticas completas, intervalos de confiança e versões por mecanismo estão no artigo do benchmark.
Limitações
Os números de serviço em memória são fórmulas de fornecedor calibradas contra um pico de construção e serviço, não uma medição direta de serviço, portanto carregam a faixa de 25 a 30 por cento que a calculadora mostra. A RAM de serviço para pgvector e LanceDB é uma suposição de cache não medida, razão pela qual a calculadora dimensiona esses dois em disco. As formas de implantação também diferem por design. O LanceDB é uma biblioteca incorporada, o pgvector é uma extensão do PostgreSQL, os outros cinco são servidores independentes, e o Redis executou com persistência desligada, portanto a pegada e as taxas de cada mecanismo refletem sua própria forma operacional, em vez de uma configuração idêntica. O benchmark usou um modelo de embedding com 1024 dimensões, portanto um modelo diferente ou contagem de dimensões desloca todas as pegadas, razão pela qual o modelo é uma entrada e não um número fixo. Mecanismos gerenciados e hospedados na nuvem são uma comparação separada.
Conclusão
Para um banco de dados vetorial auto-hospedado em RAG, a escolha é um problema de dimensionamento e seleção, não de precisão, já que os sete mecanismos ficam dentro de 0.014 nDCG entre si. A calculadora transforma a matemática de pegada e os limites de carga de trabalho medidos em uma resposta para um servidor específico, em vez de um ranking. Em uma máquina de 16 GB com 1024 dimensões, comporta 1.5M vetores no Redis até 3.7M no Qdrant em RAM, e 14M a 27M nos mecanismos em disco, e ativar uma carga de trabalho com alta rotatividade elimina Chroma e LanceDB, enquanto deixa Milvus e Weaviate livres. O benchmark medido por trás de cada um desses números é a comparação de banco de dados vetorial de código aberto.
Leitura adicional
- Benchmark de modelos de embedding
- Benchmark de reranker
- Banco de dados vetorial para RAG
- Modelos de embedding de código aberto
- Modelos de embedding multilíngues
- Embeddings multimodais
- Frameworks de RAG agênticos
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Calculadora de Dimensionamento e Seleção de Banco de Dados Vetorial}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/vector-database-for-rag}},
note = {AIMultiple. Acessado em 20 Julho 2026}
}
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.