/relevance-feedback

name: qdrant-relevance-feedback
description: "Expanding the candidate pool via relevance feedback, as an alternative to reranking when a dense retriever is too weak. Use when someone asks about 'Qdrant's Relevance Feedback API', 'improving dense search relevance/recall', 'how to discover/get more relevant results from vector search', 'cheaper/better alternative to reranking', 'using a more heavy/big embedding model for dense search but can't afford it', 'finding more relevant documents beyond the initial search pool', or 'feedback loops'. Also trigger when the user has a search quality problem due to a dense retriever being weak and is considering reranking as a solution — this API may be a better fit"

Reranking reorders documents that have already been retrieved. Qdrant's Relevance Feedback (RF), available since **v1.17**, instead modifies the vector search process itself based on a small amount of reranker feedback, distilling reranker (feedback model) knowledge into the search step. This allows RF to surface documents that the initial ANN search did not score highly enough.

The RF is intended for tasks where relevance correlates with similarity in vector space. It is available as of Qdrant 1.17.

Read this whole skill before implementing: pick the usage pattern that matches the user's goal, and check the What NOT to Do list.

How It Works

A relevance feedback query takes the query (`target`), a few seed documents (`feedback`) scored by a feedback model (3-5 seeds is enough), and formula weights for the `naive` strategy. See [Relevance Feedback](https://skills.qdrant.tech/md/documentation/search/search-relevance/?s=relevance-feedback) for the request format.

The formula weights MUST be trained once per general search use case (your dataset, dense retriever, and feedback model). If you do not train them, results will at best be random and will not align with your data distribution or model behavior. Training is lightweight because the formula itself is simple.

During search, it scores each candidate by combining similarity to the original query, similarity to highly rated seed documents and dissimilarity to poorly rated ones.

Feedback Model

A **feedback model** is any model that can produce a float relevance score for `(query, document)` pairs. Higher scores must always mean higher relevance.

Examples: a cross-encoder, embedding similarity (for example, cosine similarity between query and document embeddings, or max_sim for late interaction models), an LLM-based scorer, a custom ranker.

The feedback model used during training and inference MUST be the same model. Formula weights during training are calibrated to that model's score distribution. If you switch feedback models, you must retrain.

**What is a Good Feedback Model:**

• If the model does not improve ranking quality when used as a reranker on retrieved documents, the RF search will not have a meaningful signal to amplify.
• RF search quality depends heavily on how well the feedback model scores partial matches. The training loss of RF formula relies on relative ordering, so poor score separation in the middle range (documents that are neither clearly relevant nor clearly irrelevant) weakens results.

To Make the RF API Work, You Need to Calibrate Weights First

Use when: setting up RF for a new use case — a new collection, feedback model, or embedding model powering ANN search.

RF uses a weighted formula that combines the original query vector with feedback signals.

For the currently available `naive` strategy, the learned weights control:

• `a` — how much to trust the original ANN query-document similarity
• `b` — how strongly differences in feedback scores matter
• `c` — how strongly to follow the feedback direction (toward relevant documents and away from irrelevant ones)

These weights must be learned from your data before use. You cannot safely use arbitrary values.

• Train the weights with the [qdrant-relevance-feedback](https://pypi.org/project/qdrant-relevance-feedback/) Python library, following the [Training](https://skills.qdrant.tech/md/documentation/tutorials-search-engineering/using-relevance-feedback/?s=training) walkthrough. Use the same retriever and feedback model you will use at inference.
• Train on 50-300 representative queries. Prefer real queries from the user's traffic; if there are none, generate representative queries for the use case and tell the user, and give them the option to provide their own.
• Inform the user on cost and quality trade-offs of training: the feedback model scores every training query × `limit` candidates.
• Check the train metrics, which show whether RF had a signal (disagreement between retriever and feedback model) to distill and learn from. If there was no signal, adapt training parameters, queries, or the feedback model, and retrain until RF learns well.
• Store the resulting RF parameters in your configuration and use them during inference. Retrain if your query distribution or corpus changes significantly.
• Evaluate the formula on a separate test set of representative queries before production, as in the tutorial's [Evaluation](https://skills.qdrant.tech/md/documentation/tutorials-search-engineering/using-relevance-feedback/?s=evaluation) section. If results seem unsatisfactory, try: adjusting `limit` to retrieve more candidates during training, changing the feedback model, or curating a more representative query set.

Building the Query

Check the [Relevance Feedback](https://skills.qdrant.tech/md/documentation/search/search-relevance/?s=relevance-feedback) documentation and study the code and methods of the relevant SDK before filling in any field. For both patterns below:

• Set `using` to the retriever's vector name: RF operates in the retriever's vector space.
• Set `target` to the query embedding from the retriever (Qdrant Cloud Inference also works).
• Use the `naive` strategy with your calibrated weights.
• A point ID in a feedbac