krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-09-30 00:18:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

explain query_points_groups inline and remove pattern-doesnt-fit section

Browse Source 
Adds a one-line comment above the query_points_groups call so readers
see what the function does without waiting for the When to Group
subsection (which now sits at the end of the design-decisions list).

Removes the entire 'Where This Pattern Doesn't Fit' section: the
short/homogeneous paragraph read as obvious (a reader who's deep into
this tutorial wouldn't try to multi-rep a tweet), and the
inconsistent-metadata paragraph was too vague to be actionable.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dylan Couzon
2026-05-11 19:08:37 -04:00
co-authored by Claude Opus 4.7
parent 8ea4653ee8
commit 479d305aca
1 changed files with 1 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/documentation/tutorials-search-engineering/multi-representation-search.md
+1 -6
View File
@@ -182,6 +182,7 @@ def retrieve(query, limit=10, group_size=3, tags=None):
models.Filter(must=[models.FieldCondition(key="tags", match=models.MatchAny(any=tags))])
if tags else None
)
# query_points_groups runs the prefetches, fuses with RRF, applies the filter, and groups results by document_id.
return client.query_points_groups(
collection_name="arxiv_multi_repr",
prefetch=[
@@ -259,12 +260,6 @@ Two operational notes:
For the step-by-step build-up that produced this design (dense baseline, plus sparse, plus title prefetch, plus grouping, plus boosting) with eval numbers showing the lift at each step, see the [accompanying notebook](https://github.com/qdrant/examples/blob/master/multi-representation-search/multi-representation-search.ipynb). For a complementary view that varies the *query* across three representations against a single document representation, see the [Universal Query for Hybrid Retrieval demo](/course/essentials/day-5/universal-query-demo/). This tutorial is the document-side equivalent: multiple document representations against a single query.
## Where This Pattern Doesn't Fit
Multi-representation retrieval pays off when items are long and structured. It's overkill, and sometimes worse than a single dense vector, when items are short and homogeneous. Tweets, product names, and one-line forum titles don't have a meaningful title-versus-body distinction; splitting them into representations adds query latency without adding signal. For those cases, a single well-chosen dense model and a sparse fallback are usually enough.
The pattern also assumes you can identify the representations cleanly. If your corpus has inconsistent metadata (some documents have abstracts, others don't), the missing-representation case becomes its own design problem: empty vectors, fallback strategies, or a separate index per representation availability.
## Wrapping Up
Multi-representation retrieval is a schema decision, not a model decision. Once each representation has its own named vector, the Query API composes them at query time: prefetch per representation, fuse with RRF, group by document for presentation, and apply a formula for ranking preferences.