The Leaderboard Is Not Your Corpus: Why Top-Ranked Embedding Models Disappoint in Production

A team swaps the embedding model behind their retrieval system for the one currently sitting at the top of the Massive Text Embedding Benchmark. The published average is 1.8 points higher than the model they were using. Recall on their own evaluation set goes down. Somebody re-runs it, and it goes down again.

This is not a rare outcome, and the usual explanations, bad chunking, bad queries, a bad day, are usually wrong. The leaderboard measured something real; it simply did not measure the thing that was about to change. Three distinct mechanisms separate a benchmark rank from retrieval quality on a specific corpus, and each of them is large enough on its own to reverse a two-point gap.

The most concrete of the three has a number attached. MTEB publishes training splits for many of its datasets, models train on them, and the benchmark now reports a zero-shot score to say how much: for a model trained on \(n_{\text{train}}\) of the benchmark's \(n_{\text{total}}\) datasets,

The documented example is e5-mistral-7b-instruct at 95%, meaning it was trained on roughly 5% of the benchmark's training splits (Chung et al., 2025, Maintaining MTEB, arXiv:2506.21182). Models with substantially lower scores appear on the same board, ranked by the same average.

Why this matters: Retrieval quality sets the ceiling on every RAG system built above it. A generator cannot cite a document the retriever did not return, and no amount of prompt engineering recovers a missed chunk. If the model selection step is being made from a number that does not transfer, everything downstream inherits the error, and the failure is invisible because there is nothing to compare against.

TL;DR

• MTEB's zero-shot score is \(z = 1 - n_{\text{train}}/n_{\text{total}}\); a model can rank highly with a substantially sub-100% score, and the score is reported precisely because that happens.
• Filtering the leaderboard to 100% zero-shot models was tried and abandoned, because it penalised labs that honestly disclosed their training data while leaving undisclosed models in place.
• The benchmark average spans task families that want incompatible geometry: retrieval wants near-duplicates separated, semantic similarity wants them together. A good average is a compromise, not an optimum.
• BEIR's original finding still holds: BM25 is a robust zero-shot baseline that many dense retrievers fail to beat out of domain, which is the whole reason hybrid retrieval remains a default.
• Model size is not the axis. Across MMTEB's 500+ tasks and 250+ languages, the best publicly available model was multilingual-e5-large-instruct at 560M parameters.
• Hubness, a property of high-dimensional geometry rather than of any model, causes a few documents to appear in vast numbers of neighbour lists and others in none. No leaderboard measures it, and it is corpus-dependent.
• A 300-query internal evaluation cannot resolve a two-point difference. Detecting a 2 percentage-point paired difference at 80% power needs roughly 2,900 queries; a 10-point domain effect needs about 200.
• The correct use of a leaderboard is as a shortlist generator. The decision belongs to a few hundred labelled pairs from your own traffic, which is enough to resolve the effects that actually matter.

At a Glance

flowchart LR
    A["Leaderboard rank"] --> B{"What it measures"}
    B --> C["Benchmark corpora<br/>public, frozen, short docs"]
    B --> D["Averaged over<br/>8 task families"]
    B --> E["Possibly trained on<br/>the same datasets"]
    F["Your retrieval quality"] --> G{"What it depends on"}
    G --> H["Your domain<br/>and vocabulary"]
    G --> I["Your chunk length<br/>and query style"]
    G --> J["Corpus geometry<br/>hubness, duplicates"]
    G --> K["Reranker and<br/>hybrid stage"]

    classDef blue fill:#1e40af,stroke:#3b82f6,stroke-width:1px,color:#fff
    classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0
    classDef rose fill:#be123c,stroke:#fb7185,stroke-width:1px,color:#fff
    classDef emerald fill:#047857,stroke:#34d399,stroke-width:1px,color:#fff

    class A,F blue
    class B,G slate
    class C,D,E rose
    class H,I,J,K emerald

The two halves of that diagram share no nodes. That is the argument of this article in one figure.

How Retrieval Evaluation Got Here

