IA générative : personnalisation et contextualisation, deux défis pour les entreprises en 2024

Un petit état de l’art des techniques de personnalisation des modèles d’IA générative

Le prompt engineering est une activité – et parfois un métier – consistant à peaufiner les instructions et les questions soumises aux modèles LLM. D’apparence triviale, cette technique réclame de connaître le fonctionnement général des réseaux de neurones et plus particulièrement des modèles NLG et NLP. C’est un travail continu nécessitant de suivre les potentielles évolutions des modèles. Ici, point de phrase magique : il convient d’ajuster les prompts à l’ensemble des tâches qu’une entreprise souhaite effectuer. « Cela demande du temps, de l’expertise. C’est faussement facile », prévient Laurent Daudet, PDG et cofondateur de LightON. « Ce n’est pas parce que vous pouvez l’écrire en français et non pas en langage Python qu’il est simple de rédiger un prompt qui répondra à vos besoins métiers ».

« Ce n’est pas parce que vous pouvez l’écrire en français et non pas en langage Python qu’il est simple de rédiger un prompt qui répondra à vos besoins métiers ».

C’est pourtant la méthode plus abordable techniquement. Elle permet, si les coûts sont maîtrisés, d’obtenir de premiers résultats convenables. En outre, les fenêtres de contexte des grands modèles de langage sont utilisées pour contextualiser une instruction en y ajoutant des exemples. Les fournisseurs de LLM, dont OpenAI, Anthropic, Mistral, Meta ou encore Google ont fait en sorte d’allonger cette fenêtre de contexte, qui joue à la fois le rôle d’accueil des prompts en entrée et de mémoire d’une conversation pour le LLM. Ainsi, ces modèles acceptent des chaînes de consignes plus importantes et peuvent traiter en une fois jusqu’à 500 pages de texte (200 000 tokens), dans le cas de Claude 2.  

La mise en place d’une architecture RAG consiste, elle, à encadrer une instruction ou de compléter la réponse d’un LLM à l’aide d’une base de données compilant un plus grand ensemble de fichiers internes à une entreprise. Ici, la recherche ne s’appuie pas forcément sur des mots clés, mais sur la comparaison de vecteurs. Les documents (généralement du texte, mais l’on peut vectoriser des images, des vidéos et des sons) sont d’abord traités par un modèle dont le rôle est de diviser les portions de texte en tokens (ou unité lexicale) avant d’être soumis à un autre modèle chargé de les transformer en représentations mathématiques. Comme les modèles d’IA générative appliquent le même processus sémantique pour interpréter les instructions ou les questions (un plongement lexical), il est possible de comparer les similarités entre les vecteurs issus des documents et ceux issus des prompts afin d’identifier les informations à retranscrire dans une réponse.

La recherche vectorielle s’impose

LigthON est en train de déployer pour le compte du conseil régional d’Île-de-France un système RAG et un LLM couplés à un chatbot en complément de la base documentaire interne consacré au support informatique. Cela permet de restreindre les réponses au corpus sélectionné, afin d’éviter les erreurs les plus grossières, et d’en indiquer les sources.

« Il y a d’abord le fait de s’assurer que le résultat sera le plus fidèle possible à la recherche dans la base de données. Ensuite, il y a une à deux étapes supplémentaires pour astreindre le modèle – via des instructions et en orchestrant le pipeline du système RAG – à ne répondre qu’avec les extraits à disposition », explique Olga Lopusanschi, responsable de projets chez LightON.

Chez la startup française, cette capacité devient une fonction de sa plateforme Paradigm, nommée « Chat with docs ».

En sus des activités de consultance auprès des entreprises, SIA Partners a lancé SiaGPT, une application SaaS, qui permet également de charger des documents en volume, d’en extraire de l’information et de les interroger en langage naturel. Sa filiale Heka.AI est en train d’intégrer cette même capacité dans RegReview, un outil de veille réglementaire et pourrait le faire pour l’ensemble de ses produits. AWS, Google Cloud, Microsoft Azure, mais aussi OVHcloud entendent faire de ce type d’application des services génériques.

Pour autant, cette technique comporte des limites. « Pour l’instant, cela ne peut pas être déployé à l’échelle avec plus de 100 millions de documents », prévient Laurent Daudet.

