Lucene and ES implement a shortcut for filters that are restrictive enough. Since it's already optimized for figuring out if something falls into your filter set, you first determine the size of that. You traverse the HNSW normally, then if you have traversed more nodes than your filter set's cardinality, you just switch to brute forcing your filter set distance comparisons. So worst case scenario is you do 2x your filter set size vector distance operations. Quite neat.
You know, humans pick up hobbies like cycling or running which they do consistently for years, listen to specific music genres or even electronic music which is mostly just a beat, hang up a painting they like in the living room and look at it for years and years, go out to their favorite place to eat consistently or cook the same passed down family recipe, and in so many other aspects avoid sudden changes, and you're surprised that for video games we enjoy the same formula repeatedly?
>I'm still looking for a systematic approach to make a hybrid search (combined full-text with embedding vectors).
Start off with ES or Vespa, probably. ES is not hard at all to get started with, IMO.
Try RRF - see how far that gets you for your use case. If it's not where you want to be, time to get thinking about what you're trying to do. Maybe a score multiplication gets you where you want to be - you can do it in Vespa I think, but you have to hack around the inability to express exactly that in ES.
I don't know how this is something related to AI - you could polish and embellish your resume before LLMs too, I'm fairly sure. I guess this gets the clicks.
Not being to remember small details about certain projects is also perfectly fine for people who have worked for more than a couple of years. Unless you can discover a pattern of lying like the author supposedly did then I would just be perfectly fine moving on to another topic.
4.8b words on English Wikipedia. Knowledge cutoff of 6 months. A valid use case is to search across Wikipedia and ground your
answers.
Trivially proves that RAG is still needed.
People wait for things all the time and if it can take away the hassle or driving your kids somewhere, maintaining multiple vehicles for multiple family members etc. I'd bet that it does take off. Public transport doesn't solve groceries or other types of shopping though even in highly connected cities, especially for people with health problems or just aging ones.
>I find it really challenging to talk with people who have completely separated their work from their emotional being. For me, work is part of life and it should be a meaningful one.
I like my work too but when I hear things like this it's so hard not to cringe because of how much of a place of privilege this comes from. Most jobs are things no one would want to do if they didn't need to survive, and that's fundamentally built into our society and economic system. Let them eat cake though.
>Solved to the point that squeezing a bit more recall out of vector retrieval isn't the problem anymore.
I think this is a bit of a strawman.
I don't think recall is the main point these systems are trying to sell us on, it's more about robustness and ease of use compared to building something inhouse or using a lower level library to build a system on top of it just for this small part of your overall project/product (be it RAG, search, whatever).
I guess Lucene-based solutions, while very mature overall in terms of engineering, lagged behind this functionality (out of caution, trying to build what's going to be long term useful) and are also perceived a bit too cumbersome. So these stores do make sense, I think. The core functionality is nothing too complex (at least HNSW), but hiding it behind a stable black box with just a few inputs and levers, has value for people that are likely to use these stores.
I do, and it's very very rough around the edges to be honest. Lots of things broken, things are even breaking between releases suddenly in unexpected places. Or at least, I'm used to working with more robust data stores.
If my work was more high stakes, I'd have already advocated for moving our vector search to something more robust. Thankfully it's not and I can just maintain what we're making with not too much stress, and enjoy seeing this OS project grow from a user perspective (haven't seen a data store go through this very initial phase in my career yet).
Support from the team is great however, and congrats to them for this round!
The fact that the stats that drive this could be weighted in any arbitrary way makes the overall rankings pretty worthless in my eyes. And looking at the top 10 vs bottom 10 kind of validates these thoughts.
I would much rather live in most of the bottom ten than in the top ten, if we're talking long term.