Vector Embeddings with AI_EMBED and AI_SIMILARITY
1. Vector Embeddings with AI_EMBED and AI_SIMILARITY
A model reads a piece of text and produces a vector, typically hundreds and thousands of numbers long. You can think of that vector as a point in space. Every point of text gets its own point, and the texts that mean similar things end up getting a point close together. Since computers don't think of similarities the same way humans do, they use this type of math to approximate them. Zipper broken and closure snapped off are nearby in that space, but my order hasn't arrived is somewhere else entirely. The model has learned from training on a massive amount of text which concepts are related and what aren't. That knowledge gets baked into the geometry of that space. This is why semantic search works. When you search for a broken zipper, the system doesn't look for those exact words. It converts your query to an embedding, then finds the points in that space that are nearest to it. Nearest points indicate related meaning, even if the specific words are different. You may never think about embeddings directly when you're using Cortex Search. Cortex Search generates them for you, indexes them, and runs nearest neighbor search behind the scenes. You just define what data to index and send queries. But there are situations where you want to work with embeddings yourselves. Maybe you're building your own retrieval pipeline and you want to pre-compute and store embeddings in a table so you can run efficient similarity lookups later. Maybe you want to score similarity between two specific pieces of text. Maybe you're doing clustering or deduplication or anomaly detection on text data. All of those start with embeddings. That's where AI_EMBED and AI_SIMILARITY come in. AI_EMBED is Snowflake's unified function for generating embeddings. It was made generally available in November 2025. Before that, Snowflake had two separate functions, EMBED_TEXT_768 and EMBED_TEXT_1024, which were model-specific. AI_EMBED replaces those with a single interface. The basic syntax is straightforward and looks like this. You pass out a model name and text input. It returns a vector stored as a Snowflake vector type. You can store that in a column, use it in a join, or pass it in another function. The model name here, snowflake-arctic-embed-l-v2.0, is one of the Snowflake-hosted embedding models. Snowflake provides several options at different sizes and performance tradeoffs. The right choice depends on your use case, but for most text similarity work, this is a reasonable default to start with. Remember, models update periodically, so always check the Snowflake docs for the most up-to-date versions. While AI_EMBED creates the embeddings, AI_SIMILARITY uses embeddings to compute semantic similarity between the two pieces of text. It returns a score between -1 and 1, and when 1 means the texts are semantically identical and -1 means they're unrelated. Here's a concrete example from the Ski Gear scenario. We are comparing the words broken zipper to the problem of the zipper snapping off. If we run that, and you will get a score close to 1. Those two phrases describe the same problem, so the model puts them near each other in the embedding space. Now compare that with something genuinely unrelated, like your order not arriving. That score will be much lower because these words represent different parts of the space entirely. You can use this at scale to score similarities across rows. Say you want to find all the transcripts that are semantically similar to a known complaint. This ranks your entire table by semantic closeness to that complaint. No keyword matching required. For our demo table, this runs quickly, but on a large table, precomputing and storing embeddings with AI_EMBED is a more practical path, since you're not regenerating vectors on every query. So, when should you reach for AI_EMBED and AI_SIMILARITY directly versus letting Cortex Search handle everything? Cortex Search is the right tool when you're building a retrieval system. It handles embeddings, index, and search infrastructure, and it's optimized for that query pattern. Use it when you want a managed search service. AI_EMBED and AI_SIMILARITY are the right tools when you're looking for something more custom. If you want to precompute embeddings and store them in a table, use AI_EMBED. You might want to do this if you're building your own nearest neighbor logic or if you're working with a dataset that doesn't fit neatly into Cortex Search service model. If you want to score similarity between two specific texts, on demand, use AI_SIMILARITY. It's one function call. There's no index to set up and no service to maintain. It is good for ad hoc analysis, QA checks, deduplication, or anywhere you need quick relevance scores without building a full retrieval system. The two approaches complement each other. Cortex Search uses embeddings under the hood. AI_EMBED and AI_SIMILARITY give you direct access to the same capability when you need it. Let's recap. An embedding converts text into a vector of numbers where semantic meaning is captured as geometric distance. Related text ends up close together in that space. Lastly, Cortex Search handles all of this automagically for managed retrieval. AI_EMBED and AI_SIMILARITY are there when you want to work closer to the metal.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.