38 — DPR (Dense Passage Retrieval)

Answer:

Dense Passage Retrieval (Karpukhin et al., Facebook AI, 2020) is the architecture that replaced sparse BM25 retrieval with learned dense vectors for open-domain question answering. Before DPR, retrieval for open-domain QA relied almost entirely on keyword-matching methods like BM25/TF-IDF, which fail whenever a question and its answer passage share meaning but not vocabulary ("How tall is the Eiffel Tower?" vs. a passage saying "The tower stands 330 meters high").

DPR trains two separate BERT encoders — one for questions, one for passages — using contrastive learning on (question, positive passage, negative passages) triplets, producing a retrieval system that understands semantic intent rather than requiring literal word overlap. Every modern RAG embedding model (BGE, E5, Contriever, GTE, Nomic-Embed) is a direct architectural descendant of DPR — understanding DPR is understanding the foundations of dense retrieval that the rest of this bank builds on.

Answer:

The distinctive mechanism is learned, independently-encoded dense vectors compared by inner product, in place of hand-designed keyword-frequency statistics (BM25's term-frequency/inverse-document-frequency heuristic). Two consequences follow directly from this:

1. Semantic matching — because the encoders are trained end-to-end with contrastive loss (Q4) on real question-passage pairs, they learn to place semantically related but lexically different text close together in vector space, something no fixed keyword-weighting formula can do.
2. Offline indexability — because the question and passage encoders are independent networks (not a single model that jointly reads both), every passage in the corpus can be encoded once, in advance, and stored in an index; only the (much cheaper) question encoding happens at query time. This is what makes dense retrieval practical at billion-passage scale, and it's the property a cross-encoder (which must jointly process the query and each candidate passage together) fundamentally cannot offer.

Answer:

┌─────────────────────────────────┐   ┌─────────────────────────────────┐
│  Question Encoder (BERT-base)   │   │  Passage Encoder (BERT-base)    │
│  Input: "What is RAG?"          │   │  Input: "RAG combines retrieval │
│                                 │   │  with generative models..."     │
│  [CLS] token → d-dim vector     │   │  [CLS] token → d-dim vector     │
│  q = E_Q(question)              │   │  p = E_P(passage)               │
└────────────────┬────────────────┘   └────────────────┬────────────────┘
                 │                                      │
                 └──────────────┬───────────────────────┘
                                │
                         sim(q, p) = q · p   (inner product)

At index time (offline, once): every passage in the corpus is run through the passage encoder, producing a d-dimensional vector per passage, stored in a FAISS index (Q9). At query time (online, per request): the question is run through the separate question encoder, producing a single query vector; the retriever computes the inner product of that query vector against every stored passage vector (approximately, via FAISS) and returns the top-k highest-scoring passages. The two encoders never interact directly — they only ever meet through the inner product computed after both have already produced their vectors, which is exactly the design choice that separates DPR from a cross-encoder and enables offline indexing (Q2).

Answer:

DPR is trained with an InfoNCE-style contrastive loss: for each training sample (q, p+, p1-, p2-, ..., pn-), the similarity to the positive passage should be high and similarity to negatives should be low:

Loss = -log [ exp(sim(q, p+)) / Σ exp(sim(q, pi)) ]
     = cross entropy over the batch, treating in-batch passages as negatives

The key efficiency trick is in-batch negatives: every other passage in the same training batch (which is the positive passage for some other question in the batch) is used as a free negative for the current question — at batch size 128, that's 127 negatives per positive with no additional sampling or computation beyond what training already does. This is why DPR's training scales well: the effective number of negatives grows with batch size for free, rather than requiring a separate negative-mining pass for every training example. In-batch negatives alone, however, tend to be "easy" (obviously irrelevant passages) — DPR's actual training recipe combines them with explicitly mined hard negatives (Q13) for a much stronger signal.

Answer:

Both encoders share the same architecture (a BERT backbone, using the [CLS] token as the sentence representation) but are trained as two independent parameter sets:

from transformers import BertModel
import torch.nn as nn

class DPREncoder(nn.Module):
    def __init__(self, model_name: str = "bert-base-uncased"):
        super().__init__()
        self.bert = BertModel.from_pretrained(model_name)

    def forward(self, input_ids, attention_mask) -> torch.Tensor:
        output = self.bert(input_ids=input_ids, attention_mask=attention_mask)
        return output.last_hidden_state[:, 0, :]  # [CLS] token representation, [batch, 768]

class DPR(nn.Module):
    def __init__(self):
        super().__init__()
        self.question_encoder = DPREncoder()
        self.passage_encoder = DPREncoder()

    def encode_question(self, input_ids, attention_mask):
        return self.question_encoder(input_ids, attention_mask)
    def encode_passage(self, input_ids, attention_mask):
        return self.passage_encoder(input_ids, attention_mask)

def train_step(model, batch, optimizer):
    q_vecs = model.encode_question(batch["question_input_ids"], batch["question_attention_mask"])
    p_vecs = model.encode_passage(batch["passage_input_ids"], batch["passage_attention_mask"])
    loss = dpr_loss(q_vecs, p_vecs)  # Q8
    optimizer.zero_grad()
    loss.backward()
    optimizer.step()
    return loss.item()

Note that question_encoder and passage_encoder are separate DPREncoder instances — they start from the same pretrained BERT checkpoint but diverge during fine-tuning into two distinct models, which is what Q6 explains the rationale for.

Answer:

Empirically, separate encoders outperform a shared one. The intuition: questions and passages come from different distributions — questions are typically short, interrogative, and keyword-sparse; passages are declarative, longer, and informationally dense. A shared encoder must produce vectors from both distributions in the same space using the same weights, which creates tension during training — the model is pulled toward a compromise representation rather than one specialized for either role.

Separate encoders can specialize: the question encoder learns to represent intent, while the passage encoder learns to represent answer-relevant content. The cost is double the parameter count (~220M instead of ~110M for a single BERT-base), but the accuracy gain justifies it for retrieval quality. Modern models like BGE and E5 follow the same underlying pattern, though many now use a single shared encoder with different instruction prefixes for queries vs. passages rather than fully separate weights — an efficiency middle ground DPR's original design didn't explore.

Answer:

The progression here is architectural continuity, not a series of unrelated inventions: modern embedding models keep DPR's core recipe (bi-encoder, contrastive training, inner-product/cosine similarity) and improve on it with larger backbones, broader and more diverse training data, instruction-tuned asymmetric encoding (a different prompt prefix for "query:" vs "passage:" rather than fully separate weights), and multilingual pretraining. BM25 still wins on exact-match and out-of-domain robustness (Q14), which is why hybrid BM25+dense retrieval remains standard practice rather than fully retiring sparse search.

Answer:

The loss treats the batch's similarity matrix as a classification problem: for question i, the correct answer is passage i (the diagonal), and every other passage in the batch is a negative:

import torch
import torch.nn.functional as F

def dpr_loss(q_vecs: torch.Tensor, p_vecs: torch.Tensor) -> torch.Tensor:
    """
    q_vecs: [batch, dim] question embeddings
    p_vecs: [batch, dim] passage embeddings (i-th passage is positive for i-th question)
    """
    sim_matrix = torch.matmul(q_vecs, p_vecs.T)  # [batch, batch]: q_i . p_j
    labels = torch.arange(q_vecs.size(0), device=q_vecs.device)  # diagonal = positive pairs
    return F.cross_entropy(sim_matrix, labels)  # maximize diagonal, minimize off-diagonal

This one function is the entire training signal: torch.matmul computes every question's similarity to every passage in the batch in one call, and cross_entropy with labels = arange(batch_size) is exactly the InfoNCE formula from Q4 — no explicit loop over negatives is needed, because the off-diagonal entries of the similarity matrix are already every in-batch negative. This is a large part of why DPR's training is efficient: one matrix multiplication and one cross-entropy call captures the full contrastive objective for the whole batch.

Answer:

Indexing runs once, offline, over the whole corpus; retrieval runs per-query, online, against the pre-built index:

import faiss
import numpy as np

def build_dpr_index(passages: list[str], passage_encoder, tokenizer, batch_size: int = 256) -> faiss.Index:
    all_embeddings = []
    for i in range(0, len(passages), batch_size):
        encoded = tokenizer(passages[i:i + batch_size], padding=True, truncation=True,
                             max_length=512, return_tensors="pt")
        with torch.no_grad():
            embs = passage_encoder(**encoded)  # [batch, 768]
        all_embeddings.append(embs.cpu().numpy())

    all_embeddings = np.vstack(all_embeddings).astype("float32")
    dim = all_embeddings.shape[1]
    index = faiss.IndexFlatIP(dim)          # exact inner product
    faiss.normalize_L2(all_embeddings)       # normalized inner product == cosine similarity
    index.add(all_embeddings)
    return index

def dpr_retrieve(question: str, question_encoder, tokenizer, faiss_index, passages, k: int = 5) -> list[str]:
    encoded = tokenizer(question, return_tensors="pt", truncation=True, max_length=128)
    with torch.no_grad():
        q_vec = question_encoder(**encoded).cpu().numpy().astype("float32")
    faiss.normalize_L2(q_vec)
    scores, indices = faiss_index.search(q_vec, k)
    return [passages[i] for i in indices[0]]

IndexFlatIP performs exact (brute-force) inner-product search — correct but O(n), fine for evaluation or small corpora; production systems at scale replace it with an approximate index (HNSW, IVF) exactly as covered in Naive RAG's ANN discussion, since the DPR-produced vectors are just ordinary dense embeddings once computed, indexable by any standard vector database.

Answer:

Batch size and hard-negative count interact: a very large batch already supplies many easy negatives, so the marginal value of adding more hard negatives per example is highest when batch size (and therefore in-batch negative count) is constrained by hardware — the two are partial substitutes for the same underlying goal of giving the model enough contrastive signal per training step.

Answer:

The standard metric is top-k recall: for what fraction of test questions does at least one of the top-k retrieved passages actually contain the answer? On Natural Questions (NQ), DPR reported roughly 78% top-20 recall vs. BM25's roughly 38% — meaning DPR found an answer-containing passage in its top 20 results more than twice as often as pure keyword search, on a benchmark built from real Google search queries paired with Wikipedia answers.

Evaluating a DPR-style retriever for your own use case follows the same recipe: build a labeled set of (question, answer-containing passage) pairs from your domain, measure recall@5/10/20 (and MRR/NDCG if rank position matters, not just presence in the top-k), and compare against a BM25 baseline on the same corpus and same query set — published NQ/TriviaQA numbers don't transfer to a different domain's vocabulary and query style, which is exactly why Q12's decision-gate framing (fine-tune vs. off-the-shelf) requires your own benchmark rather than trusting the paper's headline figures.

Answer:

Fine-tuning a bi-encoder is expensive (labeled data collection, GPU training time, ongoing maintenance as the corpus evolves) relative to simply using an off-the-shelf modern embedding model (BGE/E5), so the decision needs a benchmark, not a default:

1. Build a domain-specific golden eval set: (query, relevant passage) pairs drawn
   from real user queries or SME-authored questions against your actual corpus.

2. Baseline: measure recall@10/NDCG with an off-the-shelf model (e.g., BGE-large)
   with zero fine-tuning, using your real chunking strategy.

3. Fine-tuning candidate: fine-tune the same base model on your domain's
   (question, positive passage, hard negatives) triplets, following DPR's
   recipe (Q4, Q13) but starting from a modern pretrained checkpoint rather
   than raw BERT.

4. Compare recall/NDCG delta against the cost of fine-tuning: data labeling
   effort, GPU-hours, and the ongoing cost of re-training as the corpus and
   query distribution drift over time.

5. Gate: only commit to fine-tuning if the delta clears a threshold that
   justifies the ongoing maintenance burden — e.g., >5 percentage points of
   recall@10 improvement on the golden set. A smaller gain is usually better
   spent on reranking (a cross-encoder reranker on top of an off-the-shelf
   bi-encoder often closes most of the gap at a fraction of the engineering cost).

The general pattern: fine-tuning a retriever is a high-maintenance investment (it needs to be redone as the corpus and query distribution shift, unlike a static off-the-shelf model), so it should be justified by a measured gap on your own data, not assumed to always be worth it just because DPR's original paper showed large gains over BM25 on a benchmark far removed from your domain.

Answer:

In-batch negatives (Q4) are easy negatives — random passages that happen to share a training batch, usually obviously irrelevant to the question. A model trained only on these learns to distinguish a cooking recipe from a RAG paper, but struggles with the much harder distinction between "a passage that mentions the same topic but doesn't answer the question" and "the passage that actually answers it":

Easy negative: "What is RAG?" question → negative from a cooking recipe passage
Hard negative: "What is RAG?" question → negative from a passage about "retrieval"
               in general information-retrieval theory (topically related, not the answer)

Symptom: the model performs well on coarse retrieval benchmarks (distinguishing broadly different topics) but its top-k results are cluttered with topically-adjacent-but-wrong passages once the corpus contains many documents on the same general subject — exactly the situation any real production corpus is in, since a corpus of unrelated documents is rare.

Fix: mine hard negatives explicitly rather than relying on in-batch negatives alone:

def sample_hard_negatives(question: str, positive_id: str, bm25_index, corpus, n: int = 7) -> list[str]:
    bm25_results = bm25_index.search(question, k=100)
    return [corpus[r["id"]] for r in bm25_results if r["id"] != positive_id][:n]

BM25's top-k (excluding the actual positive) is a cheap and effective source of hard negatives: it surfaces passages that share keywords with the question but aren't the answer, which is exactly the fine-grained distinction in-batch negatives fail to teach.

Answer:

Dense retrieval's semantic strength is also its exact-match weakness: a bi-encoder trained to generalize across paraphrases can underperform on queries where the literal token match is the signal — product SKUs, error codes, exact legal citations, or rare proper nouns that appeared rarely or never in training data. BM25, having no learned generalization to overfit or under-fit, handles these cases robustly by design. This is also where DPR's out-of-domain weakness shows up most clearly: a bi-encoder fine-tuned on Natural Questions-style trivia QA carries no guarantee of transferring well to, say, legal or medical text with substantially different vocabulary and question style, whereas BM25's keyword-matching behavior degrades much more gracefully across domains.

Mitigation: hybrid search — run BM25 and dense retrieval in parallel and merge results (typically via Reciprocal Rank Fusion), so exact-match queries are still caught by BM25 even when the dense retriever's semantic generalization doesn't cover them, and semantic queries still benefit from the dense side. This is standard practice in essentially every production RAG system now, precisely because DPR-style dense retrieval and BM25 have close-to-orthogonal failure modes: what one misses, the other frequently catches.

Answer:

Two independent BERT-base encoders (~110M parameters each, ~220M total) means DPR pays roughly double the parameter count of a single-encoder model, though only the question encoder runs at query time (the passage encoder only ever runs offline during indexing, Q9). Illustrative query-time cost: encoding a single question through BERT-base on a modern GPU is low-single-digit milliseconds — the dominant query-time cost in a production system is almost always the FAISS/vector-DB search itself at scale, not the question encoding.

Illustrative offline indexing cost for 10M passages: encoding at ~256 passages/batch on a single GPU, roughly 40,000 batches; at ~0.1s/batch this is over an hour of GPU time for a one-time (or periodic, on corpus change) job — trivial compared to the ongoing query-time cost across millions of subsequent queries.

Modern models optimize this in two directions: (1) shared-weight asymmetric encoding (a single model with different instruction prefixes for "query:" vs. "passage:" inputs, as BGE/E5 use) halves the parameter count relative to DPR's fully-separate encoders, with comparable or better retrieval quality; (2) smaller, distilled encoder backbones for latency-sensitive query-time encoding, while keeping a larger model for offline passage encoding where latency doesn't matter — an asymmetry DPR's original symmetric BERT-base/BERT-base design didn't exploit.

Answer:

IndexFlatIP (Q9) is exact but O(n) per query — completely impractical at billion-passage scale, where a single query would require billions of dot products. Production scaling requires the same approximate-nearest-neighbor techniques covered generally for vector databases, applied to DPR-produced vectors: HNSW or IVF indexes trade a small accuracy loss for orders-of-magnitude faster query time, and are the default choice in any production vector database (Qdrant, Weaviate, Milvus) rather than FAISS's flat index.

Beyond the index structure itself: (1) sharding — partition the passage index across multiple machines by hash or by corpus segment, querying all shards in parallel and merging results, since no single machine holds a billion-vector index in memory; (2) quantization — compress vectors from float32 to int8 or binary (as covered generally for vector storage cost) to fit a billion-vector index in a feasible amount of RAM; (3) incremental indexing — DPR's original design assumes a static, fully pre-computed offline index; a production system layers an incremental-upsert path on top (as covered in Streaming RAG, #35) so new passages don't require a full re-index; (4) passage encoder batching at ingestion time — encoding billions of passages is itself a large one-time (or recurring) compute job that needs to be pipelined and checkpointed, not run as a single unbounded script.

Answer:

• Embedding inversion — like any dense embedding, a DPR-produced passage or query vector can potentially be approximately inverted back toward the original text by an adversary who knows the encoder architecture (the same vec2text-class risk covered for privacy-preserving RAG, #34). This matters specifically for the question encoder's output if query vectors are ever logged or transmitted to a less-trusted party.
• Adversarial passage crafting — because ranking is purely a dot-product against a passage vector, an attacker who can influence what gets indexed (a corpus with open or semi-open contribution, like a wiki or forum) can craft a passage whose embedding sits unusually close to many common query vectors, causing it to rank highly across a disproportionate number of unrelated queries — a manipulation vector cross-encoders are more resistant to, since they process the query and passage jointly rather than via a pre-computed static vector.
• Training data leakage — DPR's encoders are trained on (question, passage) pairs; if that training data includes sensitive or proprietary content, the resulting encoder weights can, in principle, be probed to reveal information about what it was trained on (a membership-inference-style risk), separate from any risk in the deployed retrieval corpus itself.
• Stale hard-negative mining reinforcing bias — if hard negatives (Q13) are mined using a previous model iteration's own retrieval results, and that model has systematic blind spots, successive fine-tuning rounds can reinforce rather than correct those blind spots, since the negatives it's trained against never include the failure cases it doesn't already partially recognize.

Mitigation follows the same general pattern as other embedding-based systems in this bank: treat passage vectors and query vectors as containing (some) recoverable information about their source text rather than as fully opaque, screen contributed content before indexing in open-contribution corpora, and periodically re-evaluate hard-negative mining against a held-out, human-curated set rather than only the model's own prior outputs.

Answer:

Starting from DPR's core recipe (bi-encoder, contrastive training, offline indexing) and applying what the field has learned since 2020:

1. Encoder: replace two separate BERT-base models with a single modern
   backbone (E5/BGE-class) using asymmetric instruction prefixes
   ("query: ..." vs "passage: ...") -- halves parameter count vs DPR's
   fully separate encoders (Q15) with comparable or better quality.

2. Training data: combine in-batch negatives (Q4) with hard negatives mined
   from BOTH BM25 (Q13) and a prior model checkpoint's own top-k misses,
   rather than BM25 alone -- catches failure modes BM25-only mining misses.

3. Index: HNSW-based approximate index (Qdrant/Weaviate) rather than FAISS
   IndexFlatIP, sharded for billion-scale corpora (Q16), with int8
   quantization to control memory footprint.

4. Retrieval: hybrid BM25 + dense with Reciprocal Rank Fusion by default
   (Q14) -- never dense-only, given DPR's known exact-match weakness.

5. Reranking: add a cross-encoder reranking stage on top of the bi-encoder's
   top-k -- recovers much of the accuracy a pure cross-encoder would give
   without paying its cost on the full corpus, since it only reranks the
   already-narrowed candidate set.

6. Freshness: layer an incremental upsert path (as in Streaming RAG, #35)
   on top of DPR's originally-static, fully-offline indexing assumption.

The throughline: every upgrade here addresses a specific, named limitation of DPR's original 2020 design (parameter count, hard-negative quality, index scalability, exact-match weakness, cross-encoder accuracy, staleness) without abandoning DPR's foundational insight that a bi-encoder trained contrastively and indexed offline is the right shape for retrieval at scale.

Answer:

Dense Passage Retrieval (Karpukhin et al., Dense Passage Retrieval for Open-Domain Question Answering, arXiv:2004.04906, 2020) replaced sparse BM25 retrieval with two BERT encoders trained end-to-end with contrastive loss on question-passage pairs. The breakthrough was demonstrating that a bi-encoder — separate encoders for questions and passages, with no joint cross-attention — trained on curated QA pairs could significantly outperform BM25 on open-domain QA benchmarks: roughly 78% top-20 recall on Natural Questions versus BM25's roughly 38%, while keeping queries fast via offline indexing (Q2).

It established the two ideas that all modern RAG retrieval still relies on: (1) semantic retrieval via learned dense vectors is more powerful than keyword matching for the large class of queries where meaning and vocabulary diverge; (2) offline pre-computation of passage embeddings makes billion-scale dense retrieval computationally practical, since only the (cheap) query encoding happens online. Nearly every embedding model used in RAG today traces its architecture directly back to this paper.

Answer:

What DPR established, still true of every modern embedding model:

1. Bi-encoder = offline indexability — the foundational insight enabling billion-document RAG at all.
2. Hard negatives are critical — in-batch negatives alone produce mediocre models; hard-negative mining defines modern training recipes.
3. Inner product (normalized = cosine) as the universal retrieval metric — essentially every vector database's default similarity function today.
4. Separate (or asymmetric) question/passage representations — empirically better than a fully symmetric shared encoder, because queries and passages have different distributional properties (Q6).

Limitations relative to modern descendants: DPR's original BERT-base backbone and English-only, QA-benchmark-specific training data leave it weaker on out-of-domain text, multilingual queries, and code/technical content than instruction-tuned modern models trained on far larger and more diverse corpora (Q7). It also carries no built-in defense against its exact-match weakness (Q14) — hybrid search wasn't part of DPR's original design, and became standard practice only once dense retrieval's blind spots were well understood in production. Every modern embedding model (BGE, E5, Nomic, Contriever) is best understood as "DPR's recipe, scaled up and refined" rather than a fundamentally different architecture — which is exactly why understanding DPR's training objective, hard-negative strategy, and offline-indexing design pays off well beyond DPR itself.

Answer:

A few thousand support articles and a startup-sized budget means the right move is almost certainly not to reproduce DPR's original training recipe from scratch — training two BERT encoders end-to-end (Q4, Q5) is exactly the kind of investment Q12's decision gate exists to guard against defaulting into.

What the situation implies: a modest, static-ish corpus, limited engineering time, and support docs that likely mix conversational questions with exact terms (product names, error codes) — meaning both semantic matching and exact-match matter.

Recommended approach: start with an off-the-shelf modern embedding model (BGE or E5) rather than training DPR-style encoders — these are direct architectural descendants of DPR (Q7, Q20) that already generalize well out of the box. Build a simple IndexFlatIP or small ANN index (Q9) — exact search is entirely fine at a few-thousand-document scale. Critically, keep BM25 running alongside the dense retriever in a hybrid setup (Q14) rather than replacing it outright: support docs commonly contain exact product names and error codes that a semantic-only retriever can under-rank (DPR's own well-known exact-match weakness, Q14), so hybrid retrieval with RRF is the safer default from day one, not an afterthought.

Trade-offs to flag: (1) before fully committing to the switch, build a small golden set (query, relevant doc) pairs and measure recall@10 for BM25-only, dense-only, and hybrid (Q11, Q12) — don't assume dense retrieval is strictly better without checking on your own query distribution; (2) fine-tuning the embedding model is very unlikely to be worth it at this scale unless the golden-set evaluation reveals a specific, measurable gap (Q12's gate).

Answer:

At 200 million documents with a strict re-indexing cadence, DPR's original design choices — two fully separate BERT-base encoders, English-only training, exact IndexFlatIP search (Q3, Q9) — are all constraints that need upgrading, not a starting point to build on directly.

Design: use a shared-weight asymmetric encoder (Q15) — a single modern backbone (E5/BGE-class) with different instruction prefixes for queries vs. passages — rather than DPR's fully separate encoder pair, halving the parameter count that must be trained and served at this scale with comparable or better quality. Use a multilingual base checkpoint (mE5-class) given the corpus is multilingual, since DPR's original English-only training doesn't transfer (Q7). For training data, combine in-batch negatives with hard negatives mined from both BM25 and the prior model checkpoint's own top-k misses (Q13, Q18) — this catches failure modes that BM25-only mining alone would miss, which matters more at this scale since retraining is expensive and each cycle should improve meaningfully.

Index and re-indexing cadence: replace IndexFlatIP with a sharded, quantized HNSW/IVF index (Q16) — 200M documents makes exact search infeasible regardless of cadence requirements. To actually meet a strict re-indexing cadence, layer an incremental upsert path (Q16, cross-referencing Streaming RAG's approach, #35) on top of DPR's originally fully-offline, batch-indexing assumption, so a re-embed doesn't mean reprocessing the entire 200M-document corpus every cycle.

Keep hybrid BM25+dense retrieval as the production default (Q14, Q18) — the exact-match weakness doesn't go away with scale or multilingual training, and a vendor serving diverse customer query patterns needs that safety net more, not less.

What to monitor: recall@10/NDCG segmented by language (multilingual quality often varies unevenly across languages), actual re-indexing cycle time against the cadence SLA, and hybrid fallback trigger rate for exact-match and out-of-domain queries.