Toutes les publications

PaLM 2 : le multilingue comme contrainte d'architecture

MultilingueRAGArchitectureDonnées2023-05-1010 min

Rédiger dans une langue et répondre dans dix casse la recherche documentaire si l'index ne gère pas la correspondance entre langues. Ce n'est pas un réglage.

Le vrai problème n'est pas la génération

Un modèle récent répond correctement dans une dizaine de langues ; c'est la recherche, pas la rédaction, qui casse en contexte multilingue. L'arrivée de PaLM 2 met l'accent sur cette capacité, et déplace la difficulté d'un cran sans que ce déplacement soit annoncé.

Le cas typique : une organisation rédige sa documentation en français et reçoit des questions en anglais, en espagnol, en allemand. Le modèle saura formuler la réponse dans la bonne langue, sans effort particulier. Encore faut-il qu'il ait reçu le bon document, et c'est là que ça échoue, silencieusement.

Schéma d'une question posée en français qui retrouve un document rédigé en anglais
Sans index multilingue, une question dans une langue ne retrouve pas un document rédigé dans une autre.

Pourquoi l'index décide de tout

Un modèle d'embarquement entraîné surtout sur l'anglais place les textes français loin de leurs équivalents anglais, et la recherche croisée s'effondre. C'est un point technique précis, découvert tard dans la plupart des projets internationaux que j'ai repris.

Le symptôme est reconnaissable entre tous : le système fonctionne parfaitement pour les utilisateurs francophones, et rend des réponses vides ou hors sujet pour les autres. On soupçonne le modèle, on ajuste le prompt, on augmente le nombre d'extraits, et rien ne change, parce que le problème est en amont, dans la récupération.

Le mécanisme sous-jacent est expliqué dans les embeddings expliqués à une direction. Retenir ceci : la proximité de sens est calculée par un modèle, ce modèle a été entraîné sur un corpus, et si ce corpus est majoritairement anglophone, la notion de proximité qu'il encode l'est aussi.

Les quatre décisions à prendre en contexte multilingue

  • Choisir un modèle d'embarquement explicitement multilingue, et le vérifier sur vos propres paires de langues plutôt que sur une fiche produit.
  • Constituer un jeu de tests par langue. Trente cas en français ne disent rien du comportement en allemand. Voir l'évaluation continue.
  • Décider de la langue d'autorité. Si la version française et la version anglaise d'une procédure divergent, laquelle fait foi ? La question est organisationnelle, pas technique, et personne ne la pose spontanément.
  • Afficher la langue de la source avec la réponse. Un utilisateur qui reçoit une réponse en espagnol tirée d'un document français doit pouvoir le savoir, et remonter au document.

Le cas de la traduction à l'indexation

Traduire tout le corpus dans une langue pivot avant de l'indexer est une option viable, et souvent la plus simple à exploiter. Elle a un coût, la traduction elle-même, et sa mise à jour à chaque évolution du document, mais elle supprime entièrement la question de la correspondance entre langues.

Je la recommande quand le corpus est stable et le nombre de langues élevé : une documentation réglementaire, un référentiel produit, un catalogue technique. À l'inverse, sur un corpus qui bouge chaque semaine, la double maintenance devient vite ingérable et un index nativement multilingue est préférable.

Dans les deux cas, la décision doit être prise au cadrage. La reprendre après coup impose une réindexation complète du corpus, ce qui est techniquement simple mais coûteux en temps de calcul et surtout en confiance : les utilisateurs qui ont eu de mauvaises réponses pendant trois mois ne reviennent pas d'eux-mêmes. C'est un cas particulier de la dette technique d'un système d'IA.

Le test qui révèle le problème en dix minutes

Prendre dix questions réelles, les traduire dans chaque langue d'usage, et vérifier que le même document remonte. Si les résultats divergent selon la langue de la question, l'index n'est pas multilingue, et aucun réglage de prompt ne le corrigera.

Ce que ça implique pour les secteurs concernés

Toute organisation qui vend hors de son marché domestique rencontre ce problème, et il est presque toujours découvert en production. Le luxe et le retail, le tourisme, l'industrie exportatrice, les services financiers : la documentation est produite dans une langue et servie dans dix.

Le traiter au cadrage coûte le choix d'un modèle d'embarquement et un jeu de tests par langue, soit deux jours de travail. Le traiter après la mise en service coûte une réindexation complète du corpus, plus la reconquête d'utilisateurs qui ont déjà cessé de s'en servir.

Il existe un cas où le problème se manifeste même sans intention internationale : un corpus francophone contenant des documents techniques rédigés en anglais, ce qui est la norme en informatique, en pharmacie et en aéronautique. L'organisation se croit monolingue, son corpus ne l'est pas, et les questions portant sur les documents anglophones échouent sans explication apparente.

Questions fréquentes

Un modèle multilingue suffit-il à traiter un corpus multilingue ?

Non. Le modèle de génération et le modèle d'embarquement sont deux composants distincts. Un excellent modèle de génération ne compense pas un index qui ne retrouve pas les bons documents.

Faut-il traduire le corpus ou utiliser un index multilingue ?

Traduire convient à un corpus stable et à un grand nombre de langues. Un index nativement multilingue convient à un corpus qui bouge souvent, où la double maintenance deviendrait ingérable.

Comment savoir si mon index gère vraiment le multilingue ?

En posant les mêmes dix questions dans chaque langue d'usage et en vérifiant que les mêmes documents remontent. C'est un test de dix minutes qui évite plusieurs semaines de diagnostic.

Le problème existe-t-il dans une organisation monolingue ?

Oui, dès que le corpus contient des documents techniques en anglais, ce qui est la norme en informatique, en pharmacie et en aéronautique. L'organisation se croit monolingue, son corpus ne l'est pas.