constella-zero — FastEmbed-first card, run p35w-2m-s2500

README.md

@@ -148,15 +148,79 @@ table shipped here (sha `a7007b1a…`).
 | system | arguana | fiqa | nfcorpus | scidocs | scifact | trec-covid | **average** |
 |---|---|---|---|---|---|---|---|
 | **constella-zero (int8)** | 0.5916 | 0.3728 | 0.3124 | 0.1677 | 0.6101 | 0.5490 | **0.4339** |
-| + BM25, convex fusion | 0.5975 | 0.4026 | 0.3497 | 0.1881 | 0.7068 | 0.7018 | **0.4911** |
+| **+ BM25, Qdrant `Fusion.DBSF`, prefetch 100** | 0.5800 | 0.3872 | 0.3442 | 0.1850 | 0.7173 | 0.7184 | **0.4887** |
+| + BM25, convex fusion (not runnable in Qdrant) | 0.5975 | 0.4026 | 0.3497 | 0.1881 | 0.7068 | 0.7018 | **0.4911** |
 | BM25 alone | 0.4878 | 0.2532 | 0.3180 | 0.1565 | 0.6791 | 0.6099 | 0.4174 |
 | the teacher, used on both sides | 0.6369 | 0.5536 | 0.4134 | 0.2395 | 0.7796 | 0.8234 | 0.5744 |
 
 A lookup table retains **75.5%** of the teacher's quality (0.4339 / 0.5744), with a query side
 that does no matrix multiplication at all.
 
-The fused row is **weighted score fusion**, `0.8 × dense + 0.2 × BM25` on min-max normalized
-scores — not reciprocal rank fusion, so Qdrant's `Fusion.RRF` will not reproduce it.
+### Fusing with BM25 in Qdrant
+
+**The recommended fused system is `Fusion.DBSF` with a prefetch limit of 100** — the row in bold
+above. DBSF has **no fitted fusion weights**; the prefetch limit of 100 was chosen from where DBSF
+saturates on our development set, plus a deployability criterion, so the configuration is
+development-informed even though the operator itself fits nothing.
+
+Fusion needs **named** vectors, so hybrid search gets its own collection:
+
+```python
+# The sparse side is whatever lexical model you use -- FastEmbed's `Qdrant/bm25`, or your own.
+# Placeholder sparse vectors here, so this snippet runs with no extra download.
+client.create_collection(
+    "hybrid",
+    vectors_config={"dense": models.VectorParams(size=1024, distance=models.Distance.COSINE)},
+    sparse_vectors_config={"bm25": models.SparseVectorParams()},
+)
+client.upsert("hybrid", points=[
+    models.PointStruct(
+        id=i,
+        vector={"dense": D[i].tolist(),
+                "bm25": models.SparseVector(indices=[i], values=[1.0])},
+        payload={"text": t})
+    for i, t in enumerate(docs)])
+
+hits = client.query_points(
+    "hybrid",
+    prefetch=[
+        models.Prefetch(query=q.tolist(), using="dense", limit=100),
+        models.Prefetch(query=models.SparseVector(indices=[0], values=[1.0]),
+                        using="bm25", limit=100),
+    ],
+    query=models.FusionQuery(fusion=models.Fusion.DBSF),
+    limit=10,
+).points
+print(hits[0].payload["text"])
+```
+
+**On the four datasets with no disclosed teacher overlap** (see Limits), DBSF at prefetch 100 scores
+**0.4912** against convex fusion's 0.4866; across all six, 0.4887 vs 0.4911. Both differences are
+inside the ~0.005 band we treat as noise, and we computed no confidence interval for them, so read
+this as **no measured quality difference in either direction** — not as DBSF being better. The
+reason to prefer it is that it *runs in the product*, needs no 1000-deep prefetch, and removes a
+tuned weight from the system.
+
+The `convex fusion` row is retained for continuity: it was the operator of record when this model
+was released. It is `0.8 × dense + 0.2 × BM25`, each channel divided by its per-query maximum, at
+prefetch depth 1000 — **Qdrant does not implement it**, and a 1000-deep prefetch to return 10
+results is not a realistic configuration.
+
+`Fusion.RRF` is the weaker choice. We swept it fairly — `k` from 1 to 101 in Qdrant's units (best
+`k=3`), and 24 weighted configurations (best `k=2, weights=[2, 1]`) — and its best point lands
+below DBSF on our development set. An earlier version of this card said only that RRF "will not
+reproduce" the fused row; that was true, but rested on an unweighted, badly-ranged comparison,
+which has since been redone.
+
+**Caveats.** Numbers use `bm25s` (lucene defaults), not Qdrant's own BM25, which has a fixed
+`avg_len` and its own tokenizer; DBSF normalises over the returned scores, so a different lexical
+implementation shifts its inputs.
+
+Our evaluation excludes each query's own document *before* truncating to 100, so the numbers
+describe a prefetch with a **self-exclusion filter** (`must_not` on the point id). Without one, a
+plain `limit: 100` spends a slot on the self-match. This matters only where queries are also
+documents — ArguAna (1,298 of 1,406 queries) and FiQA (55); the other four datasets have none, so
+the clean-4 figures are unaffected either way.
 
 ## Limits