Embeddings & Vector Search· Lesson 6 of 7
Embedding Models — Picking the Right One
In one line · An embedding model is what turns your text into a vector, and each one has a different vector size, language coverage, and cost.
Choosing a model that handles Arabic poorly quietly wrecks any Arabic search; the model sets the ceiling for everything downstream in the pipeline.
Like choosing a camera lens: all take photos, but one is sharper for faces and another for landscapes. Pick the model for your language and text type.
Like picking a translator: they all translate, but one raised on Arabic catches the fine distinctions others miss. And the same translator must read both your question and the answer so the meanings line up.
If your content is Arabic, a multilingual model gives far more accurate similarity than an English-only one — try both on the same sample and compare. And note: the same model must embed both the query and the documents; you can't mix models.
An embedding model is a neural network (usually a transformer) trained so that similar texts produce close vectors. When comparing models, look at four things: (1) languages — multilingual or English-only? (2) vector size (dimensions) — bigger isn't always more accurate, but it's always costlier to store and search; (3) input token limit — longer text gets truncated; (4) performance on benchmarks like MTEB and on a sample of your own data. And remember: vector size is fixed by the model, so switching models means re-indexing everything.
🧪 Try it: pick two embedding models (a multilingual one and an English-only one, say) and prepare 10 Arabic sentence pairs: 5 similar in meaning, 5 not. Embed each pair with both models and compute cosine. The better model shows a clear gap between similar-pair and dissimilar-pair scores — and that gap matters more than any general benchmark number.
The biggest mistake: picking a model off a general benchmark leaderboard without testing it on your own data — a model brilliant in English can be dismal in Arabic or in your domain's jargon. Second: assuming 'more dimensions = better' — the extra size costs storage and speed and may add no accuracy. Third: switching to a newer model while keeping the old vectors — you must re-embed every document with the new model before any query.
Invest in model comparison when starting a new system, when your content is in a specific language or domain (Arabic, medical, legal), or when retrieval quality plateaus no matter how much you tune chunking.
Don't reach for a model swap as the first response to any retrieval problem — most issues trace to chunking or the query, not the model, and swapping is the most expensive move (a full re-index). And skip fine-tuning an embedding model before exhausting off-the-shelf options — it's rarely worth the complexity early on.