Qdrant disponibilizou gratuitamente 10 bilhões de vetores (FineWeb 10B)

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Qdrant Just Gave Away 10 Billion Vectors For Free (FineWeb 10b) · Canal: Better Stack · 12:33 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings, RAG, busca e recuperação de informação

Resumo

A Qdrant publicou o FineWeb 10B, um conjunto gratuito com 10 bilhões de vetores e ground truth calculado por busca exaustiva, além de abrir o código do Supernova, ferramenta para gerar e executar benchmarks. O vídeo explica por que benchmarks de bancos de dados vetoriais são difíceis: conjuntos pequenos não refletem a escala de produção, e calcular os vizinhos mais próximos exatos em grande escala exige um custo computacional enorme. Em um teste com um milhão de vetores, o apresentador compara Qdrant, Milvus, Elasticsearch e pgvector, observando diferenças entre velocidade e recall. Ele ressalta que os resultados do teste reduzido não podem ser extrapolados diretamente para os 10 bilhões de vetores e recomenda testar os sistemas com os próprios dados.

Pontos-chave

Benchmarks com poucos vetores podem não revelar pressão de memória, tempo de construção do índice e latência em escala de produção.
Calcular ground truth exato em 10 bilhões de vetores e 120 mil consultas requer mais de um quatrilhão de cálculos de distância.
O FineWeb 10B contém 10 bilhões de documentos incorporados como vetores densos e esparsos usando GTE multilingual base.
O conjunto inclui 120 mil consultas e os 10 mil documentos mais próximos, em ordem, para cada consulta.
O Supernova, disponibilizado sob a licença Apache 2.0, permite gerar embeddings, carregar bancos de dados e executar testes de carga.
O apresentador executou testes com uma amostra de um milhão de vetores e calculou ground truth exato para essa amostra.
No teste apresentado, Elasticsearch foi mais rápido em uma faixa de precisão, enquanto Qdrant e Milvus alcançaram maior recall.
Os resultados em um milhão de vetores não garantem o mesmo desempenho em 10 bilhões; o vídeo recomenda cautela com benchmarks publicados por fornecedores.

Capítulos

Início	Capítulo	Resumo
00:00	Por que benchmarks vetoriais são difíceis	O vídeo apresenta os problemas de escala e de cálculo de ground truth que dificultam comparar bancos de dados vetoriais.
03:23	O que contém o FineWeb 10B	O apresentador descreve o corpus, os vetores densos e esparsos, as consultas e o ground truth ordenado do conjunto.
06:00	Limitações e ferramentas para reproduzir os testes	O vídeo aborda os vieses possíveis de um benchmark de fornecedor e explica como o Supernova permite testar dados próprios ou uma amostra.
08:45	Comparação de bancos de dados com uma amostra	O apresentador compara Qdrant, Milvus, Elasticsearch e pgvector em uma amostra de um milhão de vetores, medindo recall e latência.
11:00	Resultados e conclusão	O vídeo alerta que os resultados da amostra não garantem o desempenho em 10 bilhões de vetores e defende testes com dados próprios.

Citações

É genuinamente difícil fazer benchmarking de busca vetorial de forma honesta. — 00:00

A 10 bilhões de vetores e 120 mil consultas, são mais de um quatrilhão de cálculos de distância. — 02:20

Você pode apontar a ferramenta para seu próprio corpus e criar o mesmo tipo de benchmark com seus dados. — 07:03

O principal não são os números da demonstração, mas o conceito: agora temos um conjunto grande o bastante para comparar bancos de dados vetoriais com precisão. — 11:32

Conceitos e entidades

