I Rebuilt 5,383 Embeddings After a Dimension Change

I changed one embedding model and had to rebuild the whole vector index.

The old path used OpenAI text-embedding-3-small at 1,536 dimensions. The new path uses nomic-embed-text through Ollama at 768 dimensions on my RTX 5090. The model swap was easy. The data migration was the real job.

The short version: An embedding dimension change is a schema change, not a model setting. I changed the vector column, cleared the old rows, rebuilt the HNSW index, re-embedded 5,383 chunks from 1,605 notes, and checked retrieval with three known queries after the rebuild.

Canonical URL: https://bmdpat.com/blog/rebuild-vector-index-embedding-dimensions-2026

Why can I not mix 1,536 and 768 dimension vectors?

My Supabase table stored each embedding in a vector(1536) column. The local model returned 768 values. Those are different data shapes.

Changing only the application code would leave the database contract behind. Keeping the old rows would also leave corpus vectors and query vectors produced by different models. Even if I copied them into a looser storage format, the similarity scores would not represent one shared vector space.

I treated the change like a database migration. The new column became vector(768). The search function accepted a 768-value query. The HNSW index was rebuilt for the new column. Old embeddings did not survive the cutover.

What did the rebuild include?

The July 10, 2026 handoff report records the full pass: 5,383 chunks from 1,605 notes. One background run on the RTX 5090 generated every replacement vector with nomic-embed-text.

I kept the corpus and query paths on the same model. config/brain/embed_vault.py embeds notes. The vault search server embeds each query. Both now call the same Ollama model and expect 768 dimensions.

That symmetry matters more than the model name. A corpus built by one embedding model and queried by another can return numbers, but those numbers do not prove useful retrieval. I want one encoder, one dimension, and one migration boundary.

The process was simple:

1. Apply the 768-dimension schema and search function.
2. Clear the old corpus rows.
3. Rebuild every chunk with the local embedding model.
4. Run known queries and inspect the top results.

How did I test retrieval after the migration?

I used three queries with obvious expected answers. The AgentGuard query returned its entity note first at 0.694 cosine similarity. The Raspberry Pi researcher query returned its deployment README first at 0.676. The workflow audit query returned Offer.md first at 0.637.

Those scores are not universal quality targets. They are results from this corpus and this model. The useful test was whether each known query returned the expected source at the top after the rebuild.

This is the same reason I preview retrieval before a local LLM runs. Retrieval should produce an inspectable artifact before generation begins. A model cannot repair a missing source it never received.

I also keep durable facts in files before they enter semantic search. That design is covered in why I write agent memory to files. The vector index makes those files easier to find. It is not the source of truth.

What should fail closed during an embedding migration?

The embedding helper now checks that the local response has exactly 768 values. A wrong-length vector stops the run. The database schema provides a second boundary. The query path uses the same expected dimension.

I would also stop the cutover if the corpus count was far below the source count, if the embed service returned empty vectors, or if the known-query checks missed their expected files. A completed migration is not a successful migration unless retrieval still works.

The safest rollout is a full rebuild with a small parity suite. Keep the old index available until the new one passes. Then switch the query path once. Do not let two embedding models write into the same active corpus.

When is a full rebuild worth it?

I rebuilt because the change removed a paid API dependency from a daily vault search path. It also let me re-embed the corpus on hardware I own whenever the source files change.

That benefit justified one clean migration. It would not justify swapping models every week. Each embedding model change creates a new corpus version, a new query contract, and another parity run.

My rule is now explicit: pin the embedding model and dimension together. If either changes, version the index and rebuild the corpus. The application should never discover that contract drift during a live query.

Accompanying prompt

What the prompt does: This prompt turns an embedding-model change into a fail-closed vector-index migration plan with retrieval checks.

Copy/paste this prompt:

Copy-ready prompt

Paste the exact block into your coding agent.

No article chrome, no footnotes, no formatting drift.

Copy promptSelect text

Role: You are a vector search migration reviewer. Context: Paste the current embedding model, new model, dimensions, table schema, corpus counts, and three known queries with expected results. Task: 1. Identify every schema, index, corpus, and query-path change. 2. Define the order for rebuilding vectors without mixing models. 3. Write parity checks that must pass before the query path switches. Output: - A numbered migration plan with rollback points. - A pass/fail table for vector length, corpus count, and known-query results. - The exact evidence to record after the rebuild. Constraints: - Keep it short. - Use exact numbers and file paths when available. - Do not invent missing measurements. - Treat a model or dimension change as a new corpus version.

21 lines/768 chars

Ready

This prompt and every other one we publish live in the free prompt library.

Copy the block above.

I publish measured local-model migrations, failures, and fixes in The 5090 Reports. Join the list to get the next artifact.