blog.ruahverce Vol · 2026 · Issue 013 — A field log of LLMs, RAG, and ML systems

Field Log · Entry

RAG Embedding·Index Migration: Dual Write·Shadow Read·무중단 전환 (7/10)

기존 active와 새 candidate index에 snapshot backfill·delta·shadow read를 적용한 뒤 release gate, atomic alias 전환과 rollback을 수행하는 RAG migration

오늘의 결론

  • Embedding model을 바꾸는 일은 API model 이름 하나를 수정하는 배포가 아닙니다. 문서·query가 공유하는 vector space, dimension, normalization, metric, chunk identity와 index generation을 함께 교체하는 data migration입니다.
  • 기존 index를 제자리에서 덮어쓰지 않습니다. Immutable canonical snapshot으로 새 candidate generation을 만들고, backfill 중 발생한 변경은 delta stream으로 따라잡습니다.
  • Dual write는 데이터 동기화 수단이고 shadow read는 검색 동작 비교 수단입니다. 둘을 같은 말로 쓰지 않습니다.
  • Offline Recall만 좋아졌다고 전환하지 않습니다. Coverage·ACL·deletion parity, query cohort별 retrieval 품질, p99 latency, empty result와 비용을 release gate로 봅니다.
  • Cutover는 논리 alias·routing pointer를 atomic하게 바꾸고, old generation과 old query encoder를 일정 기간 보존해 즉시 rollback할 수 있게 합니다.

앞 글에서는 source change를 sequence와 snapshot으로 관리했습니다. 그 기반이 있어야 migration 시작 시점 이후의 update·delete·ACL 변경을 놓치지 않고 새 index가 현재 상태를 따라잡을 수 있습니다.

freeze migration contract
  → create isolated candidate generation
  → backfill canonical snapshot
  → replay delta changes / dual write
  → shadow-read real queries
  → quality, security, latency gates
  → atomic read alias cutover
  → watch, rollback, retire safely

기존 active와 새 candidate vector index에 snapshot backfill과 delta change를 반영하고 shadow read로 결과를 비교한 뒤 atomic alias를 전환하며 이전 generation으로 rollback 가능한 RAG migration

먼저 답하기: 새 embedding을 기존 vector field에 덮어쓰면 왜 안 되는가?

Model A의 vector와 Model B의 vector는 같은 길이라도 같은 좌표계를 공유한다는 보장이 없습니다.

doc vector = embed_B(document)
query vector = embed_A(query)
similarity(doc, query)  # 의미 없는 비교가 될 수 있음

Dimension이 다르면 storage 자체가 거부할 수 있고, 같아도 normalization·distance metric·prompt prefix가 달라질 수 있습니다. Migration 중 일부 document만 B라면 한 index 안에 서로 다른 vector space가 섞입니다.

따라서 query encoder와 document index를 하나의 호환 단위로 versioning합니다.

이 글의 대상과 학습 시간

  • 대상: 운영 중인 vector search의 model·chunking·index를 바꾸려는 초·중급 개발자
  • 선수 지식: embedding, ANN, canonical document snapshot과 CDC
  • 빠르게 읽기: 약 12분
  • 전환 설계까지 이해하기: 약 35분
  • 실제 rehearsal 포함: 약 2시간 이상

1. 무엇이 바뀌는지 migration class를 분류한다

모든 변경이 같은 backfill을 요구하지는 않습니다.

변경Document 재처리Query 변경새 index 권장
Metadata filter field 추가경우에 따라filter logic대개 권장
Analyzer·BM25 설정lexical reindexanalyzer권장
ANN parameter 일부engine별없음rebuild 여부 확인
Distance metricvector 재사용 가능성 있음scoring강력 권장
Embedding dimension재embedding새 encoder필수
Embedding model재embedding새 encoder필수
Normalization 변경재계산동일 규칙필수에 가까움
Chunking 변경reparse·rechunk없음필수
Parser·OCR 변경reparse·rechunk없음권장
ACL projection 변경metadata rebuildfilter권장

Vendor가 in-place setting update를 지원하더라도 rollback·비교·partial failure 요구를 보면 별도 generation이 더 안전한 경우가 많습니다.

2. Retrieval generation을 완전한 계약으로 표현한다

embedding_model=v2만 저장하지 않습니다.

