Qdrant - Vector Database
Recommendations API
'You might also enjoy' on Netflix works without queries - just from your watch history. The Recommendations API in Qdrant does the same: no embedding model at runtime, only IDs of points already in the collection.
- **Netflix-style recommendations:** recommend(positive=[watched_ids], negative=[disliked_ids]) - personalization without embedding calls
- **'Similar products':** recommend(positive=[current_product_id]) - one request, no API calls
- **Exploration:** discover(target=genre_vector, context=[{style_A, not_style_B}]) - fine-grained catalog navigation
Предварительные знания
Example-based search without an embedding model
**Regular search** requires an embedding model: query → embed → vector → search. **Recommendations API** works differently: 'find similar to these points', using vectors that already exist in the collection. No embedding model needed at runtime.
**When to use Recommendations:** 1. 'similar articles' on a content page 2. 'you might also like' in e-commerce 3. personalization based on like history 4. when an embedding model is unavailable or expensive at query time.
| Scenario | Method | Why |
|---|---|---|
| Text search by query | search() | Need to encode query semantics |
| 'Similar to this product' | recommend() | Product vector already exists in the collection |
| 'Based on your likes' | recommend(positive=[...ids]) | Multiple examples, no embedding call |
| 'Liked this, not that' | recommend(positive, negative) | Pull toward and push away by vectors |
| Exploration without explicit query | discover() | Context-based: target + negation pairs |
A user liked 3 articles on the site (ids: 15, 28, 67). How do you show them similar articles?
Positive and negative examples
**Positive examples** are points we want to move toward. **Negative examples** are points we want to move away from. Combining them lets you precisely express 'I want something like this, but not like that'.
**Positive aggregation strategies:** Qdrant supports `average_vector` (average the vectors of all positives) and `best_score` (take the best score from each positive). Default is `average_vector`. For diverse positive examples, `best_score` often works better.
A user liked both science fiction and crime thrillers. With the average_vector strategy, what happens to the recommendations?
Recommend with best_score strategy
**strategy: best_score** vs **average_vector** - fundamentally different recommendation modes. The choice affects what ends up at the top of the results.
| Strategy | Algorithm | When to use |
|---|---|---|
| average_vector | Mean of positives → nearest neighbors | Similar positives (one genre, one style) |
| best_score | max(score to any positive) | Diverse positives (different genres/topics) |
E-commerce: a user bought Nike sneakers (sports) and an Armani tie (formal). Which strategy is better for recommendations?
Discover API: context-based search
**Discover API** is the most expressive mode, designed for exploration. It accepts a `target` (what to look for) and `context` (positive/negative pairs to narrow the search space). It finds points closer to the target than the negatives, and further from the negatives than the positives.
**recommend vs discover:** `recommend` finds nearest neighbors to the positives (pushing away from negatives). `discover` finds points similar to `target`, using `context` to steer the search through the vector space - a subtle but important distinction for exploration tasks.
**recommend vs discover - in brief:** recommend('similar to these') - for 'you might also like'. discover('similar to target, guided by context') - for fine-grained navigation in vector space, exploration, and when you need to set a 'direction' via contrast.
Using recommend() for all 'find similar' cases - it is the Recommendations API after all
recommend() for 'similar to ID examples'; discover() for 'similar to target with contextual constraints'
recommend and discover solve different problems. recommend - 'have likes, find similar'. discover - 'have a goal + context, search with nuance'. Using the right API gives better recommendation quality
You want to find articles about 'machine learning' (target) that are written simply (like beginner-friendly article id:5), but not academically (like complex article id:8). Which API should you use?
Key Ideas
- **recommend()** - find similar by IDs of existing points. No embedding model needed at runtime
- **positive** attracts, **negative** repels - express 'I want this but not that'
- **average_vector** - for similar positives; **best_score** - for diverse positives
- **discover()** - search by target + context pairs. Fine-grained vector space navigation
- recommend = 'similar to examples'; discover = 'target + contextual constraints'
- Remember the hook? No API calls at runtime - faster, cheaper, more elegant
What's next
You've mastered the Recommendations API. You've completed the full Hybrid & Advanced Search cycle.
- Hybrid Search — Combine recommend with hybrid for even better quality
- Result Grouping — Group recommend results by document
- Filtering — Constrain recommendations by payload conditions
Вопросы для размышления
- Which scenario in your project calls for recommend() rather than search()? Where is the boundary?
- How do you collect positive/negative signals from users (likes, dislikes, time on page)?
- How do you measure recommendation quality? Which metrics would you use?
Связанные уроки
- qd-06-hnsw — Recommend API is built on top of HNSW for ANN search
- qd-11-hybrid-search — Recommendations can be enriched with hybrid search strategy
- ml-12 — Collaborative filtering in ML - same idea: similar objects
- aie-12-rag-fundamentals — RAG retrieval is recommendations by semantic similarity
- ml-01-intro