Benchmark de Bancos de Dados Vetoriais: 7 Motores de Código Aberto para RAG

Fizemos o benchmark de sete bancos de dados vetoriais de código aberto e auto-hospedados como camada de recuperação de um pipeline de RAG, cada um executado individualmente em embeddings bge-m3 idênticos e consultas médicas e técnicas reais, de modo que o índice do banco de dados foi a única variável. A carga de trabalho abrangeu MedRAG-50k, TechQA-28k e um corpus de 2.25M vetores em oito dimensões, desde precisão e qualidade de recuperação até velocidade, memória, busca filtrada e híbrida, custo de construção e rotatividade ativa.

Velocidade de thread única

Cada motor é avaliado no mesmo nível de recall, o ponto de operação compartilhado onde seu parâmetro de busca (seja ef ou nprobe) é ajustado até atingir um Recall@10 de 0.95, permitindo uma comparação justa dos números de velocidade.

Em uma única thread de cliente, o Redis serve 764 QPS no MedRAG-50k com 559 MB de pico de RAM, a maior taxa de transferência e a menor memória do conjunto. A ordem de thread única é Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70, uma diferença de 10x do topo ao fundo. O LanceDB é o outlier em disco, trocando RAM por latência com um p95 próximo de 22 ms. O Redis continua mais rápido e o LanceDB mais lento no TechQA-28k (651 a 81) e em 2.25M (495 a 28), embora o meio se reorganize em escala, onde o Milvus cai do terceiro para o sexto lugar.

Para RAG, a latência de cauda impulsiona a experiência do usuário mais do que a taxa de transferência bruta. A latência por consulta, agrupada em 100 execuções de 154 consultas com recall correspondente, acompanha a ordem de taxa de transferência.

O Redis foi executado com persistência desativada (sem snapshot RDB ou arquivo append-only), portanto seus números de velocidade e memória são para uma configuração volátil, sem durabilidade.

Taxa de transferência sob concorrência

O QPS de thread única responde o quão rápida é uma consulta. A questão de produção é a taxa de transferência sob muitos clientes concorrentes, e a resposta depende de como o cliente é construído, não apenas do banco de dados.

Um cliente de loop fechado pode ser conduzido de duas maneiras, e ambas são comuns em aplicações Python de RAG. Um processo assíncrono ou com threads desserializa cada resultado concorrente (gRPC/protobuf ou RESP) em um único GIL, portanto o cliente, não o servidor, limita a taxa de transferência. Vários processos de trabalho (o padrão gunicorn -w N) cada um obtém seu próprio GIL, expondo muito mais da capacidade do servidor. Medimos ambos em uma caixa de 32 vCPUs com um ef fixo de 128, e verificamos o recall em cada ponto.

À medida que a concorrência de solicitações aumenta de 1 para 512 em até 32 processos de trabalho, as linhas de taxa de transferência se cruzam. O Redis começa mais alto com uma solicitação e termina mais baixo, enquanto o Weaviate sobe do final do grupo para um platô de 8330 QPS em 512 solicitações, passando por 7,114 no caminho em 32. Em um único processo assíncrono, a classificação acompanha a eficiência de análise do cliente Python, já que o RESP do Redis é o mais leve para desserializar e perde menos para o GIL.

O pico de processo único de cada motor e o pico de 32 processos são os tetos em toda a varredura de 1 a 512, não a taxa de transferência em qualquer contagem de solicitações.

O Redis detém a menor latência de consulta única do conjunto (cerca de 1.6 ms) e seu núcleo de busca de thread única satura em torno de 1642 QPS com 32 solicitações concorrentes, e depois anti-escala além disso (o pool de threads de consulta WORKERS do RediSearch está desativado por padrão). O Weaviate e o Milvus (servidores multithread) e o pgvector (um backend Postgres independente por conexão) escalam nos 32 núcleos. O pgvector tem o menor pico de processo único (536) e o segundo maior pico de 32 processos (4832). Sob um orçamento de p99 abaixo de 100ms, a ordem de múltiplos processos é Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.

A análise gRPC mais pesada do Qdrant torna seu número co-localizado limitado pelo cliente, não pelo servidor, já que apenas a contagem de processos o move de 455 QPS em um processo para 1859 em 32. Chroma e LanceDB foram excluídos da execução de múltiplos processos. O Chroma fixa o ef na criação da coleção e anti-escala, com um p99 de 13 segundos em 512 solicitações, e o LanceDB é incorporado, portanto a história do cliente de rede não se aplica.