{
  "generation_id": "rag-index-2026-07-16-g2",
  "canonical_snapshot_id": "kb-snap-8842",
  "source_high_watermarks": {
    "dms": "seq-99142",
    "wiki": "cursor-22018"
  },
  "parser_revision": "parser-3.2",
  "chunking": {
    "algorithm": "layout-semantic-v4",
    "max_tokens": 420,
    "overlap_tokens": 40
  },
  "embedding": {
    "provider": "internal",
    "model": "embed-ko-v7",
    "revision": "sha256:...",
    "dimension": 1024,
    "document_prefix": "passage: ",
    "query_prefix": "query: ",
    "normalize": "l2"
  },
  "index": {
    "engine": "example-ann",
    "distance": "cosine",
    "algorithm": "hnsw",
    "build_params": {"m": 32, "ef_construction": 200}
  },
  "metadata_schema_revision": "meta-6",
  "acl_policy_revision": "acl-policy-184"
}

숫자는 예시입니다. 이 manifest가 document encoder, query service, evaluation report와 active alias를 연결합니다.

3. 호환성 matrix를 먼저 만든다

Migration 중 다음 조합이 동시에 존재합니다.

Query encoderIndex generation호환설명
AG1(A)예기존 production
BG2(B)예candidate
AG2(B)아니오vector space mismatch
BG1(A)아니오vector space mismatch

API routing은 반드시 encoder와 index를 같은 generation으로 묶습니다.

def search(query, generation):
    contract = registry.get(generation)
    qvec = encoder_pool[contract.embedding_revision].encode_query(query)
    return index_pool[contract.index_name].search(qvec)

Active index alias만 바꾸고 query encoder 배포가 늦으면 mismatch가 생깁니다. 하나의 release pointer가 두 자원을 함께 선택하게 하거나, generation header로 일관된 routing을 합니다.

4. Stable identity가 migration 비교를 가능하게 한다

73번 글의 stable ID가 여기서 필요합니다.

document_id   = source-independent business resource
version_id    = source revision
chunk_id      = version + structural span + chunking revision
generation_id = retrieval representation contract

Chunking이 바뀌면 chunk ID도 바뀔 수 있습니다. Old와 new result를 chunk ID exact match만으로 비교하면 모두 다르다고 나옵니다.

비교 단위를 계층화합니다.

  • Exact chunk match
  • Same document match
  • Same source span overlap
  • Same canonical entity·section match
  • Human relevance label match

5. 제자리 변경 대신 candidate index를 만든다

read alias: rag-search → G1

G1 active: immutable serving baseline
G2 candidate: isolated build and test

Candidate를 분리하면 다음이 가능합니다.

  • Backfill을 production query와 격리
  • Schema와 dimension을 독립 생성
  • 여러 번 삭제·재build
  • Shadow traffic만 허용
  • Cutover 전 접근 제어
  • 즉시 G1 rollback

Name에 의미 없는 new, final2를 쓰지 않고 immutable generation ID를 사용합니다.

6. Migration 시작점과 cutoff를 기록한다

Backfill 시작 시 canonical snapshot과 source high-watermark를 고정합니다.

T0:
  snapshot_id = S8842
  dms_sequence = 99142
  wiki_cursor = 22018

G2 backfill은 S8842를 읽고, T0 뒤 변경은 delta stream에서 처리합니다.

G2 state = backfill(S8842) + replay(changes after high-watermarks)

이 경계가 없으면 backfill 중 수정된 문서가 어느 version으로 들어갔는지 알기 어렵습니다.

7. Backfill plan을 shard와 work unit으로 나눈다

전체 corpus를 한 job으로 돌리지 않습니다.

{
  "migration_id": "mig-g1-g2",
  "partition_id": "tenant_fab_a/0042",
  "snapshot_id": "kb-snap-8842",
  "range": {"document_id_from": "doc_40000", "to": "doc_40999"},
  "expected_documents": 982,
  "status": "running",
  "attempt": 2,
  "last_checkpoint": "doc_40491"
}

Work unit은 다음을 고려합니다.

  • Tenant와 ACL boundary
  • Source·file type
  • Page·token·byte cost
  • Embedding provider quota
  • Index shard distribution
  • Retry와 resume granularity

각 partition에 expected, succeeded, skipped, quarantined와 failed count를 둡니다.

8. Backfill은 production resource budget 안에서 실행한다

Embedding migration은 CPU·GPU, network, storage와 index merge를 동시에 사용합니다.

Resource guard

  • Embedding tokens/sec cap
  • Concurrent parser jobs
  • Index write throughput cap
  • Search p99 latency guard
  • Storage high-watermark
  • Provider rate limit
  • Tenant별 fair share

