Stabilizing Embedding Space Drift in Production RAG: Detecting, Measuring, and Containing Similarity Regressions

A team ships a routine RAG upgrade on a Thursday afternoon.

Nothing dramatic: a newer embedding model, slightly larger chunk size, cleaner HTML stripping, and a small tweak to boilerplate removal. The offline benchmark looks fine. In fact, on the team’s relevance set, Recall@10 improves by 4 points. Indexing completes overnight. By Friday morning, support tickets are up.

The failures do not look like “retrieval is broken.” They look like product weirdness.

Sales users say the assistant suddenly ignores the latest pricing PDF and answers from old enablement docs. Support agents report that troubleshooting steps now cite release notes instead of the canonical runbook. A compliance workflow starts including policy-adjacent documents rather than the exact governing procedure. Latency is unchanged. The LLM did not change. The generated answers are still fluent.

What changed was the geometry.

The new embedding space reordered neighborhood relationships just enough that many queries still retrieved plausible-looking documents, but no longer the right documents. Hybrid search thresholds were tuned for the old cosine score distribution. Query-result caches keyed on normalized text but not retrieval version started serving stale contexts. The team’s reranker masked some regressions in head traffic, while tail queries fell apart. Offline metrics had given the migration a green light because the evaluation set was too small, too clean, and too tied to exact-match relevance judgments from the old chunking strategy.

This is a common production failure mode in retrieval-augmented generation systems: embedding space drift. Not only model swaps cause it. Any change that perturbs the mapping from text to vectors, or changes the document units being embedded, can produce retrieval regressions that are subtle, non-local, and hard to diagnose from standard offline dashboards.

If you run RAG in production, you should assume that embedding drift is not an edge case. It is a recurring operational reality.

This article is a field guide for engineering teams managing that reality. The goal is not to freeze your retrieval stack forever. It is to make upgrades safe. We will cover the production patterns that matter most:

• what counts as embedding space drift in practice
• why standard offline retrieval metrics often mislead during migrations
• how to compare old and new retrieval stacks without pretending vector spaces are directly commensurable
• how to run dual-write and dual-retrieval migrations
• how to protect hybrid retrieval, caches, rerankers, and thresholds during transitions
• how to define rollback gates using retrieval, grounding, and business outcome signals
• how to reason about cost, latency, and operational tradeoffs

The throughline is simple: don’t ask “is the new embedding model better?” Ask “under my production traffic, corpus dynamics, ranking stack, and answer-generation behavior, is the new retrieval path safer and more useful than the old one?”

What embedding space drift actually is

In production conversations, teams use “embedding drift” to describe several different phenomena. It helps to separate them, because mitigation differs by type.

1. Model-induced drift

You switch from embedding model A to model B. Even if both are strong, they carve the semantic space differently.

Common effects:

• nearest neighbors change for the same query
• score distributions shift, even when ranking quality improves
• specific domains improve while others regress
• vector norms, anisotropy, and cluster density differ enough to break tuned thresholds or ANN settings

This is the most obvious form of drift, but not the only one.

2. Document-distribution drift

The model stays fixed, but your corpus changes.

Examples:

• a new product line introduces vocabulary the model handles differently
• a flood of repetitive templated documents increases local density in one region of the space
• multilingual content grows from 5% to 30%
• newer documents systematically differ in style, metadata quality, or structure

This can create retrieval regressions even with no model change, because local neighborhood structure shifts as the corpus evolves.

3. Chunking-induced drift

You change chunk size, overlap, section splitting, table handling, or title propagation.

This is often the most underestimated source of drift. In production RAG, changing chunks is effectively changing the retrieval unit, which changes both index geometry and relevance labeling assumptions.

A query that used to match a highly focused 250-token chunk may now map to a 900-token chunk that contains the answer but also a lot of semantic noise. Or the reverse: a broad procedural question may now require aggregating evidence across several smaller chunks, which your current retriever plus reranker pipeline may not do well.

4. Preprocessing-induced drift

You modify text normalization, HTML stripping, OCR cleanup, de-duplication, boilerplate removal, code fence handling, or metadata concatenation.

These changes often look innocuous and “obviously better,” but they can alter key lexical and semantic anchors. Removing repeated headers can help. Removing section labels like “Eligibility,” “Exception,” or “Rollback Procedure” can hurt badly. Concatenating titles into chunks can improve navigability for some corpora and overfit retrieval toward generic section names in others.