Consumo de memória

Em 50k vetores, o pico de RAM varia de 559 MB (Redis, em RAM, persistência desativada) a 3,300 MB (Milvus), com Weaviate em 1,201, LanceDB em 1,574, Chroma em 1,800 e pgvector em 2,024. A classificação muda em 2.25M, onde a troca entre memória e disco se abre.

O pico de RAM em 2.25M, nos cinco motores em memória, varia de 17.0 GB (Milvus) a 62.4 GB (Chroma), uma faixa de 3.7x, ou 7.5 GB a 27.7 GB por milhão de vetores. O Milvus permanece o mais enxuto porque descarrega o índice para disco (estilo DiskANN), enquanto os motores HNSW totalmente em RAM crescem mais rápido, de modo que o Milvus, o mais pesado em 50k (3,300 MB), é o mais enxuto em 2.25M (17.0 GB), com o Chroma o mais pesado em 62.4 GB.

Os dois motores em disco ficam fora dessa comparação de RAM porque sua pegada é em disco, não em RAM. O pgvector mantém um índice em disco de 18.4 GB e o LanceDB um de 12.0 GB em 2.25M, e sua RAM de serviço é um cache de página sobre esse índice, não o conjunto de trabalho completo, que não foi medido. Uma ressalva também se aplica aos números em memória. Eles representam uma marca d'água alta de construção e serviço, não apenas a pegada de serviço, portanto uma nova medição apenas de serviço é um refinamento em aberto.

Atualização, escritas e exclusões sob rotatividade ativa

As outras sete dimensões medem uma carga estática de leitura após inserção em lote. As bases de conhecimento reais de RAG adicionam, atualizam e excluem documentos continuamente enquanto o índice mescla em segundo plano. Essa carga de rotatividade foi executada no MedRAG-50k em uma caixa separada de 8 vCPUs, portanto sua taxa de transferência é interna a esta seção e não comparável aos números de velocidade de 32 núcleos. Os sinais de correção (verificações de recall e tombstone) são independentes do hardware.

Atualização (leitura após escrita). Na configuração de consistência com que cada motor foi configurado, todos são de leitura após escrita. Um documento recém-escrito é pesquisável imediatamente, com zero de cerca de 150 escritas não visíveis. A latência de confirmação de escrita até a visibilidade na pesquisa é de 2 ms p50 para Redis, 4 ms para Weaviate, 9 ms para Qdrant, 12 ms para Milvus, 14 ms para pgvector, 31 ms para LanceDB e 41 ms para Chroma. O Milvus encontra a nova linha por meio de uma varredura de consistência forte do segmento em crescimento ainda não selado (o vetor entra no grafo HNSW persistente posteriormente), portanto seus 12 ms representam a pesquisabilidade do segmento em crescimento, uma leitura após escrita válida voltada ao usuário.

Escritas e leituras sob carga mista. Com um escritor visando 150 escritas/s e seis leitores consultando por 60 segundos, o recall de leitura manteve-se entre 0.96 e 1.00 para todos os motores, e nenhum índice se degradou sob escritas concorrentes. A taxa de transferência de escrita de linha única separa os motores por 57x, e a ordem é próxima ao inverso da classificação de construção estática.

O LanceDB paga um commit copy-on-write por linha e o Chroma uma adição HTTP por linha, razão pela qual os construtores estáticos mais rápidos são os mais lentos sob rotatividade. A taxa de transferência de escrita aqui é a taxa alcançada contra uma meta de 150/s sob leituras concorrentes, portanto os motores rápidos são limitados perto de 150 em vez de mostrar seu pico. Leia isso como comportamento de escrita online de alta frequência e linha única, não ingestão em lote, que é o ponto de design desses motores e não foi testado aqui.

Exclusão e compactação. Ao excluir aleatoriamente 20% do conjunto ativo e reinserir 20% de novos documentos, o vazamento de tombstone foi zero para todos os motores. Um id excluído nunca ressurgiu na pesquisa, e o Recall@10 permaneceu de 0.97 a 1.00 após o ciclo completo. A correção se mantém sob rotatividade em todos os lugares. O custo difere por motor. O pgvector paga um VACUUM de 53 segundos e o Milvus uma compactação de 11 segundos, enquanto a reinserção domina nos motores de escrita lenta (Chroma 276 s, LanceDB 1139 s para cerca de 6,000 documentos).