Qdrant (empresa): Empresa de banco de dados vetorial que publicou o conjunto FineWeb 10B e o framework Supernova.
FineWeb 10B (repo): Conjunto de dados com 10 bilhões de vetores derivados de documentos do FineWeb, disponibilizado gratuitamente no Hugging Face.
Supernova (ferramenta): Framework open source para gerar embeddings, carregar bancos de dados e executar testes de carga.
GTE multilingual base (modelo): Modelo usado para gerar vetores densos e esparsos a partir dos documentos do conjunto.
FineWeb (repo): Conjunto de dados de páginas e textos da web usado como corpus para o FineWeb 10B.
MS MARCO (repo): Coleção pública de consultas de busca reais usada para compor parte das consultas do benchmark.
Milvus (ferramenta): Banco de dados vetorial comparado no teste do vídeo.
Elasticsearch (ferramenta): Sistema de busca comparado no vídeo, inclusive quanto à velocidade e ao recall em busca vetorial.
pgvector (ferramenta): Extensão de busca vetorial para PostgreSQL incluída na comparação.
Hugging Face (empresa): Plataforma onde o FineWeb 10B está disponível para download.

Tradução completa (pt-BR)

00:00 Se você está procurando um banco de dados vetorial confiável para o seu projeto, escolher um é muito difícil. E isso porque todo fornecedor tem uma página de benchmark e mostra que está vencendo nos próprios benchmarks. Isso não significa necessariamente que todos estejam mentindo, mas sim que fazer benchmarks de busca vetorial com honestidade é realmente difícil, e quase todos os benchmarks públicos recorrem a alguns atalhos e produzem resultados incompletos. Mas a Qdrant acabou de publicar a solução definitiva para esse problema: um conjunto de dados de benchmark com 10

00:34 bilhões de vetores. São 24,5 terabytes de embeddings, e o conjunto é totalmente gratuito para baixar no HuggingFace. Além disso, eles também disponibilizaram como open source, sob a licença Apache 2.0, toda a cadeia de ferramentas que usaram para criá-lo. Então, no vídeo de hoje, vamos dar uma olhada nesse conjunto de dados de benchmark, ver como ele funciona e usá-lo para fazer o benchmark de alguns dos bancos de dados vetoriais mais populares e descobrir o que os benchmarks realmente nos dizem. Vai ser muito divertido. Então, vamos nessa.

01:09 Há duas coisas que são realmente difíceis ao fazer benchmark de bancos de dados vetoriais. A primeira é a escala. Os números dos benchmarks anteriores da própria Qdrant foram obtidos com um conjunto de dados chamado DBPedia OpenAI 1 million, que contém 1 milhão de vetores, e com o Deep Image 96, que contém 10 milhões. E, se você estiver usando 100 milhões de vetores em produção, um benchmark com 1 milhão de vetores essencialmente não diz nada, porque, com 1 milhão, tudo cabe na RAM e tudo é rápido quando cabe na RAM. O que realmente põe seu sistema à prova em escala é a pressão sobre a memória, o tempo de criação do índice e a latência de cauda quando o índice começa a paginar para o disco.

01:44 Mas nada disso aparece de verdade com uma amostra pequena. Então, você está medindo uma configuração completamente diferente daquela que vai colocar em produção. O segundo problema é ainda maior: a verdade de referência. Vamos usar a revocação como exemplo. A revocação mede o seguinte: entre os verdadeiros vizinhos mais próximos de uma determinada consulta, quantos o mecanismo realmente me retorna? Então, para medir a revocação, você

02:20 precisa saber qual é a resposta correta. Isso significa que alguém precisa ter calculado antes os verdadeiros vizinhos mais próximos — não de forma aproximada, mas exata. E isso significa comparar cada consulta com cada vetor do corpus, sem índice, sem atalhos e sem aproximações. Com 1 milhão de vetores, isso é bastante viável. Basicamente, dá para fazer em um laptop. Mas, com 10 bilhões de vetores e 120 mil consultas, são mais de um quatrilhão de cálculos de distância.

