RAG multilingue : documents et questions dans des langues différentes

Une entreprise française avec des filiales en Allemagne et en Espagne stocke des contrats en trois langues, mais ses équipes posent leurs questions en français. Un système RAG pensé pour une seule langue rate alors les bons passages, même s'ils existent. Le RAG multilingue répond à ce problème avec trois leviers principaux : des embeddings qui comprennent le sens au-delà des mots, une traduction intelligente au moment de la requête ou de l'indexation, et une recherche par mots-clés adaptée à chaque langue.

Pourquoi le RAG multilingue n'est pas qu'un RAG avec plus de langues

Dans un RAG classique, le pipeline suppose implicitement que la question et les documents partagent la même langue. Le modèle d'embeddings a été entraîné principalement sur cette langue, l'analyseur de recherche plein texte applique les bonnes règles de pluriel et de conjugaison, et personne ne se pose la question de savoir si « contrat de travail » et « employment contract » désignent la même chose.

Dès qu'une entreprise mélange les langues, deux problèmes distincts apparaissent. Le premier touche la recherche sémantique : un vecteur produit pour une phrase en français ne se rapproche pas automatiquement du vecteur produit pour la même idée en anglais, sauf si le modèle d'embeddings a été spécifiquement conçu pour ça. Le second touche la recherche par mots-clés : un moteur plein texte configuré pour le français ne reconnaît pas les racines des mots allemands ou les conjugaisons espagnoles, et inversement. Un système qui ignore ces deux dimensions renvoie des réponses incomplètes, pas parce que l'information n'existe pas, mais parce qu'elle n'a jamais été retrouvée.

Les trois stratégies pour la recherche cross-lingue

Trois approches permettent de retrouver un passage en anglais à partir d'une question en français, ou l'inverse. Elles ne s'excluent pas et sont souvent combinées.

Les embeddings multilingues : chercher par le sens, pas par les mots

Un modèle d'embeddings multilingue est entraîné pour placer des phrases équivalentes dans des langues différentes à proximité dans l'espace vectoriel. « Délai de préavis » et « notice period » obtiennent des vecteurs proches, même si aucun mot n'est partagé. C'est l'approche la plus naturelle pour la recherche cross-lingue : elle ne nécessite ni traduction explicite ni duplication de contenu, et elle s'intègre directement dans un pipeline de recherche sémantique existant.

Sa limite : la qualité varie fortement selon les paires de langues. Les couples très représentés dans les données d'entraînement (anglais-français, anglais-espagnol) fonctionnent bien. Des langues moins dotées, ou des domaines très techniques avec un vocabulaire spécialisé (jurisprudence, normes industrielles), donnent des résultats plus inégaux. Il faut tester, pas supposer.

La traduction de la requête à la volée

Deuxième approche : traduire automatiquement la question posée vers la langue des documents avant de lancer la recherche. Une question en français sur un corpus entièrement en anglais est traduite en anglais, la recherche s'effectue en anglais, puis les passages trouvés (et éventuellement la réponse finale) sont retraduits ou simplement cités tels quels avec leur traduction. Cette approche fonctionne bien quand le corpus est homogène dans une langue connue à l'avance.

L'inconvénient est la latence et le coût : chaque requête ajoute un appel de traduction, et une mauvaise traduction de la question (un terme technique mal rendu) dégrade toute la suite de la recherche, même si le moteur de recherche lui-même est parfait.

La traduction des documents à l'indexation

Troisième option : traduire les documents une seule fois, au moment de l'ingestion, vers une langue pivot (souvent l'anglais), et indexer les deux versions. La requête n'a alors plus besoin d'être traduite si elle est posée dans la langue pivot, et le coût de traduction est payé une fois pour toutes plutôt qu'à chaque question. C'est la stratégie la plus robuste pour un corpus volumineux et stable, mais elle double le volume de contenu à stocker et à maintenir à jour si les documents sources changent.

Stemming et recherche par mots-clés : un piège par langue

La recherche hybride, qui combine recherche plein texte et recherche vectorielle, bat presque toujours une approche purement sémantique. Mais la partie plein texte dépend d'un analyseur linguistique : un stemmer qui réduit un mot à sa racine (« travaillons », « travaillait », « travail » deviennent une seule forme). Ce stemmer doit correspondre à la langue du texte indexé, sinon la recherche par mots-clés échoue silencieusement.

