Bedrock Embedding Migration: What Must Be Rebuilt?

Decide when a Bedrock embedding change needs new document vectors, a rebuilt index or a matched query route, with a worked compatibility example.

When an embedding model changes, review the document vectors, query encoder and retrieval index as a matched generation. Matching vector dimensions does not establish semantic compatibility. Unless the proposed encoders are demonstrably compatible, plan to regenerate the affected document embeddings and keep the candidate generation separate while evaluating it.

An answer-generation model change can leave retrieval untouched. An embedding-model change reaches into stored retrieval state. This includes version changes within one provider: a shared model-family name does not establish compatibility with existing vectors. Moving only the query call to a new endpoint can therefore produce valid requests and plausible but wrong matches.

This article helps a retrieval owner choose the scope of that change before implementing a migration. It uses Amazon Bedrock documentation and a constructed numerical example. The example is not output from Titan or an AWS evaluation.

What Bedrock changes, and what the vector store still does

An embedding model converts input text into a numerical representation. The vector store compares those representations and retrieves candidates. AWS explicitly separates these responsibilities in its Titan embedding overview. Calling a new embedding model does not rewrite vectors already stored in a database.

For a concrete documentary candidate, consider Titan Text Embeddings V2, model ID amazon.titan-embed-text-v2:0, through Bedrock Runtime InvokeModel in us-east-1. The model card lists that API, endpoint and Region combination. The endpoint is https://bedrock-runtime.us-east-1.amazonaws.com. This is a documented route, not confirmation of access, quota or permission in a particular account.

The V2 request section of AWS's embedding parameter reference documents dimensions, normalization and embedding type. The page heading mentions G1; use its V2 Request subsection for this model. The following is an illustrative request body for direct model invocation, not a complete SDK call:

{
  "inputText": "Exports are disabled while a tenant is suspended.",
  "dimensions": 512,
  "normalize": true,
  "embeddingTypes": ["float"]
}

Pin those choices rather than relying on defaults. Apply the chosen model's documented query and document encoding rules. For example, the AWS Cohere Embed v3 reference distinguishes search_document from search_query inputs. Those are not Titan request parameters. Compatibility means the intended pairing, not necessarily identical preprocessing.

The surrounding retrieval contract also includes the distance metric, vector data type, index configuration and text preparation. A response with the expected array length establishes only one structural property. It does not establish useful neighbors, preserved permissions or adequate answer evidence.

Same dimensions can still produce the wrong neighbor

Consider a fictional corpus containing two passages:

• Relevant passage R: “Exports are disabled while a tenant is suspended.”
• Distractor D: “Active tenants may export their records.”

The query is: “Can a suspended tenant export records?” The expected evidence is R. D is superficially related but describes a different tenant state.

Construct two two-dimensional embedding spaces, U and V. All vectors below have unit length. V is U rotated by a right angle, so each space preserves the same internal relationships. These coordinates are stipulated teaching inputs, not learned embeddings or provider results. Query and R have identical coordinates solely to simplify the counterexample; real relevant passages need not share their query's vector.

For unit vectors, cosine similarity is their dot product. Within U, the query scores R at 1 and D at 0. Within V, it also scores R at 1 and D at 0.

Now change only the query encoder to V while keeping U's document vectors. The new query scores old R at 0 and old D at 1. The wrong passage ranks first even though every vector has two dimensions and the arithmetic is well defined.

Equal dimensions do not prove compatible representations. Each matched toy space ranks the relevant passage first. Mixing the V query with U documents reverses the scores and ranks the distractor first. These are constructed vectors, not Titan output.

This counterexample establishes why dimension equality cannot prove compatibility. It does not predict how two real models will differ. The 512-dimensional Titan request above is independent of these two-dimensional teaching coordinates.

Do not repair this mismatch by copying a score threshold from the old route. Nor should a reranker be assumed to recover R if the first retrieval stage has excluded it. Test candidate evidence before judging a fluent generated answer.

Decide what actually needs rebuilding

Re-embedding documents and rebuilding a search index are different operations. A new index over unchanged, compatible vectors may not require another model call. A new embedding representation generally requires generating the corresponding document vectors, not merely recreating the old index structure.

Use the changed contract to choose the work:

Check the candidate's input limits before carrying the existing chunking recipe forward. If chunks do not fit, revise or hold the text-preparation plan rather than allow unnoticed truncation; record changed source spans and evaluate the evidence the new chunks retain.

A normalization-only change needs a more specific check. For nonzero vectors, positive rescaling of either vector cancels in mathematical cosine similarity, even if only the query or document side is rescaled. For dot product, positive query-only scaling multiplies every candidate score equally: ordering stays the same, although an absolute score cutoff can behave differently. Unit-normalizing each document can change dot-product ordering because documents with different lengths receive different scaling factors.

For a separate stipulated example, let q = (1, 0), R = (1, 0) and D = (2, 2). Under raw dot product, R scores 1 and D scores 2, so D ranks first. After unit-normalizing the documents, R scores 1 and D scores 1 divided by the square root of 2, approximately 0.7071, so R ranks first. Mathematical cosine gives 1 for R and approximately 0.7071 for D both before and after document normalization. These are constructed coordinates and derived arithmetic, not provider results.