5. Index/retrieval-stack drift

You keep embeddings fixed, but change ANN parameters, compression, quantization, vector DB version, hybrid weights, reranker model, or metadata filters.

Strictly speaking this is not embedding drift, but operationally it behaves similarly: same queries, different neighbors, different answer behavior.

In production, users do not care which layer drifted. They care that “the assistant got worse.” Your migration process should therefore treat the whole retrieval path as the unit under test.

Why the naive approach fails

The naive approach to an embedding migration usually looks like this:

1. Sample a few thousand labeled query-document pairs.
2. Re-embed the corpus with the new model.
3. Compare Recall@k, nDCG@k, maybe MRR.
4. If the numbers are up, cut over.

This is better than nothing, but it is not enough. Here is why it repeatedly fails in real systems.

Offline metrics collapse different failure modes into one number

A single Recall@10 score can hide severe regressions concentrated in:

• important customer segments
• long-tail informational queries
• fresh documents
• structured content like tables, policies, or code
• high-consequence flows where a near miss is operationally unacceptable

If your aggregate goes from 0.72 to 0.75, that may still mask a drop from 0.81 to 0.58 on the revenue-critical slice.

Your labels are usually entangled with the old system

Many production retrieval datasets are bootstrapped from prior click logs, accepted answers, or human judgments over chunks produced by the current pipeline. That means the eval set is not an objective view of relevance. It is partially shaped by:

• the old chunking regime
• the old candidate pool
• the old reranker
• the old UI exposure patterns

When the retrieval unit changes, old labels often become weak supervision at best. A “miss” may actually reflect that the answer moved into a different chunk granularity. A “hit” may still be insufficient grounding for generation.

Vector spaces are not directly comparable by score

Teams often compare cosine similarities between old and new systems as though a 0.84 in one space means the same thing as a 0.84 in another. It does not.

Embedding spaces differ in:

• score calibration
• concentration of measure
• neighborhood density
• separation between relevant and non-relevant items
• sensitivity to lexical overlap vs paraphrase

This matters for thresholded workflows like semantic cache hits, “no good context found” decisions, hybrid weighting, and retrieval gating.

Rerankers and generators can hide retrieval regressions

A strong reranker may rescue mediocre candidate sets for head queries but fail on tail queries or filtered searches. Likewise, a powerful LLM may generate plausible answers from weak context, giving you deceptively good answer-quality ratings while silently increasing hallucination risk.

If you only look at end-to-end answer preference scores, you can miss a degrading retrieval foundation.

Production traffic is adversarial in a way offline sets are not

Users type shorthand. They omit nouns. They ask organization-specific questions that rely on internal acronyms. They ask broad questions that require retrieving several complementary chunks. They issue repeated reformulations after failures. They filter by account, region, product line, or time range.

A clean benchmark rarely captures this distribution.

The practical lesson: treat an embedding migration as a production change-management problem, not a benchmark leaderboard exercise.

The better approach: evaluate the retrieval path as a versioned system

The durable pattern is to version the entire retrieval path and compare versions under realistic conditions.

A retrieval-path version should minimally encode:

• embedding model version
• chunking version
• preprocessing version
• metadata composition version
• ANN/index parameters
• hybrid search configuration
• reranker version
• retrieval thresholds and gating policies

Think of this as retrieval_profile_vN rather than “embedding model B.”

That shift matters because many regressions blamed on embeddings are really interaction effects between embeddings and the rest of the stack.

Recommended architecture for safe migrations

A production-safe architecture typically has these components:

1. Versioned ingestion pipeline

   • deterministic preprocessing
   • deterministic chunking
   • embedding generation tagged with retrieval profile
   • dual-write support to old and new indexes

2. Parallel indexes

   • old vector index
   • new vector index
   • optionally separate lexical index if document units changed

3. Retrieval experiment router

   • can shadow queries to multiple retrieval profiles
   • can return one profile to users while logging both
   • supports slice-based traffic allocation

4. Unified judgment and telemetry store

   • query, profile version, candidate set, reranker outputs, chosen context, answer, user interaction, and groundedness signals

5. Evaluation service

   • offline replay
   • online shadow analysis
   • counterfactual comparison where possible
   • rollback gate computation