timeline
    title From Cosine Similarity to a Contested Leaderboard
    2013 : word2vec makes dense vectors a practical representation
         : Evaluation is analogy tasks and small similarity datasets
    2019 : Sentence-BERT makes sentence-level dense retrieval fast enough to deploy
    2020 : DPR beats BM25 top-20 accuracy by 9 to 19 points with in-batch negatives
         : Dense retrieval becomes a default rather than a research curiosity
    2021 : BEIR evaluates 10 systems zero-shot across 18 heterogeneous datasets
         : Finds BM25 a robust baseline many dense retrievers fail to beat out of domain
    2022 : MTEB standardises evaluation across 8 tasks, 58 datasets, 112 languages
         : E5 shows weakly-supervised contrastive pretraining beats models 40x larger
    2024 : Leaderboard training splits become widely used; contamination concerns go public
    2025 : MMTEB extends to 500+ tasks and 250+ languages; best public model is 560M parameters
         : MTEB adds a zero-shot score after filtering by it proved to penalise transparency

The arc is worth noticing. BEIR was built in 2021 on the explicit premise that in-domain evaluation says nothing about transfer, and it found that BM25 was hard to beat zero-shot (Thakur et al., 2021, BEIR, arXiv:2104.08663). MTEB then broadened coverage enormously, which was a genuine advance, and in doing so published training splits, which reopened exactly the in-domain problem BEIR had been built to close (Muennighoff et al., 2022, MTEB, arXiv:2210.07316).

That is not a criticism of either project. It is what happens when a benchmark becomes the field's selection mechanism: the incentive to fit it appears the moment it starts deciding anything.

Three Mechanisms, Any One of Which Reverses a Two-Point Gap

One: the training splits are public

MTEB's own maintainers describe the resulting situation plainly. Their initial response was to filter the leaderboard to models with 100% zero-shot scores or unknown training data, and they abandoned it because it "penalized transparency by hiding otherwise strong models that honestly disclosed their training data." The replacement is a granular annotation shown alongside the rank.

Nils Reimers, an MTEB co-author and the author of Sentence-BERT, has stated publicly that training on MTEB training splits and evaluating on MTEB for a leaderboard submission was never the intent, that embedding models must be evaluated out of domain for the number to mean anything, and that publishing those splits was a mistake (public statement, December 2024).

The mechanism is ordinary supervised learning. A model that has seen the training split of a dataset has seen that dataset's query style, its document distribution, its notion of relevance, and often near-paraphrases of its test items. It will score well on that dataset. None of that transfers to a corpus of internal engineering documentation.

flowchart TB
    A["Benchmark dataset D"] --> B["Train split of D<br/>published"]
    A --> C["Test split of D<br/>used for ranking"]
    B --> E["Model training mixture"]
    E --> F["Model"]
    F --> C
    C --> G["Leaderboard rank"]
    F --> H["Your corpus<br/>no train split exists"]
    H --> I["Production recall"]
    G -.->|"weak predictor"| I

    classDef blue fill:#1e40af,stroke:#3b82f6,stroke-width:1px,color:#fff
    classDef rose fill:#be123c,stroke:#fb7185,stroke-width:1px,color:#fff
    classDef purple fill:#6d28d9,stroke:#a78bfa,stroke-width:1px,color:#fff
    classDef emerald fill:#047857,stroke:#34d399,stroke-width:1px,color:#fff
    classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0

    class A,B,C blue
    class E,F purple
    class G rose
    class H,I emerald

Contamination is also not always deliberate, which is why the zero-shot score is described as a coarse estimate rather than a verdict. Many models train on Wikipedia title-body pairs and many benchmark datasets derive from Wikipedia; MTEB's guidance explicitly does not count that as leakage for tasks not built from title-body pairs. The boundary between "trained on adjacent data" and "trained on the task" is a judgement call, made case by case.

[IMAGE: Scatter plot with MTEB average score on the x-axis and zero-shot score on the y-axis, each point a model, point size proportional to parameter count. A shaded band highlights the top of the score range, where points span a wide range of zero-shot values. Caption: "Rank and zero-shot score are reported side by side because they are close to independent."]

Two: the average spans incompatible objectives

MTEB averages retrieval, reranking, clustering, classification, pair classification, semantic textual similarity, summarisation and bitext mining. These tasks make contradictory demands on the same geometry.

Retrieval wants the space stretched around fine distinctions: two passages that are topically near-identical must be far apart if only one answers the query. That is exactly what hard-negative training produces, and it is the mechanism behind most of the last five years of retrieval progress, from in-batch negatives in DPR (Karpukhin et al., 2020, arXiv:2004.04906) to index-refreshed ANN mining in ANCE (Xiong et al., 2020, arXiv:2007.00808).