Les pièges les plus fréquents : l'allemand compose des mots longs (« Arbeitsvertrag » pour « contrat de travail ») qui nécessitent une décomposition spécifique ; l'anglais a des formes irrégulières (« went » pour « go ») que les règles françaises ignorent complètement ; et un document qui mélange deux langues dans le même paragraphe (une clause en anglais citée dans un contrat français) dérègle n'importe quel analyseur mono-langue appliqué globalement.

• Détecter automatiquement la langue de chaque document, voire de chaque section, avant indexation
• Appliquer l'analyseur plein texte adapté à cette langue détectée, pas un analyseur unique pour tout le corpus
• Éviter de chunker un document au milieu d'un passage bilingue pour ne pas casser le contexte linguistique d'un fragment
• Vérifier régulièrement que les mots-clés métier spécifiques (acronymes, noms de normes) remontent bien dans les deux langues

Construire un pipeline RAG multilingue concret

Voici l'enchaînement recommandé pour un corpus qui mélange plusieurs langues, du plus simple au plus avancé.

1. Détecter la langue de chaque document à l'ingestion et la conserver comme métadonnée attachée à chaque chunk
2. Choisir un modèle d'embeddings multilingue éprouvé plutôt qu'un modèle optimisé pour une seule langue, même si les performances mono-langue semblent légèrement inférieures
3. Configurer un analyseur de recherche plein texte distinct par langue détectée, pour que le stemming et les règles de pluriel soient appliqués correctement
4. Découper les documents en respectant les frontières linguistiques, voir les stratégies de chunking, pour qu'un chunk ne mélange pas deux langues sauf nécessité (citation, clause contractuelle)
5. Décider si la requête doit être traduite avant recherche ou si les embeddings multilingues suffisent, en fonction du nombre de langues réellement présentes dans le corpus
6. Toujours citer la langue d'origine du passage source dans la réponse, pour que l'utilisateur sache s'il lit une traduction ou le texte original

Sur Kopik, l'indexation hybride (plein texte et recherche sémantique) gère automatiquement cette hétérogénéité au moment où les documents sont découpés et indexés : un contrat en anglais et un avenant en français dans la même base de connaissances restent interrogeables ensemble, sans configuration manuelle d'analyseur par langue de la part de l'utilisateur.

Contrôler la qualité : les vérifications à ne pas sauter

Un pipeline RAG multilingue qui fonctionne sur quelques exemples de démonstration peut échouer silencieusement en production, car les écarts de performance entre paires de langues ne sont pas visibles sans test dédié. Les principes d'évaluation d'un système RAG s'appliquent, avec des vérifications supplémentaires propres au multilingue.

• Construire un jeu de questions-réponses dans chaque langue cible, pas seulement dans la langue principale de l'équipe qui a testé le système
• Vérifier que le rappel (la proportion de bons passages retrouvés) reste stable quand la langue de la question diffère de la langue du document source
• Mesurer si la réponse finale cite bien le passage dans sa langue d'origine, plutôt qu'une reformulation qui s'éloigne du texte source
• Surveiller les cas où une traduction automatique introduit un contresens sur un terme technique ou juridique, qui peut ensuite se propager dans la réponse générée
• Réévaluer régulièrement, car l'ajout de nouveaux documents dans une langue peu représentée peut dégrader silencieusement la qualité globale

Cas d'usage typiques et limites à connaître

Le RAG multilingue est particulièrement utile pour un wiki interne d'un groupe international où la documentation RH existe en plusieurs langues selon les filiales, pour un cabinet qui traite des dossiers juridiques impliquant du droit étranger cité en langue d'origine, ou pour un service client qui doit répondre dans la langue du client à partir d'une base de connaissances produit rédigée en anglais.

La limite à garder en tête : la traduction automatique, aussi bonne soit-elle, reste une approximation. Pour des documents à forte valeur juridique ou réglementaire, mieux vaut toujours renvoyer le passage source dans sa langue d'origine avec citation, plutôt qu'une traduction présentée comme le texte faisant foi. C'est le principe même des réponses sourcées : la traduction aide à comprendre, la citation garantit l'exactitude.

Une base de connaissances interrogée via l'API ou le serveur MCP de Kopik conserve cette distinction : la réponse générée peut être formulée dans la langue de la question, mais les passages cités restent ceux du document original, avec leur langue d'origine visible, ce qui permet à l'utilisateur de vérifier lui-même la correspondance.

Questions fréquentes