O Weaviate executou esta seção com 3,000 documentos iniciais em vez de 30,000 (sua ingestão em lote síncrona é lenta na caixa pequena), portanto seu QPS de leitura é em um corpus menor. Nessa escala, sua atualização corrigida é de cerca de 5 ms e sua taxa de escrita cerca de 102/s, o que coloca ambos no meio do grupo.

Métricas explicadas

Recall ANN@10 é a fração dos 10 verdadeiros vizinhos mais próximos (de acordo com um oráculo kNN exato de força bruta sobre os mesmos embeddings que o DB indexou) que o índice aproximado retornou. Ele isola o banco de dados (tipo de índice, ef/nprobe, implementação), não o embedding.

nDCG@10 é uma pontuação ponderada pela posição de 0 a 1 que indica se o documento correto rotulado por humanos aparece perto do topo da lista de resultados. Ele mede a relevância da recuperação ponta a ponta, que é em grande parte uma propriedade do modelo de embedding, mantida constante aqui em todos os motores.

Δ (ponte delta) é o nDCG@10 do oráculo menos o nDCG@10 do banco de dados em uma determinada configuração de busca. Ele converte o erro de aproximação de cada motor na qualidade de resposta que sua velocidade custa, reportável porque mantemos tanto um oráculo quanto rótulos humanos.

Descobertas do benchmark de bancos de dados vetoriais

Os sete motores empatam na precisão da recuperação

Em Recall@10 = 0.95 no MedRAG-50k, o nDCG@10 fica entre 0.803 (pgvector) e 0.817 (LanceDB), uma diferença de 0.014. A ponte delta-para-oráculo varia de 0.009 (LanceDB) a 0.023 (pgvector), portanto a aproximação do banco de dados custa no máximo 0.023 pontos de nDCG de qualidade de resposta.

Sob este embedding, corpus, k=10 e ponto de operação de 0.95, a escolha do banco de dados move o nDCG@10 em no máximo 0.014, contra a diferença de 10x na taxa de transferência de thread única e a diferença de 3.7x no pico de memória mostrada acima. A escolha do índice começa a mover a qualidade em Recall@10 = 0.99 ou superior, em k maior, em corpora muito maiores ou com índices quantizados.

A confiabilidade da recuperação varia mais pelo que uma consulta pergunta do que por qual banco de dados responde. Nas 154 consultas MedRAG no oráculo kNN exato, as buscas factuais pontuam 0.888 nDCG@10, questões condicionais 0.836, questões comparativas 0.779 e questões de existência de cláusula 0.763. A lacuna de 0.125 entre factuais e de existência de cláusula está presente de forma idêntica em todos os sete motores.

Filtros de metadados custam taxa de transferência, não recall

Com um predicado de metadados aplicado, o pior caso de Recall@10 permanece entre 0.968 (Redis) e 1.00 (Weaviate, pgvector, LanceDB) em uma grade de seletividade (1/5/20/50%) e correlação de predicado (espalhada e agrupada). A separação está na taxa de transferência filtrada.

A separação está na taxa de transferência. Chroma (11-19 QPS) e pgvector (10-56 QPS) mantêm o recall com taxa de transferência filtrada 20 a 40x menor que os demais. O Milvus mantém o maior recall de pior caso (0.984) com 268 a 732 QPS através da seletividade, enquanto o Redis é o mais rápido em baixa seletividade (1,374 QPS em 1%) com um piso de recall mais baixo (0.968). Com seletividade de 1-5%, um recall de 1.00 é em grande parte o ramo de varredura completa exata do planejador de consultas abaixo do limite de varredura completa de cada motor, não HNSW filtrável, divulgado por motor.

*O recall filtrado do LanceDB foi medido inicialmente em 0.24 em filtros agrupados, depois retratado. A varredura variou ef, mas o botão de recall do LanceDB é nprobes, portanto ele executou com um padrão de cerca de 9% das partições. Medido novamente com nprobes adequados, o Recall@10 agrupado se recupera de 0.24 para 0.76 (nprobes=128) até cerca de 1.00 (nprobes=256), com QPS 3 a 5x menor. O LanceDB mantém o recall filtrado, lentamente. Uma nova medição de taxa de transferência filtrada com recall correspondente e mesmo host ainda está pendente, portanto o QPS filtrado do LanceDB não está listado.

