Picture this.
A company has 500,000 support tickets sitting in Snowflake. Years of troubleshooting notes, product defects, workarounds, resolutions, and occasional messages that just say "fixed after restart." Very helpful, thanks.
Someone wants an AI assistant that can search those tickets and suggest resolutions. The architecture looks straightforward. Take the documents, generate embeddings, store vectors, retrieve similar records, and let an LLM write the answer.
A few SQL queries later, you have a demo.
Then someone asks which embedding model you picked.
"Arctic."
Which Arctic?
"The bigger one."
Why?
"More dimensions."
And there it is. We've designed an intelligent search system using the same decision-making process people use to buy televisions. Snowflake Cortex offers eight built-in text embedding models through AI_EMBED. Some produce 768-dimensional vectors, others 1,024. Some are English-focused. Others support multiple languages. Context windows vary considerably.
The problem isn't a shortage of options.
It's figuring out what actually matters.
I've spent about eight years working with Snowflake, and one lesson from enterprise data engineering keeps showing up: the technically impressive option isn't necessarily the right one for your workload. Embedding models are no exception.
Meet the suspects
According to Snowflake's AI_EMBED documentation, the built-in text embedding lineup includes:
| Model | Dimensions | Language focus |
|---|---|---|
|
| 768 | English |
|
| 768 | English |
|
| 768 | English |
|
| 1,024 | Multilingual |
|
| 1,024 | Multilingual |
|
| 1,024 | English |
|
| 1,024 | Multilingual |
|
| 1,024 | Multilingual |
Snowflake also supports image embeddings through voyage-multimodal-3, but that's a different use case. We're keeping this investigation focused on text.
Eight models sound like eight chances to get it right. Or eight chances to explain to your architect why you chose one based on a name.
Let's narrow down the questions.
Round 1: 1,024 dimensions versus 768
The first temptation is obvious.
A 1,024-dimensional embedding contains more numbers than a 768-dimensional embedding. More numbers must mean more meaning. Unfortunately, vector search doesn't work like upgrading a laptop from 16 GB to 32 GB of RAM.
An embedding model learns a representation of language. Its dimensions are coordinates in that learned space, not a score for intelligence.
A larger representation might capture useful distinctions. It might also deliver no measurable improvement on your particular documents.
Imagine three fictional incident records:
- Incident A: Payment reconciliation failed after an upstream schema change.
- Incident B: Settlement processing rejected records following a column modification.
- Incident C: The finance department completed its quarterly budget review.
Now a user asks:
"Why did settlement reconciliation fail after the column changed?"
A useful model should recognize that A and B are relevant, while C is mostly unrelated.
But here's the interesting part. Suppose a 768-dimensional model puts B first, while a 1,024-dimensional model puts A first.
Which one won?
You can't answer that from the dimension count. Maybe both are valid. Maybe one describes the exact failure while the other concerns an older version of the pipeline. Maybe neither contains the accepted resolution.
The model's job isn't to produce a beautiful vector.
It's to retrieve useful evidence.
For an English-only knowledge base containing relatively short documents, I'd start with a compact model such as Arctic Embed M v1.5 as a baseline.
Then I'd test whether a larger model improves retrieval.
Not assume it does.
Round 2: The multilingual trap
Now the support organization expands.
Some tickets are in English. Others are in Spanish, French, Japanese, or a combination of languages.
One customer writes:
"El proceso de conciliación falló después de modificar una columna."
Another asks in English:
"Why did reconciliation fail after the column update?"
Ideally, your retrieval system can connect these without requiring every ticket to be translated first. This is where models such as multilingual-e5-large, Arctic Embed L v2.0, and Voyage Multilingual 2 become candidates.
But multilingual support comes with an uncomfortable question. Does supporting multiple languages mean equally good retrieval in every language?
No.
A model can support multilingual embeddings and still perform differently across languages, technical domains, and query styles.
Here's what I'd test:
- An English question against Spanish documentation.
- A Spanish question against English documentation.
- Mixed-language incident descriptions.
- Product names that should never be translated.
- Technical identifiers embedded inside ordinary sentences.
That last one matters.
An error such as ERR_RECON_042 should remain ERR_RECON_042, regardless of the surrounding language.
A model that understands a Spanish sentence but loses the exact error identifier hasn't solved the whole problem. I'd also separate two questions: can the model retrieve semantically similar information across languages, and does the retrieved information actually answer the user's question?
They're related, but they're not identical. Multilingual support earns a model a place in the evaluation. It doesn't automatically win the contract.
Round 3: The 32,000-token temptation
Next comes document length.
Consider a 40-page incident report. It contains the original failure, several failed fixes, the successful workaround, and a postmortem written two weeks later.
A model with a short context window can't embed the whole document in one pass. A model supporting longer inputs gives you more room.
Arctic Embed L v2.0 8K supports longer inputs than its standard version. Voyage Multilingual 2 supports up to 32,000 tokens. At first glance, longer sounds better. Fewer chunks. Less processing logic. Everybody goes home early.
Except there's a problem.
That 40-page report isn't necessarily about one thing.
The first section describes ingestion. The second discusses schema evolution. The third explains a permissions issue. The fourth says the original root-cause theory was wrong. Put everything into one vector and you're asking the model to summarize several distinct concepts into a single location in embedding space.
Now imagine a user searching specifically for the permissions issue.
Will the document-level vector represent that section strongly enough? Maybe. But I wouldn't bet the retrieval architecture on it.
Chunking exists for a reason. Sometimes a focused 300-token chunk retrieves better than an entire document represented by one embedding. Sometimes larger context helps preserve the explanation that a smaller chunk would lose.
The answer depends on the structure of the content.
I'd compare different chunking strategies before spending time arguing about context-window sizes. The bigger window may be useful. It isn't permission to stop thinking about document structure.
Round 4: Let SQL do some work
One thing I like about the Cortex approach is that generating a text embedding doesn't require standing up a separate model-serving application.
Snowflake provides AI_EMBED.
For example:
SELECT AI_EMBED( 'snowflake-arctic-embed-m-v1.5', 'An upstream schema change caused payment reconciliation to fail.' ) AS EMBEDDING; The function returns a vector.
Let's use a small fictional knowledge base.
CREATE OR REPLACE TEMP TABLE INCIDENTS ( INCIDENT_ID NUMBER, DESCRIPTION VARCHAR ); INSERT INTO INCIDENTS VALUES (1, 'Payment processing failed after a schema modification.'), (2, 'An upstream column change broke settlement reconciliation.'), (3, 'The finance team completed its quarterly budget.'), (4, 'A scheduled batch job exceeded its memory allocation.'); Generate embeddings:
CREATE OR REPLACE TEMP TABLE INCIDENT_VECTORS AS SELECT INCIDENT_ID, DESCRIPTION, AI_EMBED( 'snowflake-arctic-embed-m-v1.5', DESCRIPTION ) AS EMBEDDING FROM INCIDENTS; Now search:
WITH QUERY_VECTOR AS ( SELECT AI_EMBED( 'snowflake-arctic-embed-m-v1.5', 'Why did settlement reconciliation fail after a column change?' ) AS EMBEDDING ) SELECT I.INCIDENT_ID, I.DESCRIPTION, VECTOR_COSINE_SIMILARITY( I.EMBEDDING, Q.EMBEDDING ) AS SIMILARITY FROM INCIDENT_VECTORS I CROSS JOIN QUERY_VECTOR Q ORDER BY SIMILARITY DESC LIMIT 3; That's the basic mechanism.
For this illustrative example, we're calculating similarity against a tiny table. It's not a proposed production retrieval architecture for millions of documents.
More importantly, this SQL demonstrates how to retrieve candidates, not whether the chosen model retrieves the right candidates.
Those are two different problems.
And no, I haven't run this example across all eight models and discovered a secret winner. There are no fabricated benchmarks hiding behind the curtain.
The goal here is to make the model-selection process understandable and reproducible.
Round 5: When the nearest neighbor is still wrong
Here's my favorite trap in semantic search.
A user asks:
"How do I resolve error ERR_RECON_042?"
The system retrieves a document discussing reconciliation errors.
Great semantic match. Wrong error code.
The correct document contains ERR_RECON_042, but a different document talks about similar failures in more natural language. The embedding model prefers the descriptive document. Now the LLM receives the wrong evidence and writes a perfectly polished answer.
We've successfully automated being confidently incorrect.
This is why I wouldn't build enterprise retrieval around vector similarity alone. Exact identifiers, error codes, schema names, version numbers, and product IDs often deserve lexical matching. Semantic search helps when people describe the same problem differently. Keyword search helps when the exact characters matter. Both can be useful.
Cortex Search supports hybrid retrieval, making it worth evaluating for applications that need semantic and lexical matching together.
The right question isn't always "Which embedding model should I use?"
Sometimes it's "Why am I asking an embedding model to solve a problem that exact matching handles better?" A screwdriver isn't a bad tool because it struggles with nails.
Round 6: The migration nobody budgeted for
Let's say you've embedded two million documents using snowflake-arctic-embed-m-v1.5.
Your application works.
Six months later, a new model looks promising. Someone changes the model name used to generate query embeddings.
Done?
Not even close.
The stored documents were embedded with the old model. Your queries now use a different model. Even if two models return vectors with identical dimensions, their embedding spaces aren't necessarily compatible. And if one returns 768 dimensions while the other returns 1,024, the mismatch is even more obvious.
So switching models isn't just a configuration change.
It's a data migration.
You may need to regenerate embeddings for the corpus, maintain parallel indexes, measure retrieval changes, and coordinate the cutover.
I'd track at least:
- The embedding model identifier.
- The embedding version or generation configuration.
- The source document version.
- The chunking strategy.
- The time the embedding was generated.
This may sound like too much metadata for a vector. Until someone asks why search behavior changed last Tuesday. Then suddenly everyone loves metadata.
The judges' scorecard
If I were evaluating embedding models for a real enterprise application, I wouldn't start with a leaderboard.
I'd start with a set of questions and known relevant documents. For an initial experiment, something like 100–200 representative queries could help expose failure patterns, although broader testing would be needed before making general performance claims.
I'd include straightforward questions, ambiguous queries, similar-but-wrong incidents, multilingual examples, and cases with no valid answer. Then I'd compare candidate models against the same data.
Here's the scorecard I'd use:
| Measure | What it tells me |
|---|---|
| Recall@5 | Did the correct evidence make the top five? |
| MRR | How high did the first relevant result appear? |
| nDCG@10 | Were the most relevant results ranked appropriately? |
| Query latency | How quickly can the model process a search query? |
| Ingestion cost | What does it cost to embed the document collection? |
| Re-embedding cost | How expensive is a future model migration? |
| Failure analysis | What kinds of questions does the model get wrong? |
I'd measure actual costs using Snowflake's current pricing and usage information rather than infer them from vector dimensions. And I'd pay special attention to the failures.
Suppose Model A retrieves the correct document for 94 out of 100 questions. Model B succeeds on 96.
Model B wins, right?
Maybe.
What were those two extra questions?
A routine FAQ? Or an incident where retrieving an outdated fix could cause another production outage?
Raw accuracy alone doesn't tell you which failure matters more.
That's the problem with declaring winners before understanding the workload.
One more thing: your trial account might disagree
There's a practical issue worth mentioning. You can have unused Snowflake trial credits and still be blocked from calling certain Cortex embedding functions.
For example, a trial account may return an error indicating that an internal embedding function isn't available. That isn't proof that the SQL syntax is wrong or the requested model doesn't exist.
Account eligibility, regional availability, permissions, and service access all matter. Before writing a benchmark, verify that the account can actually invoke the candidate models. It's a small step that can save an afternoon of debugging the wrong thing.
Ask me how I know.
Post-match analysis
After looking at the options, here's how I'd approach model selection.
- For short, mostly English documents: Start with a compact English-focused baseline such as Arctic Embed M v1.5. Move to larger models when measured retrieval quality justifies it.
- For multilingual content: Evaluate
multilingual-e5-large, Arctic Embed L v2.0, and Voyage Multilingual 2 against actual cross-language queries. - For long documents: Test longer-context models, but compare them against sensible chunking strategies.
- For error codes and technical identifiers: Don't force embeddings to do everything. Evaluate hybrid retrieval.
- For enterprise deployment: Track model versions and plan for re-embedding before somebody decides to swap models on a Friday afternoon.
And for every category, verify model availability, pricing, and restrictions in your Snowflake region.
This isn't a universal ranking. It's a shortlist of where I'd begin testing.
The verdict
Snowflake Cortex makes generating embeddings easy. Choosing the right model is still your responsibility.
Eight models don't mean eight levels of intelligence. A larger vector doesn't guarantee a better match. A longer context window doesn't eliminate chunking. And multilingual support doesn't guarantee that every language or technical domain performs equally well.
A model can retrieve something semantically similar and still miss the evidence your application needs. That's the part worth testing.
If I had to make the decision tomorrow, I'd start with a simple baseline, build a representative evaluation set, and bring in more capable models only when they solve a measured problem.
Because the embedding model isn't supposed to win a beauty contest.
It's supposed to find the right document. And when it doesn't, I'd much rather know that before the LLM writes three paragraphs explaining the wrong answer.
References
- Snowflake: AI_EMBED function
- Snowflake: Vector Embeddings
- Snowflake: Cortex Search Overview
- Snowflake: Cortex AI Model and Regional Availability
Author’s note: The scenarios and SQL examples in this article are illustrative. They are not drawn from confidential systems, and no comparative benchmark results are claimed.
