WARP: An Efficient Engine for Multi-Vector Retrieval

Christopher Potts; Gustavo Alonso; Jan Luca Scheerer; Matei Zaharia; Omar Khattab

REVIEW 3 major objections 5 minor 25 references

WARP: An Efficient Engine for Multi-Vector Retrieval

T0 review · 3 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read WARP claims a 41x speedup for XTR-style retrieval, cutting LoTTE Pooled latency from about six seconds to 171 ms on a single CPU thread while preserving retrieval quality.

desk verdict WARP's implicit-decompression trick is real and worth knowing; the 41x and 3x latency headlines are not matched comparisons, so treat them skeptically. read the letter →

arxiv 2501.17788 v3 pith:GMAKPLEX submitted 2025-01-29 cs.IR

Jan Luca Scheerer , Matei Zaharia , Christopher Potts , Gustavo Alonso , Omar Khattab This is my paper · ORCID

classification cs.IR

keywords multi-vectorretrievallateinteractionXTRColBERTresidualcompressionmissingsimilarityimputationcandidategenerationefficiency

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that multi-vector retrieval trained with the XTR objective can be made fast enough for interactive CPU search. It presents WARP, an engine that cuts end-to-end single-threaded latency on the LoTTE Pooled benchmark from just over six seconds to 171 milliseconds, a 41x reduction, while keeping retrieval quality intact. WARP also reports a 3x speedup over the ColBERTv2/PLAID engine and a 2x to 4x smaller index than a ScaNN-based XTR baseline. If these claims hold, token-level late-interaction models stop being a research luxury and become a practical option for production retrieval.

What carries the argument

The load-bearing object is the additive decomposition of a quantized residual vector's score into a precomputed query-centroid score plus a sum of bucket-weight lookups: $s_{i,j,k} = S_{c_j,q_i} + \sum_{d=1}^{128} \upsilon_{i,d}[(r_{i,j,k})_d]$, where $\upsilon_{i,d}$ is the product of query dimensions and shared quantization bucket weights. This identity lets WARP score a candidate token with a selective sum and bitwise unpacking instead of explicit decompression, giving $O(1)$ multiplications per additional cluster. Around this identity, WARPSELECT sets the missing-similarity estimate $m_i$ for each query token to the first centroid score in the sorted list whose cumulative cluster size exceeds a threshold $t'$, and the two-stage reduction merges per-token strides by max and then sums document scores with prefix sums for missing values.

What would settle it

Run WARP with WARPSELECT's imputed scores on a held-out set and compare its top-100 ranking to the ranking produced when each missing token score is replaced by the exact maximum similarity over that document's tokens: if the overlap, for instance Recall@100, drops materially on LoTTE Pooled, then the imputation heuristic, not just the engine's speed, is carrying the quality result.

Watch

Extended reading notes

Core claim

WARP is a retrieval engine that combines PLAID-style residual compression with XTR's token-level scoring, and its central claim is that this combination removes the major latency bottlenecks of both systems. The paper reports that on LoTTE Pooled, XTRbase/WARP answers queries in 171 ms single-threaded, versus 6,862 ms for the unoptimized XTR reference and 2,155 ms for an optimized ScaNN variant, while matching or slightly improving Success@5 and nDCG@10 on LoTTE and BEIR. The engine also reports a 3x latency reduction against ColBERTv2/PLAID and index sizes that are 2x to 4x smaller than the ScaNN-based XTR index. These results are attributed to three mechanisms: WARPSELECT, which imputes missing token similarities during candidate generation; implicit decompression, which scores compressed residuals without reconstructing vectors; and a two-stage max-then-sum reduction that avoids materializing the full score matrix.

Load-bearing premise

WARP's quality claims rest on the heuristic that the first centroid score whose cumulative cluster size passes a tuned threshold $t'$ accurately stands in for the token similarities XTR would have retrieved but WARP did not compute.

Editorial extensions

If this is right

