In my experience, retrieval architecture - not the model - decides whether an enterprise AI assistant gets trusted or abandoned. Almost every failed system I’m called in to fix retrieved the wrong context, presented it confidently, and went unnoticed until a user caught it. The model is rarely the problem.
This guide is for CTOs, AI leads, and engineering heads who are past the proof of concept and need to know what a production system actually demands.
The encouraging part is that retrieval quality responds quickly once you target the right levers. The result I quote most often to clients is Anthropic’s work on contextual retrieval: adding a short piece of context to each chunk before indexing cut retrieval failures by 35%, combining that with keyword search took the reduction to 49%, and adding a reranking step reached 67%. Not one of those gains required a different model.
I’ve never seen a single reference architecture that works out of the box for every enterprise RAG implementation. Vendors like to sell single best-practice templates, but the right choice always depends on the exact shape of your data, the shape of the questions your users actually ask, how much a wrong answer costs your business, and how fresh the answer has to be.
Before choosing an architecture, five principles dictate every build I run:
- the default “chunk, embed, take the top five” pipeline handles a much narrower band of questions than its popularity suggests, and I see it oversold constantly
- lexical search and metadata are load-bearing components, not legacy ones to be replaced by embeddings; I have never taken them out of a working system
- if I can add only one thing to a baseline, I add a reranker
- when a question asks for a number, I send it to SQL, never to a vector index
- and none of the above is actionable without a labelled evaluation set, which is the first thing teams skip
What is a RAG architecture in enterprise AI?
When I say RAG architecture, I mean the set of decisions that determine how your information is prepared, stored, searched and assembled into context before a language model generates anything.
I think of it as three layers: how documents are split and enriched before indexing, which search method finds candidate material, and how the user’s question is transformed before the search runs.
The default pipeline - split documents into fixed-size chunks, embed them, run a nearest-neighbour search, paste the top hits into a prompt - is a reasonable prototype, and I have built plenty of them. I also know exactly how it fails: it can’t find documents by identifier, answer questions requiring a whole document, has no concept of which version is current, and always returns results whether or not any are relevant.
Key takeaway: in practice I almost never pick one of these. Most systems I build run two or three behind a router that selects by question type.
Start with the questions, not the documents
The most common sequencing mistake I see is choosing a RAG architecture before anyone has looked at what users will ask.
The highest-value exercise I run at the start of a project is also the least technical one: I collect 100-300 real questions, from support tickets, search logs, email threads, or a workshop with the people who currently answer them manually, and classify them.
The distribution matters far more than the list. If most of your traffic is single-passage lookup, building a knowledge graph is an expensive way to make a search box slower - I have watched that happen, and it is hard to unwind once it exists.
The pattern this exercise exposes recurs so reliably across domains that I now warn clients about it in advance.
A project gets scoped around the hardest-sounding capability - interpreting policy wording, reasoning over contract language, summarising technical documentation - because that’s the capability the stakeholders find most impressive.
Classification then shows that the interpretive questions are a minority of real traffic, and that the majority splits into two much cheaper categories: identifier lookups, where someone already knows the claim or part or case number and wants everything attached to it, and counts and totals, which a reporting system probably already answers.
When I find that distribution, I change the shape of the build. Identifier traffic goes to a keyword index with metadata filters and needs no language model in the retrieval path at all. Aggregation traffic goes to parameterised SQL. Only the remainder justifies the semantic retrieval work the project was originally sized for.
Two days of classification routinely redirects considerably more than two days of engineering and, more importantly, redirects it before I have committed to an architecture.
Data preparation: Chunking, metadata, and summaries
Retrieval quality is capped by the quality of what you indexed. In my experience, preparation decisions about parsing, chunking, and metadata (the core focus of data engineering services) have a larger effect on final accuracy than the choice of embedding model, and they are far cheaper to change afterwards.
Chunking
"What chunk size should I use?" is the wrong question. Ask instead whether a chunk makes sense on its own. A fragment stating "this represents a 12% increase over the previous period" is worthless in isolation, yet standard vector search will retrieve it and force the model to guess the missing context.
What I do, roughly in order of value:
- Respect the document’s own structure. I split on headings, clauses, sections and table boundaries. Enterprise documents already carry structure that someone was paid to create, and I would rather use it than fight it.
- Decouple the retrieval unit from the generation unit. I retrieve on something small and precise, then hand the model something larger. In the ARAGOG benchmark of advanced RAG techniques, sentence-window retrieval outperformed a classic flat vector database on retrieval precision, which matches what I see in practice.
- Add context to each chunk before embedding it. This is the Anthropic result I cited above, and one of the few techniques I can point at with a clean published number attached. The cost is one model call per chunk at ingestion, though with prompt caching the parent document is cached across the indexing pass, and Anthropic reports the cost at roughly one US dollar per million document tokens.
I treat that as worthwhile on most high-value corpora; for very large, low-traffic archives I run the calculation rather than assume it either way.
- Test overlap rather than assuming it. The 10–20% overlap convention gets repeated everywhere, and the published evidence is genuinely split. A systematic analysis of chunking strategies (Bennani & Moslonka, ECIR 2026) found that overlap provided no measurable benefit and only increased indexing cost. An empirical evaluation on financial documents found close to the opposite: 25% overlap lifted mean reciprocal rank from 0.53 to 0.66 on one benchmark, with zero overlap performing worst of the settings tested.
Both studies used the same retriever family, so I don’t read the disagreement as an artefact of retrieval method - it tracks document type, with the null result on open-domain web text and the positive result on dense financial filings. My conclusion is that overlap is corpus-dependent, so I measure it rather than inherit it.
One point deserves more emphasis than it usually gets, and it’s the first thing I check: parsing quality outranks all of this. If your extractor is shredding two-column layouts, merging table cells and dropping headers, no chunking strategy will compensate.
The financial-documents study above put numbers on it: holding everything else constant, swapping the PDF parser alone moved retrieval MRR between 0.588 and 0.646 on the same content, as large a difference as the choice of chunking strategy produced. When a retrieval system underperforms, my first diagnostic step is always a human reading twenty parsed documents.
Metadata and access control enforcement
I treat metadata as the control plane of enterprise retrieval. It determines how permissions are enforced, how queries are scoped to the right jurisdiction or product line, how the current version of a procedure is distinguished from the one it replaced, and whether anyone can verify a citation.
Two recommendations here:
First, I enforce access control inside the retrieval query, never after it. Filtering results in application code means the system has already retrieved forbidden content, and a single bug or prompt injection puts it in front of the model. I put the filter in the index as a pre-filter, with a policy engine handling the genuinely complex cases.
Second, permissions in source systems are always worse than anyone believes. I have yet to find an exception. A retrieval system makes buried documents findable, which converts years of quiet permission debt into an immediate incident. I treat auditing source-repository access as part of the project, not as a prerequisite somebody else owns.
I can describe the failure mode in advance because I have watched it play out more than once. A departmental shared drive is signed off as low sensitivity and indexed. A compensation spreadsheet, disciplinary record, or draft reorganisation plan might be buried in an old subfolder with inherited permissions that no one has checked in years. It was never a secret.. People simply couldn’t find it unless they already knew where to look.
Semantic search removes that accidental protection completely, and for every user at once on the day the pilot opens. My remedy is procedural rather than technical: audit access across the source repositories before ingestion, and give the pipeline an explicit allowlist of locations it’s permitted to touch rather than a denylist of ones it’s not.
The sequence I keep being called in to fix - index, discover, pause, audit - costs considerably more than running the audit first, and it spends credibility the project usually cannot afford to lose that early.
Hierarchical retrieval and RAPTOR in advanced RAG architecture
Stanford’s RAPTOR paper (Recursive Abstractive Processing for Tree-Organized Retrieval) addresses a limitation I run into regularly. Flat chunk retrieval can only return fragments, so it can’t answer questions whose answer is not written down in any single fragment.
RAPTOR recursively clusters chunks, summarises each cluster, then clusters and summarises those summaries, producing a tree you can query at any level of abstraction. The original paper reported a gain of around 20 absolute points on QuALITY, a reading-comprehension benchmark built around multi-step questions.
The hidden costs of tree retrieval:
Tree retrieval works, but the trade-offs are very real:
- Every level of the tree is model-generated, making ingestion expensive and recurring.
- Summaries built from documents that have since changed become wrong, and a stale summary looks far more authoritative than a stale chunk.
- You are retrieving text the model wrote rather than text the organization approved, which, in the regulated environments, is a governance conversation rather than a technical one.
Cheaper alternatives to try first:
I try the simpler members of the same family first: a document summary index used for routing, or parent–child retrieval where a matched chunk pulls in its parent section. In the ARAGOG comparison, a document summary index performed competitively with the classic vector setup at a fraction of the build cost. I bring in RAPTOR when query classification shows a meaningful share of questions genuinely require cross-document abstraction, not before.
Key takeaway: preparation is where you win or lose accuracy. Complexity added at the retrieval layer rarely compensates for weak parsing, thin metadata, or chunks that can’t stand alone.
Comparing retrieval methods for your RAG architecture
Vector search
Strong on paraphrase, vocabulary mismatch, conceptual questions and multilingual corpora - this is what lets “when do I get my money back” find a section titled “refund eligibility”.
Weak on exact identifiers, negation, rare proper nouns and numbers. The property that catches teams out most often, in my experience, is that it has no native notion of “no result”: a ranked list always has a top entry, and while you can threshold similarity scores, those scores are poorly calibrated and rarely transfer between corpora, so a threshold I tune on one collection tends not to hold on the next.
My advice on embedding leaderboards: ignore them. I see teams spend weeks chasing the #1 model on MTEB, only to find it performs worse on their proprietary contract filings than the model sitting at #15.
The gap between hosted and open-weight models has narrowed enough that self-hosting is now viable if you have GPU capacity or data-residency constraints, but leaderboard position tells you very little about your corpus, and changing the embedding model means re-indexing everything. Test two or three candidates on your own labelled data before you commit.
Newer developments worth raising early:
- Late-interaction retrieval (ColBERT family): Keeps a vector per token rather than compressing a chunk into one, and matches query terms individually. The financial-documents study found exactly the split this predicts: a single-vector dense model led on narrative questions, while late interaction led clearly on table-focused ones, where the task is matching specific tokens to specific cells.
- Visual patch retrieval (ColPali family): Extends the idea to page images, embedding each page as a grid of visual patches and retrieving it without text extraction at all - to my mind the most interesting answer currently available to the parsing bottleneck for scanned and layout-heavy documents.
Both carry costs: hundreds of vectors per page rather than a handful per chunk, heavier serving, and a narrowing advantage over well-tuned single-vector multimodal embeddings. I treat them as targeted tools for corpora where tables, figures and layout carry the answers, and I validate them on a labelled set like any other retriever rather than adopting them as defaults.
Keyword search
BM25 is decades old, costs almost nothing, and is still the best tool I have for a large class of enterprise queries. It finds the exact policy number, the error code, the clause reference. It’s also explainable - I can show a user why a document matched, which matters more in regulated industries than most technical write-ups acknowledge.
Technical documentation is where I find this easiest to demonstrate. Where users search by equipment code, part number or model identifier, pure vector search degrades in a specific and dangerous way: two manuals for different models in the same product family are nearly identical in language and differ mainly in an alphanumeric code, which the embedding treats as close to noise.
The retrieved document is topically perfect and factually about the wrong machine. Nothing in the output signals the error, which makes it the worst failure mode I know of. Adding a lexical index and boosting exact code matches is typically an afternoon of work, and it fixes precisely what further embedding and reranking effort will not touch.
So I don’t treat keyword search as the legacy option you replace, rather as a component I keep.
Hybrid search and reranking
Running dense and sparse retrieval together and fusing the results is my default starting architecture for almost any enterprise corpus, because the failure modes of the two methods are close to complementary.
One thing worth knowing before you choose the sparse half: BM25 is not your only option. Learned sparse retrievers such as SPLADE produce a sparse, term-based representation like BM25 but expand each document with related terms the model predicts, which recovers much of the synonym handling that pure lexical matching lacks while keeping the interpretability and exact-match behavior.
In the financial-documents study I cited earlier, SPLADE placed second on both the narrative and the table-focused benchmark and was the strongest all-rounder across the two - a property I value when a corpus contains both and a single index is preferable to three. The trade-off is heavier indexing than BM25 and thinner support in managed search products.
If you can add only one component after that, make it a reranker. It is the highest-return single addition I know: retrieve a wide candidate set of 100–150 results, score each against the query with a cross-encoder, and keep the best 10–20. Vector similarity is a decent filter and a poor ranker, and reranking addresses exactly that gap.
Two caveats I always attach.
Reranking adds latency and per-query cost, competing directly with your response-time budget.
Not every reranker helps on every corpus. ARAGOG found that one widely used commercial reranker showed no significant improvement over baseline on their dataset, while model-based reranking did. I treat it as a hypothesis to test, not a component to install.
GraphRAG and knowledge graph retrieval
Graph retrieval extracts entities and relationships, builds a knowledge graph, and answers by traversing it. Community detection and hierarchical community summaries let it answer corpus-level questions such as “what are the dominant themes across these five thousand reports?” - something no top-k chunk retriever can do, because that answer is not written in any chunk.
Where it fits (and where it fails):
I reach for it when the answer is a relationship (ownership structures, supply-chain exposure, approval chains), when questions require multiple hops across documents, or when the requirement is sensemaking over a bounded and reasonably stable corpus. I avoid it for straightforward fact lookup and for fast-changing corpora.
The GraphRAG-Bench study was motivated precisely by the observation that graph retrieval frequently underperforms conventional RAG on real-world tasks, and found the benefit concentrated in multi-hop reasoning and aggregation rather than plain retrieval, at higher indexing time and query latency.
The cost picture has improved substantially since I first started turning these projects down on budget grounds. Microsoft Research’s LazyGraphRAG, which defers summarisation to query time, reports indexing costs identical to plain vector RAG and 0.1% of full GraphRAG’s, with global-query costs over 700 times lower.
What has not changed is the prerequisite: graph retrieval only pays off if entity extraction is accurate, and entity resolution is where I watch these projects actually spend their time.
The entity resolution problem
Take a supplier-risk question that is trivial to state and hard to answer: which contracts expose you to a given supplier, directly or through subcontracting. The difficulty I hit every time is that across a real contract set, one supplier appears under a trading name, a full legal name with a corporate suffix, an abbreviation used inconsistently between business units, and a former name predating an acquisition.
Extract that naively and one supplier becomes five unconnected nodes. Every multi-hop query then returns a fraction of the true exposure, confidently, with nothing to indicate anything is missing.
If “ACME Corp”, “ACME Corporation” and “ACME Limited” become three nodes, the graph encodes a fiction. The consolation I offer clients is that the resolution work has value independent of the graph: a canonical entity list is an asset in its own right, and you need it whether or not graph retrieval turns out to be the answer.
SQL and structured queries
If the answer is a number, I don’t retrieve it from text. This sounds obvious and gets ignored constantly, because natural-language querying demonstrates so well.
The demonstration vs. production gap
The gap between demos and production becomes obvious when looking at the Spider benchmarks. On Spider 1.0, the older academic benchmark, the same class of system reached 91.2% execution accuracy. On Spider 2.0 - enterprise-realistic schemas, often over a thousand columns, multiple SQL dialects, multi-step workflows - a code agent built on a frontier reasoning model initially solved roughly 20% of tasks.
What has happened since is the more useful lesson. The Spider 2.0 leaderboard now shows entries above 90% on the Snowflake track, but those are purpose-built systems; generic agent-plus-frontier-model submissions still sit far lower.
I would treat the exact figures as directional rather than precise: the top entries are unpublished commercial systems, the maintainers revise the evaluation suite over time, and a CIDR 2026 analysis audited the 121 Spider 2.0-Snow problems with publicly available gold SQL and found an annotation error rate of 66.1%.
Why pipeline architecture beats model choice
What this actually tells us is that the engineering around the model closes the gap, not the model itself. That means building four things every time: a semantic layer of curated views and certified metric definitions so the model never sees the raw warehouse, schema linking as an explicit step, validation with execution feedback and retries, and a library of verified queries covering the questions that repeat.
Long-context and agentic retrieval
Two claims dominate the conversations I am having at the moment, and I think both deserve a calmer reading than they usually get.
Claim 1: “Long context makes retrieval obsolete.”
Chroma’s context-rot research tested 18 frontier models and found all of them becoming less reliable as input length grew, even on trivially simple tasks, and degradation was worse when the correct information was semantically similar to surrounding distractors, which is exactly the situation in the homogeneous enterprise corpora I work with.
I read an advertised context window as a capacity limit, not a working range. The pattern I use is retrieval to narrow the field, then a large window to reason over what survives. One caveat, from Anthropic’s own guidance: below roughly 200,000 tokens of total knowledge, skip retrieval entirely and put everything in the prompt.
Claim 2: “Agents with filesystem tools replace vector search.”
Partly, under conditions I would want to check first. LlamaIndex ran the comparison directly: across a handful of documents, an agent with grep-style tools beat a hybrid RAG pipeline on correctness and relevance because it could read whole files rather than fragments, but it was slower.
Scaled to 100 and then 1,000 documents, the RAG pipeline won on speed and edged ahead on correctness, though it was a small experiment, five questions per setting, so I read it as directional rather than definitive.
In a follow-up piece the same team set out the limits plainly: lexical agentic search can’t read a PDF, a scan or a slide deck, and at a million documents incidental matches fill the agent’s context before it can reason.
The trade-offs of agentic search
My read is this. Agentic retrieval is genuinely better for small, text-native, fast-changing corpora, for background work where latency is not a constraint, and for multi-hop investigation where you cannot know the right query in advance. I stay with indexed retrieval for scale, interactive latency budgets, unstructured formats, and anywhere the retrieval path has to be reproducible and auditable.
Query transformation techniques and when to use them
Query transformation attracts more unnecessary complexity than any other layer I work on. Techniques get stacked because a reference architecture diagram included them, and each one adds a model call, latency, cost and a new failure mode.
The rule to apply: Don’t add a transformation until you can name the retrieval failure it fixes and state the latency you’re willing to pay for it.
Conversational vs. general rewriting
Conversational rewriting - resolving “and what about the second one?” into a standalone query - is the one form I apply almost by default. Without it, the third turn of any conversation retrieves nonsense.
General rewriting has weaker evidence than its popularity suggests. A study across three retrieval benchmarks (Adobe, March 2026) found prompt-only rewriting degraded ranking quality by 9% on a financial QA corpus, improved it by about 5% on a COVID corpus (a gain the author notes was statistically marginal after correction) and had no measurable effect on a scientific-claims corpus.
Attempts to apply it selectively did not reliably beat never rewriting at all. This is a single-author preprint rather than peer-reviewed work, so I take it as a caution rather than a settled finding; my conclusion is simply that rewriting should not go out globally on the assumption of free upside.
HyDE vs. hypothetical questions
HyDE generates a hypothetical answer and searches with that embedding instead of the query’s, because comparing document-shaped text to real documents beats comparing a question to them, even when the hypothetical is factually wrong. I get the most out of it where user vocabulary sits far from corpus vocabulary, and ARAGOG found it among the strongest single improvements to retrieval precision it tested.
In fact-bound domains, where the user already knows the correct terminology and the answer hinges on a specific figure or clause, a hallucinated hypothetical drags the search into a plausible but wrong neighbourhood.
It also costs a full generation before retrieval can even start, which rules it out of the tight latency budgets I usually work within. A strong hybrid setup plus a reranker often delivers the same recall gain without the extra hop, so I try that first and reach for HyDE only if that language mismatch remains the primary bottleneck.
Hypothetical questions invert HyDE: at ingestion, generate the questions each chunk can answer and index those, so query time compares a real question against hypothetical questions with no additional model call. I prefer this trade for high-traffic, latency-sensitive systems with stable content, because the cost moves to ingestion where it can be batched. The trade-offs I watch for are index bloat, sensitivity to generated-question quality, and regeneration whenever documents change.
Step-back prompting asks a broader question alongside the specific one, moving from “can this customer cancel in month 14?” to “what governs cancellation rights?” I find it helps when a narrow question skips the governing concept, which is common in the policy and regulatory corpora I see, and adds little when the corpus is well structured and users already speak its language.
Decomposition splits genuinely multi-part questions into sub-questions. I consider it necessary for real multi-hop queries and wasteful otherwise - ARAGOG found naive multi-query expansion actually reduced retrieval precision relative to the plain baseline.
Apply transformations conditionally, based on query classification, rather than uniformly. A cheap classifier in front of the pipeline is usually a better investment than a more elaborate pipeline applied to everything.
Common failure modes in enterprise implementations
Of all these blockers, two do the most invisible damage.
Measuring only generation quality is the most insidious, and the one I find most often on arrival: the system scores well on faithfulness - the answer is grounded in whatever was retrieved - while retrieval recall quietly collapses underneath it, because the model writes coherently even from partial context. I instrument the two stages separately, always.
The inability to say “I don’t know” is the fastest route to lost trust I have seen. I put unanswerable questions in the evaluation set and measure the abstention rate explicitly, because one confident fabrication costs more trust than ten correct answers earn.
Build in-house or work with a partner
Building internally gives you full control and lasting capability. Model expertise is rarely the bottleneck. The real friction comes from the surrounding engineering, like parsing documents at scale, mapping permissions across legacy systems, setting up evaluation infrastructure, and the discipline to measure retrieval separately from generation.
The arrangement I have seen work best is hybrid. Your internal team owns the domain knowledge, the evaluation criteria and the operational workflow, while an external team supports architecture, pipeline engineering and scaling until the system becomes part of normal operations.
I would suggest partnering when you need a pilot in under three months, when document formats are heterogeneous and parsing is non-trivial, when access control spans several legacy systems, or when nobody internally has the capacity to maintain and monitor the system long term.
Retrieval architecture is not only about the model
The interesting architectural decisions matter far less than they appear to, and the unglamorous ones matter considerably more. Parsing, metadata, permissions, and evaluation determine whether anyone can rely on the answers at all; the choice between vector, graph, and hierarchical retrieval mostly determines which specific questions the system can address.
What produces results is disciplined sequencing: classify the questions, prepare the information properly, start with a hybrid baseline, and add complexity only where measurement justifies it. The organisations I have watched follow that path end up with systems their teams actually use, and with the evaluation infrastructure needed to keep improving them.
Next step: start with the right pilot
If you are considering an enterprise retrieval system, the fastest path I know is a focused pilot on one question category, with a labelled evaluation set, clear retrieval metrics, and operational ownership from day one.
Let’s talk about what a realistic roadmap could look like for your data and your users.
Sources
Every figure I have quoted above traces to one of the sources below.
Information preparation
- Bennani & Moslonka, A Systematic Analysis of Chunking Strategies for Reliable Question Answering (arXiv:2601.14123, January 2026; ECIR 2026) — overlap finding and the “context cliff”. Note: three-page short paper, single dataset (Natural Questions), SPLADE retrieval with a Ministral-8B generator.
- El Bachyr et al., Empirical Evaluation of PDF Parsing and Chunking for Financial Question Answering with RAG (ICSE-SEIP 2026, with BGL BNP Paribas) — the contrary result on overlap (25% best on both FinanceBench and TableQuest, MRR 0.529 to 0.658), the parser-effect figures (MRR 0.588–0.646 across six parsers on identical content), and the BM25 / SPLADE / E5 / ColBERT retriever comparison.
Retrieval methods
- Xiang et al., When to use Graphs in RAG (ICLR 2026) / GraphRAG-Bench.
- Microsoft Research, LazyGraphRAG: Setting a new standard for quality and cost — indexing at 0.1% of full GraphRAG, ~700x lower global-query cost.
- Lei et al., Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (ICLR 2025) and the live Spider 2.0 leaderboard. Original Spider 1.0 for the contrast.
- Jin, Choi, Zhu & Kang, Text-to-SQL Benchmarks are Broken: An In-Depth Analysis of Annotation Errors (CIDR 2026, UIUC) — the annotation-error caveat: a 66.1% error rate across the 121 Spider 2.0-Snow problems with public gold SQL, and 52.8% on BIRD Mini-Dev. An extended version (arXiv:2601.08778) revises the Spider figure to 62.8% and adds leaderboard-rank impact.
- Chroma Research, Context Rot: How Increasing Input Tokens Impacts LLM Performance — 18 frontier models.
- LlamaIndex, Did Filesystem Tools Kill Vector Search? (January 2026) and Is grep all you need? (May 2026).Faysse et al., ColPali: Efficient Document Retrieval with Vision Language Models (ICLR 2025) — late-interaction retrieval over page images; the original ColBERT is Khattab & Zaharia, SIGIR 2020.
Query transformation
- Kotte, Not All Queries Need Rewriting: When Prompt-Only LLM Refinement Helps and Hurts Dense Retrieval (Adobe, March 2026) — the FiQA / TREC-COVID / SciFact results. Note: single-author preprint, not peer-reviewed; the TREC-COVID gain is marginal after correction.
