Embedding interoperability is becoming its own category

For the last few years, most of the attention in AI infrastructure has gone toward the models themselves: bigger models, cheaper models, faster models, multimodal models.

But underneath all of that, another layer has quietly become essential: embeddings.

These days, embeddings are the backbone of many things like search, finding information, suggesting products, and even entire user experiences. They act as a bridge between raw data and artificial intelligence applications.

The problem is that embeddings are not interoperable.

When an embedding model is used, it effectively creates its own system for organising information, kind of like its own map for understanding meaning. And if millions or billions of documents are embedded using that map, the entire retrieval system becomes dependent on it. This means that when a search query comes in, it also needs to exist in the same vector space as the embedded documents, otherwise retrieval quality starts to break down. It’s like trying to navigate a city using a map that follows completely different streets and landmarks, the same map needs to be used across the whole system, or things stop lining up.

If a model is deprecated, the problem becomes immediate.

Many AI systems depend on embeddings remaining compatible over long periods of time. The moment a provider retires a model, stops supporting it or pushes customers toward a newer version, existing vectors stop matching new queries correctly. Search quality degrades, recommendations become unreliable and Retrieval pipelines break. Entire indexes may need to be rebuilt.

And model deprecation is only one part of the problem.

When models become too expensive, retrieval quality starts drifting, or regulatory concerns emerge, organisations can find themselves needing to migrate to a different provider or a sovereign / self-hosted stack. That shift quickly becomes a major operational problem.

So, changing embedding models is not as simple as swapping an API endpoint.

It usually means re-embedding entire databases, rebuilding indexes, re-validating retrieval quality, managing infrastructure costs and navigating potential downtime. And the process repeats every time the ecosystem changes.

This matters far beyond engineering teams.

For CTOs, embedding lock-in creates long-term technical debt and makes AI systems harder to evolve over time. For product leaders, it slows down the ability to improve search, recommendations and AI-driven experiences because changing the underlying model can trigger major operational disruption. For CEOs, it becomes a flexibility and cost problem. Even switching to a cheaper or better-performing model can turn into a multi-month infrastructure migration with significant unexpected cost.

As AI systems mature, problems that once lived mainly in research papers are becoming operational realities for companies building production AI systems. There’s already strong research around embedding translation, vector alignment and representation mapping. However, most of that work still lives in papers, benchmarks and experimental projects. Very little has made its way into production-grade infrastructure that developers can actually use.

That gap is what UniVec exists to address.

At UniVec, conversion models are being built to map embeddings from one vector space into another without requiring the original source text to be re-embedded.

The goal is not “better embeddings”.

The goal is portability.

This category is likely to become substantially larger over the next few years for a few reasons:

• The number of embedding models is exploding
• Enterprises increasingly want provider flexibility
• Sovereign and on-prem AI requirements are growing
• Multimodal embeddings dramatically increase migration cost
• Model lifecycles are shortening
• Retrieval infrastructure is becoming core production infrastructure

In other words, the ecosystem is fragmenting faster than interoperability standards are emerging.

Right now, most teams handle embedding migrations as separate engineering projects. Over time, embedding interoperability will likely become a standard infrastructure layer, much like cloud orchestration, payments, databases and APIs eventually did.

That’s why some of UniVec’s early models are available publicly on Hugging Face under the Apache 2.0 license.

Partly because infrastructure categories only become real when developers can inspect, test and run the technology themselves. And partly because this field needs more open evaluation, reproducibility and discussion than it currently has. These models focus on converting between commonly used embedding families including OpenAI, Cohere, Google, AWS Titan, Snowflake Arctic, BGE and GTE. Some models are designed for broad production use cases. Others are intended as benchmarking references against existing translation research. All models are shared in ONNX format, allowing them to run on both CPUs and GPUs.

The broader AI ecosystem is still early in recognising that embedding interoperability may become a foundational infrastructure layer for modern AI systems. We’re interested in speaking with people working on retrieval systems, search infrastructure, vector databases or large-scale embedding migrations. If that’s relevant to the work being done, we’d love to hear about the challenges being encountered in practice.

Andreea Wade — CEO, UniVec