XTR-based retrieval can serve queries in well under a second on a single CPU thread, making responsive late-interaction search feasible without GPU acceleration.
The 2x to 4x index compression means multi-vector indexes for hundreds of millions of tokens can fit in tens of GiB rather than hundreds, broadening deployment options.
Query encoding, not search, becomes the dominant cost at small and medium collection sizes, so further latency gains depend on faster encoders.
WARP parallelizes to 16 threads with about a 3x speedup, so operators can trade CPU allocation against latency without changing retrieval code.
The two-stage reduction keeps scoring nearly constant as candidate depth grows, which makes larger $n_{\text{probe}}$ values affordable when recall demands them.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Editorial inference: the same centroid-residual decomposition should transfer to any late-interaction retriever whose scoring is a dot product over unnormalized residuals, so WARP-style implicit decompression could be adopted by future non-XTR models.
Editorial inference: WARPSELECT's threshold $t'$ is tuned per dataset, which suggests a learnable or adaptive imputation estimator could recover additional quality, especially on small collections where cluster sizes vary widely.
Editorial inference: because WARP never reconstructs token vectors explicitly, its scoring path is a natural fit for hardware with wide lookup-table or SIMD primitives, and integrating those could extend the reported speedups.
Editorial inference: the paper's own latency breakdowns make query encoding the new bottleneck, so end-to-end gains beyond WARP will likely come from lighter query encoders or speculative query-token pruning.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: WARP has one genuinely nice idea—implicit decompression—and a credible engineering effort, but the headline numbers mix incomparable setups, so quote the 12.8x over the authors' own optimized XTR/ScaNN, not the 41x or the 3x.

The nice idea is in Section 4.4. By precomputing query-centroid scores and query-bucket-weight products, WARP turns decompression from vector reconstruction into a selective sum over residual indices. That is a clean, non-obvious rearrangement, and it explains most of the engine's speed advantage. WARPSELECT is a reasonable pragmatic heuristic for missing similarity imputation; the paper is honest that it doesn't come with a bound, and it's cheap to compute. The two-stage reduction is well-defined and implemented with prefix sums. On the engineering side, they did the right thing by profiling, rewriting the slow Python scoring in XTR's reference code, and measuring against their own optimized baseline. Even then WARP is 12.8x faster on LoTTE Pooled, with similar or better Success@5. The memory savings look real.

Now the soft spots. The 41x figure is against the unoptimized reference implementation they themselves rewrote; by their own numbers, XTR/ScaNN 'opt=True' is already 3.5-6.3x faster, so 41x is marketing. The 3x claim over ColBERTv2/PLAID is the more serious issue. Figure 1 shows PLAID at k=1000 and WARP with nprobe=32 but no final-k, while the quality evaluation reports Success@5. Different encoders (XTRbase vs ColBERTv2) and likely different result counts are both confounded. Their own Figure 2 shows PLAID latency at k=10 is 284ms versus 507ms at k=1000, so a good chunk of the advertised 3x could be the workload difference. I'd want to see a matched comparison: same k, same encoder where possible, and at least the ColBERTv2/WARP latency from Table 5. Query encoding also dominates WARP's own runtime (Figure 9), so the engine speedup is mostly in the search stages, and encoder choice matters.

Who is this for? People building or benchmarking multi-vector retrieval engines, especially XTR-style systems. It deserves a serious referee—the algebraic core is correct, the engineering is solid, and the limitations are mostly in the evaluation, not the method. My recommendation: send it out, but ask the authors to fix the latency comparison before it's cited as '3x over PLAID.'

Referee Report

3 major / 5 minor

Summary. The paper presents WARP, a CPU retrieval engine for XTR-style multi-vector models. It combines WARPSELECT dynamic imputation of missing token similarities with implicit decompression of compressed residuals and a two-stage max-then-sum reduction, implemented in dedicated C++ kernels. Experiments on LoTTE and BEIR report a 41x end-to-end latency reduction versus the XTR reference implementation, a 12.8x speedup versus the optimized XTR/ScaNN baseline on LoTTE Pooled, a 3x speedup versus ColBERTv2/PLAID, and comparable or slightly better retrieval quality, with a 2-4x smaller index than ScaNN. The core algorithmic derivations in Section 4 are algebraic rearrangements of residual scoring and appear correct.

Significance. If the speedups hold under matched conditions, WARP is a valuable systems contribution: it demonstrates that XTR's token-retrieval design can be made CPU-efficient without explicitly reconstructing full vectors, and the implicit-decompression trick is a clean and reusable idea. The paper ships code and provides detailed latency breakdowns across datasets and thread counts, which strengthens reproducibility. However, the headline performance claims currently rest on comparisons at different result counts and with different encoders, and the WARPSELECT imputation heuristic, while empirically motivated, lacks a direct ablation isolating its effect on quality.

major comments (3)

