What is Retriever
Retriever - A saved, versioned search pipeline: the ordered stages that turn a query into ranked results
A retriever is a query pipeline you declare once and execute many times. It chains stages, typically a filter, a vector search, sometimes a keyword search, a fusion step and a reranker, each handing a candidate set to the next. Saving it as an object rather than assembling it per call is what makes retrieval reproducible: the same named retriever returns comparably ranked results tomorrow, and a change to it is a versioned change rather than a quiet edit in application code.
How It Works
You declare the stages and their parameters, including how many candidates each stage passes on. At execution you supply the inputs the retriever declares, usually a query string and any filter values, and it runs the stages in order. The candidate budget between stages is the main cost lever, because a cross-encoder reranker runs a model forward pass per candidate, so the number handed to it is close to the whole cost curve of the pipeline.
Technical Details
A retriever that reports what it did with your request is worth more than one that merely returns rows: which inputs it recognised, which it ignored, and which filter conditions it relaxed because the input they referenced was missing. A relaxed filter means the result set is broader than the one you wrote, and that is the case which is otherwise invisible. Retrievers are also the natural place for evaluation, since a saved pipeline can be replayed against a labelled query set to produce recall and NDCG that are comparable across runs.
Common Pitfalls
- Setting the reranker's candidate budget once by guess and never measuring where the recall curve flattens
- Post-filtering a selective predicate and getting far fewer results than requested, instead of pushing the filter down
- Assuming a filter applied, when the field it references was never provided and the condition was dropped
- Comparing scores across stages or corpora that were never normalised to each other
- Editing pipeline behaviour in application code rather than in the retriever, so the change is invisible to anyone reading the saved definition
Relevance to Multimodal Systems
Multimodal retrieval needs the pipeline to be explicit because the stages have wildly different unit costs and the row counts are large: one hour of segmented video can produce a couple of thousand documents, so ten thousand hours is twenty million rows before any frame-level features exist. At that scale stage order and candidate budgets decide whether a query is a product or a timeout. See retriever templates, the retrievers documentation, and multi-stage retrieval.
Put multimodal search to work
Connect a bucket and Mixpeek runs the whole multimodal search pipeline for you: extraction, indexing, and search over your own objects. No models to wire up, nothing to host.
Start with ManagedAlready have vectors?
Keep your embeddings on your own cloud and run dense, sparse, and BM25 search directly on object storage. From $25/mo.
Start with MVS