Selon Olga Lopusanschi, le plus gros système RAG déployé par LightON embarque environ 100 000 documents. « Cela n’est pas indicatif. Il faut prendre également en compte la taille des documents dans le système », signale-t-elle.

Premier point, les bases de données vectorielles disponibles sur le marché ne seraient pas assez performantes pour assurer cette montée à l’échelle. « D’où l’intérêt de superposer un système RAG par-dessus un moteur de recherche d’entreprise », poursuit Laurent Daudet.

Benoît Bouffard, responsable produit et marketing chez LigthON, illustre cette réalité en évoquant les cas de Google et de Microsoft qui n’ont pas remplacé Chrome et Bing, mais ont intégré les assistants Bard et Copilot dans les interfaces afin de simplifier l’obtention de résultats pertinents.

Or, dans la pratique, un internaute se rend rapidement compte que les réponses de Bard dans Google et Copilot dans Bing sont régulièrement hors sujet.

En découle le deuxième point : à savoir que plus le modèle a de documents à sa disposition, plus le risque d’hallucination est élevé. Il faut alors, potentiellement, effectuer un fine-tuning du LLM.

Fine-tuning des LLM… et des modèles d’embeddings

Le fine-tuning consiste à réentraîner en partie le modèle en y injectant de nouvelles données spécifiques afin d’en modifier les poids et les paramètres. L’approche paraît fastidieuse et coûteuse, mais des techniques telles que PEFT (Parameter Efficient Fine-Tuning) et LoRa (Low Rank Adapation of Large Language Models) visent à réduire considérablement le nombre de paramètres qui seront changés lors de cette deuxième phase d’entraînement. Elles s’averent, qui plus est, moins coûteuses et moins longues que la modification d’un jeu de données de préentraînement. En outre, les géants de la Tech ont mis en place des phases d’apprentissage par renforcement aidés des retours effectués par des utilisateurs finaux (Reinforcment learning with human feedback). Une approche qui commence à intéresser les grands groupes, dont LVMH. Le RLHF doit permettre d’obtenir des réponses fidèles au discours d’une marque et, idéalement, débarrassées de toutes ambiguïtés éthiques.

En résumé, en entraînant les grands modèles de langage avec des données spécifiques au domaine d’activité d’une entreprise, il est possible de restreindre les hallucinations et d’obtenir des résultats plus pertinents.

« Les modèles d’embeddings ne se valent pas tous. Certains d’entre eux offrent de meilleurs résultats que d’autres ».

Afin d’améliorer le bon fonctionnement d’un système RAG, les modèles de vectorisation peuvent aussi être soumis à cette phase de réglage fin. L’idée est de faire en sorte que les mises en relation entre les mots représentés par des vecteurs soient effectuées à l’aune d’un métier, d’une spécialité scientifique, d’un secteur d’activité, etc. « Nous étudions également le fine-tuning de ces modèles d’embeddings », renseigne Olga Lopusanschi. « C’est un travail plus récent que le réglage fin des LLMs, mais c’est une piste que nous explorons ». Pour l’heure, LightON s’appuie sur une combinaison de modèles d’embeddings ouverts compatibles avec les grands modèles de langage, dont Falcon-40B et sa déclinaison fine tunée par la startup, Alfred-40B.

« Les modèles d’embeddings ne se valent pas tous. Certains d’entre eux offrent de meilleurs résultats que d’autres », prévient la responsable de projets chez LightON.

Pour autant, Benoît Bouffard signale que cette spécialisation peut provoquer des régressions linguistiques. « Si le cas d’usage l’exige, il faut réfléchir à la problématique multilingue. Si nous avons des clients français qui interrogent une documentation rédigée en arabe ou en allemand, il faut que le ou les modèles aient la capacité de traduire le résultat dans la langue de l’utilisateur », illustre-t-il.

En clair, il ne s’agit plus de multiplier les démonstrations techniques. « Nous rentrons dans un monde où nous déployons une solution pour plus de 5000 utilisateurs qui peuvent appeler simultanément des documents éparpillés sur un éventail de bases de données, dans des formats et des langues différentes. Là, ça devient un peu plus complexe », poursuit Benoît Bouffard.

Olga Lopusanschi souligne qu’il faut préparer les données à vectoriser en alignant les formats de fichiers et d’encodage afin d’éviter les erreurs ou les incohérences lors de l’utilisation des embeddings ou de leur entraînement. « Nous sommes en train d’automatiser ce système pour rendre nos clients autonomes », indique-t-elle.