Stop condition

if production_search_p99 > latency_guard
or index_cluster_disk > disk_guard
or error_budget_burn > threshold:
  pause low-priority backfill

Threshold는 환경에서 정한 예시값입니다. ACL revoke와 deletion lane은 migration보다 우선합니다.

9. Reindex API와 재embedding을 구분한다

Search engine의 reindex API는 source index document를 destination index로 복사·변환하는 데 유용합니다. OpenSearch 공식 문서는 source와 destination index를 지정해 reindex하고 query, script, slicing과 throttling 등을 설정하는 API를 제공합니다.

하지만 embedding model이 바뀌면 기존 vector를 단순 복사할 수 없습니다.

engine reindex:
  copy existing fields / mappings / selected documents

embedding migration:
  canonical text → new document encoder → new vector

Canonical text와 source span을 다시 읽어 새 vector를 계산합니다. Index 안에 저장된 잘린 text가 정본이 되지 않게 합니다.

10. Dual write와 delta replay를 선택한다

Dual write

새 change가 들어오면 G1·G2 양쪽 representation을 갱신합니다.

change event
  ├─ pipeline contract G1 → index G1
  └─ pipeline contract G2 → index G2

장점:

  • Candidate가 빠르게 현재 상태를 따라갑니다.
  • Cutover 전 parity를 관찰하기 쉽습니다.

비용:

  • 두 parser·encoder를 동시에 운영
  • Partial success와 retry 복잡도
  • Delete·ACL을 양쪽에 적용해야 함
  • Provider 비용 증가

Single durable log + independent consumers

하나의 change log를 G1·G2 consumer가 각자 읽습니다.

장점:

  • Source write path를 두 destination에 동기 결합하지 않습니다.
  • Consumer별 replay와 offset 관리가 쉽습니다.
  • G2 실패가 G1 serving write를 막지 않습니다.

대부분 이 구조가 더 안전한 시작점입니다.

Delta replay

Backfill 완료 후 T0 이후 event를 high-watermark까지 재생합니다. Cutover 직전 G2 lag가 허용 범위인지 확인합니다.

11. Dual write의 partial failure를 숨기지 않는다

G1 write success
G2 write failure

전체 request를 무조건 실패시키면 production이 불안정해지고, 무시하면 candidate parity가 깨집니다.

Migration write ledger를 둡니다.

{
  "event_id": "evt-99143",
  "resource_id": "doc_0194",
  "g1": {"status": "applied", "sequence": 99143},
  "g2": {"status": "retry", "attempt": 2},
  "operation": "upsert",
  "updated_at": "2026-07-16T02:10:00Z"
}

Parity dashboard는 G2 lag, failed event age와 delete·ACL mismatch를 보여 줍니다.

12. Shadow read는 사용자 응답을 바꾸지 않는다

Production query 일부를 복제해 G2에서도 실행하되 응답은 G1 결과로 만듭니다.

user query
  ├─ primary: encoder A → G1 → user response
  └─ shadow:  encoder B → G2 → comparison store

필수 조건:

  • Shadow path 실패가 primary latency를 늘리지 않음
  • Query·principal·tenant handling이 privacy policy를 만족
  • G2에도 같은 ACL filter 적용
  • Shadow result가 cache나 user response에 섞이지 않음
  • Sampling rate와 budget 제한

Shadow query를 비동기 queue로 보내면 primary와 느슨하게 분리할 수 있습니다. 다만 auth context freshness와 query timestamp를 보존합니다.

13. 결과 비교를 한 숫자로 줄이지 않는다

Coverage parity

document coverage = active documents represented / expected active documents
chunk coverage
ACL projection parity
delete parity
source sequence lag

Retrieval overlap

Jaccard@k = |docs_G1 ∩ docs_G2| / |docs_G1 ∪ docs_G2|

Overlap이 낮다고 G2가 나쁜 것은 아닙니다. 더 좋은 문서를 찾았을 수 있습니다.

Labeled quality

  • Recall@k
  • MRR·nDCG
  • Source span relevance
  • Answer groundedness·citation correctness
  • Empty-result rate

Operational

  • Query embedding p50·p95·p99
  • Search latency by filter selectivity
  • Index memory·disk
  • Cost per 1,000 queries
  • Timeout·error rate

Cohort

  • Korean·English·mixed query
  • Acronym·part number
  • Short vs long query
  • Tenant·group·ACL selectivity
  • PDF table·OCR document
  • Recent vs historical document
  • Head vs tail entity

