Vertex AI is retiring text-embedding-005 and three other embedding models: how to re-embed before search breaks

If your search box, document chatbot or recommendations run on Vertex AI's older embedding models, they stop working on 1 April 2027. Google is retiring text-embedding-005, text-embedding-004, text-multilingual-embedding-002 and multimodalembedding@001 that day. You can't fix it by swapping a model name, because every vectordefinitionThe list of numbers you get back for one item. How long it is, 768 or 3,072 for example, is the vector size, and your database has to be set up for it. you've stored was made by the old model and has to be made again.

When the model behind a search feature retires, the failure isn't gradual. Each search has to embed the user's question with the same model that embedded your documents. Once that model stops answering, the question can't be embedded and the search step errors out. A chatbot built on retrieval then either fails outright or answers without your documents, which is worse, because it sounds confident and nobody notices.

The real cost is the re-embedding. Every document, product, image or ticket you've indexed has to go through the new model again, and that's where the time goes. A small help centre is a quick job. A product catalogue with millions of images, or years of support tickets, is a project with its own budget and test plan, and it needs to start well before spring.

Google's retirement table leaves the replacement column blank for all four. Still, its text embeddings page says gemini-embedding-001 covers what text-embedding-005 and the multilingual model used to do, and the Gecko models retired last year pointed there too. So we'd expect most text work to end up on gemini-embedding-001, though gemini-embedding-2 takes text too. For images and video, the one multimodal model left is gemini-embedding-2. Neither behaves quite like the model it replaces, so test before you commit.

For engineers: Google says outright that gemini-embedding-001 and gemini-embedding-2 vectors can't be compared, and that moving between them means re-embedding everything. RAGdefinitionShort for retrieval-augmented generation. The app pulls the most relevant passages from your documents and hands them to a chat model, which answers from them. Engine goes further and ties each corpus to one embedding modeldefinitionA model that reads a piece of content and turns it into a long list of numbers. Two things that mean the same get similar numbers, and that's what lets search work by meaning. for its whole life. Treat any model change the same way. If the new model's vectors are a different size, you'll get dimension errors. If you've trimmed them to the old size, you get no error at all, just bad results, and that's the version that slips through testing.

The vector size is the column that causes the most work. The old text models give you 768 numbers per item and gemini-embedding-001 gives 3,072 by default. Every table column, index setting and storage estimate built around 768 has to change, unless you ask the new model for 768 using output_dimensionalitydefinitionA setting you pass to a Gemini embedding model to get shorter vectors, say 768 numbers in place of 3,072. You save storage, and Google says the quality loss is small.. If you do shrink it, normalise the vectors yourself: Google's docs say gemini-embedding-001 only normalises the full 3,072, while gemini-embedding-2 handles it for you.

Tuned models are the awkward case. Google's tuning page lists only text-embedding-004, text-embedding-005 and text-multilingual-embedding-002 as tunable, so all three tunable models are on the retirement list. If you tuned one on your own data, there's no tunable successor listed to retrain on. RAG Engine's docs do say a tuned model you deployed yourself keeps working after the publisher model is discontinued. Even so, plan to test the stock gemini-embedding-001 against your tuned model on your own queries, and keep whichever one wins.

Unless you keep a tuned model you host yourself, every path below ends in a full re-embeddefinitionRunning every stored item through a new embedding model again, because vectors from different models can't be compared., because the old models simply stop. What differs is the model you land on and how big the vectors get. Pick by what you search over and what your database can index.

Price matters at scale. On Google's pricing page, Gemini Embedding costs $0.00015 per 1,000 units online against $0.000025 for the older text models, six times as much, and batch is a little cheaper for both. For a help centre that's pocket change. For a team embedding every product description and support ticket daily, run the numbers before choosing 3,072 dimensions, since bigger vectors cost more to store and search as well.

Expect quota trouble during the bulk load. Developers on Google's AI developer forum have reported 429 errors from gemini-embedding-001 through the Gemini API, one of them at about 5% of quota. In that September case the error named a Vertex AI quota, and Google staff put it down to an intermittent issue. For a big re-embed, batch jobs are the safer route. They take up to a million rows each and can sit in the queue for 72 hours, so give yourself slack.

The inventory is the slow part, because embedding calls hide in places a model-name search misses. RAG Engine corpora don't name the model in your code. BigQuery remote models keep it in SQL DDL, and AlloyDB keeps it in a registered model endpoint. Ask every team that owns a Google Cloud project to run the same search, since the callers nobody wrote down usually sit outside the main repo. Then match each one to an owner.

This won't be the last time. Google already retired the Gecko embedding models, and now these four are going. Most of the pain comes from vectors nobody tagged with the model that made them, and model names copied into a dozen services. You're re-embedding anyway, so fix that now.

These three are made-up examples, so don't read them as client stories. What the models do in each one is taken from Google's documentation.

We do this work as part of our Vertex AI and Gemini Enterprise Agent Platform engagements. We find every caller and vector store, build the relevance test from your real queries, run the re-embed and switch over behind a flag. If you need engineers to do the work with your team, see who we can staff. If you'd rather start by sizing it, our assessment gives you an inventory and an order of work.