A busca híbrida adiciona até 0.067 nDCG

Adicionar um braço de palavra-chave BM25 padrão e fundi-lo com o braço denso através de fusion de rank recíproco (RRF, k=60) eleva o nDCG@10 em 0.030 a 0.067 para todos os motores com um braço de palavra-chave. No MedRAG, os braços denso e BM25 têm força quase igual individualmente (cerca de 0.80 cada), portanto a elevação recupera os erros de cada braço em vez de um braço dominar.

Os motores com um braço BM25 forte ganham mais, e pgvector e Weaviate ganham menos, acompanhando seus braços de palavra-chave mais fracos (0.740 e 0.782). O híbrido de nenhum motor fica abaixo do seu braço denso uma vez medido corretamente.

O que separa os motores é a fusion nativa versus idas e vindas do lado do cliente, do Milvus com 340 QPS nativo ao pgvector com 12 QPS do lado do cliente. Quatro motores fazem fusion nativamente (Qdrant, Milvus, Weaviate, LanceDB). O Redis executa BM25 nativo e KNN, mas sem fusion do lado do servidor nesta versão, então o cliente faz duas idas e vindas e funde em Python. O pgvector não tem fusion API, funde do lado do cliente, e seu braço de palavra-chave é o ts_rank do Postgres (frequência do termo com normalização de comprimento, sem IDF), que com uma varredura de texto completo OR executa a 12 QPS. O Chroma auto-hospedado não tem busca por palavra-chave ranqueada (BM25 é um recurso do Chroma Cloud), portanto não tem linha híbrida.

O tempo de construção do índice varia 13x

Em 50k vetores, a construção do índice leva de 7 segundos (LanceDB) e 11 a 13 (Weaviate, Milvus) até 88 segundos (pgvector). Em 2.25M, a diferença atinge 13x. LanceDB e Milvus terminam em 7 a 8 minutos, contra 44 minutos para o Redis e 92 para o pgvector. Normalizado para a taxa da caixa, o custo de construção varia de €0.04 por 1M de vetores (LanceDB) e €0.05 (Milvus) a €0.58 (pgvector). A construção é um custo único, pago novamente apenas quando o corpus é reindexado.

Qualidade de recuperação em 2.25M vetores

Para testar a qualidade em escala enquanto mantemos rótulos humanos reais, construímos um corpus de 2.25M vetores. Ele combina os 50k documentos rotulados do MedRAG com 2.2M distratores do PubMed, todos no mesmo espaço bge-m3, verificados quanto à integridade para que nenhum distrator seja um alvo rotulado incorretamente. Conjuntos de dados ANN de escala de bilhões padrão não carregam rótulos de relevância humana, portanto não podem mostrar o que acontece em seguida.

O recall ANN geométrico se mantém em escala. Todos os motores ainda atingem Recall@10 acima de 0.973 em 2.25M (Qdrant e Milvus em 0.999), portanto o índice encontra os verdadeiros vetores mais próximos. A qualidade semântica da resposta não se mantém. O nDCG@10 cai de cerca de 0.81 em 50k para cerca de 0.56 em 2.25M para todos os motores, porque o documento correto está enterrado entre 2.2M distratores.

O colapso não é um efeito do banco de dados. Ele atinge o oráculo kNN exato de forma idêntica (nDCG@10 do oráculo em 2.25M é 0.572, e todos os motores ficam nesse teto em torno de 0.55 a 0.57). Se a causa é o teto do embedding, a ambiguidade do corpus ou rótulos de único positivo que perdem quase-duplicatas agora relevantes, não é julgado aqui. Separar essas causas requer uma re-rotulação humana dos documentos recém-classificados no topo. O fato reportável é que escalar o corpus 45x apagou cerca de um terço da qualidade da resposta (nDCG@10 0.81 para 0.56) enquanto todos os índices ANN relatavam recall quase perfeito, um efeito que um benchmark apenas geométrico perderia.

Durabilidade, alta disponibilidade e segurança por motor

