Private intelligence across languages

Monaco’s Constitution, Article 8, makes French the official language of the State. Private work in the Principality often runs in more than one. A single file can hold a French contract, English correspondence, an Italian valuation and a scanned letter in a fourth language. A private AI system for that work has to find, read and answer across all of them, and say plainly which language each source was in.

This article reflects public research and documentation available in May 2026. Model and benchmark details change fast. The method matters more than any single model named here.

What the model says it supports

Model makers publish the languages they test. The Llama 3.1 model card, for example, lists eight supported languages: English, German, French, Italian, Portuguese, Hindi, Spanish and Thai. It adds that the model was trained on a broader set, and treats use in languages beyond the eight as out of scope unless the developer takes responsibility for it.

That distinction is useful. A model may produce fluent text in a language it was never evaluated in. Fluency is not accuracy. For each language the firm relies on, the question is whether the maker tested it, and whether the firm has tested it on its own documents.

Retrieval across languages

In a retrieval system, the model answers from passages that a search step finds first. That search runs on embeddings: numeric representations of text. If the embedding model handles only one language well, a question in English will miss the French clause that answers it, and the language model never sees it.

Multilingual embedding models aim to place a question and its answer close together even when they are written in different languages. The M3-Embedding paper describes one such model, with support for more than 100 working languages, cross-lingual retrieval and inputs up to 8,192 tokens. Benchmarks such as MMTEB compare embedding models across many languages and tasks.

Benchmarks help build a shortlist. They do not settle the choice. A firm’s documents have their own vocabulary: legal terms, vessel names, company forms, abbreviations. A retrieval test in each working language, and across language pairs, shows which model finds the right passages in this collection.

Normalise text before you index it

Accented characters can be stored in more than one way. The letter “é” may be a single character or a plain “e” followed by a combining accent. On screen they look identical. To a naive search, they differ. Unicode Standard Annex #15 defines normalisation forms that make such sequences comparable. NFC composes characters into their canonical form. NFKC also folds compatibility variants, which changes more and needs more care.

Documents arrive from scanners, email clients, word processors and PDF exports, each with its own habits. Normalising text to a single form at ingestion, and applying the same form to every question, prevents a class of silent misses. The same step handles names that appear with and without accents across files.

Languages cost different amounts of context

Models read text as tokens, not words. Petrov and colleagues showed that the same text, translated into different languages, can produce very different token counts, up to 15 times apart in some cases, and that the gap persists even in tokenizers built for multilingual use. The paper links this to cost, latency, and how much content fits in a model’s context.

In a private system, cost per token is not a bill, but context is still finite. A retrieval budget tuned on English passages may carry fewer passages in another language. The practical step is to measure token counts for real documents in each working language, and set retrieval limits with that spread in view.

Decide the answer language, and keep sources whole

Three rules keep multilingual answers honest:

1. Answer in the language of the question, unless the user asks for another.
2. Quote sources in their original language. A translated quotation presented as the source text is a new text, with new errors.
3. Label every translation as a translation, and link it to the original passage.

Legal and financial terms rarely map one to one. A French term of art and its nearest English equivalent can carry different scope. Keeping the original term beside any translation, and building a short glossary of the firm’s recurring terms, reduces drift. For decisions that turn on wording, the original document governs, and a qualified reader should check it.

Test each language, and each pair

An evaluation for a multilingual firm adds language to every case. The question set holds questions in each working language, questions in one language whose answers sit in another, documents with mixed languages, and scanned pages that need optical character recognition before any of this works. Each answer is reviewed by someone who reads both the question and the source language.

Results often differ by language. A system can serve French and English well and still stumble on a third. That result is useful. It lets the firm use the system where it works and keep a person in the loop where it does not.

Scope, stated plainly

No system handles every language equally. A careful deployment names the languages it was tested in, the pairs it supports for retrieval, and the checks a user should make when working outside them.

To plan a private system around the languages your firm works in, write to contact@desgarde.com.