[Section 5.1 / Figure 1] The headline 3x speedup over ColBERTv2/PLAID is not a matched workload. PLAID is run with k=1000 and XTR/ScaNN with k'=40000, while WARP's final k is never stated and the quality metrics (Success@5, nDCG@10) suggest a much smaller result list. Figure 2 shows PLAID latency rising from 284ms at k=10 to 507ms at k=1000, so the advertised advantage may largely reflect result-count and encoder differences (ColBERTv2 vs XTRbase). Please report WARP latency at k=10/100/1000 with the same encoder where possible, or explicitly justify the comparison as an end-to-end system-level one with different models and result counts.
[Section 5.1 / Table 2] The 41x speedup in the abstract and conclusion is measured against the authors' own 'unoptimized' XTR reference implementation, which the paper itself rewrote; against the optimized XTR/ScaNN baseline, Table 2 reports 12.8x on LoTTE Pooled. The manuscript should lead with the optimized baseline or clearly separate the 'vs reference' and 'vs optimized' claims so that readers are not left with an inflated headline number.
[Section 4.3] WARPSELECT sets the missing-similarity estimate m_i to the first centroid score whose cumulative cluster size exceeds the threshold t', but no formal or empirical relation is established between this centroid-based value and the true missing token similarities, and the paper acknowledges that XTR's upper-bound property is lost. The quality-preservation claim therefore rests entirely on this heuristic, yet Tables 2-3 compare WARP to XTR/ScaNN with different candidate generation and imputation simultaneously, so the effect of the imputation choice is confounded. Please add an ablation that replaces WARPSELECT with XTR's lowest-retrieved-score imputation inside WARP, and report the sensitivity of Success@5/nDCG@10 to t' (not just Recall@100).

minor comments (5)

[Section 4] Equation (1) uses n and m for query and document lengths, while later sections use query_maxlen and other notation; please align the notation for readability.
[Table 2 caption] The caption contains a typo: 'nnprobe' should be 'nprobe'.
[Figures 1 and 3] The legends include a 'Filtering' stage for XTR/ScaNN, but the text describes XTR's pipeline as query encoding, token retrieval, and scoring; please clarify whether 'Filtering' corresponds to the token retrieval stage.
[Appendix A.3] The ColBERTv2/WARP generalization results are reported only on BEIR; adding LoTTE results or a sentence stating this limitation would make the generalization claim easier to assess.
[Section 5.1] The sentence 'we limit our evaluation to a comparison with the XTR/ScaNN baseline' is immediately followed by a comparison with ColBERTv2/PLAID; please rephrase to reflect the actual scope.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: WARP's algorithmic derivations are algebraic identities and its claims are empirical measurements against external baselines.

full rationale

The paper's derivation chain is self-contained. WARPSELECT (Section 4.3) defines the missing-similarity estimate m_i as a centroid-score threshold chosen from cumulative cluster sizes; this is an explicit heuristic, and the paper itself notes (footnote 8) that XTR's upper-bound argument no longer holds for WARP. The implicit-decompression identity in Eqs. (2)-(5) follows algebraically from the definition of decompression, reusing centroid-query scores rather than fitting any target. The two-stage reduction in Eqs. (6)-(8) is a formal description of max/sum aggregation with imputed missing values and is verified to be independent of the merge order. Hyperparameters nprobe, t', and b are tuned on development splits and then evaluated on held-out test sets (Tables 2-3), which is standard model selection rather than fitting a prediction. The quality and latency comparisons use external, publicly released baselines (XTR/ScaNN, ColBERTv2/PLAID); citations to the authors' prior work (PLAID, ColBERTv2) point to code-released systems and are not used to justify the novel WARP-specific mechanisms. The mismatched-k comparison with PLAID and the choice of an unoptimized XTR reference implementation are experimental-design and fairness concerns about the strength of the speedup claims, not circularity: no claimed result is equivalent to its own input by construction.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

WARP introduces no new physical or conceptual entities. The free parameters are standard system hyperparameters tuned on development data. The main ad hoc element is WARPSELECT's t' threshold, which is a heuristic choice rather than a derived quantity.

free parameters (3)

nprobe = 32
Number of centroids selected per query token during candidate generation; chosen on dev sets based on normalized Recall@100 curves in Figure 6.
t' (imputation threshold) = proportional to sqrt(dataset size), capped by t'_max
WARPSELECT's missing-similarity threshold; set empirically per dataset. The paper states t' proportional to the square root of collection size works well, with a maximum bound, but no closed-form value is given.
b (residual bits per dimension) = 4
Quantization bits for residual vectors; the paper compares b=2 and b=4 and uses b=4 for main results.

assumptions (5)