전체 평균이 좋아도 특정 tenant나 숫자 query가 크게 나빠질 수 있습니다.

14. Shadow diff를 설명 가능한 record로 남긴다

{
  "query_id": "q-hmac-...",
  "query_cohort": ["ko", "part-number"],
  "auth_fingerprint": "ent-204",
  "g1": {
    "generation": "g1",
    "document_ids": ["d7", "d3", "d9"],
    "latency_ms": 41
  },
  "g2": {
    "generation": "g2",
    "document_ids": ["d7", "d12", "d3"],
    "latency_ms": 49
  },
  "overlap_at_3": 0.5,
  "gold_relevant": ["d7", "d12"],
  "policy_revision": "p-184"
}

민감 query 원문은 기본 저장하지 않고 HMAC ID와 consent·retention 정책을 적용합니다. Human review sample에는 별도 보호 경계를 둡니다.

15. Release gate를 사전에 고정한다

전환 직전에 기준을 바꾸지 않습니다.

candidate: g2
required:
  document_coverage: "target agreed with source inventory"
  acl_mismatch_count: 0
  deletion_mismatch_count: 0
  source_lag: "within freshness SLO"
  recall_at_20: "no unacceptable cohort regression"
  p99_latency: "within serving SLO"
  error_rate: "within error budget"
  rollback_rehearsal: passed

Threshold는 조직과 dataset에서 정합니다. 0이어야 하는 security invariant와 통계적으로 비교할 quality metric을 구분합니다.

16. Canary read로 사용자 영향 범위를 제한한다

Shadow에서 통과하면 일부 실제 request의 primary를 G2로 보냅니다.

Canary cohort 선택

  • 내부 직원 tenant
  • Non-critical use case
  • 명시적 beta group
  • 특정 query type
  • 작은 traffic percentage

Sticky routing

Session 중 G1·G2가 계속 바뀌면 비교와 user experience가 혼란스러워집니다.

generation = hash(tenant_id, principal_id, experiment_id) % 100

Routing은 ACL을 약화하지 않으며, 각 generation에 맞는 query encoder를 선택해야 합니다.

17. Atomic cutover는 read pointer를 바꾸는 일이다

Application code에 physical index name을 박지 않습니다.

logical name: rag-search-active
before: rag-search-active → G1
after:  rag-search-active → G2

Elasticsearch 공식 문서는 alias가 application이 쓰는 index를 실시간으로 바꿀 수 있고, 여러 alias action을 단일 atomic operation으로 수행해 downtime 없이 swap할 수 있다고 설명합니다. Qdrant도 collection alias를 통해 application이 collection 이름을 바꾸지 않고 전환하는 패턴을 제공합니다. 정확한 atomicity와 failure semantics는 사용하는 engine version에서 확인합니다.

Encoder와 index pointer를 함께 바꾼다

Registry record 예시:

{
  "route": "rag-search-active",
  "generation": "g2",
  "query_encoder_revision": "embed-ko-v7",
  "physical_index": "rag-docs-g2",
  "activated_at": "2026-07-16T03:00:00Z",
  "previous_generation": "g1"
}

Query worker가 이 record를 일관되게 읽고, stale local cache의 최대 age를 제한합니다.

18. Cutover 전에 write lag를 닫는다

Cutover checklist:

  1. Backfill partition 완료
  2. Quarantine 승인 또는 명시적 제외
  3. Delta consumer high-watermark 도달
  4. ACL·delete parity 0 mismatch
  5. Candidate index refresh·replica healthy
  6. Query encoder warm-up
  7. Cache namespace 준비
  8. Rollback command와 approver 대기
  9. Dashboard와 synthetic probe 활성

Cutover 몇 분 전 source write를 완전히 멈출 필요는 없지만, delta lag와 atomic routing을 설명할 수 있어야 합니다.

19. Cache namespace를 generation으로 분리한다

query_embedding_cache_key = (encoder_revision, normalized_query)
retrieval_cache_key = (generation_id, auth_fingerprint, query_hash)
answer_cache_key = (generation_id, model_revision, context_ids, prompt_revision)

G1 query vector를 G2에 쓰거나 G1 result cache를 G2 experiment로 재사용하면 평가가 오염됩니다. Cutover 시 cache를 모두 지울 필요는 없지만 generation namespace를 분리합니다.

20. Rollback은 old alias로 돌아가는 것 이상이다

