Multilingual and cross-lingual retrieval

Read these first

• Asymmetric search
• Multilingual prompting and behavior

What you will know

• Retrieve across languages and measure the drop

  Use fixed relevance judgments and report recall@k or nDCG for each query-language and corpus-language pair instead of one pooled score.

• Choose a genuinely multilingual embedding model

  Verify aligned representations, language and script coverage, domain fit, and low-resource behavior; accepting several input languages does not guarantee cross-language retrieval.

• Build a per-language eval rather than an aggregate one

  Stratify results by language, language pair, script, query type, and sample size so high-volume locales cannot hide a weak tail.

• Decide between translating the query and embedding it natively

  Compare both paths on the same queries while accounting for translation errors, terminology loss, added latency, and translation cost.

• Reproduce a broken locale hidden by aggregate metrics

  Trace a failing language from query normalization through retrieval and ranking, then show how its result is obscured by the overall average.

Chapters

1. 1

   Accepting a language is not aligning its representations

   A card promising support for 100+ languages guarantees the model will accept those languages as input, and says nothing about whether a German query vector lands near the English passage that answers it. Alignment is the property you actually need and the one rarely stated outright. Learn what evidence to demand from a card — training objective, script coverage, low-resource behaviour — and what only measurement can settle.

   Read chapter
2. 2

   The cross-lingual drop is a table of language pairs, not one score

   Take an English query set you have already judged, translate the queries, and run them against the unchanged English corpus with the same judgments and the same cutoff: the gap between the monolingual and cross-lingual runs is the number no model card gives you. Report it for each query-language and corpus-language pair, because a single pooled figure describes no actual user's experience. State the instrument's bias in the same breath as its result — translated queries inherit English phrasing and length, while real native queries are shorter, carry local terminology and code-switch, so this proxy flatters cross-lingual health for precisely the locales you are most worried about. It is a first read, to be replaced with genuine native queries wherever a locale matters.

   Read chapter
3. 3

   A retriever prefers a document in the query's own language, right or wrong

   Any system serving fourteen locales has the same policy sitting in three languages, which turns the question from how well a German query reaches an English passage into which of several candidates comes back. Same-language similarity is inflated by shared script, shared vocabulary and shared surface form, so a mediocre German paraphrase routinely outranks the authoritative English original that actually answers the question — and the failure presents as a relevance problem rather than a language one. Fill the grid in properly, every query language against every corpus language, reporting the diagonal separately from the off-diagonal cells. Then make the retrieval policy explicit instead of leaving it to whichever vector scored highest.

   Read chapter
4. 4

   A locale at 2% of traffic can fail totally and move nothing

   Fourteen locales, an aggregate recall@10 of 0.84, and Turkish sitting at 0.15 are arithmetically consistent: at two percent of traffic, complete failure costs under two points and the dashboard stays green all quarter. Stratify by query language crossed with corpus language, plus script and query type, and print the sample count beside every cell so a thin stratum cannot pass itself off as evidence.

   Read chapter
5. 5

   Tokeniser fragmentation is the overlooked cause of a broken locale

   Follow a failing Turkish query from normalisation, where case folding mangles the dotted and dotless i, into a tokeniser that shatters agglutinative words into far more tokens than their English equivalents, eating the sequence budget and clipping content before it is ever embedded. Reproduce the locale end to end, then carry four arguments into the conversation with the exec asking why two percent of users deserve a sprint: two percent of queries is not two percent of contract value or of the accounts up for renewal; 0.15 is a broken product rather than a degraded one; the aggregate that stayed green all quarter is now known to be uninformative for every thin stratum and not only this one; and the fix sits in normalisation and tokenisation, so it is bought once for a group of tail locales rather than for Turkish alone.

   Read chapter
6. 6

   Translate the query or embed it natively: each path loses something

   Machine-translating a Spanish query into English lets you point a strong English-only encoder at an English legal corpus, at the cost of terminology with no clean equivalent, plus latency, spend, and a second service that can fail on its own. Embedding natively removes the hop but only works where representations are genuinely aligned. Run both over the same queries, commit to one, and know what breaks in the path you rejected.

   Read chapter