Re:Comparison of vector databases
by IKantRead on Monday July 31, 2023 @11:52AM
(#36944506)
There are other use cases, but the big reason vectorDBs are exploding now (outside of general "hype") is that LLM embeddings + easy vector search means you can build a semantic search engine for basically anything you want very fast.
"Semantic search" simply means that I want to match the meaning of my query to the meaning of some other value (as opposed to something like string matching, or even TF-IDF representation).
For example: do you want better documentation search? Previously you had to use some other text search engine that likely used an older technique to do query matching and requires you to learn how to configure their software. Now? You can just take each section of your documentation, pass it to an embedding model, and store a link along with the embedding in the vector db.
Want to avoid duplicate code in your code base? You can just pass every function defined into an LLM, store a pointer to the code and an embedding, then when ever a new function is added you can look up similar function, even if those function have entirely different names.
Maybe you want to build out a recommendation engine for similar users of your app based on there profile: Pass the the profiles into an LLM for embedding, then query each user profile agains the db the find all the similar users. Most vectordbs allow arbitrary metadata to be included, so if you wanted to restrict this to similar users in a similar area you could easily code that up.
All of these projects, which formerly would have been pretty major efforts that might not have worked so well, into likely very good retrieval that can be prototyped in a few days once you have the db setup.
"Semantic search" simply means that I want to match the meaning of my query to the meaning of some other value (as opposed to something like string matching, or even TF-IDF representation).
For example: do you want better documentation search? Previously you had to use some other text search engine that likely used an older technique to do query matching and requires you to learn how to configure their software. Now? You can just take each section of your documentation, pass it to an embedding model, and store a link along with the embedding in the vector db.
Want to avoid duplicate code in your code base? You can just pass every function defined into an LLM, store a pointer to the code and an embedding, then when ever a new function is added you can look up similar function, even if those function have entirely different names.
Maybe you want to build out a recommendation engine for similar users of your app based on there profile: Pass the the profiles into an LLM for embedding, then query each user profile agains the db the find all the similar users. Most vectordbs allow arbitrary metadata to be included, so if you wanted to restrict this to similar users in a similar area you could easily code that up.
All of these projects, which formerly would have been pretty major efforts that might not have worked so well, into likely very good retrieval that can be prototyped in a few days once you have the db setup.