Semantic textual similarity wants the opposite. Two near-identical passages should score as near-identical, because that is the definition of the task.

A model that averages well across both has been pulled toward the middle. If your application is retrieval and only retrieval, the model you want may sit several ranks down the average column and at the top of the retrieval column. This is not a subtle effect and it is trivially checkable, which makes it the most avoidable of the three.

MTEB's own launch finding was that no method dominates across tasks. The average column exists to make a leaderboard sortable, not because a single number is meaningful.

[IMAGE: Two side-by-side scatter plots of the same corpus embedded by two models, projected to 2D. The left, from a retrieval-tuned model, shows near-duplicate passages pushed apart into distinguishable clusters. The right, from a similarity-tuned model, shows the same passages collapsed on top of each other. Caption: "The same corpus, two defensible geometries. The benchmark average asks for both at once."]

Three: geometry the benchmark never sees

The third mechanism is the least known and the least fixable by model choice, because it is a property of your corpus interacting with high-dimensional space.

Define the k-occurrence \(N_k(x)\) of a point as the number of other points that have it among their \(k\) nearest neighbours. In low dimensions this distribution is roughly symmetric. As dimensionality rises it becomes strongly right-skewed: a few hubs appear in a disproportionate share of all neighbour lists, and many anti-hubs appear in none (Radovanović, Nanopoulos & Ivanović, 2010, Hubs in Space, JMLR 11, 2487-2531).

The cause is concentration of distances. In high dimensions, distances from a query to all points cluster around a similar value, so rankings are decided by small margins. Points slightly closer to the data mean are marginally closer to everything, and they win those small margins repeatedly, across queries with nothing in common.

Retrieval takes the arg-top-\(k\), which maximises exposure to precisely the points that rank highly for spurious reasons. And the effect compounds with anisotropy: learned embedding spaces occupy a narrow cone rather than the full sphere, which raises effective concentration above what the i.i.d. theory predicts.

Two consequences, of very different visibility:

Hubs are noticed. An irrelevant document keeps appearing; somebody files a ticket.

Anti-hubs are not. A document that is nobody's nearest neighbour is functionally absent from the index. Aggregate recall barely moves, because the affected queries are a small fraction of any test set. It surfaces months later as "the system never finds our security policies," a complaint with no failing test behind it.

No benchmark measures this, because it depends on your corpus, not on the model. It takes one pass over your index to measure.

[IMAGE: Two histograms of k-occurrence for k=10, side by side. The left, from a 50-dimensional projection, is roughly bell-shaped. The right, from the full 1024-dimensional space over the same corpus, is heavily right-skewed with a long tail and a large spike at zero. The zero spike is annotated "documents that are nobody's neighbour". Caption: "Same corpus, same model, different dimensionality. The spike at zero is the invisible failure."]

By the Numbers

Sources: Muennighoff et al., 2022 (arXiv:2210.07316); Chung et al., 2025 (arXiv:2506.21182); Enevoldsen et al., 2025 (arXiv:2502.13595); Thakur et al., 2021 (arXiv:2104.08663); Karpukhin et al., 2020 (arXiv:2004.04906); Sentence Transformers, Embedding Quantization. The DPR figure is in-domain on open-domain QA and does not describe out-of-domain transfer.

A Concrete Example

The obvious response to everything above is "so evaluate on your own data." Correct, and the interesting question is how much data, because the answer determines whether the exercise is an afternoon or a quarter.

Step 1: the naive evaluation. You label 300 query-document pairs from production traffic. Model A returns the correct document in the top 10 for 210 of them: \(\hat{p} = 0.70\).

The standard error of that estimate:

A 95% confidence interval is therefore \(0.70 \pm 1.96 \times 0.0265\), or roughly 64.8% to 75.2%. Ten and a half points wide.

The leaderboard gap you were trying to adjudicate was 1.8 points. It is not merely inside that interval; it is inside a fifth of it.

Step 2: how many queries would settle it, unpaired. To detect a difference \(\delta\) between two proportions at significance \(\alpha = 0.05\) and power \(0.8\), the usual approximation is

With \(z_{\alpha/2} = 1.96\), \(z_{\beta} = 0.84\), \(p = 0.70\) and \(\delta = 0.02\):