domain assumption The XTR scoring objective in Equation 1, including the missing-similarity imputation term, is the correct relevance model for the fine-tuned XTR base model.
The paper adopts Equation 1 from the XTR paper without re-derivation; all quality claims depend on this scoring being appropriate for the model.
ad hoc to paper WARPSELECT's m_i, defined as the first centroid score whose cumulative cluster size exceeds t', is a sufficient approximation of missing token similarities.
Section 4.3 introduces this heuristic without theoretical guarantee; the claim that retrieval quality is preserved depends on it.
domain assumption Skipping PLAID's post-decompression L2 normalization has negligible effect on retrieval quality.
Section 4.5, footnote 10, asserts that residuals are already normalized prior to quantization; the paper gives empirical support but no formal guarantee.
domain assumption The nprobe selected centroids capture all document tokens needed for accurate top-k scoring.
Candidate generation prunes all documents that do not appear in the selected clusters; recall curves on dev sets justify nprobe=32, but this is a heuristic with no worst-case guarantee.
domain assumption k-means clustering on a sqrt-sized sample of passages produces centroids adequate for residual compression.
Section 4.1 states this follows ColBERTv2 practice; no new analysis is provided.

how reviews work

0 comments

Cite this review

Pith. "Pith review of WARP: An Efficient Engine for Multi-Vector Retrieval." pith.science (2026). https://pith.science/paper/GMAKPLEX

@misc{pith2026250117788,
  author       = {Pith},
  title        = {Pith review of: WARP: An Efficient Engine for Multi-Vector Retrieval},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GMAKPLEX}},
  note         = {Machine review of arXiv:2501.17788}
}

abstract

Multi-vector retrieval methods such as ColBERT and its recent variant, the ConteXtualized Token Retriever (XTR), offer high accuracy but face efficiency challenges at scale. To address this, we present WARP, a retrieval engine that substantially improves the efficiency of retrievers trained with the XTR objective through three key innovations: (1) WARP$_\text{SELECT}$ for dynamic similarity imputation; (2) implicit decompression, avoiding costly vector reconstruction during retrieval; and (3) a two-stage reduction process for efficient score aggregation. Combined with highly-optimized C++ kernels, our system reduces end-to-end latency compared to XTR's reference implementation by 41x, and achieves a 3x speedup over the ColBERTv2/PLAID engine, while preserving retrieval quality.

Figures

Figures reproduced from arXiv: 2501.17788 by the authors.

