Embedding models across workstations & vaults
AdminIf you run several desktop workstations alongside a shared API, the question comes up: may each workstation run a different embedding model? The short answer: yes — in the normal case this is safe. There is exactly one exception that breaks without any error message; this page describes it, plus three operating rules.
Why the normal case is safe
Section titled “Why the normal case is safe”A search query is always embedded by the store that owns the data — vectors are never compared across model spaces:
| Vault type | Who embeds the query? |
|---|---|
| Local / personal vault | the local workstation with its model |
| Shared vault (API) | the API server with its model — the client only sends the query text, never a vector |
Results from multiple sources are merged by rank (Reciprocal Rank Fusion); raw similarity scores from different models are never compared with each other.
Consequence: as long as each physical vector store is filled and queried by only one model, workstation A, workstation B and the API may use different embedding models. That is the supported topology: independent local stores plus federated shared vaults.
The silently breaking exception
Section titled “The silently breaking exception”If two clients with different embedding models point at the same Qdrant collection (same endpoint, same collection name), this happens:
- Different vector dimension → a loud error on write. Annoying, but visible.
- Same dimension → no error, but useless results. Similarity across two model spaces is meaningless; search silently returns poor matches.
The second case is the real risk: the dimension is checked, the model identity is not — two different models sharing a width (e.g. 768 or 1536) are indistinguishable to the system.
Operating rules
Section titled “Operating rules”- Never point two clients with different embedding models at the same Qdrant collection name. If a Qdrant instance must be shared: one collection name per model (
Qdrant:VectorCollectionNameis configurable per client). → Set up Qdrant - Model or dimension change ⇒ force a re-index. Otherwise old vectors come from the old model and new queries from the new one — with matching dimensions, result quality silently collapses. This also applies when settings were imported from another workstation via peer sync. → Admin tab: Knowledge areas & indexing
- Workstations without embeddings fall back to BM25 full-text search — no mixing risk, but noticeably weaker results (especially for semantic and German queries). Heterogeneous quality across workstations is normal in that case.