Multilingual Search: Why Translation Is Not Enough

A document search system built and tested in English usually works. The same system, pointed at a corpus in Turkish, Russian, Persian and Chinese, usually does not. The failure is rarely obvious. Results still come back, the model still produces a fluent answer, and nobody notices that the right document was never retrieved.

Multilingual retrieval is not English retrieval with a translation step bolted on. The problems sit in the tokenizer, in the embedding space, in the ranking layer and in the evaluation set, and each one has to be handled deliberately.

The first mistake: translate then search

The obvious approach is to translate every query into the language of the corpus, or translate the whole corpus into English, then search normally.

Both versions lose information at exactly the point where precision matters. Machine translation is optimised for fluency, not for terminological fidelity, so it substitutes near-synonyms freely. In an ordinary sentence that is harmless. In a regulatory document, a product specification or a contract clause, the near-synonym is a different legal category. A term that maps to one precise concept in the source language arrives as a general word in English, and the search that follows is looking for the wrong thing.

Translating the corpus has a second problem: it doubles your data and freezes it. Every source update requires re-translation, and the translated copy is now an artefact that can drift from the original without anyone noticing. When a user disputes an answer, you have to explain which version the system actually read.

Translation has a place, but it belongs at the presentation layer — showing a retrieved passage to a user in their language — not in the middle of the retrieval path.

Tokenization breaks before anything else does

Retrieval systems split text into tokens before doing anything with it. That splitting behaves differently across languages, and the differences are structural rather than cosmetic.

Agglutinative languages build meaning through suffixes. Turkish attaches case, possession, number and tense to a stem, so a single concept appears in many surface forms across a corpus. Keyword matching on surface forms will miss most of them. Stemming and lemmatisation are not optional preprocessing niceties here; without them, recall collapses.

Languages without spaces need segmentation. Chinese and Japanese have no word boundaries, so segmentation is a modelling decision rather than a parsing step. Segment differently and you get different units, different matches, and different results for the same query.

Scripts carry variants. Arabic-script languages including Persian have optional diacritics and multiple Unicode forms for visually identical characters. Cyrillic and Latin transliterations of the same name coexist in the same corpus. Turkish has the dotted and dotless i, which means naive lowercasing corrupts words outright.

Token budgets are not equal. Text in a non-Latin script often consumes considerably more tokens than the same content in English, which changes how much context fits in a prompt and what a call costs. A chunking strategy tuned on English will produce oversized chunks in some languages and fragments in others.

Normalisation has to be defined per language and applied identically at indexing time and at query time. A mismatch between the two — normalising documents one way and queries another — produces a system that silently fails to match text it has already stored.

Embeddings are not automatically cross-lingual

Modern retrieval uses embeddings: text is converted to vectors, and similar meanings sit close together. Multilingual embedding models aim to place the same meaning from different languages in the same region of that space, so a Turkish query can find a Russian document.

They do this imperfectly, and in ways worth knowing before you rely on it.

Alignment quality varies by language pair, and it depends heavily on how much text in each language the model saw during training. Well-resourced pairs align closely. Pairs involving languages with less training data align more loosely, and the gap widens on technical vocabulary that appears rarely in general web text.

There is also a clustering effect: documents in the same language as the query often score higher simply because they share a language, not because they are more relevant. Without correction, a Turkish query returns Turkish documents and quietly ignores a more relevant Russian one.

Domain vocabulary is the sharpest edge. Trade, legal and medical terms frequently do not have clean equivalents across languages, and a general-purpose embedding model has no reason to know that two very different-looking terms denote the same regulatory category.

What actually works

The designs that hold up in production share a few properties.

Hybrid retrieval. Combine dense vector search with lexical search rather than choosing one. Lexical matching catches exact identifiers — codes, article numbers, product references, proper nouns — that embeddings blur together. Dense search catches paraphrase and cross-lingual meaning. Each covers the other's failure mode, and identifiers are exactly what technical users search for.

Language-aware indexing. Detect and store the language of each document and each chunk as metadata. That lets you normalise correctly per language, filter when a user needs sources in a specific language, and detect the clustering bias by measuring which languages get returned for which queries.

Terminology anchoring. Where a domain has controlled vocabulary — classification codes, standardised nomenclature, official term lists — map it explicitly rather than hoping the embedding model inferred it. A curated mapping from terms in each language to a canonical concept is unglamorous work, and it outperforms a better embedding model on the queries that matter most.

Reranking. Retrieve a wide candidate set, then rerank it with a model that scores query and passage together. Reranking is where much of the cross-lingual accuracy is recovered, because a reranker reads both texts jointly instead of comparing two independently produced vectors.

Answer in the user's language, cite in the source language. Generate the response in whatever language the user wrote in, but show the citation as the original passage. Users who read the source language can verify the claim, and nothing in the audit trail depends on a translation.

Evaluation has to be per language

A single aggregate accuracy figure hides everything that matters here. A system can look healthy overall while failing badly in one language, because the languages with the most documents dominate the average.

Build evaluation sets separately for each language you support, with real queries in that language, judged by someone who reads it. Then measure retrieval and generation separately. The question "was the correct passage in the candidate set" has to be answered before "was the answer faithful", because a good answer drawn from a wrong passage still scores well on fluency.

Cross-lingual cases need their own test set: a query in one language whose correct answer lives in a document in another. Those are the cases a monolingual test suite will never exercise, and they are the reason a multilingual system exists at all.

How this shows up in our work

Ara, our trade intelligence agent, is in development, and multilingual retrieval is the core of the problem rather than a feature on top of it. It is built for the Türkiye–Iran–Caucasus–Central Asia corridor, where the regulatory sources that answer a single question are published in different languages by different authorities, and where a trader asks the question in a fourth. Classification codes and documentation requirements are exactly the kind of controlled vocabulary that rewards explicit terminology mapping over general-purpose embeddings.

The same constraints shape Hublinkly, our B2B trade network, which is in beta. Members write RFQs and product descriptions in their own languages, and matching them means comparing meaning across those languages rather than matching strings.

If you are building search over a multilingual corpus, the first useful question is not which embedding model to use. It is whether your tokenization, your normalisation and your evaluation set treat each language as its own problem.

https://hublinktech.com/en/hublinkly https://hublinktech.com/en/services/business-intelligence https://hublinktech.com/en/blog/rag-vs-fine-tuning-what-each-one-fixes https://hublinktech.com/en/services/saas