Live data from Hacker News

Vector database built for scalable similarity search

milvus.io

21–30 of 95 posts

Re: Vector database built for scalable similarity search

#21
post #7
post #4

I work at Zilliz ( https://zilliz.com ) and am a part of the Milvus community. Here are some other resources in case anybody's interested in learning more about embeddings, vector search, and vector databases: 1) Embedding crash course https://developers.google.com/machine-learning/crash-course/... 2) What is a vector database? https://zilliz.com/learn/what-is-vector-database 3) Introduction to vector similarity sear…

Does Zilliz do BYOC?

What is BYOC? Bring your own Cloud?

Re: Vector database built for scalable similarity search

#23

I only heard about vector databases along with the recent advents of AI. Assuming they've been around for a while, what were the benefits of using them over "normal" search engines (e.g. ElasticSearch)?

Traditional search such as ES and Lucene rely primarily on bag-of-words retrieval and keyword matching e.g. BM25, TF-IDF, etc. Vector databases such as Milvus allow for _semantic_ search.

Here's a highly simplified example: if my query was "fields related to computer science", a semantic engine could return "statistics" and "electrical engineering" while avoiding things such as "social science" and "political science".

Re: Vector database built for scalable similarity search

#24
post #22

What algorithms are these databases using for fast similarity search? Are they guaranteed to return the most optimal similar neighbors or will they be sloppy in return for efficiency?

One key differentiator of Milvus is the ability to use a variety of different indexing algorithms. Some will consume very little memory and provide significant speedup at the expense of recall, while others are more powerful at the expensive of compute time or memory consumption.

The most commonly used one I've seen is HNSW, which greatly speeds up search at the expensive of some extra memory consumption. Recall is also strong - for many large-scale use cases you can get 95%+ with properly tuned parameters.

Re: Vector database built for scalable similarity search

#25
I really don't want another database. I just want to have a solution built in for Postgres, and more specifically, RDS, which we use. I know there will be some extra difficulty that I will have to manage (e.g. reindexing to a new model that is outputting different embeddings), but I really don't want another piece of infrastructure.

If anyone from AWS/Google/Azure is listening, please add pgvector [1] into your managed Postgres offerings!

1. https://github.com/pgvector/pgvector

Re: Vector database built for scalable similarity search

#27

I only heard about vector databases along with the recent advents of AI. Assuming they've been around for a while, what were the benefits of using them over "normal" search engines (e.g. ElasticSearch)?

ES has support for vector search now too. Really you want both in use cases where the user expects the the top results to contain the search keywords, but also wants results that are synonyms or conceptually similar. TF/IDF and BM25 help with first part and vectors help with the second. Theoretically only vectors should be needed, but that isn't my experience in practice.

Re: Vector database built for scalable similarity search

#29
post #28

It feels like there are an influx of "vector databases" right now, I haven't had a strong answer out of anyone on why you'd be better off using these over Redis which offers vector storage with similarity search in a battle-tested OSS solution.

Or Postgres with pgvector

https://github.com/pgvector/pgvector

Re: Vector database built for scalable similarity search

#30

I only heard about vector databases along with the recent advents of AI. Assuming they've been around for a while, what were the benefits of using them over "normal" search engines (e.g. ElasticSearch)?

ES has support for vector search now too. Really you want both in use cases where the user expects the the top results to contain the search keywords, but also wants results that are synonyms or conceptually similar. TF/IDF and BM25 help with first part and vectors help with the second. Theoretically only vectors should be needed, but that isn't my experience in practice.

Which is why Pinecone supports hybrid search, which has shown to provide better results for out-of-domain use cases than either semantic search or keyword search alone: https://www.pinecone.io/learn/hybrid-search-intro/
Post reply on HN