02:52 10 elevado a 15. E é exatamente por isso que ninguém tinha feito isso antes. Então, a maioria dos benchmarks faz uma de duas coisas. Ou calcula uma verdade de referência aproximada — o que significa que você está medindo uma aproximação contra outra aproximação e chamando o resultado de preciso — ou usa vetores sintéticos gerados aleatoriamente, que não têm a estrutura de agrupamento dos embeddings reais. Assim, o próprio problema de busca fica artificialmente fácil. Mas

03:23 a Qdrant fez o que era caro. Eles gastaram muito poder computacional de GPU para produzir esse enorme conjunto de dados com 10 bilhões de vetores. Então, o que há nele, exatamente? O corpus é o FineWeb, um conjunto de dados do Common Crawl do Hugging Face, que contém páginas da web e textos reais. Eles pegaram 10 bilhões de documentos e geraram embeddings para cada um deles duas vezes, usando um modelo chamado GTE multilingual base: uma vez como vetor denso, que codifica o significado. Assim,

03:55 por exemplo, “carro” e “automóvel” acabam próximos um do outro; e outra vez como vetor esparso, que codifica termos concretos, mais parecido com o funcionamento de um índice tradicional de palavras-chave. E ter os dois tipos gerados pelo mesmo modelo e a partir dos mesmos documentos significa que você pode fazer benchmark de recuperação híbrida sem mudar mais nada nos dados. E depois há a verdade de referência. São 120 mil consultas no total. 100 mil delas são consultas densas do MS Marco, uma coleção pública de consultas de busca reais

04:27 digitadas por pessoas reais. Depois, há 10 mil consultas esparsas e 10 mil consultas com filtros. A verdade de referência é muito importante porque a busca vetorial com filtros — isto é, “encontre documentos semelhantes, mas apenas os marcados com X” — é algo em que muitos mecanismos falham. Mas também é algo que praticamente toda aplicação real faz, e quase ninguém testa em benchmarks, porque gerar uma verdade de referência com filtros dá ainda mais trabalho do que gerar a versão normal. Então, para

04:57 cada consulta, eles registraram os 10 mil documentos mais próximos, em ordem. Por que isso importa? Porque aplicações diferentes precisam de quantidades diferentes. Um chatbot que faz recuperação pode buscar os cinco documentos mais relevantes para inserir em um prompt. Uma página de resultados de busca pode mostrar 20 resultados. Um sistema de busca avançado costuma buscar mil candidatos e, em seguida, executar sobre eles um modelo de reclassificação mais lento e inteligente. Essas são perguntas realmente diferentes e,

05:28 normalmente, cada uma precisa da própria execução para gerar a verdade de referência. Mas, se você já tem os mil primeiros em ordem, obtém todas essas respostas de graça. Se quiser saber quais são os 10 primeiros de verdade, são os 10 primeiros itens da lista. Os 100 primeiros de verdade? São os 100 primeiros. Basta cortar a lista onde precisar. E, como ela já está ordenada do melhor para o pior, o que sobra é exatamente a resposta que você procura. E é por isso que foi preciso uma quantidade insana de poder computacional para gerar esse conjunto de dados. O cálculo da verdade de referência exigiu mais de um quatrilhão de cálculos de distância,

06:00 feito uma vez, com profundidade de 1.000. Então, este pode ser o conjunto de dados de verdade de referência mais preciso que existe. Mas quero deixar uma coisa clara, porque também não quero exagerar. Este ainda é um benchmark de fornecedor. A própria Qdrant é uma empresa de banco de dados vetorial, e foi a Qdrant que escolheu esse corpus e o modelo de embedding. A Qdrant também escolheu o conjunto de consultas e criou o harness. Todas essas escolhas influenciam os resultados, e outro modelo de embedding

