Live data from Hacker News

Choosing vector database: a side-by-side comparison

benchmark.vectorview.ai

31–40 of 125 posts

Re: Choosing vector database: a side-by-side comparison

#31
post #28

Let me half hijack to ask a related question: I'm building a RAG for my personal use: Say I have a lot of notes on various topics I've compiled over the years. They're scattered over a lot of text files (and org nodes). I want to be able to ask questions in a natural language and have the system query my notes and give me an answer. The approach I'm going for is to store those notes in a vector DB. When I ask my quer…

For the normal ones https://en.wikipedia.org/wiki/Evaluation_measures_(informati...

The main thing is that there's no "objective" way, but if you rank and label your own data then you can certainly get a ranking that's subjectively well performing according to you.

Re: Choosing vector database: a side-by-side comparison

#32
post #14

I'd love to know how vector databases compare in their ability to do hybrid queries, vector similarity filtered by metadata values. For example, find the 100 items with the closest cosine similarity where genre = jazz and publication date between 1990 and 2000. Can the vector index operate on a subset of records? Or when searching for 100 closest matches does the database have to find 1000 matches and then apply the…

> do hybrid queries "no" - the graph objects after training are opaque AFAIK

Actually a lot of the databases offer filtering before or after similarity search.

Re: Choosing vector database: a side-by-side comparison

#33

Everyone I talk to who is building some vector db based thing sooner or later realizes they also care about the features of a full-text search engine. They care about filtering, they care to some degree about direct lexical matches, they care about paging, getting groups / facet counts, etc. Vectors, IMO, are just one feature that a regular search engine should have. IMO currently Vespa does the best job of this, tho…

Vespa looks interesting, hadn't seen it before but will definitely take a look at it

Re: Choosing vector database: a side-by-side comparison

#34
post #28

Let me half hijack to ask a related question: I'm building a RAG for my personal use: Say I have a lot of notes on various topics I've compiled over the years. They're scattered over a lot of text files (and org nodes). I want to be able to ask questions in a natural language and have the system query my notes and give me an answer. The approach I'm going for is to store those notes in a vector DB. When I ask my quer…

For small personal projects its kind of hard to build metrics like this because the volume of indexed content in the database tends to be pretty low. If you're indexing paragraphs you might consistently be able to fit all relevant paragraphs in the context itself.

What I can recommend is to take the coffee tasting approach. Don't try and test and evaluate individual responses, instead lock the seed used in generation, and use the same prompt for two different runs. Change one variable and do a relative comparison of the two outputs. The variables probably worth testing for you off the top of my head:

* Choice of models and/or tunes

* System prompts

* Temperature of the model against your queries

* Threshold for similarity for document inclusions (you only want relevant documents from your RAG, set it too low and you'll get some extra distractions, too high and useful information might be left out of the context).

If you setup a system to track the comparisons either automatically or by hand that just indicates which side of the change worked better for your use case, and test that same change for a bunch of different prompts you should be able to tally up whether the control or change was more preferred.

Keep those data points! The data points are your bench log and can be invaluable later on for anything you do with the system to see what changed in aggregate, what had the most outsized impact, etc and can guide you to build useful tooling for testing or finding existing solutions out there.

Re: Choosing vector database: a side-by-side comparison

#37

I'll add txtai to the list: https://github.com/neuml/txtai txtai is an all-in-one embeddings database for semantic search, LLM orchestration and language model workflows. Embeddings databases are a union of vector indexes (sparse and dense), graph networks and relational databases. This enables vector search with SQL, topic modeling and retrieval augmented generation. txtai adopts a local-first approach. A production…

Txtai looks interesting, maybe you could help me collect some of the comparision parameters for it?

Re: Choosing vector database: a side-by-side comparison

#40
post #7

Curious about the lack of Vespa, especially given the thoroughness of the article and its long-time reputation. OpenSearch is also missing, but perhaps it can be considered being lumped in with Elasticsearch due to them both being based on Lucene. The products are starting to diverge, so would be nice to see, especially since it is open-source. For the performance-based columns, would be also helpful to see which ver…

Someone else also pointed out that Vespa was missing. I'll have to look in to it and add it to the article!
Post reply on HN