Step 3: pair the comparison. Both models answer the same queries, so this is a paired design, and only the queries where the two models disagree carry information. McNemar's test applies, and the sample size depends on the discordance rate \(\pi_d\):

With a realistic discordance rate of 15%, meaning the two models differ on 15% of queries:

Pairing bought roughly a 3x reduction, and 2,900 labelled queries is still well beyond what most teams will produce.

Step 4: the useful conclusion. Run the same arithmetic for the effects that actually appear in production. Suppose a candidate model is 10 points better on your domain, which is an entirely ordinary gap between an in-domain-tuned model and a generic one. With \(\delta = 0.10\) and a correspondingly higher discordance rate of 25%:

Two hundred labelled queries resolves a ten-point domain effect. Three thousand would be needed for a two-point leaderboard effect.

That asymmetry is the practical thesis. A small internal evaluation is not underpowered for the decision you should be making; it is underpowered only for the decision the leaderboard invites you to make. Stop trying to adjudicate two-point differences, in either direction, and spend the labelling budget on detecting the large effects: domain fit, chunk-length sensitivity, query-style mismatch, and whether adding a reranker beats changing the embedder at all.

[IMAGE: Required sample size on a log y-axis against detectable effect size on the x-axis from 1 to 20 percentage points, with two curves for unpaired and paired (McNemar) designs. Horizontal reference lines at 200, 1,000 and 3,000 queries mark plausible labelling budgets. Annotations mark "typical leaderboard gap" at 2 points and "typical domain effect" at 10. Caption: "The same evaluation set is hopeless for one question and comfortably sufficient for the other."]

[IMAGE: Two ranked result lists for the same query, side by side, one produced with real user queries and one with LLM-generated queries derived from the documents. The generated-query list shows the correct document at rank 1 with a large score margin; the real-query list shows it at rank 7 with a compressed margin. Caption: "Synthetic queries inherit the document's vocabulary, which is exactly the difficulty a real user creates."]

Where It Breaks

The zero-shot score is coarse by design

It counts datasets, not similarity. A model trained on data that merely resembles a benchmark dataset scores as fully zero-shot on it. And the Wikipedia title-body carve-out is a reasonable judgement that nonetheless demonstrates the boundary is a judgement. Treat the score as a strong signal and not as a certificate.

Benchmark saturation compresses the signal

As models converge at the top, the gaps between ranks fall inside the noise band, and rank order becomes an artefact of seed, preprocessing and evaluation harness version rather than of capability. This is the same dynamic as contamination in LLM benchmarks, and it needs the same treatment: error bars, private held-out sets, and a bias toward your own harness. A leaderboard that everyone optimises against eventually stops discriminating, and the point at which that happened is not announced.

Cost and latency are entirely absent

Dimensionality determines index size. Sequence limit determines chunking strategy. Inference cost and latency determine what you can afford at query time. None appears in a rank. A 1024-dimensional model that is 0.5 points better than a 384-dimensional one costs 2.7x the index memory, and there is no column for that. Matryoshka representation learning and binary quantisation change that calculus substantially, and neither is visible on the board either.

Chunk length is a silent mismatch

Many benchmark documents are short. If your chunks run to 2,000 tokens, you are operating a model outside the regime it was ranked in, and the pooling behaviour that works at 100 tokens is not guaranteed to hold at 2,000. Check the sequence limit and the length distribution of the benchmark corpora before assuming transfer.

The multilingual tail is thin

MMTEB's 250+ languages is a real achievement, and per-language task counts fall sharply in the tail, so a low-resource language's score may rest on a single dataset with no error bar worth the name. Code-mixed and transliterated text is worse: off-distribution for both language identification and alignment, and far below the headline number. See cross-lingual embedding alignment.

Your corpus drifts and the benchmark does not

The benchmark is frozen. Your corpus gains documents weekly, and the geometry that determined hub structure last quarter is not this quarter's. Model selection is a point-in-time decision; retrieval quality is a continuously varying quantity. Treat it with the monitoring you would apply to any other production model.

Alternative Designs

sequenceDiagram
    participant Q as Query
    participant B as BM25 index
    participant V as Vector index
    participant F as Fusion
    participant R as Cross-encoder
    participant G as Generator

    Q->>B: lexical search
    Q->>V: dense search
    B-->>F: top 50 lexical
    V-->>F: top 50 dense
    Note over F: reciprocal rank fusion, no hubs from the lexical side
    F->>R: merged shortlist of ~80
    R-->>G: rescored top 5
    Note over R,G: the reranker absorbs fine distinctions the embedder missed