Review what actually changes: the query, documents, metric or score cutoff. A normalization flag alone does not establish incompatibility or require re-embedding. Quantization, finite-precision behavior and the store's handling of zero vectors still need separate contract checks; mathematical cosine is undefined for a zero vector.

Separate logical generations, not necessarily physical databases. An independent index, collection, namespace or vector field might provide the required separation, depending on the store. Verify the chosen mechanism rather than assuming a namespace is an authorization boundary.

For the wider store-migration procedure, use the vector database selection playbook. The decision here is whether stored representations remain usable and which generation a query may address.

Knowledge Bases adds a resource-configuration boundary

If the application invokes an embedding model and owns its retrieval store, the team controls how the new representation is built and routed. Bedrock Knowledge Bases is a different arrangement: ingestion, embedding configuration and storage mappings are attached to service resources.

The UpdateKnowledgeBase API permits changes to name, description and role ARN, but says the knowledge-base and storage configurations must remain the same. For a vector knowledge base, the embedding model is part of that configuration. Do not interpret the presence of an embedding-model field in the request schema as permission to replace it in place. A changed embedding configuration needs a replacement-resource plan under this API contract, rather than an endpoint-only update.

The chosen vector store must also support the model's dimensions and representation. AWS's vector-store prerequisites describe those constraints and field mappings. The direct Runtime request above does not establish that every Knowledge Bases storage combination accepts the same settings.

Ingestion is not a universal “convert all old vectors” operation. AWS documents incremental synchronization: unchanged documents may be skipped, and certain metadata-only changes can reuse existing vectors. Consequently, a successful sync is not evidence that an entire corpus was encoded with a new model. Bind the target resource, ingestion history and resulting generation before making that claim.

Chunking is part of the representation too. AWS describes splitting content before embedding and retaining a mapping to its source. A new parser or chunker can change the evidence available for retrieval even when the embedding model stays fixed.

Keep a generation-pairing record

Before allocating a rebuild, fill one record for the current generation and one for the candidate. Bind the query route to the record, not just to a model-name environment variable.

The following filled specimen describes a proposed application-owned retrieval design. Its resource aliases and corpus revision are fictional. It is not a Knowledge Bases configuration or a deployed router.

The model choice and metric in B are comparison inputs, not a recommendation or an accepted result. A production record should replace aliases with configuration references and retain the source revisions and build checkpoints that substantiate them.

Extend the record with corpus coverage, excluded or failed documents, source-to-chunk mappings, store/schema configuration, query preprocessing, evaluation cases and the release owner. A version label alone cannot prove that the vectors were generated with the declared recipe.

At serving time, select the query encoder and its compatible index together. Do not permit the new query encoder to use the old index merely because both advertise 512 dimensions. Cache entries and retrieval traces should identify the relevant generation so a route change cannot silently reuse incompatible candidate sets. This pairing is an application design requirement, not an automatic AWS migration feature.

Compare evidence before moving answers

Begin with fixed permitted source revisions and hold parsing and chunking constant where possible. That isolates the representation comparison. If a new model requires different text preparation, record that as part of the candidate rather than attributing every result to the model alone.

Include exact-term queries, paraphrases, similar but inapplicable passages, missing evidence and the languages and document types the application supports. For each case, identify the required source passage and disallowed evidence. Compare meaning and source spans when chunk identifiers differ.

Evaluate retrieval before generation: did the required permitted passage reach the selected context? Then evaluate whether the answer used it correctly. The retrieval-regression article provides the debugging method for missing or altered evidence.

Choose stop conditions from the task. Unauthorized evidence, lost decisive exceptions, unexplained missing documents or unverified encoder/index pairings should stop the affected candidate from receiving more traffic. A better aggregate relevance score does not cancel a consequential failure. Inspect latency, freshness and operating cost alongside task quality, without reusing the old similarity cutoff as a probability of correctness.

Keep both generations current during the chosen comparison and reversal window, or explicitly state why one cannot serve. That includes updates, deletions and permission changes, not only newly added documents. Backfill counts alone cannot prove the two views contain the same source revisions.

Reverse the pair, not just the endpoint

If B fails acceptance, stop sending eligible queries to B and restore the complete A pairing only if it remains current, permitted and operable. Using A's query encoder with B's vectors needs its own compatibility evidence; the database's unchanged name provides none.

Where A has not received recent deletions or revocations, do not blindly return traffic to it. Reconcile or restrict the affected scope first. Rollback is a serving decision; it does not recall documents already disclosed or remove candidate vectors, logs and caches.

Coexistence has a cost: document encoding, duplicate storage, evaluation queries, update propagation and operating effort. Size that temporary work before choosing the migration window. This article supplies no provider prices, savings estimate or universal retention period.

A full cutover procedure needs owned synchronization, reconciliation, limited exposure and retirement checks. Avoid doing those informally as part of an SDK change. The RAG architecture playbook covers the wider source-to-answer system.

Start with one proposed change and complete the two generation records. Name the source recipe, document encoder, query pairing, index and reversal condition. Then challenge the plan with the mismatched pair from the worked example. If the design can accept that combination without an explicit compatibility decision, fix the binding before paying to rebuild the corpus.

For help implementing the resulting scope, Ampity's LLM and RAG systems work covers the retrieval boundary; evaluation and observability covers the separate task and operating checks.