6. Cache namespace isolation

   • semantic/query-result caches keyed by retrieval profile
   • context caches keyed by document/chunk version

7. Operational controls

   • canary rollout
   • per-tenant or per-segment override
   • fast rollback to previous retrieval profile

This sounds heavyweight, but if RAG matters to your business, these controls pay for themselves quickly.

Measuring drift without fooling yourself

You cannot compare vector spaces by raw similarity scores. You can compare them by behavior.

The most useful measurements are behavior-centric and layered.

Layer 1: Candidate set stability metrics

These tell you how much top-k retrieval changes between profiles for the same query.

Useful metrics:

• Top-k overlap / Jaccard on document IDs or canonical source IDs
• Rank-biased overlap to emphasize top positions
• Source-family overlap when chunk IDs change but source documents remain the same
• Coverage shift: fraction of queries where the top relevant source disappears entirely

Interpretation:

• low overlap is not automatically bad if quality improves
• high overlap is not automatically good if both profiles miss
• dramatic overlap drops on stable, high-value queries are strong warning signals

When chunking changes, compare at multiple granularities:

• chunk level
• source document level
• section level if available

Otherwise you will overstate regressions that are actually chunk-boundary changes.

Layer 2: Retrieval quality metrics on adjudicated sets

Use standard IR metrics, but build the dataset carefully.

Recommended eval set composition:

• historical production queries sampled by frequency decile
• long-tail queries from failure logs
• fresh-content queries where recency matters
• structured-document queries: tables, lists, policies, code, PDFs
• filtered queries using metadata constraints
• multi-hop or evidence-aggregation queries if your product supports them
• high-risk business flows weighted explicitly

Recommended metrics:

• Recall@k and Precision@k
• nDCG@k if graded relevance exists
• Success@k at source-doc level and answer-span level
• filtered retrieval success rate
• freshness-aware retrieval success for recent documents

Important: maintain two judgment schemes when chunking changes:

• content-equivalent relevance: did the retrieved unit contain the needed evidence?
• unit-equivalent relevance: did it retrieve the exact labeled chunk or source?

Content-equivalent relevance is usually the better indicator for migrations.

Layer 3: Grounding metrics

Retrieval is not the goal. Useful grounded answers are the goal.

Track:

• citation correctness
• answer-supported-by-context rate
• unsupported claim rate
• context sufficiency rate
• evidence completeness for workflow tasks

These can be measured with a combination of human review, model-assisted grading, and deterministic checks for citation-source alignment.

A common pattern is to see retrieval Recall@10 improve slightly while grounding gets worse because the retrieved set becomes broader and noisier, making it harder for the generator to pick the right evidence.

Layer 4: Business and behavioral metrics

This is where migrations live or die.

Examples:

• task completion rate
• deflection rate with downstream satisfaction constraints
• escalation rate
• time to resolution
• answer copy/export rate
• corrective search/retry rate
• abandonment after first answer
• explicit thumb-downs or hidden dissatisfaction signals

The key is not to wait until these degrade in full rollout. Use them as gated signals in canaries.

Designing evaluation sets that survive migrations

A brittle eval set is worse than none because it gives false confidence.

A production-grade migration set should have three layers.

1. Gold set

Small, expensive, manually adjudicated, high-quality.

Use for:

• release blocking
• regression diagnosis
• measuring high-risk scenarios

Size guidance:

• 300–1000 queries can be enough if carefully stratified
• ensure strong representation of business-critical slices

2. Silver set

Larger set derived from observed queries plus heuristic or weak labels.

Sources:

• clickthrough with dwell thresholds
• accepted/copied answers with source usage
• human-reviewed tickets mapped to documents
• synthetic query generation seeded from docs, but validated on a sample

Use for:

• broad coverage
• trend detection
• slice comparisons

Treat as directional, not authoritative.

3. Shadow traffic set

Live production queries replayed or mirrored in real time to both profiles.

Use for:

• candidate-set drift analysis
• score distribution monitoring
• online groundedness estimation
• before-user-impact validation

This is where you catch “the benchmark said fine, traffic says no.”

Dual-write and dual-retrieval migrations

The safest migration pattern in production RAG is dual-write plus dual-retrieval.

Dual-write ingestion

When building the new retrieval profile:

• process new and updated documents through both old and new ingestion pipelines
• preserve stable canonical document IDs across profiles
• assign versioned chunk IDs: doc_id + profile_version + chunk_seq
• write to separate indexes and, if needed, separate lexical stores

Why dual-write matters:

• it keeps old and new corpora similarly fresh during the migration window
• it enables apples-to-apples query comparisons
• it lets you roll back without reindexing under pressure

Storage costs increase, but for most teams this is cheaper than a failed cutover.

Dual-retrieval serving

On query serving:

• send the live query to the active profile for the user-facing answer
• shadow the same query to the candidate profile
• log candidate sets, scores, reranker outputs, latencies, and grounding estimates for both

In a later stage, run a canary where a small percentage of users actually receive answers from the new profile.

Recommended phases:

1. Offline replay only
2. Online shadow mode with 0% user exposure
3. Internal dogfood on selected teams
4. Canary by segment: 1–5% low-risk traffic
5. Expanded canary with high-value segments still protected
6. Full cutover with rollback readiness
7. Post-cutover dual-read window for monitoring and rapid fallback

What to log during dual-retrieval

At minimum:

• query text and normalized form
• user segment / tenant / locale / product area
• applied filters
• retrieval profile version
• candidate IDs and ranks
• source-doc IDs and chunk IDs
• raw similarity scores and any normalized scores
• lexical scores if hybrid
• reranker scores
• selected context fed to generator
• answer output
• latency breakdown by stage
• cache hits and cache key version
• user actions and explicit feedback

Without this, postmortems become guesswork.

Protecting hybrid search during transitions

Hybrid search often becomes unstable during embedding migrations because teams only migrate the dense side.

A typical hybrid score might look like:

final_score = a * dense_score + b * bm25_score + c * reranker_score

The problem is that dense_score distributions change across embedding spaces. Reusing the old a and the old dense thresholds is a classic way to degrade retrieval.

Safer hybrid migration patterns

Normalize within profile

If you combine dense and lexical scores, calibrate or normalize scores per retrieval profile, not globally.

Options:

• min-max or z-score normalization on a sampled query set
• percentile-based mapping of dense scores to calibrated bands
• learning-to-rank or simple logistic calibration over relevance judgments

Percentile-based approaches are often more robust than pretending cosine scales are portable.

Refit hybrid weights

Do not inherit hybrid weights from the old profile. Refit them on a validation set and verify online.

Sometimes a stronger embedding model should actually reduce the lexical contribution. Sometimes a more semantic space needs stronger lexical anchoring for entity-heavy domains. There is no universal rule.

Re-check metadata filters and sparse recall

If chunking or preprocessing changes, BM25 indexing behavior changes too. Teams sometimes discover that their “embedding migration” regressions are partly due to sparse-side tokenization or field-weight changes.

Evaluate these cases explicitly:

• exact entity lookup n- version numbers and SKUs
• error codes
• table row retrieval
• section-title-heavy queries

Dense retrieval often underperforms sparse methods on these unless carefully supported.

Protecting caches during transitions

Caches can silently poison migrations.

In many RAG stacks, at least three caches exist:

• query-to-retrieval-result cache
• semantic cache for answer reuse
• context assembly/cache for chunk bundles or prompt snippets

If caches are not versioned by retrieval profile, you can serve stale contexts generated under the old space while thinking you are testing the new one.

Cache rules for migrations

1. Namespace every cache by retrieval profile version

   • profile_v1:query_hash
   • profile_v2:query_hash

2. Include filter state and authorization scope in keys

   • especially for multi-tenant systems

3. Separate semantic cache thresholds by profile

   • nearest-neighbor query similarity in embedding space is not portable across model versions

4. Expire or invalidate context bundles tied to old chunk IDs

   • chunk boundaries changed means prompt snippets may no longer align

5. Measure cache-hit quality, not just hit rate

   • during migration, a lower hit rate with correct version isolation is better than a high hit rate serving contaminated results

This is one of the least glamorous but highest leverage controls in a retrieval migration.

Implementation details that matter more than people expect

Stable canonical IDs

Every document needs a canonical source ID independent of retrieval profile. Without this, comparing old vs new is painful and often misleading.

Recommended ID hierarchy:

• source_id: stable business object or file
• source_version_id: content version or ingestion timestamp
• chunk_id: derived from source_version_id + retrieval_profile + ordinal

