De la révolution des mémoires
Les mémoires de traduction remontent à plus de 40 ans déjà. C'étaient de simples bases de données interrogeables par le language SQL (Pour langage de requête structuré). Ce language est très intuitif car pour trouver la phrase "Arrêtez le moteur", dans une table qui s'appelle segments, la requête est exprimée tout simplement par : "SELECT * FROM segments WHERE colonne1 = 'Arrêtez le moteur'". Si on veut que la table nous donne cette phrase qui se trouve au sein d'une phrase plus longue, la requête sera "SELECT * FROM segments WHERE colonne1 ilike '%Arrêtez le moteur%'". Dans ce dernier cas, la requête va afficher la phrase même si elle est précédée par un texte et suivie par un autre texte, comme par exemple "Avant tout entretien, arrêtez le moteur et débranchez son alimentation".
Mais vous remarquez que dans ce type de mémoire, c'est une formulation textuelle que le système recherche. Si vous changez "Arrêtez le moteur" par "Coupez le moteur", le système ne trouvera rien alors que la signification est la même. C'est là évidemment une limite structurelle importante. Et pour la dépasser, il a fallu l'avènement de l'intelligence artificielle ou plutôt les outils de l'intelligence artificielle et dont la vectorisation est la plus importante.
A la révolution des vecteurs
La notion de vecteurs est à la base de l’intelligence artificielle, car celle-ci, contrairement à ce que son nom laisse entendre, ne comprend pas le texte comme le ferait un être humain : elle le transforme en représentations numériques appelées vecteurs. Chaque vecteur est constitué d’un ensemble de valeurs numériques représentant les caractéristiques du texte. Rappelez-vous le titre du célèbre article publié en 2017 par Ashish Vaswani et plusieurs chercheurs de Google : « Attention Is All You Need ». Le mécanisme d’attention permet au modèle d’attribuer une importance différente aux relations entre les tokens en fonction de leur contexte. Ces représentations vectorielles et ces mécanismes d’attention constituent le socle commun des grands modèles de langage (LLM) et des nouvelles mémoires de traduction.
Dans ces mémoires, les segments sources et cibles sont stockés dans des colonnes au format texte. Ces textes restent indispensables à la restitution et à la vérification des traductions, mais une autre colonne devient prédominante pour effectuer la recherche : la colonne vectorielle. Rappelez-vous qu’une table de base de données est constituée de colonnes et de lignes.
Le vecteur enregistré dans cette colonne est généré par un modèle d’embedding reposant sur une architecture appelée Transformer. Le segment source est d’abord découpé par un tokenizer en tokens, qui correspondent à des mots, à des parties de mots ou à des signes de ponctuation. Le modèle transforme ensuite ces tokens en vecteurs de 1 024 dimensions en partant du vecteur initial associé à chaque token. C'est le cas pour le modèle BGE-M3 mais le nombre de dimensions peut varier selon les modèles.
Les vecteurs sont affinés à travers les 24 couches du Transformer, qui les modifie en fonction du vecteur initial de chaque token, de sa position dans le segment et des relations avec les autres tokens du segment. Après ces 24 couches, les vecteurs des tokens sont contextualisés, puis agrégés afin de produire un seul vecteur de 1 024 dimensions représentant l’ensemble du segment. Les valeurs de ce vecteur final n’ont plus de signification directement interprétable séparément : c’est leur combinaison qui représente le contenu sémantique du segment.
Avec les vecteurs, place au calcul mathématique
Une fois rassurés sur nos précieux vecteurs, tout devient simple. L’utilisateur va envoyer une requête à notre système en lui demandant : « Trouve-moi la traduction de la phrase “Avant chaque entretien, arrêtez le moteur”. »
Notre modèle de tokenisation et de transformation va découper la phrase recherchée en tokens, puis la transformer en un vecteur. C’est ce vecteur qui est envoyé à la base de données vectorielle pour effectuer la recherche, et non le texte lui-même.
La base va alors réaliser une opération de comparaison qui vous rappellera sûrement vos cours de terminale : le calcul sur les vecteurs. Elle recherchera, parmi les vecteurs stockés, celui qui présente la similarité cosinus la plus élevée avec le vecteur de la phrase recherchée.
Cette similarité entre le vecteur recherché (A) et un vecteur stocké (B) est calculée selon la formule suivante : Similarité (A, B) = (A · B) / (‖A‖ × ‖B‖)
Autrement dit, la similarité est égale au produit scalaire des vecteurs A et B, divisé par le produit de leurs longueurs. Et plus cette valeur est proche de 1, plus la similarité est élevée (si les deux vecteurs ont la même direction, leur angle va être proche de 0 et par conséquent leur cosinus est proche de 1).
Et voilà qu'on entre dans le royaume des mémoires "pensantes"
Nous avons vu que le vecteur final attribué à chaque segment par le modèle tokenizer-tranformer tient compte de la valeur de base de chaque token, de son emplacement dans segment et de la valeur des tokens qui l'entourent. Or, pour un tokenizer-transformer qui se respecte le segment "Arrêtez le moteur avant chaque entretien" et le segment "avant chaque opération de maintenance, vous devez couper le moteur" signifie la même chose et il y a de fortes chances que leur vecteur final présente une similarité élevée. Donc que vous demandez la traduction du premier ou du deuxième segment, il y aura de fortes chances que la proposition de traduction qui vous sera soumise soit la même.
C'est ce qu'on appelle la recherche sémantique vectorielle.
La chaîne vectorielle et les modèles de traduction automatique
Le marché a vu apparaître de bons modèles de traduction automatique comme DeepL, ModernMT et d’autres. DeepL next-gen, l’un des plus avancés de ces modèles actuellement, peut exploiter les résultats d’une recherche dans les mémoires de traduction comme informations de contexte pour guider sa traduction. Il permet également de connecter les mémoires et les glossaires des utilisateurs. Les traductions existantes peuvent alors être directement réutilisées lorsqu’une correspondance est trouvée ; pour les autres segments, son moteur génère une nouvelle traduction en s’inspirant de la terminologie et du style qui lui ont été soumis.
Pour résumer schématiquement, voici le type d’instruction qui pourrait être soumis à un modèle comme DeepL next-gen : « Voilà notre mémoire de traduction, nos glossaires et notre document à traduire. Nous vous demandons de traduire le document en vous inspirant de la terminologie fournie et des traductions stockées dans notre mémoire. » Les concordances parfaites peuvent être récupérées telles quelles. Le reste du document est traduit en tenant compte du glossaire et des ressources linguistiques fournies.
C’est certes un progrès par rapport aux anciens modèles, mais celui-ci a un prix : dépendance à l’infrastructure de DeepL, absence de maîtrise du fonctionnement du moteur et de la mise à jour des mémoires, ainsi que des enjeux de souveraineté et de confidentialité liés au recours à un prestataire extérieur.
La solution des mémoires sémantiques adaptatives
La brèche laissée ouverte par un modèle comme DeepL next-gen, aussi avancé soit-il, peut être comblée par la technologie des mémoires sémantiques adaptatives. Parmi les éditeurs proposant des technologies adaptatives figurent notamment memoQ AGT et Smartling.
L’un des principes de cette technologie est l’adaptation des fuzzy matches. Là, le prompt peut être plus précis : « Voilà le segment source et le segment cible d’une ancienne traduction, ainsi qu’un nouveau segment pour lequel nous avons trouvé une forte similarité avec le segment déjà traduit. Je te demande d’adapter la traduction fournie au nouveau segment source, sans tout retraduire. »
Un moteur de traduction automatique classique n’est pas nécessairement conçu pour recevoir une ancienne paire source-cible et adapter directement sa traduction selon une instruction détaillée. Un LLM comme GPT, Claude ou Gemini est particulièrement bien adapté à cette tâche, car il peut comparer les trois segments, repérer leurs différences et modifier uniquement les éléments concernés.
Si vous soumettez à un LLM le prompt ci-dessus avec ces trois données :
Ancien segment source : « Change the engine oil every 300 operating hours or once a year, whichever comes first. »
Ancien segment traduit : « Effectuez la vidange de l’huile moteur toutes les 300 heures de fonctionnement ou une fois par an, selon la première échéance atteinte. »
Nouveau segment à traduire : « The engine oil must be changed every 300 operating hours or every six months, whichever comes first. »
On demandera alors au LLM de conserver autant que possible la construction de la phrase et la terminologie utilisées, et de se contenter d’adapter la traduction au sens du nouveau segment. Il pourra ainsi proposer : « Effectuez la vidange de l’huile moteur toutes les 300 heures de fonctionnement ou tous les six mois, selon la première échéance atteinte. »
La boucle est bouclée : on passe de la recherche textuelle à la recherche sémantique vectorielle puis à l'adaptation sémantique.
Ce qui frappe, au terme de ce parcours, c'est que cette technologie longtemps réservée aux grands éditeurs est en train de se démocratiser. Hier encore, concevoir une mémoire véritablement sémantique et adaptative supposait des moyens de recherche considérables. Aujourd'hui, la vectorisation, les modèles d'embedding et les LLM sont accessibles à tous, souvent en open source.
Les différents acteurs du secteur ne vont plus s'affronter autour de l'accès à ce modèle mais plutôt sur le mode de cet accès. Les grands acteurs, essentiellement les éditeurs de logiciels, vont continuer à pousser vers la perpétuation de la dépendance des utilisateurs à leurs logiciels d'accès propriétaires et à leurs infrastructures. Et c'est normal. Mais les utilisateurs, essentiellement les prestataires de services linguistiques, vont pouvoir envisager des solutions autonomes grâce aux progrès technologiques et à la richesse de l'open source.