Change a Knowledge Base's Embedding Model Safely

Changing a knowledge base’s embedding model in Fours Insulin re-embeds every document on the new model, and search hides each document until its rebuild finishes — so results are never mixed across two models. This post gives the model choice and a switch-over runbook, as documented on September 30, 2026.

---

You picked an embedding model when you created a knowledge base, and now you want a different one — a bring-your-own-key organization moving off the hosted default, or a switch to a model that handles your documents better. The worry is the same either way: will changing it break search while every document re-embeds? In Fours Insulin the change is a managed rebuild with a visible counter, and search keeps answering throughout from whatever is already rebuilt.

Every label and behaviour named here is documented as of publication, September 30, 2026; re-check the Knowledge Bases documentation before a rebuild relies on it. One thing stays true across the whole post: search never mixes two models’ vectors. A knowledge base answers only from the documents already on its new model and hides the rest, so a half-finished rebuild degrades coverage rather than quality.

What is a knowledge base’s embedding model?

A knowledge base’s embedding model is the model that turns its documents, and every search against them, into the vectors that hybrid and vector search compare. Each knowledge base has exactly one. Every document is embedded with it, every search uses it, and because the query and the documents must live in the same vector space, you cannot search one model’s documents with another model’s vectors.

That single-model rule is why changing the model is a rebuild and not a setting you flip. The new model produces different vectors, so every document has to be re-embedded before search can compare it against a query, which is the whole reason the switch-over has a runbook at all.

Which model should you pick, hosted or your own?

You choose between two Fours-hosted models on Fours’ key and a model from a provider you connected with your own key (BYOK). The chooser labels every option with its provider, vector size and hosting — such as openai · 1536 dims · BYOK or deepinfra · 1024 dims · Suger-hosted — and the hosting label is how you tell Fours’ BGE-M3 apart from BGE-M3 on your own OpenRouter or DeepInfra key.

Source	Embedding models, documented as of publication	Which knowledge bases can use them	Who pays
Fours-hosted, on Fours’ key	BGE-M3 (the default) and Qwen3 Embedding 0.6B	Personal and organization knowledge bases alike, only while Allow Fours platform key is on	Metered as Fours’ own AI
Your own provider, on your own key	OpenAI: text-embedding-3-small and text-embedding-3-large. Gemini: Gemini embedding 2. OpenRouter: BGE-M3. DeepInfra: BGE-M3 and Qwen3 Embedding 0.6B. Fireworks: Nomic Embed v1.5. Together: multilingual-e5-large-instruct	Organization knowledge bases use the organization’s connections; personal knowledge bases use yours, never the organization’s	Your provider’s own spend

Two things decide whether the hosted models even appear:

• The platform-key switch gates them. Turn off Allow Fours platform key and the hosted models leave the picker for everyone in the organization. A bring-your-own-key organization with no embedding provider connected then cannot create a knowledge base at all — there is nothing left to embed with. This is the same switch that governs the chat pool; the AI model allowlist is the setting to read before turning it off.
• Not every provider you can connect for chat can embed. Fours registers an embedding model only for OpenAI, Gemini, OpenRouter, DeepInfra, Fireworks and Together. A connection to Anthropic, Cloudflare Workers AI or DigitalOcean GradientAI adds nothing to the embedding chooser — those provide chat models only. If a provider you connected isn’t offered here, that is why. The full roster for both jobs is in which models serve Insulin chat and knowledge bases.

What happens when you change the embedding model?

Insulin confirms the rebuild, then re-embeds every document on the new model while search keeps answering from the ones already rebuilt. Confirm the change and the knowledge base starts re-indexing immediately; you do not take it offline.

The confirmation states the cost plainly: “Switching to re-embeds all documents in this knowledge base, which takes provider time and spend.” When the new model is one of your own, that spend is your provider’s, billed to your key, not a Fours charge — the same way any BYOK usage is attributed to the provider whose key served it. Re-embedding a large knowledge base is not free, so read <N> before you confirm.

Here is the switch-over, in order:

1. Confirm the change. In the knowledge base’s Settings, the Embedding model section shows the Current model; pick a new one and accept the “Change embedding model?” prompt. Re-indexing starts at once.
2. Watch N of M documents searchable. The Re-indexing progress counts the documents already rebuilt on the new model, as in 3 of 42 documents searchable. Search works the whole time — it just covers fewer documents until the count catches up. An agent that searches mid-rebuild is told how much of the knowledge base it actually covered.
3. Clear failures with Index them now. Failed documents are called out separately from the progress count, because waiting will not clear them. Index them now retries every outstanding document on the new model.
4. Use Restart indexing if progress stalls. Restart indexing in the same panel picks up exactly what is outstanding, without redoing documents already rebuilt.