유지할 것

  • G1 physical index
  • G1 query encoder artifact와 runtime
  • G1 manifest
  • T0 이후 G1 change consumer
  • G1 cache namespace 또는 재생성 방법
  • Rollback command와 권한

Rollback trigger 예시

  • Security parity violation 1건
  • p99 latency SLO breach
  • 특정 critical cohort의 relevance regression
  • Empty result 급증
  • G2 error budget burn
  • Source delta lag 증가

Rollback 후

G2에서만 발생한 새로운 change가 G1에도 반영됐는지 확인합니다. Cutover 뒤 G1 write를 바로 중단했다면 rollback 시 state가 오래됐을 수 있습니다.

따라서 soak 기간 동안 양쪽 change consumer를 유지하거나, rollback 전에 missing delta를 replay합니다.

21. Dual 운영을 무기한 유지하지 않는다

두 generation을 오래 유지하면 비용과 실수가 늘어납니다.

Retirement criteria:

  • G2 soak period 통과
  • No rollback trigger
  • Evaluation·incident sign-off
  • G1 retention deadline 도달
  • G1 snapshot·manifest 보존 확인
  • Cache TTL 만료
  • Old encoder consumer와 secret 정리
  • Physical index deletion approval

Retire event도 audit log에 남깁니다.

22. 흔한 실패 패턴

실패 1. Dimension만 맞으면 compatible하다고 가정

같은 768차원이라도 model space는 다를 수 있습니다.

실패 2. Production index에 batch overwrite

Partial mixed space와 rollback 불가 상태를 만듭니다.

실패 3. Backfill 완료율만 확인

Delete, ACL, source sequence와 quarantined document를 놓칩니다.

실패 4. Shadow에서 ACL을 생략

품질 비교가 production candidate set과 달라지고 민감 문서가 comparison store에 들어갑니다.

실패 5. Alias만 바꾸고 query encoder는 별도 배포

짧은 시간이라도 incompatible 조합이 생깁니다.

실패 6. Cutover 직후 old index 삭제

Regression을 발견해도 즉시 rollback할 수 없습니다.

실패 7. New model score threshold를 old 값 그대로 사용

Similarity score distribution은 model·normalization·metric마다 달라집니다. Abstention·routing threshold를 다시 calibration합니다.

23. 가상 반도체 RAG migration 예시

다음은 설명을 위한 가상 예시입니다.

변경

  • G1: 768차원 multilingual embedding, fixed 500-token chunk
  • G2: 1024차원 Korean-domain embedding, layout-aware 420-token chunk
  • 목표: 장비 코드와 표 기반 query retrieval 개선

Migration

  1. Canonical snapshot S8842와 source cutoff를 고정합니다.
  2. rag-docs-g2를 새 dimension·metric으로 만듭니다.
  3. Tenant·file type partition별 backfill을 실행합니다.
  4. T0 뒤 update·delete·ACL event를 G1·G2 consumer가 처리합니다.
  5. Production query 5%를 비동기 shadow합니다. [예시값]
  6. Document·source span overlap과 gold Recall@20을 query cohort별 비교합니다.
  7. part-number + table cohort가 좋아져도 long natural-language cohort regression을 확인합니다.
  8. Canary tenant를 G2 primary로 보내고 p99·empty result·citation accuracy를 봅니다.
  9. Registry pointer를 G1→G2로 바꿉니다.
  10. Soak 기간 동안 G1 consumer와 rollback route를 유지합니다.

반드시 0이어야 할 것

  • Cross-tenant result
  • ACL projection mismatch
  • Deleted resource visibility
  • Mixed encoder/index generation request

24. 구현 순서

1단계. Migration contract

Source snapshot, parser, chunker, embedding, dimension, prefix, normalization, metric, index와 ACL revision을 manifest로 고정합니다.

2단계. Candidate infrastructure

Physical index, query encoder runtime, registry와 별도 cache namespace를 만듭니다.

3단계. Partitioned backfill

Checkpoint, throttling, quarantine과 expected count를 가진 job으로 실행합니다.

4단계. Delta convergence

Durable change log의 independent consumer로 update·delete·ACL을 따라잡습니다.

5단계. Offline·shadow evaluation

Coverage, security parity, cohort quality와 latency를 비교합니다.

6단계. Canary

작은 cohort를 sticky routing으로 G2 primary에 보내고 SLO를 봅니다.

7단계. Atomic cutover

Encoder와 physical index를 포함하는 logical generation pointer를 바꿉니다.

8단계. Soak·rollback·retire