**Figure 2.** Breakdown of ColBERTv2/PLAID’s avg. latency for [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

**Figure 3.** Breakdown of XTRbase/ScaNN on LoTTE Pooled. As seen in Figure 3a, the scoring stage constitutes a significant bottleneck in the end-to-end latency of the XTR framework, particularly when dealing with large values of 𝑘 ′ . We argue that this performance bottleneck is largely attributed to an unoptimized implementation in the released code, which relies on native Python data structures and manual iteration, introduc… view at source ↗

Figures from the paper (6 more)

**Figure 4.** Figure 4: WARP Retrieval consisting of query encoding, [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]

**Figure 6.** Figure 6: nRecall@100 as a function of 𝑡 ′ and 𝑛probe 0 20000 40000 60000 80000 100000 t 0 0.70 0.75 0.80 0.85 0.90 0.95 1.00 Normalized Recall@10 nprobe = 32, b = 2 nprobe = 32, b = 4 (a) LoTTE Pooled (Dev Set), nRecall@10 0 20000 40000 60000 80000 100000 t 0 0.70 0.75 0.80 0.8…

**Figure 5.** Figure 5: WARP’s scoring phase: (a) In token-level reduction, [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

**Figure 8.** Figure 8: WARP’s scaling behavior with respect to dataset [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]

**Figure 9.** Figure 9: Breakdown of XTRbase/WARP’s avg. single-threaded latency for 𝑛probe = 32 on the BEIR NFCorpus, LoTTE Lifestyle, and LoTTE Pooled datasets. 0 25 50 75 100 125 150 175 200 Latency (ms) XTRbase/WARP LoTTE Pooled (Test) XTRbase/WARP LoTTE Lifestyle (Test) XTRbase/WARP BEIR…

**Figure 10.** Figure 10: Breakdown of XTRbase/WARP’s avg. latency for 𝑛probe = 32 and 𝑛threads = 16 on the BEIR NFCorpus, LoTTE Lifestyle, and LoTTE Pooled datasets A Additional Results A.1 Latency Breakdowns In the following, we provide a more detailed breakdown of WARP’s performance on thre…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 7 canonical work pages

[1]

Thibault Formal, Stéphane Clinchant, Hervé Déjean, and Carlos Lassance. 2024. Splate: sparse late interaction retrieval. (2024). arXiv: 2404.13950 [cs.IR]

work page Pith review arXiv 2024
[2]

Luyu Gao, Zhuyun Dai, and Jamie Callan. 2021. Coil: revisit exact lexical match in information retrieval with contextualized inverted list. (2021). https://arxiv .org/abs/2104.07186 arXiv: 2104.07186 [cs.IR]

arXiv 2021
[3]

Stanford Future Data Systems Research Group. 2024. colbert-ir/colbertv2.0. https://huggingface.co/colbert-ir/colbertv2.0. (2024)

work page 2024
[4]

Stanford Future Data Systems Research Group. 2024. ColBERTv2/PLAID (Code). https://github.com/stanford-futuredata/ColBERT. (2024)

work page 2024
[5]

Ruiqi Guo, Philip Sun, Erik Lindgren, Quan Geng, David Simcha, Felix Chern, and Sanjiv Kumar. 2020. Accelerating large-scale inference with anisotropic vector quantization. (2020). https://arxiv.org/abs/1908.10396 arXiv: 1908.10396 [cs.LG]

arXiv 2020
[6]

Herve Jégou, Matthijs Douze, and Cordelia Schmid. 2011. Product quantization for nearest neighbor search. IEEE Transactions on Pattern Analysis and Machine Intelligence, 33, 1, 117–128. doi: 10.1109/TPAMI.2010.57

doi:10.1109/tpami.2010.57 2011
[7]

Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen-tau Yih. 2020. Dense passage retrieval for open- domain question answering. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP) . Bonnie Webber, Trevor Cohn, Yulan He, and Yang Liu, (Eds.) Association for C...

doi:10.18653/v1/2020.emnlp-main.550 2020
[8]

Omar Khattab and Matei Zaharia. 2020. Colbert: efficient and effective passage search via contextualized late interaction over BERT. CoRR, abs/2004.12832. https://arxiv.org/abs/2004.12832 arXiv: 2004.12832

arXiv 2020

Show all 25 references

[9]

Ron Kohavi, Alex Deng, Brian Frasca, Toby Walker, Ya Xu, and Nils Pohlmann
[10]

Jinhyuk Lee, Zhuyun Dai, Sai Meher Karthik Duddu, Tao Lei, Iftekhar Naim, Ming-Wei Chang, and Vincent Y. Zhao. 2024. google/xtr-base-en. https://huggi ngface.co/google/xtr-base-en. (2024)

2024
[11]

Jinhyuk Lee, Zhuyun Dai, Sai Meher Karthik Duddu, Tao Lei, Iftekhar Naim, Ming-Wei Chang, and Vincent Y. Zhao. 2024. Rethinking the role of token retrieval in multi-vector retrieval. (2024). arXiv: 2304.01982 [cs.CL]

2024 arXiv
[12]

Jinhyuk Lee, Zhuyun Dai, Sai Meher Karthik Duddu, Tao Lei, Iftekhar Naim, Ming-Wei Chang, and Vincent Y. Zhao. 2024. XTR: Rethinking the Role of Token Retrieval in Multi-Vector Retrieval (Code). https://github.com/google-d eepmind/xtr. (2024)

2024
[13]

Minghan Li, Sheng-Chieh Lin, Barlas Oguz, Asish Ghoshal, Jimmy Lin, Yashar Mehdad, Wen-tau Yih, and Xilun Chen. 2022. Citadel: conditional token in- teraction via dynamic lexical routing for efficient and effective multi-vector retrieval. (2022). https://arxiv.org/abs/2211.104...

2022 arXiv
[14]

Sean MacAvaney and Nicola Tonellotto. 2024. A reproducibility study of plaid. arXiv preprint arXiv:2404.14989

2024 arXiv
[15]

Franco Maria Nardini, Cosimo Rulli, and Rossano Venturini. 2024. Efficient multi-vector dense retrieval using bit vectors. (2024). arXiv: 2404.02805[cs.IR]

2024 arXiv
[16]

Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J. Liu. 2023. Exploring the limits of transfer learning with a unified text-to-text transformer. (2023). https://arxi v.org/abs/1910.10683 arXiv: 1910.10683 [cs.LG]

2023 arXiv
[17]

Stephen Robertson and Hugo Zaragoza. 2009. The probabilistic relevance frame- work: bm25 and beyond. Foundations and Trends® in Information Retrieval, 3, 4, 333–389. doi: 10.1561/1500000019

2009 doi
[18]

Keshav Santhanam, Omar Khattab, Christopher Potts, and Matei Zaharia. 2022. Plaid: an efficient engine for late interaction retrieval. (2022). arXiv: 2205.09707 [cs.IR]

2022 arXiv
[19]

Keshav Santhanam, Omar Khattab, Jon Saad-Falcon, Christopher Potts, and Matei Zaharia. 2021. Colbertv2: effective and efficient retrieval via lightweight late interaction. CoRR, abs/2112.01488. https://arxiv.org/abs/2112.01488 arXiv: 2112.01488

2021 arXiv
[20]

Nandan Thakur, Nils Reimers, Andreas Rücklé, Abhishek Srivastava, and Iryna Gurevych. 2021. Beir: a heterogenous benchmark for zero-shot evaluation of information retrieval models. (2021). https://arxiv.org/abs/2104.08663 arXiv: 2104.08663 [cs.IR]

2021 arXiv
[21]

Lee Xiong, Chenyan Xiong, Ye Li, Kwok-Fung Tang, Jialin Liu, Paul Bennett, Junaid Ahmed, and Arnold Overwijk. 2020. Approximate nearest neighbor negative contrastive learning for dense text retrieval. (2020). https://arxiv.org /abs/2007.00808 arXiv: 2007.00808 [cs.IR]

2020 arXiv
[22]

Jingtao Zhan, Jiaxin Mao, Yiqun Liu, Jiafeng Guo, Min Zhang, and Shaoping Ma
[1176]

doi: 10.1145/2487575.2488217

isbn: 9781450321747. doi: 10.1145/2487575.2488217
[2013]

In Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD ’13)

