Pick the right embedding model for cross-lingual retrieval over 30 languages

MCQ·Medium·4.0 · 0·~1 min·Asked atHugging Face Ltimindtree Turbopuffer

Attempt it

For retrieval across many languages, the right answer is to pick an embedder that was explicitly trained on multilingual data. BGE-M3 from BAAI and multilingual-e5-large from Microsoft are the standard open-weights choices. Cohere embed-multilingual-v3 is the standard hosted choice. These models are trained with a shared embedding space across languages. A query in Spanish and a document in Japanese can land near each other in vector space if they are semantically related. That is the property you need for cross-lingual retrieval. The other options in the question all fail. Picking text-embedding-3-large because of MTEB rank ignores that MTEB is English-dominant; the leaderboard score does not predict multilingual quality. Assuming multilingual capability 'comes for free' from any modern transformer is wrong and shows up immediately in benchmarks. Pre-translating all documents to English adds a translation step in the critical path, which means latency, cost, and a new failure mode (bad translations producing bad retrieval). For a workload across 30 languages including non-Latin scripts, BGE-M3 is the canonical pick.

**The answer is BGE-M3 (or multilingual-e5-large, or Cohere embed-multilingual-v3).** These models are explicitly trained on multilingual data with a shared embedding space across languages. Which is exactly what cross-lingual retrieval requires. The other options in the question each fail a specific way. - **text-embedding-3-large** is English-dominant. Its MTEB score is computed primarily on English tasks. Throw non-Latin script at it and you get vectors clustered in a poorly-trained region of space: high mean cosine to each other, low correlation with actual semantic content, silent recall collapse on non-English queries. - **'Any English model works'** is the most expensive belief in multilingual RAG. Empirically, English-only models score in the 30s on MIRACL (the multilingual retrieval benchmark) while explicitly-multilingual models score in the 60s. - Pre-translate everything to English adds a translation-quality failure mode to the critical path. Translation errors compound with embedding errors. Latency and cost increase. The pattern is rarely worth it when an actually-multilingual embedder exists. **Why BGE-M3 specifically.** Beyond the shared multilingual space, it produces three output types from one forward pass: dense, sparse (learned BM25-style), and multi-vector (ColBERT-style). This makes hybrid retrieval cheap and natural.

TL;DR

Use an explicitly multilingual embedder (BGE-M3 or Cohere embed-multilingual-v3) for cross-lingual retrieval; English-only models silently degrade and pre-translation introduces a new failure mode on the critical path.

Memory aid

Easy to grasp

Imagine asking a librarian to organize a library so readers in five different languages can all find their books. A librarian fluent in all five languages will file each book where every reader can find it, regardless of the language. A librarian fluent only in English will file the English books beautifully and dump the rest into one 'foreign' pile where no reader can find anything specific. Search tools follow the same rule. Pick one trained on many languages and every reader gets a useful shelf. Pick one trained only on English and the non-English books end up in a useless corner.

Key concepts

Embeddings RAG Vector databases

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Multilingual retrieval is one of the places where the wrong default choice ships a silently broken product. A team picks text-embedding-3-large because it tops the MTEB leaderboard, indexes a corpus that contains Spanish, Mandarin, Hindi, and Arabic content, and ships. English queries work fine. Non-English queries return random-looking results. The bug surfaces weeks later through user complaints, not through alerts.

This deep dive walks the structural reason English-only models fail on multilingual content, what a properly-multilingual embedder does differently, why pre-translation is the wrong fix, and how to validate the choice for a specific language mix.

Why English-only embedders silently fail on non-English content

An English-trained embedder has seen relatively little non-English text during training. When it encounters Spanish, Mandarin, Hindi, or Arabic, the tokenizer produces tokens it has seen before (Unicode does not error), and the model produces vectors of the right shape. The retrieval pipeline does not crash. What happens instead is more insidious.

Non-English text gets mapped to a small, under-trained region of the embedding space. Multiple non-English documents, semantically unrelated, cluster near each other because the model has weak representations for any of them and defaults to a generic 'this is foreign text' region.

The recall-collapse pattern

A non-English query embeds into the same under-trained region. Cosine similarity to non-English documents is uniformly high (they are all close in the under-trained region) but uncorrelated with actual semantic relevance. Top-K retrieval returns whichever non-English documents happen to be closest by accident, not by meaning.

Why this is silent

The failure does not produce errors, exceptions, or alerts. The pipeline is happily computing cosine similarities and returning top-K results. If your eval set is English-only, you see no problem. If your monitoring tracks request success rates rather than retrieval quality, you see no problem. The bug surfaces only when a user complains that non-English search is bad, by which time the index has been live for weeks.

What a multilingual embedder does differently

BGE-M3's three-output architecture

Why pre-translation is the wrong fix

Validating the pick on your language mix

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Many global customer-support RAG deployments default to BGE-M3 or Cohere multilingual to avoid per-language pipelines.
Major search products serving non-English markets (Yandex, Naver, Baidu) rely on multilingual or language-specific embedders, not English-only ones.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you validate BGE-M3 versus Cohere embed-multilingual-v3 on your specific language mix?

Build a small labeled retrieval set per target language, embed corpus on both, measure recall@10 per language; one wins on some languages and the other on others.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Picking text-embedding-3-large for a multilingual workload because of its high MTEB score and shipping a system that silently fails on non-Latin scripts.

60 second bullets to scan on the way to the call.

Why English-only embedders fail on non-Latin scripts
Shared multilingual space as a training objective

Primary sources. Browse if you want the original framing.