Re:Vald: A Highly Scalable Distributed Vector Search Engine
by jka on Friday April 09, 2021 @08:27AM
(#26749664)
Could you share any hints on how to determine whether an application's search domain is suitable for vector-based search?
(context: I'm maintaining a recipe search engine, and it strikes me that recipes could be considered as part of a vector space, but I'm wary of adopting new technologies with something that works 'well enough' for now (Elasticsearch, in this case))
Re:Vald: A Highly Scalable Distributed Vector Search Engine
by rkt08 on Friday April 09, 2021 @09:15AM
(#26750132)
Any search domain is good for vector search if your method for producing vectors is good! Seems like it should be possible with Recipes.Are you performing search based on recipe text? It shouldn't take long to try out a simple POC with standard text embedding models like (Glove,BERT etc) and observe vectors via tSNE or just using a vector index.
PS: I work at Pinecone and you can see if any of the examples here help you : https://www.pinecone.io/docs/examples/
Re:Vald: A Highly Scalable Distributed Vector Search Engine
by jka on Friday April 09, 2021 @09:27AM
(#26750272)
The vectors I have in mind could include (or perhaps be inferred from) recipe text, but they may also include things like nutritional content and corresponding freshest-in-kitchen-ingredients (maybe an ingredient x time-since-purchase vector?) to nearest-match-recipes.
The examples are helpful and well documented, thank you. I'd mention that I'm constraining the technology options to self-hostable and FLOSS software, and with a strong bias towards concepts that are already well-understood by most software engineers, but I'll keep a look out for Pinecone.
Re:Vald: A Highly Scalable Distributed Vector Search Engine
by rkt08 on Friday April 09, 2021 @12:15PM
(#26752420)
That is definitely an interesting use case. You can look for methods that combine multiple vectors to create a combined vector or you may want to filter on metadata and vectors both. Who knows maybe you might be able to come with something very unique for your example!
- Native, first class support for dense vectors first, no need to hack around the inverted index like this talk by Simon Hughes: https://haystackconf.com/2019/vectors/
- Using native programming languages, avoiding the JVM and all the memory and GC overhead
- Hopefully native languages might make it easier to deploy code that uses GPUs!
- A chance to focus on info retrieval when current Lucene solutions are either a bit crufty (Solr) or very focused on logs/analytics (Elasticsearch)
- a chance to have one system that unifies search and recommendations in one backend, not need to split them between two systems
- a chance to rethink the language used to specify query ranking factors. Solr has a very unique DSL that’s very write-only. Elasticsearch is very verbose to do anything non trivial.
Still I do wonder even if Lucene catches up a little, it’s current mindshare, reliability and install base will continue to dominate. For example see Lucene 9004 for adding dense vector search: https://issues.apache.org/jira/plugins/servlet/mobile#issue/...
The holy grail is a system that does a good job at classic full text search AND dense vector search. I wonder what system has the best chance of delivering that.