Velocidade, memória e recall são os eixos medidos. Para uma implantação de produção de RAG, os eixos não medidos (durabilidade, alta disponibilidade, controle de acesso) também separam esses motores. Este inventário de capacidades é fundamentado na documentação oficial de cada motor na edição de código aberto testada. É um inventário de capacidades, não um teste de caos. O tempo real de failover, a janela de perda de dados na recuperação de falhas e o isolamento de inquilinos sob carga não são medidos aqui.

Entre os sete, apenas o pgvector oferece recuperação point-in-time (através do arquivamento WAL do Postgres) e segurança em nível de linha. Qdrant, Milvus e Weaviate fornecem replicação e RBAC em suas compilações de código aberto, com a ressalva de que a alta disponibilidade do Milvus reside no modo distribuído mais pesado, não na construção standalone medida aqui. Nenhum dos sete criptografa dados em disco nativamente. Todos dependem de criptografia de disco ou volume na camada de infraestrutura.

Para RAG multilocatário, onde um filtro também funciona como limite de controle de acesso, Qdrant, Milvus, Weaviate e pgvector podem impor o isolamento de inquilinos dentro do banco de dados. Chroma e o incorporado LanceDB delegam isso à aplicação. Um pré-filtro correto sub-retorna, um risco de completude, em vez de vazar documentos de outro inquilino. Um vazamento entre inquilinos exigiria um pós-filtro bugado, o que nenhum desses motores usou.

Como funciona a busca aproximada de vizinho mais próximo

Um banco de dados vetorial armazena um vetor de alta dimensão por documento e, dado um vetor de consulta, retorna os k mais próximos por uma métrica de distância (aqui cosseno sobre vetores normalizados L2). A busca exata de vizinho mais próximo compara a consulta com cada vetor armazenado, o que é correto, mas escala linearmente com o tamanho do corpus. Em 50k vetores, isso é rápido. Em milhões, é lento demais para servir.

Índices de vizinho mais próximo aproximado (ANN) abrem mão de um pouco de precisão para pesquisar uma fração dos vetores armazenados. A estrutura dominante entre esses motores é o HNSW, um grafo de proximidade em camadas que caminha de um ponto de entrada grosseiro até uma vizinhança densa, visitando um número limitado de candidatos definido por um botão de busca (ef para HNSW, nprobe para IVF). Um ef maior visita mais candidatos, aumentando o recall e diminuindo o QPS. Um ef menor faz o inverso.

Como esse botão troca recall por velocidade continuamente, comparar dois motores em uma configuração fixa é enganoso, já que um pode estar gastando mais precisão por sua velocidade. A comparação justa varre o botão, desenha a curva de recall versus QPS de cada motor e os lê todos no mesmo recall. Esse ponto de recall correspondente (Recall@10 = 0.95 aqui) é onde os números de QPS, latência e memória neste benchmark são tomados.

Veja mais dos nossos benchmarks e insights baseados em dados na Pesquisa Google.

Adicionar como fonte preferencial

Metodologia do benchmark

Motores. Qdrant v1.18.1, Milvus v2.6.0, Weaviate 1.38.0, pgvector 0.8.x (Postgres 17), Chroma 1.5.0, Redis/RediSearch 8.2 e LanceDB 0.34.0, em imagens Docker fixas. O Redis foi executado com persistência desativada (sem snapshot RDB ou arquivo append-only).

Hardware. Um Hetzner CCX53 (32 vCPUs dedicadas, 128 GB de RAM, NVMe, nbg1) para precisão, velocidade, memória, filtrado e construção, um contêiner por vez, um contêiner novo por construção de índice e um cliente de thread única co-localizado. A dimensão de rotatividade ativa foi executada em um CCX33 (8 vCPUs, 32 GB).

Embedding. bge-m3, 1024 dim, cosseno em float32 normalizado L2, k=10, semente 42, byte-idêntico entre os motores. As consultas carregam rótulos humanos de único positivo (target_doc_id).

Corpora. MedRAG-50k (154 consultas) e TechQA-28k (151 consultas) para qualidade de recuperação, e um corpus de 2.25M vetores (50k rotulados mais 2.2M distratores) para o nível de escala. A dimensão híbrida foi reexecutada em Docker local, portanto seu QPS é comparável entre linhas híbridas, não aos números da caixa. Seu nDCG e Δ são independentes do hardware.