Read that flow against the three mechanisms. The lexical arm is immune to hubness because BM25 has no metric space. The fusion step recovers documents either arm missed alone. The cross-encoder scores pairs jointly, so it inherits neither the embedder's geometry nor its domain fit. Each stage independently reduces the sensitivity of the whole system to which embedder sits inside the dense arm, which is the practical reason embedder choice matters less than it feels like it should.

The row worth arguing about is the reranker. Teams routinely spend weeks comparing embedders when adding a cross-encoder over the top 50 would deliver a larger gain than any embedder swap available, and would deliver it independently of which embedder they eventually pick. BEIR reported exactly this in 2021: reranking and late-interaction models achieved the best zero-shot performance, at high computational cost. The cost is the reason to think about it; the ordering is the reason to think about it first.

How It Is Used in Practice

A workable selection procedure, in the order that respects what each step can actually resolve.

Shortlist from the leaderboard, using the right column. Sort by the retrieval column, not the average. Read the zero-shot score. Filter by sequence limit and dimensionality against your chunk size and index budget. Three or four candidates is enough; the differences between rank 1 and rank 8 are smaller than the differences that follow.

Build 200 to 400 labelled pairs from real traffic. Real queries, not queries generated from your documents, because generated queries inherit the document's vocabulary and systematically overstate recall. If you have no traffic yet, generate synthetically to bootstrap and replace them as soon as real queries exist.

Measure recall at your actual \(k\), with a confidence interval. Report the interval, always. A team that reports 70% and a team that reports "70%, 95% CI 65 to 75" will make different decisions from the same data.

Look for structural problems before comparing models. Compute the k-occurrence distribution over your index and check the spike at zero. Check for near-duplicate clusters. Both are one pass over the index, both are corpus properties no model choice fixes, and both are more likely to be your problem than the two points between rank 1 and rank 4.

Add hybrid and reranking before optimising the embedder. Then re-run the comparison, because the ordering of embedders can change once a reranker is absorbing the fine distinctions.

Re-measure on a schedule. The corpus drifts, the query distribution drifts, and the model does not. Retrieval quality belongs on a dashboard, not in a decision document.

[IMAGE: Funnel diagram of the selection procedure, from "all public models" through "retrieval column plus zero-shot filter" to "sequence and dimension constraints" to "3-4 candidates" to "in-house paired evaluation" to "one model", with the expected effect size annotated beside each stage: 1-3 points, 1-2 points, 5-15 points. Caption: "The stage with the largest effect is the cheapest one, and the last one anybody does."]

[IMAGE: Stacked contribution chart estimating where end-to-end recall gains come from in a typical RAG deployment, with bands for chunking strategy, embedder choice, hybrid fusion, and cross-encoder reranking. The embedder-choice band is visibly the thinnest. Caption: "Illustrative, not measured: the point is the ordering, and the ordering is stable across most deployments."]

Insights Worth Remembering

1. A leaderboard becomes an optimisation target the moment it becomes a selection mechanism. MTEB's zero-shot score exists because that happened, and its maintainers document the fact openly. The score is evidence of a healthy benchmark, not of a broken one.

2. Filtering for cleanliness punished the labs that disclosed their data. MTEB tried it and reversed course. That is worth remembering whenever anyone proposes a purity gate on any benchmark: transparency is the thing such gates penalise first.

3. The average column is a sortability device, not a measurement. It spans task families with contradictory geometric requirements. Reading the retrieval column instead removes an entire class of error, and costs nothing.

4. Retrieval-optimised and similarity-optimised embeddings are genuinely different objects. Hard-negative training pushes near-duplicates apart; STS wants them together. A model can be excellent at one and mediocre at the other, and averaging hides which.

5. Hubness is a property of your corpus, not of the model. No benchmark can measure it for you, and the anti-hub half of the effect is invisible to aggregate recall. One pass over the index turns it from a mystery into a histogram.

6. Two hundred queries is enough for the decisions that matter, and nowhere near enough for the one the leaderboard invites. Roughly 200 paired queries resolve a 10-point domain effect; roughly 2,900 are needed for a 2-point difference. Choose the question to match the budget.

