A relevant passage can be present in a search corpus and still be partly missing from the representation the search actually compares. That happens when the encoder cuts the passage off before the useful evidence appears, and switching retrievers does not automatically restore what was never encoded.
\nIn an August 26, 2026 tutorial, Tom Aarsen tested medical passages averaging 941 tokens. Raising document-length caps improved the tested multi-vector retrievers by 0.08–0.24 NDCG@10. That score rewards relevant results that appear near the top of the first ten hits. The result makes input coverage a serious alternative explanation for a weak retrieval score.
\nPSEEDR read the tutorial on November 1, 2026. This analysis uses the page available then, not an archived copy proving every result appeared on its original publication date. The measurements are the author's; PSEEDR did not reproduce them.
\nFor a team choosing a retriever, the sequence matters. First establish what each candidate sees. Then measure whether adapting it to the domain improves relevance. Finally, test the index configuration that can actually be served. Combining those changes into one headline comparison makes it difficult to know which investment helped.
\nThe Sentence Transformers usage documentation describes a multi-vector encoder, also called a late-interaction model, as retaining token-level vectors instead of compressing the whole input into one vector. Its MaxSim score finds each query token's strongest match among the document tokens and sums those matches. The query and document encoders also apply settings stored with the checkpoint: marker prefixes, length limits and a document-side skiplist of tokens ignored during scoring. The length limits are where truncation happens.
\nConsider an illustrative maintenance document containing several versions of a procedure. The user's question concerns a detail near the end. Token-level matching gives the retriever more local representations to compare with that question. But it cannot match the missing detail if the encoder retained only the beginning. A richer representation and a longer visible input solve different problems.
\nThis is also why inspecting only the stored document is insufficient. The source text may be complete while the encoded representation covers only part of it. A useful diagnosis examines the input that reached the encoder and the settings used when the index was built, not just the text returned when someone opens the original file.
\nEach comparison should match the question it is meant to answer. To compare architectures, give every candidate comparable access to the evidence, for example by setting length limits that let each candidate read the same passage text. To compare products as shipped, keep each candidate's default caps and report what they cut off. Both comparisons can be useful, because they answer different purchasing questions.
\nOnce input coverage is understood, training can address the relationship between a query and a relevant passage. The library's loss overview supports training on positive query–passage pairs with an in-batch negatives objective. Other passages in the batch supply competing matches, and larger batches supply more of them, which is why batch size matters for this objective. Its cached variant uses GradCache to compute embedding gradients in smaller chunks, allowing a larger effective training batch within a constrained memory budget. The current documentation explains these mechanisms; it is not a dated snapshot of every feature available in August.
\nWhich pairs the team chooses matters more than the convenience of their format. A pair teaches the model that this passage should outrank its competitors for this query. If the training questions resemble document headings but users ask indirect questions, the optimization may succeed at a narrower task than the product needs. That is a reason to preserve representative held-out queries before tuning.
\nAarsen's final evaluation used 1,000 held-out questions against 200,000 passages. The fine-tuned model scored 0.9139 NDCG@10 versus 0.8520 for the strongest zero-shot model, meaning one evaluated without fine-tuning on this task’s training pairs. His separate checkpoint experiment used 50,000 passages, so the two tables are not directly comparable. These reported results support domain adaptation on this test, not a universal model ranking.
\nA higher NDCG@10 is useful evidence about that ranking task. It does not by itself show that the application answered correctly, that the user found the result sufficient, or that a service met its response-time target.
\nThe MIRIAD dataset card describes question–answer pairs generated with language models from biomedical literature. The card limits its intended use to academic research and educational exploration. This is a retrieval experiment over that material, not evidence of clinical performance.
\nGenerated questions can be useful training data while leaving an evaluation question unresolved: do they resemble what the eventual users ask? A question built from its answer passage may share vocabulary and framing that a person without the passage would not know. An evaluator should inspect that relationship instead of treating the dataset's size as proof of realism.
\nThe competing corpus matters too. A query with one obvious match among unrelated documents is different from the same query surrounded by near-duplicate procedures or obsolete versions. Before interpreting a gain, the team needs to know which distractors were present and which answers counted as relevant. Changes to those conditions can alter the task without changing the model.
\nA practical trial can keep the same query set, relevance judgments and corpus while changing one major component at a time. Where the product searches both short and long material, break out those cases. An average improvement can hide the fact that a change helps only documents whose evidence was previously cut off.
\nAarsen reports roughly 45 GB for raw fp16 token vectors, the cost of storing one vector per token across the 200,000-passage corpus. A 1-bit PLAID configuration, a compressed index measured by Omar Khattab, used 3.37 GB at 0.8984 NDCG@10, below the uncompressed model's score. The index comparison shows a trade-off between storage and quality, not equal performance at a smaller size.
\nThat distinction should carry into the adoption test. Compare the compressed multi-vector index with the dense or lexical configuration the team would really deploy. A raw representation on one side and an optimized index on the other make an attractive chart but leave the operating choice unclear.
\nStorage is only one constraint. The candidate still needs to answer queries within the application's latency budget and support the required indexing work. A ranking result and an index-size measurement do not establish those properties. Measure them on the selected configuration before concluding that the quality gain is affordable.
\nThe first useful experiment may therefore be smaller than a fine-tuning run: inspect a set of retrieval misses and check whether their relevant evidence survived encoding. If it did not, correct that mismatch and rebuild the baseline. If it did, domain training and richer token-level matching become hypotheses worth testing. The resulting choice rests on what the system reads, what it learns and what it can serve.
\n" }