This lets you compute overlap and relevance at source and chunk levels.

Deterministic ingestion

If your ingestion pipeline is not deterministic, you will misattribute noise to model drift.

Pin:

• parser versions
• OCR configs
• boilerplate rules
• language detection versions
• sentence/section splitters
• metadata templates

Record the exact pipeline manifest with each index build.

Distribution monitoring for similarity scores

Because raw similarity numbers are not portable, monitor their distributions per profile.

Useful dashboards:

• top-1, top-k dense score histograms by query segment
• margin between rank 1 and rank 2 / rank k
• dense vs BM25 score correlation
• reranker uplift over retriever by profile
• no-context / low-confidence rate by profile

A migration that compresses dense score margins may require larger candidate pools or stronger reranking even if Recall@10 looks fine.

ANN parameter retuning

A new embedding space may require different ANN settings.

Examples:

• HNSW efSearch or graph construction params
• IVF cluster counts and probes
• PQ/OPQ compression settings
• candidate pool size before reranking

Do not assume the old index tuning transfers. Approximate search error can interact badly with changed neighborhood geometry. Some “model regressions” are really ANN recall regressions.

Candidate pool sizing

A better embedding model can paradoxically require a larger initial candidate set if it retrieves a broader semantic neighborhood that only the reranker can sort effectively.

Measure:

• Recall@k before rerank
• reranker rescue rate as candidate pool grows
• latency curve as candidate pool grows

A common migration win is moving from top-20 dense candidates to top-50 before rerank, accepting modest latency increase for much better tail reliability.

Model and tool tradeoffs

There is no universally best embedding model for production RAG. You are balancing retrieval behavior, operational complexity, and economics.

Comparing model choices

When evaluating models, compare on dimensions that matter in operations:

• relevance on your corpus and query distribution
• multilingual support
• robustness to OCR/text noise
• vector dimensionality and storage cost
• throughput and indexing speed
• query latency
• stability of score distributions
• support for domain-specific terms, codes, or identifiers
• provider reliability and versioning policy

A larger, more semantic model may improve paraphrase retrieval but hurt exact entity retrieval unless hybrid search is tuned well. A smaller model may be operationally easier and cheaper to reindex frequently. Self-hosted models can reduce marginal cost but often increase maintenance burden and consistency risk.

Reranker tradeoffs

A reranker is often the cheapest insurance policy against moderate embedding drift.

Pros:

• improves robustness across retriever changes
• can rescue noisy candidate sets
• provides a stable comparison layer between profiles

Cons:

• adds latency and cost
• can mask retriever failures until tail queries break
• may require larger candidate pools to be effective

If your product serves high-stakes answers, a strong reranker is usually worth it. But still evaluate retriever quality directly.

Hybrid search tradeoffs

Dense-only retrieval is attractive because it is simple. In many enterprise corpora, it is also insufficient.

Keep hybrid if you have:

• identifier-heavy queries
• exact policy titles or product names
• code, logs, error strings, SKUs, legal references
• rapidly changing terminology

Dense-only may work for broad semantic FAQ retrieval. It often struggles for mixed enterprise search.

Cost and latency tradeoffs during migration

Safe migrations cost more. The question is whether you pay in infrastructure or in incidents.

Main cost drivers

• dual index storage
• re-embedding full corpus
• shadow query execution
• extra reranking for side-by-side comparison
• duplicated cache footprint
• increased observability volume

Main latency risks

• online dual-retrieval in the request path
• larger candidate pools
• reranker passes for both profiles
• cache fragmentation reducing hit rates

Practical cost controls

1. Shadow selectively

   • mirror 100% of high-value or high-risk traffic, sample the rest

2. Asynchronous shadowing where possible

   • serve from active profile, run candidate profile out-of-band for telemetry if strict real-time comparison is not needed

3. Stage corpus reindexing

   • warm high-traffic tenants or namespaces first

4. Use source-level overlap checks before expensive full evals

   • quick way to identify dangerous segments early

5. Reserve expensive human review for disagreement cases

   • old wins, new wins, and large candidate-set divergence are the highest-yield samples

The cheapest migration is the one you do with enough instrumentation to avoid a week-long debugging fire.

Setting rollback gates that reflect reality

Rollback gates should not be based on one metric. They should reflect layered risk.

A practical gate stack looks like this.

Pre-launch gates