06:31 pode resultar em uma curva de dificuldade diferente. Mas eis o que o torna estruturalmente diferente de um conjunto de dados comum: a verdade de referência está correta ou não está. É um cálculo de força bruta sem parâmetros livres. Não há botão para ajustar nem configuração engenhosa, então não há como esconder nada. Qualquer pessoa com orçamento para GPU pode pegar o conjunto de dados, recalcular por conta própria os vizinhos mais próximos exatos e verificar se as respostas da Qdrant correspondem. E isso é, fundamentalmente, uma posição mais sólida do que pedir às pessoas que confiem em um número em uma página de

07:03 marketing. E as ferramentas são open source. A estrutura se chama Supernova. Está no GitHub sob a licença Apache 2.0 e faz a geração de embeddings, o carregamento no banco de dados e testes de carga. Portanto, você não está limitado a reproduzir o benchmark deles. Pode apontá-la para o seu próprio corpus e criar o mesmo tipo de benchmark com os seus dados, que é o que você realmente quer, porque são os seus dados, não os do FineWeb. Então, testei essa cadeia de ferramentas por conta própria, embora usando apenas uma parte do conjunto de dados inteiro, porque 10 bilhões de vetores ocupam 24 terabytes, e meu

07:37 laptop simplesmente não tem tanto espaço. E também devo esclarecer isso: como não estou executando o benchmark inteiro e, por exemplo, estou testando a Qdrant, meus números de verdade de referência serão muito imprecisos em comparação com os da Qdrant. Isso porque a verdade de referência publicada pela Qdrant foi calculada usando os 10 bilhões de documentos. No momento em que você pega apenas uma parte, a verdade de referência deixa de se aplicar, porque, para a maioria das consultas, os verdadeiros vizinhos mais próximos estão entre os bilhões de documentos que você não baixou. Então, se eu avaliar minha amostra usando as respostas publicadas pela Qdrant,

08:11 vai parecer que tudo está catastroficamente quebrado, e nada disso significa coisa alguma. Então, é preciso ter em mente que, com um subconjunto, você calcula sua própria verdade de referência usando exatamente os vetores que carregou. É para isso que serve o Nova BF. Você pode executá-lo e ainda obter uma resposta exata por força bruta, e a revocação medida em relação a ela é totalmente válida. Só responde a uma pergunta diferente. Você não vai descobrir se esse mecanismo correspondeu ao resultado da Qdrant com 10 bilhões de vetores; em vez disso, vai medir se o índice rápido desse mecanismo encontrou o que uma busca exaustiva entre meus

08:45 milhões de documentos encontra. E isso diz se o índice funciona. Basicamente, o que estou tentando dizer é que calcular por força bruta é uma tarefa computacionalmente difícil e cara, e nem todos os dispositivos de consumo conseguem fazê-lo. Mas, para fins de teste, ainda podemos calcular isso usando apenas uma parte do conjunto de dados. Enfim, criei um script de execução única que você pode rodar; ele inicia automaticamente uma instância Docker dos bancos de dados vetoriais da Qdrant, Milvus, Elasticsearch e pgvector. Depois, ele baixa uma parte do conjunto de dados do Hugging Face,

09:19 gera novamente o embedding da consulta, calcula o ground truth exato para o seu subconjunto e, então, para cada banco de dados, um por vez, inicia um contêiner, carrega os mesmos um milhão de vetores e testa cinco valores da configuração de esforço de busca, medindo a revocação e a latência em cada um deles. Assim, usamos o mesmo ground truth para todos os mecanismos, um de cada vez, para que não disputem sua CPU. Então, executei o teste em quatro mecanismos: Qdrant, Milvus, Elasticsearch e pgvector. E um único número por mecanismo não seria útil aqui, porque cada um deles tem uma configuração

09:52 que controla o quanto ele procura antes de responder. Se procurar menos, vai ser rápido, mas vai deixar passar algumas coisas. E, se procurar mais, vai ser mais lento, mas vai encontrar mais. Então, testei cada mecanismo com cinco configurações, em vez de uma. Isso gera uma curva. E essa curva permite fazer a pergunta de verdade: com o mesmo nível de precisão, qual é mais rápido? Com 94% de precisão, o Elasticsearch responde em 7,5 milissegundos. O Qdrant leva 9,5, o Milvus, 12,5, e o pgvector, 13. E o Elasticsearch vencer

