Hi @lschneidpro, thank you for your thoughts! I'll try to address the individual points:

1. Why concatenate vectors instead of doing separate cosine-similarity queries and then merging the results with e.g. RRF - we wrote this article to explain the issues of trying to merge independent orderings vs aggregating a combination of signals into one score and sorting by that score, which is what effectively happens if you do cosine-similarity queries on the concatenated vectors.

2. How to handle Natural Language Queries that refer to multiple properties of the data - i.e. let's say a query wants "popular red sweater under 100". To handle such query, you need:
   2.1 A subsystem that understands what properties of your data the query refers to (popularity bias, image contents bias, price hard filter). Our open source release uses GPT4o for this step. Inference of these query "intents" (represented in superlinked as query parameters) is a much more constrained problem compared to full text-to-SQL -> this makes it lower latency/more reliable to solve with an LLM.
   2.2 A subsystem that executes the "parsed" query - for example, you want a system that can reach into the content of image and text properties ("red christmas sweater"), system that can apply hard filters on the results and system that can blend multiple "bias" type signals. SQL, even supported with embeddings and pgvector, can't do these things efficiently and this creates a problem for all text-to-SQL-style approaches.

3. Biases vs filters - this depends on your use-case, but often we see people modeling a bias (e.g. "popular sweater") with a filter (popularity > 4.0) - this leads to over / under filtering and you still have to re-rank the results (because filters alone don't give you ranking). We design superlinked to be capable of both bias & filter inference and execution to navigate the tradeoff smoothly. If you are sure that for a given schema property you never want bias-style queries only filters, then don't create a space for that property and just add it to index fields and use it for filters. Practical examples for filters here and space combinations here. This same logic applies to categories - if you want to filter on categories, use filter, if you want to bias towards certain category sets in a fuzzy way, use the categorical space (there is a big upgrade to categorical space coming, we noticed it is normalized incorrectly in some cases).

4. Vector sizing concerns - indeed MongoDB has a very strict limit by default, but if you have a large account with them they can adjust the limits. We support 2 other Vector DBs that do not have a dimensional limit, so it's just a matter of cost. Some of these providers allow you to enable cost-saving features like quantization and SSD-based indexing and we try to be reasonably efficient with how many dimension each space takes up.

Does that make sense? Happy to answer further questions & I'm looking forward to your feedback!

I don’t necessarily think this approach is wrong, and I was curious about it since I’m exploring solutions for NLU in query handling. However, this framework seems more tailored for developers with limited search engine experience who want to build a search solution quickly—fitting the current trend of AI agent-focused tools.

That said, it introduces some limitations to meet my needs. By abstracting so much of the search engine, it becomes challenging to implement advanced features like ML-based re-ranking, boosting, hybrid search, or effectively leveraging user behaviour data.

Coming from a Solr/Elasticsearch background, I don’t think text-to-SQL compares fairly. For example, if I have a query parser (possibly powered by an LLM) and a user searches for “popular sweater,” instead of simply filtering (e.g., popularity > 4.0), I could use a function_score to dynamically boost popular items within the result set.

I'd love to hear about areas where we could add more value for advanced users - by the way, our full product offering contains commercial components for creating and querying Superlinked indices at scale (backed by a compiler that takes the Superlinked Schema->Index DAG and generates a full GPU-enabled Apache Spark-based pipeline out of it useful for batch updates and re-calculation during index schema migrations).

Comments about the advanced features you mentioned:

1. ML-based re-ranking: We aim to minimize the need for re-ranking in cases where a linear combination of scores suffices (and we help you apply that combination across the whole index, not just on the retrieved candidates, by packing the operation into a single cosine distance lookup). If you train your own linear weights model, you can just use it with the superlinked query API. If you want to train a more complex model (like a cross encoder), you can apply it to the superlinked results to re-rank on your own. Does that cover the need or do I miss something?

2. Boosting: You can assign weights to all index spaces at query time - see an example here. Under the hood, such weighted query is executed as one approximate nearest neighbor search in the underlying vector database (basically a logN operation). function_score in elastic forces a full-scan as far as I know, which is not feasible for larger indexes - often this makes people switch back to re-scoring using function_score, which runs into all the general re-ranking problems (balancing latency vs quality by re-scoring enough but not too many items & the associated tuning & evals of this). On the other hand, function_score is more flexible because it allows multiplicative and other combination modes, wheras our method only allows a weighted linear combination.

3. Hybrid search: Do you mean keyword search combined with embedding search into a single score? In superlinked any keyword-type constraint has to be interpreted as a filter - yes this can be limiting in some cases, but we found that you either really want to match all occurences of the keyword and then filtering on it is acceptable, or you keep it fuzzy and stick to a high-quality embedding model that tracks your domain/vocabulary well.

4. User behavior data: Superlinked treats behavioral events as first-class citizens in the data schema and allows you to use events to aggregate content features into user vectors and then to use the user vectors to bias the retrieval to achieve personalization. See an example notebook for this here. This is especially powerful with our Spark compiler because it allows you to process 100s of millions of events with proper parallelization, instead of having to apply them to your index one by one. We do all that pre-computation outside of the Vector DB and write the final vectors to the DB all at once, which is very efficient. We can also apply event data incrementally for real-time updates between the batch runs.

Additionally, some of our users train their own behavioral embeddings (ala collaborative filtering-style models) and they use them alongside all the other signals using the CustomSpace.

Do you have an eval setup for your NLU project? Would love to check it out!

@lschneidpro does that make sense Luca? sorry for a wall of text! :-)