Daniel Svonava says Superlinked moved from recommender systems toward vector compute because retrieval quality can reduce the need for complex reranking models.
2
A useful vector representation should preserve all available information without imposing fixed preferences, so those preferences can be adjusted at query time.
3
Vector retrieval should encode objectives before nearest-neighbor search, rather than retrieving a small candidate set and reranking only that fraction of the database.
Summary
Daniel Svonava explains why Superlinked moved from recommender systems toward infrastructure for information retrieval. The company's approach builds vectors from complex, mixed data such as text, images, metadata, popularity, timestamps, click sequences, and graph information. Daniel argues that flattening all of this into one string and sending it to a language model gives people little control. A better system keeps the different properties separate, encodes them into a normalized vector, and applies preferences later. Freshness, popularity, relevance, distance, or other factors can then shape the query vector before it reaches the vector database. This lets the underlying nearest-neighbor search find the right global set of results instead of reranking a small group of already retrieved candidates. Daniel also discusses the production work around ETL, model inference, backfills, indexing, serving, and vector database operations. The conversation covers recommender systems, RAG, analytics, and choosing among vector databases.
Superlinked moved below the recommender ranking layer
Daniel Svonava describes Superlinked's path from a shared user-preference model and recommender system platform to a more general retrieval product. He had spent six years at YouTube Ads working on user modelling, and the first product targeted personalized experiences for professional communities, jobs marketplaces, and e-commerce. The company wanted to avoid becoming a consultancy that built a new reranking model for every client. Recommender systems usually split the job into retrieval and ranking. Superlinked's approach was to make retrieval smarter, reducing how much custom ranking was needed. It did this by building complex vector embeddings for users and items, then exposing objectives through a query language for vector retrieval.
Vector compute is an abstraction for turning complex data into vectors
Daniel distinguishes vector compute from vector storage. A vector database handles indexing, sharding, reliability, access control, and related database concerns. Vector compute addresses the process of turning complicated data objects into useful vectors. Those objects can have millions of properties with different types, so the system needs to handle synchronization, backfills, feature processing, and model inference. Daniel says the important question is whether a generalized computing model is enough, or whether it is worth having an abstraction designed specifically for converting data into vectors. That abstraction must preserve control instead of turning everything into a string and handing it to a language model.
Stringifying an entire object loses control over what matters
Daniel uses a movie database to explain the problem with stringification. A movie can have a title, description, category, release date, viewership, popularity, and user click patterns. A language-model-first pipeline may concatenate every field into one string and create an embedding. The result is difficult to inspect or control. A description may dominate because of an incidental phrase, placing a movie near items that do not make sense. Prompt templates can adjust wording and field emphasis, but Daniel calls this a poor way to build a real system. The system needs an explicit way to make some properties closer together and others farther apart for the particular retrieval problem.
The base vector should preserve information without fixed preferences
Daniel says the vector for a user, document chunk, house, or machine should collect everything known about that entity and encode it in an impartial way. Text may use a language encoder, while other data may need image, graph, or time-series embeddings. A timestamp might be encoded so cosine similarity reflects a time difference. The goal is to create a rich vector that compresses the organization's observations without deciding too early whether freshness, popularity, or relevance matters most. Daniel compares this to a raw DSLR photo. It may look flat, but it keeps the information needed to adjust the image later. The vector is similarly kept open to different downstream uses.
Query-time weighting should affect retrieval itself
Daniel corrects Demetrios Brinkmann's understanding of when the vector computer applies preferences. The entity vector is built during ingestion, but the query can express different weights at retrieval time. A news system may boost freshness. A recommendation screen may favor relevance. A housing search may combine distance, size, price history, and similarity to previously clicked homes. Those preferences should shape the search vector before it is sent to the nearest-neighbor index. If a system first retrieves a small candidate set and only then reranks it, the model is optimizing over a tiny fraction of the database. Daniel wants the vector database to find the globally appropriate set using ordinary cosine or dot-product search.
Production involves much more than creating an embedding
Daniel describes the work required to move a vector pipeline from a notebook into a running service. Data may arrive from warehouses, databases, blob storage, CRM systems, and other sources. ETL brings that information into core infrastructure, while machine-learning pipelines operate on top of it. Teams must decide where models run, whether inference is colocated with pipeline workers or exposed as a service, how to avoid embedding the same data repeatedly, and how to re-embed data when a model changes. They also need to handle backfills, workflow sharding, destinations, batch and real-time workloads, parallel indexing, and the operational expectations of the chosen vector database.
Specialized embedding models can reduce the cost of retrieval systems
Daniel says vectorization is required whether a team uses vector compute or builds the pipeline itself. The language model often gets used for every type of input, even though specialized models may process particular data more efficiently. A graph embedding model for graph structure can be much smaller than a language model. He recommends using language models where they are appropriate and specialized models for other inputs. For relatively small datasets, Daniel says teams should focus first on experimentation, trying ingestion and query policies and checking results quickly. At larger scale, teams need to pay more attention to efficient model serving and managed inference options.
Vector retrieval applies to analytics as well as RAG and recommendations
Daniel extends the use cases beyond RAG and recommender systems. Vectors can help find customers who behave similarly, identify factory machines likely to fail at the same time, cluster products that sell similarly, and support other machine-learning or business-intelligence queries. He expects users may eventually run these kinds of searches through business-intelligence tools without knowing which underlying vector workload performs them. He also describes Vector Hub as a practical comparison resource for vector databases. It tracks vendor capabilities across many features, links each feature to documentation, and uses a GitHub-backed dataset that vendors can update.
"When you at the query time are deciding, okay, freshness is this important, popularity this important, relevance this important, it's important to express that in a way that it informs the underlying retrieval."Daniel Svonava39:45
Who should watch
You are building a RAG or recommender system from mixed data and need more control than a single text embedding provides.
Your retrieval pipeline works in a notebook, but you are now dealing with backfills, model inference, indexing, serving, or model version changes.
You are comparing vector databases or exploring similarity search for analytics, recommendations, or operational data.