Trigger와 retention을 지키고 old generation을 승인 후 제거합니다.

실전 체크리스트

  • 변경이 metadata, analyzer, chunking, embedding, metric 중 어디에 해당하는지 분류했다.
  • Retrieval generation manifest가 document·query encoder와 index를 함께 묶는다.
  • Compatible encoder-index matrix가 코드로 강제된다.
  • Stable document·version·source span identity가 있다.
  • Production physical index를 제자리 덮어쓰지 않는다.
  • Candidate generation이 serving traffic에서 격리돼 있다.
  • Backfill snapshot과 source high-watermark를 기록했다.
  • Backfill이 partition·checkpoint·resume를 지원한다.
  • Production latency와 resource guard가 있다.
  • New embedding은 canonical text에서 다시 계산한다.
  • T0 이후 update·delete·ACL delta가 candidate에 반영된다.
  • Dual write partial failure ledger와 retry가 있다.
  • Shadow read가 primary latency와 response를 바꾸지 않는다.
  • Shadow path에도 동일한 tenant·ACL filter가 있다.
  • Quality를 전체 평균이 아닌 query cohort별로 본다.
  • Coverage·ACL·delete parity가 release gate에 있다.
  • Score threshold와 abstention을 새 space에서 재보정했다.
  • Canary routing이 sticky하고 encoder-index 일관성이 있다.
  • Read alias 또는 registry pointer 전환이 atomic하다.
  • Cache key에 generation과 encoder revision이 포함된다.
  • Old index와 encoder가 rollback 기간 동안 최신 state를 유지한다.
  • Rollback을 실제 rehearsal했다.
  • Retirement criteria와 deletion approval가 있다.

스스로 확인하기

Q1. Model dimension이 같으면 한 index에 old·new vector를 섞어도 되는가?

아닙니다. Dimension 일치는 storage shape만 뜻합니다. Coordinate space, normalization, training objective와 prefix가 다를 수 있습니다.

Q2. Reindex API로 embedding migration을 끝낼 수 있는가?

기존 vector를 새 index로 복사하는 데는 쓸 수 있지만 model이 바뀌면 canonical text를 새 encoder로 다시 계산해야 합니다. Engine-side inference 기능을 쓰더라도 model revision과 result manifest를 고정합니다.

Q3. Dual write를 하면 backfill이 필요 없는가?

아닙니다. Dual write는 migration 시작 이후 변경만 다룹니다. 기존 corpus는 snapshot backfill이 필요합니다.

Q4. Shadow result overlap이 낮으면 migration을 중단해야 하는가?

곧바로 그렇지는 않습니다. Chunking과 model이 바뀌면 result가 달라지는 것이 목적일 수 있습니다. Gold relevance, source span과 answer citation 품질을 함께 봅니다.

Q5. Alias swap이 atomic하면 전체 release도 atomic한가?

Index pointer만 atomic할 수 있습니다. Query encoder, registry cache, application instance와 answer cache가 같은 generation을 쓰는지 별도 보장이 필요합니다.

Q6. Cutover 후 old index는 언제 삭제하는가?

Soak 기간, rollback rehearsal, retention, delta parity와 incident sign-off를 통과한 뒤 제거합니다. 비용만 보고 즉시 삭제하지 않습니다.

마무리

Embedding migration의 핵심은 새 model을 호출하는 코드보다 두 retrieval generation을 안전하게 비교하고 전환하는 운영 프로토콜입니다.

complete generation contract
  + immutable candidate index
  + snapshot backfill and delta convergence
  + ACL-aware shadow evaluation
  + atomic encoder-index cutover
  + rehearsed rollback and retirement
  = zero-downtime RAG migration

다음 글 RAG Data Quality·Drift·Observability에서는 parser·metadata·embedding·index의 품질 신호를 lineage와 trace에 연결하고, drift와 silent partial failure를 release 전에 찾는 방법을 다룹니다.

참고문헌

검증 메모 — 공식 문서는 2026년 7월 16일 확인했습니다. Alias atomicity, reindex, vector dimension·metric 변경 가능 범위와 consistency는 engine·deployment version마다 다릅니다. 본문의 model, dimension, parameter, traffic 비율과 threshold는 가상 예시입니다. 실제 migration 전 staging에서 snapshot cutoff, duplicate·out-of-order delta, partial dual-write failure, ACL·delete parity, encoder-index mismatch, cache namespace, alias failure와 rollback을 fault injection으로 반복 검증해야 합니다.