Two more facts worth knowing before you start. You can change the model again at any point, including mid-rebuild — a switch you regret is another switch, not a stuck job. And retired (deprecated) documents are skipped: a document you deprecated from search is not re-embedded, so it costs nothing and stays out of search until you restore it.

Why do documents go missing right after the switch?

Because search hides each document until it has been re-embedded on the new model, and reports what failed separately. During the rebuild, the N of M documents searchable line in Settings → Embedding model is the ground truth for coverage: a document not yet counted is not yet searchable, and a document that failed to re-embed needs Index them now rather than more waiting.

What happens to a document that cannot be re-embedded depends on whose knowledge base it is — and this is the one behaviour that differs between the two kinds:

Knowledge base	On first index with the new model	If a document can’t be re-embedded
Organization	If the chosen provider isn’t available, it falls back to a Fours-hosted model on its own and says so: “Fell back to a Fours-hosted model.”	Reported in the failure count; retry with Index them now
Personal (user)	Never switches models behind your back	Marks the affected documents Failed; fix the provider, then retry

So an organization knowledge base errs toward staying searchable — it would rather fall back to a hosted model than leave you with nothing — while a personal one errs toward doing exactly what you chose, marking documents Failed instead of quietly embedding them on a model you did not pick. Neither ever mixes the two models in one search.

Does changing the chunk strategy work the same way?

No. Changing the chunk strategy is not a rebuild — it applies to new syncs only, and a mix of chunk strategies can coexist. A chunk strategy is the rule for how a document is split into passages before indexing; in Insulin it is Fixed size or Semantic.

The contrast with the embedding model is the point. Switching the embedding model re-embeds every existing document, because the old vectors cannot be compared against the new model’s. Switching the chunk strategy touches only documents synced from that point on — existing documents keep their current chunking until you re-index or re-sync them individually, so two chunk strategies can live in one knowledge base without anything breaking. If you want the new chunking applied everywhere, you re-sync the documents yourself.

Frequently asked questions

Does changing the embedding model break search while it rebuilds?

No. Search keeps answering throughout, from the documents already re-embedded on the new model, and hides the rest — so results are never mixed across two models. The N of M documents searchable counter in Settings shows how much is covered so far.

Who pays to re-embed a knowledge base?

When the new model is one of your own connected providers, re-embedding is billed to that provider on your own key — your provider’s spend, not a Fours charge. The hosted models are metered as Fours’ own AI, and the confirmation warns it takes “provider time and spend.”

Which providers can embed a knowledge base?

Fours’ hosted BGE-M3 and Qwen3 Embedding 0.6B, plus your own key on OpenAI, Gemini, OpenRouter, DeepInfra, Fireworks or Together. A connection to Anthropic, Cloudflare Workers AI or DigitalOcean GradientAI adds no embedding model — those are chat models only.

What if some documents don’t come back after the switch?

They are still re-embedding, or they failed. The progress count lists failures separately: use Index them now to retry them, or Restart indexing if progress stalled. A personal knowledge base marks documents Failed; an organization one can fall back to a Fours-hosted model and says so.

Can I change the embedding model again mid-rebuild?

Yes. You can change the model again at any point, including while a rebuild is running. Insulin picks up the new choice and re-embeds toward it; a switch you regret is just another switch.

Does changing the chunk strategy re-embed everything too?

No. A new chunk strategy — Fixed size or Semantic — applies to new syncs only. Existing documents keep their chunking until you re-index or re-sync them, so a mix of chunk strategies can coexist in one knowledge base.

Takeaways

• A knowledge base has one embedding model; changing it re-embeds every document, so the switch is a managed rebuild, not a flipped setting.
• Search never mixes two models’ vectors. It answers from documents already on the new model and hides the rest, so a rebuild costs coverage, not accuracy.
• Watch N of M documents searchable in Settings; Index them now retries failures and Restart indexing resumes a stall. You can change the model again mid-rebuild.
• An organization knowledge base can fall back to a Fours-hosted model on first index; a personal one marks documents Failed instead. Re-embedding on your own provider is your provider’s spend.
• Changing the chunk strategy is different — it applies to new syncs only, and mixed chunk strategies coexist.

To see what Insulin knowledge bases do once they are grounded, start with the product page; the Knowledge Bases documentation is the full reference for embedding models, statuses and syncing.