7. Model size is not the axis for embeddings. MMTEB's best public entrant was 560M parameters. Data and objective dominate, which is unlike the generative scaling story and repeatedly surprises teams importing intuitions from it.

8. The reranker is usually the larger, more transferable win. It scores pairs jointly, so it inherits neither hubness nor the embedder's domain fit, and its gain is roughly independent of which embedder sits beneath it. It should be evaluated before the embedder comparison, not after.

Open Questions

Can dataset-level contamination scoring be replaced with something continuous? Measured: the current zero-shot score counts benchmark datasets a model trained on. Not yet available: a similarity-based measure of how close a model's training distribution is to each evaluation set, which would capture near-duplicate corpora that dataset counting misses entirely.

Is there a benchmark design that resists optimisation? Private held-out sets, rotating test items and pairwise arenas all help and all have known weaknesses. Whether any static public benchmark can retain discriminative power once it becomes the field's selection mechanism is genuinely open, and the answer may be no.

How much do embedding leaderboard ranks actually predict production recall? Anecdotally the correlation is weak; systematically, nobody has published a study correlating public rank with measured retrieval quality across many real corpora, largely because those corpora are proprietary. It is the single most useful missing experiment in this area.

Does hubness correction help enough to be worth the semantic cost? Known: mutual proximity, corpus centring and reranking all reduce hub pollution. Unknown: how much end-to-end recall they buy on realistic corpora, and whether the resulting scores, which are no longer cosine similarities, break more downstream thresholds than they fix.

What is the right evaluation unit for long documents? Benchmarks evaluate passage retrieval. Production systems retrieve chunks whose boundaries were chosen by an ingestion pipeline, and chunk quality and embedder quality are entangled in the measured result. Separating the two would make model comparisons far more transferable than they currently are.

Sources and Further Reading

1. Muennighoff, N., Tazi, N., Magne, L., & Reimers, N. (2022). "MTEB: Massive Text Embedding Benchmark." EACL 2023. arXiv:2210.07316

2. Enevoldsen, K., Chung, I., Kerboua, I., et al. (2025). "MMTEB: Massive Multilingual Text Embedding Benchmark." ICLR 2025. arXiv:2502.13595

3. Chung, I., Kerboua, I., Kardos, M., Solomatin, R., & Enevoldsen, K. (2025). "Maintaining MTEB: Towards Long Term Usability and Reproducibility of Embedding Benchmarks." arXiv:2506.21182

4. Thakur, N., Reimers, N., Rücklé, A., Srivastava, A., & Gurevych, I. (2021). "BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models." NeurIPS 2021 Datasets and Benchmarks. arXiv:2104.08663

5. Karpukhin, V., Oğuz, B., Min, S., Lewis, P., Wu, L., Edunov, S., Chen, D., & Yih, W. (2020). "Dense Passage Retrieval for Open-Domain Question Answering." EMNLP 2020. arXiv:2004.04906

6. Xiong, L., Xiong, C., Li, Y., Tang, K.-F., Liu, J., Bennett, P., Ahmed, J., & Overwijk, A. (2020). "Approximate Nearest Neighbor Negative Contrastive Learning for Dense Text Retrieval." ICLR 2021. arXiv:2007.00808

7. Wang, L., Yang, N., Huang, X., Jiao, B., Yang, L., Jiang, D., Majumder, R., & Wei, F. (2022). "Text Embeddings by Weakly-Supervised Contrastive Pre-training." arXiv:2212.03533

8. Radovanović, M., Nanopoulos, A., & Ivanović, M. (2010). "Hubs in Space: Popular Nearest Neighbors in High-Dimensional Data." JMLR, 11, 2487-2531. JMLR

9. Feng, F., Yang, Y., Cer, D., Arivazhagan, N., & Wang, W. (2020). "Language-agnostic BERT Sentence Embedding." ACL 2022. arXiv:2007.01852

10. Sentence Transformers documentation. "Embedding Quantization." sbert.net

11. Related concepts on this site: embedding benchmarks and the zero-shot problem, hard negative mining and contrastive embedding training, hubness in high-dimensional retrieval, binary and int8 embedding quantisation, hybrid retrieval, reranking and cross-encoders, late interaction multi-vector retrieval.

Free to read, no ads, no sign-up. If it was useful you can buy me a coffee.