10:28 me surpreendeu, na verdade, porque as pessoas veem esse mecanismo como uma ferramenta de busca por palavras-chave à qual foram adicionados vetores. Então, ele não é necessariamente um banco de dados vetorial em primeiro lugar, mas superou os outros três bancos de dados. Mas veja onde cada mecanismo para. O Elasticsearch não consegue passar de 95% de precisão, por mais que você aumente o esforço. Já o Qdrant e o Milvus chegam a 98%. Então, eles são bons em coisas diferentes. O Elasticsearch é a forma mais rápida de chegar a uma resposta aproximadamente correta, mas o Qdrant é

11:00 o único do grupo que é rápido e ainda oferece os resultados mais precisos. E preciso dizer de novo: são apenas um milhão de vetores, não 10 bilhões. Portanto, não há garantia de que essas curvas se mantenham em uma escala mil vezes maior. Os resultados poderiam ser totalmente diferentes se fizéssemos esse teste com 10 bilhões de vetores. Então, é isso, pessoal: esse é o novo conjunto de dados FineWeb de 10 bilhões de vetores do Qdrant. A principal conclusão aqui não são os números que mostrei na demonstração, mas sim o conceito em si: agora temos um conjunto de dados grande o suficiente

11:32 para ser usado em benchmarks precisos que comparam bancos de dados vetoriais entre si. E isso também é um bom lembrete de por que devemos desconfiar dos benchmarks publicados pelos fornecedores. Porque, como acabamos de ver neste vídeo, fazer benchmarks de bancos de dados vetoriais é realmente uma tarefa muito difícil. Não estou culpando os próprios fornecedores. Só estou dizendo que nada é preto no branco e que todos devemos testá-los por conta própria para chegar ao ground truth real. Então,

12:03 essas são minhas opiniões sobre o assunto, mas e você, o que acha? Adoraria ouvir suas ideias. Então, compartilhe-as na seção de comentários aqui embaixo. E, pessoal, se vocês gostam desse tipo de análise técnica detalhada, mostrem isso clicando no botão de gostei abaixo do vídeo. E também não se esqueçam de se inscrever no nosso canal. Aqui foi Andress, da Better Stack. Vejo vocês nos próximos vídeos. [música]

12:33 >> [música]

Transcrição original

[00:00] If you’re looking for a reliable vector database for your project, choosing one is so hard. And that is because every vendor has a benchmark page and every vendor shows they’re winning their own benchmarks. That’s not necessarily because they’re all lying, but it’s because benchmarking vector search honestly is genuinely difficult and almost every public benchmark takes some shortcuts and produces halfbaked results. But Quadrant just published the ultimate solution to this problem and it’s a benchmark data set with 10

[00:34] billion vectors in it. 24 and a half terabytes of embeddings and it’s completely free to download from HuggingFace and alongside it they also open sourced the entire tool chain they used to build it under the Apache 2.0 license. So, in today’s video, we’re going to take a look at this benchmark data set, see how it works, and we’re going to use it to benchmark some of the most popular vector databases to find out what the real benchmarks actually tell us. It’s going to be a lot of fun. So, let’s dive into it.

[01:09] So, there are two things that are genuinely difficult when benchmarking vector databases. The first one is scale. Quadrant’s own previous benchmark numbers ran on a data set called DBPeddia OpenAI 1 million which is 1 million vectors large and deep image 96 which is 10 million. And if you’re running a 100 million vectors in production, a 1 million vector benchmark tells you essentially nothing because at 1 million everything fits in RAM and everything is fast when it fits in RAM. The behavior that actually stress tests

