Your Note Search Index Has a Shelf Life: Switch AI Models and You Rebuild It All

Yes — if you switch the embedding model behind your notes' semantic search, you have to re-embed everything. A text-embedding vector only means something inside the exact model that produced it. Change the model and every stored vector turns to noise. The index is a disposable cache; your notes are the asset.

The instruction is boringly official. Microsoft's Azure AI Search documentation states it in one line: "To ensure accurate results, use the same embedding model for indexing and querying."¹ Break that rule and results are not slightly worse — they are meaningless, because two models place the same sentence at different coordinates. Re-embedding is the fix, and at personal scale it is cheap: a few thousand notes re-embed in minutes, for cents. So this is not a warning about cost. It is a warning about what you treat as permanent. The moment you believe the index is your library — rather than a rebuildable shadow of it — you are one cleanup script away from deleting the only copy of a note because "it's already embedded." This guide is the habit that prevents that.

The one habit: treat the index as a cache, not a copy

Treat your vector index the way you treat a thumbnail: derived, disposable, and always regenerable from the original. The originals are your plain-text notes. The vectors are a convenience layer stacked on top. If you can rebuild the index from the notes but never the notes from the index, then only one of the two is actually your data.

An embedding is a list of numbers — a coordinate — that a specific model assigns to a specific piece of text. OpenAI's own guide is precise about the coordinate's shape: "By default, the length of the embedding vector is 1536 for text-embedding-3-small or 3072 for text-embedding-3-large."² The arrows only run one way. Notes produce vectors; vectors never reconstruct notes.

flowchart TD
  A[Your notes<br/>plain text] --> B[Run through<br/>embedding model]
  B --> C[Vectors:<br/>the index]
  C --> D[Semantic search]
  E{Switch model?} -->|Yes| F[Old vectors<br/>are noise]
  F --> A
  E -->|No| D

Figure: The one-way derivation. Your plain-text notes are run through an embedding model to produce the vectors that power semantic search. Switch the model and the old vectors become noise — so the rebuild arrow returns to the notes, never to the discarded index. You can always regenerate vectors from notes; you can never regenerate notes from vectors.

That asymmetry is the whole argument. Whether you needed a vector index at all is a separate question — often you do not, and a companion piece makes the case that a vector database is usually the wrong abstraction for a personal vault.³ This guide assumes you already built one and want it to survive a model change.

Why same length still isn't the same vector

Matching dimensions do not make two vectors comparable. text-embedding-3-small and the older text-embedding-ada-002 both output 1,536 numbers, so a naive index accepts either without error — and returns nonsense, because each model learned its own coordinate space. Same length, different meaning. A distance measured across two spaces is not a distance at all.

The clearest proof that vector length is not the currency comes from the Matryoshka research. In "Matryoshka Representation Learning," presented at NeurIPS 2022, Aditya Kusupati and ten co-authors describe an embedding "which encodes information at different granularities and allows a single embedding to adapt to the computational constraints of downstream tasks."⁴ The applied payoff, in OpenAI's own numbers: a text-embedding-3-large vector "can be shortened to a size of 256 while still outperforming an unshortened text-embedding-ada-002 embedding with a size of 1536."⁵ Read that twice. A newer vector one-sixth the length beats an older vector six times longer. Dimension count tells you almost nothing; the trained space is everything.

The mechanism is not a hack. The paper reports that "MRL learns coarse-to-fine representations that are at least as accurate and rich as independently trained low-dimensional representations,"⁶ which is why OpenAI can let developers "shorten embeddings (i.e. remove some numbers from the end of the sequence) without the embedding losing its concept-representing properties by passing in the dimensions API parameter."⁷ One caveat, disclosed plainly: the paper's headline figure — "up to 14x smaller embedding size for ImageNet-1K classification at the same level of accuracy"⁸ — is measured on images, while OpenAI's 256-versus-1536 result is the same idea proven on text retrieval. Different benchmarks, one lesson: the space is the meaning, not the length.

The five-minute version: re-embed without losing anything

When you decide to switch models, the safe migration is short: keep the notes untouched, generate fresh vectors for every note through the new model, write them to a new index, then swap. Never edit in place, never delete a note mid-run, and never mix vectors from two models in one index.¹ The steps below are the whole procedure.

1. Confirm the notes are the source. Every vector must be reproducible from a note's text. If any embedding has no plain-text origin you can point to, stop and fix that first.
2. Record the new model. Write down its exact name and dimension count before you start: text-embedding-3-large is 3072 by default, text-embedding-3-small is 1536.²
3. Build a new, empty index. Do not reuse the old one. A fresh index guarantees no leftover vectors from the previous model survive the switch.
4. Re-embed from the text. Loop over every note, send its content through the new model, and write the result to the new index. The source of every vector is the note, never an old vector.
5. Validate a handful of searches. Run five queries you know the answers to. If results look right, the new space is wired correctly.
6. Swap, then delete the old index. Point search at the new index. Only now delete the old one; it was always a cache.

The thirty-minute version: make the migration boringly repeatable

The durable version adds one artifact: a small manifest that records which model built the current index, its dimension count, and the date. That single file turns "which vectors are these?" from a guess into a lookup, makes the re-embed script idempotent, and lets you detect a model change automatically instead of discovering it through bad search results.

