How would you change the parser and embedding model without breaking search?

I would start by refusing to treat this as an index alias change. There are at least four things changing together: extracted text, chunk identity, embeddings, and the mapping from an answer citation back to a source. Switching only the vector index can leave the lexical index, reranker, or citation resolver on the old generation.

The stable thing is the source document and its version. A chunk ID is an artifact of a parser and chunking policy. If the new parser splits page 12 into three chunks where the old parser had one, those IDs will not line up and should not be forced to. Each generation needs a manifest that says which source snapshot, parser, chunker, embedding model, lexical schema, and citation format produced it.

“Your chunk IDs changed. How do you compare citations?” I would compare source document versions and evidence spans, not chunk IDs. A citation should resolve to a stable source identity and a versioned location or excerpt. The renderer can show that the cited version is superseded or deleted, with a fresh authorization check. It must not silently map an old chunk offset onto different new text.

I would take a consistent source snapshot or record a source change position, then build the new generation from the original documents. Reindexing old chunks alone cannot repair text the old parser missed, and reusing old embeddings across a different model space is not meaningful. During the twelve hour build, the ingestion stream keeps a durable record of additions, edits, deletes, and permission changes. The new generation replays content changes until it is close enough to current traffic to satisfy the freshness objective. A delete carries a versioned tombstone. A late event must never resurrect an older document.

The old generation remains live and receives changes too. Otherwise rollback would take us to a search system that froze twelve hours ago. The policy path for authorization remains current in either generation. Search freshness can lag under a defined objective. A revoked permission cannot wait for the index rebuild.

At query time I would route one request to one versioned search configuration. That configuration includes the query embedding model, vector index, lexical index, rank fusion settings, reranker if its input contract changed, context selection policy, and citation resolver. Mixing an old query embedding with new document embeddings is invalid. Mixing old and new chunks in one answer can also produce duplicate or contradictory evidence unless that is an intentional experiment with explicit source deduplication.

The new path runs in shadow first. For the same permitted query and source snapshot, compare not only recall but the rank of authoritative evidence, version correctness, citation spans, answer support, unanswerable behavior, latency, and cost. Shadow traffic should not issue writes or expose unreviewed answers to users. I would include messy queries with exact identifiers, old product names, OCR documents, tenants with unusual permissions, and documents that changed during the build.

Then canary by tenant and query class, keeping an old generation control group. Roll out only when the new generation has caught up to its content watermark, its permission path is safe, and the answer level slices are acceptable. Route and cache keys must carry the generation. Otherwise a cached candidate list or final answer can make the cutover look random.

Then the new index is twelve hours old but the build says complete. I would not switch merely because the backfill job exited successfully. I want its change log catchup position, deletion parity, per tenant coverage, and source version distribution. A build can have 300 million entries and still be wrong on the one million most recent changes.

Finally, suppose we canary and need to roll back. The route returns to the old complete generation. The old ingestion pipeline, authorization path, and citation resolver must still be operating. Keep them through a measured rollback window. If a source schema change made the old pipeline unable to process new documents, rollback is not actually available and the migration plan needs another path before launch.

This is why an atomic index alias swap helps but is only one piece. Elastic documents atomic alias actions for its own indexes. It cannot atomically swap the parser, embedding query function, external vector store, caches, and citation semantics in an application. The application needs its own generation boundary.

References: Elastic index aliases, Elastic reindexing. The multi-store generation design is the answer proposed for this scenario.