mish15

Yes it's all wrong, because: a) recall is designed to measure binary relevance, but vector scores are not good relevance judgments and they aren't binary. b) most models optimise purely for distance, which makes nDCG look great, but causes content to clump together. This loses local ranking precision and the noise from embedding order is significantly greater than the approximation in the ANN system c) bi-encoders have significantly greater error than cross-encoders. Basically every vector DB is blowing at least one order of magnitude more resources than they need to to optimise bi-encoding efficiency which is wrong anyway.

Disclaimer: I work at Algolia.

Yeah basically all the vector "database" solutions in market have chosen data-dependent indexes, so you need the data upfront. Imagine if regular databases needed all data upfront before they could build indexes. It's kind of crazy...

On hybrid indexes with full text and vector support?

Last I heard Pinecone doesn’t even support full text search, let alone hybrid indexes, what do you think you are disproving exactly?

Real-time upserts on hybrid and vector indexes is very unusual, please link to how you do this.

You pay a decent cost to do the hash, it’s a compression algorithm of sorts. But the data is a fraction of the size and comparison is way faster. If you do many of these or compare the same ones more than once you amortise the cost very quickly

Yes and yes.

Network based hashing is great to maximise information quality of the hash (compared to other LSH methods). It works to compress existing vectors super efficiently.

Very soon things like language embeddings will skip the vectors and instead networks output hashes directly. These are much faster as the network can learn where to use more bits where it needs resolution, as opposed to using floatXX for everything. It’s amazing to see it work, but not fully there yet.

We will add neural hash based ANN to that repo when we get time. I expect HNSW to get pushed out in time for many reasons.

I was part of the above article. Happy to answer questions.

In terms of accuracy, it totally depends on the resolution needed. We can get >99% accuracy of L2 waaaaay faster with 1/10 of the memory overhead. For what we are doing that is the perfect trade off.

In terms of LSH, we tried projection hashing and quantization and were always disappointed.

Yes. Storage also. You can get >99% ordering quality of exhaustive cosine with a tiny fraction of memory usage

Interesting. Hadn’t seen it actually. BOW is problematic as a starting point, but this is neat and a long time ago too.

This is easily the most fun thing I’ve been involved with for years. Can’t wait to see it ship.

You just mmap memory as a slice. You can grow and shrink it, flush to disk if backed by a file, etc. In code it’s just a slice. Tough part is you need to allocate, control bounds, binary encode/decode, struct align, defrag, etc. It’s hard work, but the performance is 100% worth it if performance is your main goal.

You can do this in pure Go though, you just need to manage the allocator yourself. That is a significant technical undertaking, but once done the advantages are huge. No GC overhead, no cgo. Done properly you can even have multiple readers and writers working concurrently in the same allocation space.

What search tech are you building it on out of interest?

Totally agree. We looked at providing tech in this space and it means you have to plug into literally every system. It’s an endless problem.

Slack search is awful and they have a full team on it. Jira is a mess. Gmail search is pretty good already, which is one of the things that makes frontapp far less useful also.

We have an early access product for personalized ecommerce search @Sajari if you are interested. One early access company is on track to generate $30 million in additional revenue from switching (over 10% search conversion increase). That is across millions of skus and hundreds of products updated per second also.

We are also looking at releasing this as a k8s deployable product. It's all k8s services and gRPC already...

Unlikely, the GSA product is also discontinued. This is a push to a google cloud alternative i would guess.

Their search appliance (GSA) is being replaced with a cloud search product. I would guess once that is released it will make the GSS product a bit redundant, so it makes sense to discontinue, the timing is a bit strange though...

I'm amazed so many people and companies are focussed on trying to manage/limit peoples exposure to tracking technologies. Everyone is looking at this problem backwards. I say this because the vast majority of these technologies are javascript based and simply read cookies and execute simple image requests to send information back to tracking servers. If someone was to invent a plugin that allowed these technologies to still function, but randomly scrambled the data being sent (along with sending extra dummy requests here and there), it would be over...

Tracking companies rely on clean data, they even report on exact numbers coming out of these systems, so instead of people trying to avoid being part of their clean data, it would be far more effective to make their data dirty so they can't trust it (or sell it).