The Gemini probe followed by an automatic all-mpnet-base-v2 fallback is resilient at the request level, but risky at the index level. If both providers can write into one collection, a dimension check catches only some mismatches; two models with equal dimensions would still create semantically incompatible vectors. I would pin one embedding fingerprint per ingestion run and collection, then queue failed batches for retry rather than silently changing the vector space mid-index.
Good point! The fallback is decided once during initialization, so it doesn't switch providers mid-run. That said, pinning an embedding fingerprint to each collection and retrying failed batches is definitely a more production-ready approach. Thanks for the suggestion!
Choosing the provider once at initialization removes the worst mid-run mixing risk. I would still record model ID, revision, dimension, normalization setting, and preprocessing version in the collection metadata, then reject later writers whose fingerprint differs. That makes a rebuild or migration intentional and gives retrieval traces enough information to explain why two index generations behave differently.
Ahmet Özel
The Gemini probe followed by an automatic all-mpnet-base-v2 fallback is resilient at the request level, but risky at the index level. If both providers can write into one collection, a dimension check catches only some mismatches; two models with equal dimensions would still create semantically incompatible vectors. I would pin one embedding fingerprint per ingestion run and collection, then queue failed batches for retry rather than silently changing the vector space mid-index.