[01:44] your system at scale is the memory pressure and the index build times and the tail latency when the index starts paging off disk. But none of that really shows up with a small sample size. So you are measuring a completely different setup from the one you’re going to be deploying on production. And the second problem is a bigger one and it’s ground truth. Let’s look at recall for example. Recall measures the following. Of the true nearest neighbors to a certain query, how many does the engine actually give me back? So to measure recall, you

[02:20] have to know what the right answer is. Which means somebody has to have computed the true nearest neighbors first, not approximately, but exactly. And that means every single query compared against every single vector in the corpus with no index, no shortcuts, and no approximation. And at 1 million vectors, it’s quite doable. You can basically do it on a laptop. But at 10 billion vectors with 120,000 queries, this is over a quadrillion distance

[02:52] computations. 10 to the 15. And that is precisely why nobody had done it before. So most benchmarks do one of two things instead. Either they compute approximate ground truth which means you’re now measuring one approximation against another approximation and calling the result accurate or they use synthetic vectors randomly generated which don’t have the clustering structure the real embeddings have. So the search problem itself is artificially easy. But

[03:23] Quadrant went and did the expensive thing. They burned through a lot of GPU compute to produce this massive data set of 10 billion vectors. So what’s actually in it? Well, the corpus is fine web which is hugging faces common crawl data set and it contains real web pages and real text. They took 10 billion documents out of it and embedded every single one twice using a model called GTE multilingual base once in a dense vector which encodes meaning. So that

[03:55] for example car and automobile end up near each other and one into a sparse vector which encodes actual terms closer to how a traditional keyword index works. And having both from the same model over the same documents means you can benchmark hybrid retrieval without changing anything else about the data. And then there’s the ground truth. 120,000 queries total. 100,000 of them are dense queries taken from MS Marco which is a public collection of real

[04:27] search queries typed by real people. Then 10,000 sparse queries and 10,000 filtered queries. And ground truth is really important because filtered vector search meaning find me similar documents but only once tagged with X is what a lot of engines fail at. But it is also the thing that basically every real application does and almost nobody benchmarks it because generating filtered ground truth is even more work than generating the normal kind. So for

[04:57] every query they recorded the 10,000 closest documents in order. So why does that matter? Well, because different applications ask for different amounts. A chatbot doing retrieval might pull the top five documents to stuff into a prompt. A search results page might show 20 results. A serious search system often pulls a thousand candidates and then runs a slower, smarter re-ranking model on top of them. Those are genuinely different questions and

[05:28] normally each one needs its own groundtruth run. But if you already have the top thousand in order, you get all of those for free. If you want to know the true top 10, it’s the first 10 items on the list. The true top 100, well, those are the first 100. You just cut the list off wherever you need it. And because it’s already sorted best first, what’s left is exactly the answer you’re looking for. And that’s why it took an insane amount of compute to generate this data set. Computing the ground truth took over a quadrillion distance

[06:00] calculations doing it once at depth 1,000. So this might be the most precise ground truth data set out there. But let me be clear here because I don’t want to overhype it as well. This is still a vendor benchmark. Quadrant themselves is a vector database company and Quadrant chose this corpus and Quadrant also chose the embedding model. Quadrant chose also the query set and built the harness. All of those choices shape the results and different embedding model

[06:31] might give you a different difficulty curve. But here’s what makes it structurally different from a usual data set. The ground truth is either correct or it isn’t. It’s a brute force computation with no free parameters. There’s no turning knob, no clever configuration, so there’s nowhere to hide. Anybody with a GPU budget can take the data set, recomputee the exact nearest neighbors themselves, and check whether Quadrron’s answers match. And that’s fundamentally a stronger position than asking to trust a number on a

[07:03] marketing page. And the tooling is open source. The framework is called Supernova. It’s Apache 2.0 O on GitHub and it does embedding generation, database loading and load testing. So you aren’t limited to reproducing their benchmark. You can point it at your own corpus and build the same kind of benchmark on your own data which is the thing you actually want because it’s your data and not fine web. So, I tested this tool chain myself, albeit on just a slice of the whole data set because 10 billion vectors is 24 terabytes and my