Estatísticas. 100+ execuções por medição, corte de outliers IQR em 3.0x, temporização perf_counter_ns. Conjuntos de consultas de 154 a 246 limitam o relatório de cauda em p95, ocasionalmente p99. p99.9 é indefinido nessas contagens.

Dupla verdade fundamental. Um banco de dados vetorial tem duas verdades fundamentais independentes, e este benchmark pontua ambas. A verdade fundamental geométrica (Recall ANN@10 contra o oráculo exato de força bruta sobre os mesmos vetores) pergunta se o índice retornou os verdadeiros vizinhos mais próximos, isolando o banco de dados. A verdade fundamental semântica (nDCG@10, MRR, Hit@k contra rótulos humanos) pergunta se os documentos retornados são relevantes, o que é em grande parte o embedding, mantido constante. Como o embedding está congelado, classificar motores por pontuações semânticas brutas classificaria o embedding. O poder do banco de dados se mostra como velocidade e memória em recall ANN correspondente, e a ponte Δ traduz sua perda de aproximação em qualidade de resposta.

Âncora de correção. Cada receita por motor (filtro e híbrido) foi retirada da documentação oficial na versão exata e verificada adversarialmente antes da codificação. A dimensão híbrida carrega uma chave de resposta BM25 independente (duas referências concordam em nDCG cerca de 0.81), portanto qualquer motor pontuando longe disso sinaliza um bug no harness, não uma descoberta. Essa guarda sinalizou três erros de medição de primeira passagem, todos em nosso harness (um artefato de temporização de índice assíncrono no Weaviate, uma função de ranking Postgres errada e um bug de SQL fusion que fez o HNSW ignorar sua configuração ef), que corrigimos remedindo todos os sete motores em um ambiente consistente, onde os cinco motores já corretos reproduziram seus números exatamente. As dimensões de concorrência e rotatividade carregam a mesma âncora (reverificações de recall e tombstone), portanto nenhum número reportado é rápido-mas-errado.

Significância estatística

Cada número reportado é uma estimativa pontual bootstrap sobre 100+ execuções, com um intervalo de confiança de 95% de 1,000 reamostragens, e uma diferença conta como real quando os dois intervalos não se sobrepõem.

A elevação híbrida é a chamada mais próxima, portanto seus intervalos são a evidência decisiva. Quatro motores ultrapassam zero e dois não:

A precisão da recuperação é a mesma regra lida ao contrário. O nDCG@10 dos sete motores cai dentro de intervalos sobrepostos em uma diferença de 0.014, portanto nenhum vence, que é o que o empate significa. As ordenações de velocidade e memória ficam muito fora dessa incerteza, com lacunas (10x de taxa de transferência de thread única, 3.7x de pico de memória) que diminuem o ruído bootstrap.

Motores testados

Limitações

O Redis foi executado com persistência desativada, portanto uma configuração de fsync AOF alteraria sua latência de escrita e pegada em relação aos números voláteis reportados aqui.

Os rótulos humanos são de único positivo (um documento correto por consulta), sem relevância graduada ou concordância entre anotadores, portanto nDCG@10, MRR@10 e Hit@10 carregam sinal quase idêntico nesses dados. O embedding é mantido constante por design. Famílias de embedding, dimensões e comportamento multilíngue são um benchmark separado. Esta execução isola a camada de recuperação. Os estágios de re-ranqueador (cross-encoder) e geração de resposta do LLM de um pipeline de RAG estão fora do escopo. Motores de nuvem gerenciados (Pinecone, Zilliz e outros) são uma fase posterior. A comparação de durabilidade e segurança é fundamentada em documentação, não testada em caos.

Leitura adicional

• Benchmark de modelos de embedding
• Benchmark de rerankers
• Calculadora de banco de dados vetorial
• Modelos de embedding de código aberto
• Modelos de embedding multilíngues
• Embeddings multimodais
• Frameworks de RAG agênticos

Cite esta pesquisa

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  = {{Benchmark de Bancos de Dados Vetoriais: 7 Motores de Código Aberto para RAG}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/open-source-vector-databases}},
  note   = {AIMultiple. Acessado em 17 Julho 2026}
}

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é pesquisador de IA na AIMultiple, com foco em automação inteligente, GPUs, agentes de IA e frameworks RAG.

Ver perfil completo

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.

Nome

Endereço de email

Comentário

0/450

Postar comentário