Online controlled experiments at large scale. In Proceedings of the 19th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD ’13). Association for Computing Machinery, Chicago, Illinois, USA, 1168–
[2021]

Optimizing dense retrieval model training with hard negatives. (2021). https://arxiv.org/abs/2104.08051 arXiv: 2104.08051 [cs.IR]. WARP: An Efficient Engine for Multi-Vector Retrieval SIGIR ’25, July 13–18, 2025, Padua, Italy 0 25 50 75 100 125 150 175 200 Latency (ms) XTRbase...

2021 arXiv

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

Thibault Formal, Stéphane Clinchant, Hervé Déjean, and Carlos Lassance. 2024. Splate: sparse late interaction retrieval. (2024). arXiv: 2404.13950 [cs.IR]

work page Pith review arXiv 2024

[2] [2]

Luyu Gao, Zhuyun Dai, and Jamie Callan. 2021. Coil: revisit exact lexical match in information retrieval with contextualized inverted list. (2021). https://arxiv .org/abs/2104.07186 arXiv: 2104.07186 [cs.IR]

arXiv 2021

[3] [3]

Stanford Future Data Systems Research Group. 2024. colbert-ir/colbertv2.0. https://huggingface.co/colbert-ir/colbertv2.0. (2024)

work page 2024

[4] [4]

Stanford Future Data Systems Research Group. 2024. ColBERTv2/PLAID (Code). https://github.com/stanford-futuredata/ColBERT. (2024)

work page 2024

[5] [5]

Ruiqi Guo, Philip Sun, Erik Lindgren, Quan Geng, David Simcha, Felix Chern, and Sanjiv Kumar. 2020. Accelerating large-scale inference with anisotropic vector quantization. (2020). https://arxiv.org/abs/1908.10396 arXiv: 1908.10396 [cs.LG]

arXiv 2020

[6] [6]

Herve Jégou, Matthijs Douze, and Cordelia Schmid. 2011. Product quantization for nearest neighbor search. IEEE Transactions on Pattern Analysis and Machine Intelligence, 33, 1, 117–128. doi: 10.1109/TPAMI.2010.57

doi:10.1109/tpami.2010.57 2011

[7] [7]

Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen-tau Yih. 2020. Dense passage retrieval for open- domain question answering. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP) . Bonnie Webber, Trevor Cohn, Yulan He, and Yang Liu, (Eds.) Association for C...

doi:10.18653/v1/2020.emnlp-main.550 2020

[8] [8]

Omar Khattab and Matei Zaharia. 2020. Colbert: efficient and effective passage search via contextualized late interaction over BERT. CoRR, abs/2004.12832. https://arxiv.org/abs/2004.12832 arXiv: 2004.12832

arXiv 2020