[07:37] laptop just doesn’t have that much space. And this is something I should disclose as well because since I’m not running the whole benchmark and if I’m testing Quadrant, for example, my ground truth numbers against Quadrants will be very inaccurate. And that’s because Quadrron’s published ground truth was computed across all 10 billion documents. The moment you take a slice, the ground truth doesn’t apply to you anymore because the true nearest neighbors for most queries live in the billions of documents you didn’t download. So if I score my slice against quadrants published answers, it will

[08:11] look catastrophically broken and none of it means anything. So you have to take in mind that on a subset you compute your own ground truth over exactly the vectors you loaded and that’s what Nova BF is for. You can run it and still get an exact brute force answer and the recall measured against it is completely valid. It’s just answering a different question. You won’t get an answer for did this engine match quadrant’s 10 billion vector result, but instead you’ll be measuring did this engine’s fast index find what an exhaustive

[08:45] search over my million documents finds. And that tells you whether the index works. So basically what I’m trying to say is that computing brute force is a hard computationally expensive task and not all consumer devices can do it. But for testing purposes, we can still compute it on just a slice of the data set as a test. So anyway, I made a oneshot script that you can run and it will automatically spin up a docker instance of quadrant, milvous, elastic and pg vector databases. And then it pulls a slice from hugging face,

[09:19] regenerates the query embedded, computes exact ground truth over your slice, and then for each database, in turn, it spins up a container, loads the same million vectors, and sweeps the search effort setting across five values while measuring recall and latency at each one. So, same ground truth for every engine, one at a time, so they’re not fighting over your CPU. So I ran it against four engines. Quadrant, Milvvis, Elastic Search, and PG Vector. And one number per engine would be useless here because every one of these has a setting

[09:52] that controls how hard it looks before answering. So if you look less, you’re going to be fast, but you’re going to miss things. And if you look harder, you’re going to be slower, but you’re going to find more. So I ran each engine on five settings instead of one. And that gives you a curve. And that curve lets you ask the real question which is at that same accuracy which one is faster and at 94% accuracy elastic search answers in 7 1/2 milliseconds. Quadrant is 9 1/2 mil 12 1/2 and PG vector is 13. And elastic search winning

[10:28] actually surprised me because this is an engine people think of as a keyword search with vectors bolted on. So, it isn’t necessarily a vector database first, but it did beat all three other databases, but look at where each engine stops. So, Elastic Search can’t get past 95% accuracy no matter how hard you push it. But, Quadrant and Milvas both reach 98%. So, they’re good at different things. Elastic Search is the fastest way to be roughly right, but Quadrant is

[11:00] the only one of the bunch that is quick and still gives you the most precise results. And I have to say again this is just a million vectors not 10 billion. So whether these curves hold at thousand times the scale is not guaranteed. The results might be totally different if we would run this for 10 billion vectors. So there you have it folks that is Quadrron’s new fine web 10 billion vector data set. So the big takeaway here is not the numbers that I showed you in the demo, but rather the concept itself that we now have a large enough

[11:32] data set that can be used to accurately benchmark vector databases against each other. And this is also a good reminder of why we should be skeptical of vendor published benchmarks. Because as we just saw in this video, benchmarking vector databases is genuinely a super difficult task. So I’m not blaming vendors themselves. I’m just stating the reality that nothing is black and white and we should all test them for ourselves to get to the actual ground truth. So,

[12:03] those are my thoughts on this topic, but what are yours? I’d love to hear your insights. So, please share them in the comment section down below. And folks, if you like these types of technical breakdowns, please let me know by smashing that like button underneath the video. And also, don’t forget to subscribe to our channel. This has been Andress from Better Stack and I will see you in the next videos. [music]

[12:33] >> [music]