by that same logic, why would you not strive to push all the signals you have available into the ANN search? sure, some will have reduced resolution vs using a heavy reranker, but surely the optimal solution is to use the same signals in both stages and just add resolution in the second stage? the more they are aligned, the fewer candidates you need -> better latency & lower cost.
one thing to remember is that bm25 is purely in the domain of text - the moment any other signal enters in the picture (and it ~always does in sufficiently important systems), bm25 alone can literally have 0 recall.
Basically think mixture of experts, but each expert is an encoder with it's own input tokenization/feature engineering part and then there is some machinery to parametrize these encoders based on natural language queries and stitch their outputs together to form unified vectors for objects in the index and the queries coming in.
We have some proprietary tech besides that - mainly embedding models for things like location and then executors for the Superlinked DAG that help you run it on GPU-accelerated Spark and something analogous to that for streaming workloads - those proprietary things are how we make money, we call it Superlinked Cloud.
This article focuses on ways to make "pre-fetching" more accurate, reducing or eliminating the need for reranking to improve latency/cost but also sometimes quality - for example if you use a text cross-encoder to rerank your structured objects, you'll find that those rerankers don't actually understand much of the numbers, locations and other data like that.
If this was a solved problem, every e-com website would already run some variant of https://arxiv.org/pdf/2209.07663 for all their shopping surfaces and some version of "deep research" on every search query. They don't, so the problem isn't solved. And a big part of the problem is still the integration of behavioral, structured and unstructured signals into the underlying retrieval of products and content - which is what the article is about.
Also, the company is doing fine, not sure where that last sentence came from ^_^
It allows faster experimentation because you can't do things like partial embedding updates and reasonable schema migrations on your vector search index - if you could, you'd experiment in retrieval... and with better retrieval you don't have to move 100s or 1000s of candidates from a database and pay a ton for a ranker inference on every query (not even mentioning the latency impact of that).
If you could wave a magic wand and push all the ranking signals into retrieval and that index would be fast to update and not that expensive to operate - you would do that and you would delete all your reranking systems, wouldn't you?
We are mostly focused on natural language search in e-commerce/marketplace/travel settings right now. There we have a production deployment that drove $15M of incremental revenue through personalization of a shopping feed for a fashion e-commerce business. Happy to share more if you are interested, feel free to email me at daniel@superlinked.com!
We focus on text, images, numerical, categorical and timestamp-properties for the objects you vectorize with Superlinked. The performance will depend on which models you chose to use with the framework, your queries etc. Happy to elaborate if you could describe your use-case :-)
As you say, AstraDB also offers vector search (you can see it at https://superlinked.com/vector-db-comparison) but we haven't built the integration with them yet. We focus on fewer but higher quality integrations in general. Do you like AstraDB? Any advantages vs competition that you care about?
In terms of the plan you mentioned Astra+Redis - you don't have to do that, you can just use redis for both key-value store and vector search.