Store the manifest beside the index, and both beside the notes. Where that index should live — in a file next to your notes rather than locked inside a service — is the companion question a separate piece answers in full.⁹ The manifest is small:

{
  "embedding_model": "text-embedding-3-large",
  "dimensions": 3072,
  "note_count": 4200,
  "embedded_at": "2026-07-21",
  "source": "notes/",
  "note": "Disposable cache. Rebuild from source/ with any model."
}

Now the re-embed becomes a short, idempotent decision at the top of any indexing run: read the manifest, compare its recorded model to the one you are about to use, and rebuild from the source folder if they differ.

# Re-embed only when the model changed. Safe to run every time.
manifest  = load("index/manifest.json")
new_model = "text-embedding-3-large"

if manifest["embedding_model"] != new_model:
    fresh = new_index(dimensions=3072)
    for note in read_all("notes/"):           # notes = source of truth
        vector = embed(note.text, new_model)   # regenerate, never reuse
        fresh.add(note.id, vector)
    swap(fresh)                                # then delete the old index

The loop only ever reads note text; it never trusts an existing vector as an input. That single property is what makes a model switch a chore instead of a crisis. If your vault is small, under roughly a million words, you may not need any of this, because plain full-text search often beats the whole re-embedding treadmill.¹⁰

Common mistakes

Most re-embedding pain is self-inflicted. The failures below are not about compute cost — re-embedding a personal corpus is cheap. They are about treating a derived cache as if it were the original. Each one ends the same way: a search that quietly returns garbage, or a note that no longer exists.

• Deleting a note because "it's already in the index." This is the only truly unrecoverable mistake here. The index cannot regenerate the note's text; delete the note and the words are gone, whatever the vector remembers. The vector is a shadow, not a backup.
• Mixing vectors from two models in one index. Because two models can share a dimension count, the index accepts both silently — no error, just cosine distances measured across incompatible spaces. Rebuild into a clean index on every switch.
• Storing only the vectors and discarding the source text. Now you can never re-embed. Your corpus is frozen to a model that will be superseded on the vendor's clock, not yours: text-embedding-ada-002 was released in December 2022 and superseded about thirteen months later.¹¹
• Comparing embeddings from two different models. Cosine similarity across models is not meaningful. A query embedded by one model and documents embedded by another will not rank sensibly, even when the numbers line up in length.
• Assuming a bigger or newer model is a drop-in. Dimensions are model-coupled to your store: a vector database "that only supports embeddings up to 1024 dimensions long" forces you to shorten a 3072-dimension model with the dimensions parameter¹², a deliberate step, not an automatic one.

How this works with your own notes

The principle is easiest to hold when your notes are plain-text files you control. If every note is open Markdown, stored locally on your own device, then the source of truth is a directory you can read, back up, and re-embed against any model, this year's or next year's. The vectors come and go; the folder stays.

This is the same reason a second brain is not a search index and a search index is not a second brain: the thinking lives in the notes, and the retrieval layer is a replaceable convenience built on top of them.¹³ Better embedding models keep arriving — the multi-language retrieval benchmark jumped from 31.4% to 44.0% between ada-002 and text-embedding-3-small¹⁴ — so the pressure to switch is real and recurring. Own the layer that does not expire, and every future switch is a chore, not a crisis.

Frequently asked questions

Do I have to re-embed all my notes if I switch embedding models? Yes — the whole corpus. Query and documents must share one model, so a switch invalidates every stored vector at once. There is no partial migration and no way to convert old vectors to the new space. At personal scale this is cheap and fast, but it is mandatory, not optional.

Are embeddings tied to a particular model? Completely. An embedding is only meaningful inside the model that produced it, which is why Microsoft's documentation requires "the same embedding model for indexing and querying."¹ The numbers are coordinates in that model's private space. Feed them to a different model and they point nowhere in particular.

Can I compare embeddings from two different models? No. Cosine similarity assumes both vectors live in the same space, and two models do not share one — even when they output the same number of dimensions. A cross-model distance is arithmetic without meaning. If you want to compare two texts, embed both with one model, then compare.

Should I store the vectors or the original text? The text, always. Vectors are a rebuildable cache derived from the text; the text cannot be rebuilt from the vectors. Keep the notes as the durable asset and treat the index as scratch space you can delete and regenerate whenever a better model arrives.

Which embedding model should I choose to avoid re-embedding? None avoids it — any future switch means a full re-embed, so choose for fit today rather than to dodge migration. What removes the pain is not the model choice; it is keeping the source text so re-embedding is always a script you can re-run, against whatever model you pick next.

What happens if I query an index with a different model than the one that built it? The search still runs and still returns results, which is the trap. No error fires, because the query vector has a valid shape. But the matches are ranked in the wrong space, so they look plausible and are quietly wrong. This silent failure is the whole reason the same-model rule exists.

Is re-embedding expensive? For a personal vault, no. A few thousand notes re-embed in minutes for a handful of cents, which is exactly why the cost is not the point. The expensive failure is not paying to re-embed — it is deleting a note you assumed was safely "in the index."

A vector index is a photograph of your notes taken through one particular lens. Change the lens and you retake the photograph — you never lose the thing being photographed, unless you were careless enough to throw it away. Keep the notes. The index was always going to expire.

MNMNOTE keeps your notes as plain Markdown on your own device, so the source your search is built from stays yours — mnmnote.com.