Before any user exposure, require:

• no severe regressions on gold-set critical slices
• acceptable shadow-traffic candidate-set stability on head queries
• hybrid calibration completed for the new profile
• cache namespace isolation verified
• ANN recall checked against exact search on a sample

Canary gates

During low-percentage rollout, require:

• retrieval success non-inferiority or improvement on monitored slices
• grounding metrics stable or improved
• no rise in unsupported claims
• no increase in corrective retries above threshold
• latency and error budgets within bounds

Business gates

For wider rollout, require:

• stable task completion / deflection / conversion proxies
• no significant degradation in high-value segments
• support ticket anomaly rate normal

Example rollback policy

Rollback automatically if any of these hold for a sustained interval:

• critical-slice retrieval success drops >3% absolute
• unsupported-claim rate rises >1.5% absolute
• corrective retry rate rises >5% relative
• high-value workflow completion drops >2% relative
• p95 latency exceeds budget by >15% due to retrieval-path changes

The exact numbers depend on your business, but the pattern matters: combine retrieval, grounding, and business signals.

A concrete migration playbook

Here is a pragmatic sequence that works well.

Step 1: Define the retrieval profile explicitly

Document every changed component:

• embedding model
• chunking rules
• preprocessing transforms
• ANN config
• hybrid formula
• reranker
• thresholds and gating

If more than one variable changes, note that diagnosis becomes harder. Sometimes it is still worth bundling them if the goal is a better holistic profile, but be aware of the tradeoff.

Step 2: Build a stratified evaluation set

Create gold, silver, and shadow sets. Weight business-critical slices heavily. Add recent incidents and tail queries manually.

Step 3: Reindex with dual-write support

Generate the new index while keeping old and new pipelines live for incremental updates. Preserve canonical source IDs.

Step 4: Run offline evaluation at multiple granularities

Measure:

• chunk-level and source-level retrieval
• pre-rerank and post-rerank metrics
• grounding metrics on representative answer tasks
• hybrid calibration candidates n- score and margin distributions

Step 5: Shadow production traffic

Compare old vs new on live queries without user impact. Inspect disagreement clusters, not just summary averages.

Look specifically for:

• exact-entity lookup failures
• freshness regressions
• filter leakage or over-restriction
• noisy broad chunks replacing exact procedure chunks
• cache contamination

Step 6: Calibrate hybrid and thresholds for the new profile

Retune dense/lexical mixing, candidate pool size, reranker cutoffs, no-answer thresholds, and semantic cache thresholds.

Step 7: Canary with rollback automation

Start with low-risk traffic or internal users. Use predeclared rollback gates. Do not negotiate with the dashboard mid-incident.

Step 8: Maintain a post-cutover observation window

Keep dual-read or at least shadow comparison alive for a fixed period. Many regressions appear only as content freshness, corpus composition, or traffic patterns evolve.

Common anti-patterns

These show up repeatedly.

“The offline metric improved, so ship it”

Aggregate gains hide operational regressions.

“We only changed chunk size”

That is a retrieval-unit migration, not a cosmetic tweak.

“The reranker will fix it”

Sometimes it will. Often it will hide issues until edge cases matter most.

“Cosine > 0.85 means good across both models”

Similarity thresholds are profile-specific.

“Cache keys don’t need versioning”

They absolutely do.

“We can always roll back by switching the query model”

Not if the corpus was re-chunked, caches are contaminated, or freshness diverged between indexes.

“We’ll diagnose after rollout using thumbs-downs”

By then you are already paying user trust costs.

The big takeaway

Embedding space drift is not a niche modeling concern. In production RAG, it is an operational reliability problem.

The robust response is not to avoid change. It is to make retrieval-path changes observable, comparable, and reversible.

That means:

• version the whole retrieval path, not just the embedding model
• evaluate behavior, not raw similarity scores
• compare at chunk and source levels
• use dual-write and dual-retrieval for migrations
• recalibrate hybrid search, thresholds, and caches per profile
• set rollback gates using retrieval, grounding, and business outcomes together

If you do this well, you can upgrade embeddings, chunking, and preprocessing with confidence instead of superstition. You will still see drift. But drift will become something you detect and contain early, not something users discover for you on Friday morning.

That is the real production milestone for RAG: not reaching a permanently “best” embedding setup, but building a system that can change without losing its footing.