C’est sur cette base technique que LightON, SIA Partners, AWS, Microsoft ou encore Google espèrent favoriser le déploiement de l’IA générative à large échelle au sein des entreprises.

Une autre piste pour améliorer les architectures RAG 

Il existe toutefois d’autres pistes, notamment celle explorée par Elastic. L’éditeur considère que, pour bénéficier d'un modèle d’embeddings performant aligné avec un domaine, il convient d’annoter des dizaines de milliers de requêtes. De plus, ces modèles d’embeddings produisent des représentations denses de documents (des phrases, des paragraphes, des paires de questions-réponses, un document entier) dans un espace à dimensions fixes (512, 768, 1024 dimensions, etc.). Or, les chercheurs d’Elastic jugent que ces représentations denses sont difficiles à expliquer. Dits autrement, ces vecteurs denses ne permettent pas forcément d’obtenir des concordances exactes entre une requête et des documents dans une base de données. Ces spécialistes se sont penchés sur les modèles d’interaction tardive (late interaction models), tels ColBERT et Splade.

En principe, les modèles d’interaction tardive « produisent des représentations multivectorielle à la granularité du token », c’est-à-dire à l’échelle d’une chaîne de trois à quatre caractères, le plus souvent une syllabe. Cette approche multivecteur, plus performante parce qu’elle permet de faire comprendre au modèle des relations complexes entre les mots, avait l’inconvénient d’être gourmande en ressources IT au vu du nombre de vecteurs à calculer. Les projets ColBERTv2 et Splade V2 ont respectivement apporté des techniques de compression des vecteurs et l’usage de vecteurs à représentation clairsemée.

Ce sont ces fondamentaux qui ont inspiré l’entraînement du modèle propriétaire Elastic Learned Sparse EncodeR (ELSER). Parce qu’à l’entraînement les documents et les requêtes sont transformés en vecteurs clairsemés, Elastic prétend qu’il n’y a pas besoin d’adapter les embeddings au domaine.

« Notre modèle traite le document et y insère des tokens cachés », explique Matt Riley, directeur général, Enterprise Search chez Elastic auprès du MagIT. « Ces jetons cachés sont associés à des mots clés dans le document. Au moment d’effectuer une recherche, nous pouvons faire correspondre ces tokens cachés avec la recherche et ces jetons sont pondérés en fonction de la confiance du modèle qu’un mot a tel sens ou tel autre dans ce contexte », poursuit-il.

« Par exemple, le mot shingle, qui veut dire zona en anglais, signifie également bardeau et est plus généralement associé à un type de bardeau bitumé qui imite l’apparence d’une ardoise. Le modèle peut donc cacher le mot shingle sous les termes “matériau de couverture” dans le contexte de recherche d’une chaîne de distribution de matériaux de construction », explicite Matt Riley.

« Si l’on examine toutes ces techniques, la recherche vectorielle, l’utilisation de modèles d’interaction tardive comme ELSER ou la recherche par classement de type BM25, nous obtenons généralement de meilleurs résultats en les combinant ».

Entré en disponibilité générale en novembre, ELSER est pour l’instant calibré pour des textes courts en langue anglaise. Le modèle encode les 512 premiers tokens d’un document. En clair, il semble plus évident de l’utiliser pour traiter un extrait ou un résumé d’un document plutôt que le texte en entier. Les performances d’ingestion et d’inférence d’Elasticsearch sont également affectées par l’usage de ce modèle.

Si elle se rapproche des techniques de recherche traditionnelle, selon Matt Riley, l’interaction tardive offre un compromis entre la recherche par mot clé ou synonyme et la recherche vectorielle mises en place par des acteurs comme OpenAI. Néanmoins, Elastic ne se ferme pas à la recherche vectorielle. Elasticsearch prend en charge les vecteurs denses et les algorithmes de recherche de similarité exploités dans les architectures RAG.

Le spécialiste de l’« Enterprise Search » mise sur une évolution de la recherche sémantique, ainsi que sur une hybridation des techniques de recherche traditionnelle.

« Si l’on examine toutes ces techniques, la recherche vectorielle, l’utilisation de modèles d’interaction tardive comme ELSER ou la recherche par classement de type BM25, nous obtenons généralement de meilleurs résultats en les combinant », signale Matt Riley.