Au cœur de l’IA générative : Au-delà du buzz, cas concrets et applications en entreprise
L’intelligence artificielle générative, ou Generative AI, est en train de révolutionner le paysage technologique actuel, ouvrant des portes vers des possibilités inédites et prometteuses. D’après Global Data, le marché représentera plus de 30 milliards de dollars de chiffre d’affaires mondial d’ici à 2028.
Cet article s’appuie la conférence de Daoud Chami, Data Scientist chez Positive Thinking Company, donné à l’occasion du salon Big Data & AI 2023.
Il explique d’abord ce qu’est un Large Language Model (LLM) et ce qui le différencie d’un chatbot. Il aborde ensuite les augmentations possibles de ce modèle pour en faire une solution. Puis présente différents cas d’usage des IA génératives en entreprise, qui diffèrent un peu de ceux dont on a l’habitude d’entendre parler, à savoir la génération de contenu. Enfin il revient sur les prérequis et précautions à prendre en compte avant de commencer à utiliser un LLM.
À noter, qu’il est question exclusivement d’IA générative pour du texte et non pour de l’image ou d’autres types de contenus. Car c’est sur les IA génératives qui manipulent du texte qu’il y a actuellement les cas d’usage en entreprise les plus nombreux et les plus intéressants.
Qu’est-ce qu’un Large Language Model ?
Il s’agit d’un modèle de langue, c’est-à-dire d’un modèle statistique qui a pour objectif de prédire le mot ou la lettre qui complète un texte avec le plus de vraisemblance. Il n’y a pas de notion de vérité ou de connaissance, mais uniquement une notion statistique. À ce titre, les LLMs, même les plus performants (comme ChatGPT, Llama ou Bard), se distinguent fonctionnellement assez peu de l’autocomplétion proposée avec un clavier de téléphone.
Ils le font juste beaucoup mieux et arrivent à intégrer des contraintes et des corrélations à une échelle bien plus importante, et c’est pour cela qu’ils apportent d’aussi bons résultats.
Ces modèles-là sont entraînés, calibrés et optimisés de sorte à produire un texte vraisemblable sur la base de grands corpus de texte. Ces contenus peuvent être issus de ce qu’on appelle du contenu web text, donc des grands jeux de données disponibles en ligne, du common crawl, donc des archives de sites web, mais aussi de réseaux sociaux, Wikipédia, … Et pour une plus petite partie de livres. Et ces contenus constituent ce qu’on appelle un lot d’entraînement.
Il y a ensuite une infinité de types d’observation qui vont être mobilisés pour entraîner un modèle. Mais essentiellement il s’agit de demander au modèle de prédire le dernier mot d’un texte sur la base des mots précédents. Ce sont donc des modèles statistiques, avec des corrélations assez complexes, qui vont prédire un ensemble de probabilités sur le mot qui complète le mieux la séquence. Et au fil des réponses, le modèle va être capable d’adapter ses paramètres, donc d’adapter les contraintes statistiques qu’il a apprises, de sorte à fournir une meilleure réponse la fois suivante.
Un LLM a donc pour seule fonction de prédire l’élément suivant d’un texte au sens de l’élément le plus probable et le plus vraisemblable.
À partir de là, il est intéressant de comprendre comment faire pour passer d’un LLM, donc d’un outil qui prédit le terme suivant, à un chatbot, donc à un outil qui est capable d’avoir une conversation.
Quelle différence entre un LLM et un chatbot ?
Pour interagir avec le LLM, on se base sur un prompt, c’est-à-dire un contenu à compléter qui est transmis au modèle. Ce prompt ne contient pas uniquement la question de l’utilisateur, mais comprend aussi ce qu’on appelle un préprompt (ci-dessous en bleu). Il s’agit d’instructions qui permettent de contextualiser la complétion. Et en l’occurrence pour un chatbot, expliquer au LLM que ce qui suit est la transcription d’une conversation entre une IA et une personne, etc.
Mais il n’y a pas d’idée de conversation, là encore il y a seulement l’idée de compléter un texte. À la différence que la complétion s’effectue grâce au pré-prompt, donc un canevas dans lequel la complétion va se faire. Et aussi que le LLM peut compléter sur une durée et un volume qui sont infinis. La complétion du modèle doit donc être interrompue dès lors qu’il a répondu à la question de l’utilisateur, puis on redonne la main à celui-ci.
Donc un LLM effectue de la complétion de texte et peut être augmenté pour alimenter un chatbot, un outil qui simule une conversation. Mais en définitive on reste fondamentalement sur l’utilisation d’un modèle qui ne fait que compléter un texte avec le ou les mots les plus probables.
Chaînes, mémoire et agents ou comment bâtir une application basée sur un LLM ?
Il existe trois façons spécifiques d’augmenter un LLM pour lui donner la capacité de s’intégrer plus facilement dans un cadre de solution applicative.
Pour illustrer cela, les exemples qui vont suivre se basent sur un site e-commerce qui vend du matériel.
Augmentation d’un LLM grâce aux chaînes
La première augmentation que l’on peut utiliser pour faire d’un LLM une solution plus applicative, est ce qu’on va appeler les chaînes.
Une chaîne correspond à un template de prompt. Pour rappel, un prompt est ce qu’on donne à un LLM en vue d’obtenir une complétion. Il est constitué d’un préprompt avec du contenu fixe et du contenu variable.
Par exemple, si sur un site d’e-commerce, on souhaite rediriger les utilisateurs qui prennent contact par message vers le bon service, il est possible d’utiliser un LLM et le concept de chaîne.
L’idée est de créer une requête avec les parties fixes qui sont systématiquement communiquées au LLM, et des parties variables qui vont dépendre du message de l’utilisateur.
Dans ce cas, on considère que l’utilisateur peut prendre contact soit pour se rapprocher du SAV, pour faire une réclamation ou encore pour obtenir des informations sur un produit.
Le message de l’utilisateur va alors être incrusté dans le prompt global avec les parties fixes (en bleu ci-dessous) et c’est l’ensemble qui va être transmis au modèle.
Il y a donc une interface de prétraitement avec ce qu’un utilisateur peut dire et le LLM où les instructions sont données sur la façon de traiter ce contenu-là.
Ici, il s’agit de classification puisqu’il est demandé au LLM de rapprocher la question de l’utilisateur à une catégorie : SAV, réclamation, renseignement. Je contrains alors la façon dont le LLM doit répondre et je transmets cela au modèle pour opérer une classification.
Il s’agit d’un premier concept important : Les contenus fixes sont des contenus constants, qui n’ont pas vocation à changer et il y a les contenus variables qui peuvent provenir d’une source externe, ici d’un utilisateur sur un site. On peut donc finalement considérer que dans le développement d’une application de type LLM, ce n’est pas du code qui est produit, même s’il en faut un minimum pour intégrer tout cela, mais du texte.
Augmentation d’un LLM grâce à la mémoire
Une seconde augmentation possible est ce qu’on va appeler les mémoires.
Il faut savoir qu’un LLM ne peut faire de la complétion que sur une quantité finie de texte. Par exemple, lors d’un échange avec ChatGPT, au bout d’un certain moment le début de l’échange n’est plus accessible au LLM. En effet, quand il complète un texte, le modèle ne le fait qu’en se basant sur un certain nombre de mots précédents. Il n’a pas une mémoire infinie.
Ce qui est un problème lorsqu’on souhaite interroger le modèle sur du contenu en quantité beaucoup plus grande que celle que ce modèle peut initialement traiter.
D’où l’utilité de mettre en place des mémoires, et plus précisément des bases de données vectorielles. Il s’agit d’un concept assez simple : On utilise un LLM en lui fournissant du texte et il répond en redonnant du texte. Mais ce qu’il faut savoir, c’est que, sous le capot, un LLM manipule ce qu’on appelle des vecteurs. Un vecteur est une façon très compressée de représenter du texte. Donc lorsqu’on souhaite interroger un LLM sur des informations qu’il n’a pas à sa disposition, typiquement des informations propres à une entreprise, ou sur une quantité d’informations trop importante, on va vectoriser tous ces contenus. C’est-à-dire les mettre sous une forme très compressée dans une base de données vectorielle.
Ensuite, lorsqu’il y aura une requête sur ce contenu, elle devra aussi être vectorisée, et on va pouvoir récupérer les documents qui ont une représentation vectorielle proche de cette requête. Il s’agira donc de produire un nouveau pré-prompt qui intègre à la fois, la question de notre utilisateur et les documents récupérés qui sont pertinents pour répondre à cette question.
Par exemple, sur un site d’e-commerce, si un utilisateur a une question précise sur un produit, pour laquelle on ne peut répondre qu’en utilisant la notice du produit, cette question va être vectorisée, comparée aux différents documents de la base de données vectorielle pour récupérer les parties du manuel qui peuvent le mieux y répondre et ensuite on va créer une nouvelle requête pour le modèle. On reste toujours dans le même schéma avec cette idée de partie constante et variable.
La mémoire permet donc d’interroger de grands volumes de données, en particulier non structurées, sans avoir de contrainte sur la quantité de données que peut lire un LLM.
Augmentation d’un LLM grâce aux agents
Une autre augmentation possible est ce qu’on appelle les agents.
Ils ont pour objectif, qu’un LLM, en plus de fournir du texte, puisse aussi être opérant, autonome, fournir des instructions et éventuellement les exécuter.
L’idée est d’avoir une requête avec une partie variable et ensuite du code commenté. Le but est de donner au modèle la meilleure façon de répondre à la requête de l’utilisateur en mobilisant le code commenté (qui peut être le code d’une interface de programmation, d’une API, …).
Si par exemple, sur un site d’e-commerce, on souhaite mettre en ligne tous les produits actuellement en brouillon ou éventuellement retirer de la vente tous les articles qui ont une majorité d’avis négatifs, cela correspond à une demande textuelle. Ensuite on peut y associer un certain nombre de fonctions commentées pour que le LLM puisse comprendre comment il peut parvenir à sa fin. Donc un certain nombre de fonctions en Python sont communiquées au modèle pour répondre à la requête.
Il existe des cas d’usage dans lesquels il est possible de manipuler un outil comme Databricks via son API, en partant d’une requête en langage naturel qui va être transformée par le modèle en appel sur l’interface de programmation Databricks, puis exécuter.
Cas d’usages : Autres exemples inspirants
Il y a beaucoup d’autres cas d’usage possibles et à imaginer.
On peut notamment citer la conversion de langage naturel en langage SQL.
Le SQL est un langage qui permet d’interroger des bases de données. Mais grâce au LLM on peut assez facilement convertir une expression en français en une requête à effectuer sur notre base de données. Dans ce cas, idem, il y a un préprompt qui va donner du contexte et cadrer le LLM dans sa complétion, associé à une requête variable.
Un autre cas d’usage, dont on entend beaucoup parler, est la génération de contenu marketing, que ce soit pour LinkedIn ou autre plateforme. Par exemple à partir d’un article sur le web, un LLM peut en effectuer un résumé pour en faire du contenu adapté aux réseaux sociaux. Et ce qui devient intéressant, c’est de se dire qu’il est déjà facilement possible grâce à l’automatisation de récupérer des articles sur des sites spécialisés et de programmer un post sur un réseau social. Mais il manquait la brique pour compresser le texte, le résumer et en faire un contenu pertinent pour les réseaux sociaux. Aujourd’hui, les LLMs peuvent exécuter l’ensemble de ces tâches relativement correctement. (Ce qui ne dispense pas ceux qui s’en servent de relire bien sûr !).
Autre exemple, déjà abordé avec l’explication des chaînes, la classification de texte. Il s’agit donc d’interfaces, d’étapes que l’on met entre un utilisateur et un LLM pour lui expliquer comment traiter du contenu. En l’occurrence cela peut servir pour l’analyse de sentiment, qui est un cas d’usage déjà courant en data science. Et jusqu’alors soit on trouvait un modèle en ligne qui permettait de faire cela automatiquement, ce qui n’est pas toujours possible ou souhaitable, soit un data scientist devait collecter de la donnée, entraîner un modèle à apprendre à reconnaître les contenus positifs et négatifs, … Aujourd’hui avec les LLMs c’est quelque chose qui peut être fait quasiment instantanément. Le coût se limitant à la création de la chaîne et à l’intégration de cette chaîne dans un SI. Il suffit de partager du contenu, par exemple des avis client à un LLM, de lui donner un peu de contexte et des instructions, et ce dernier complète de sorte à produire la séquence la plus vraisemblable pour dire si le commentaire est positif ou négatif.
Ces exemples représentent une infime partie comparée à tout ce qui peut être envisagé avec les LLMs. Mais ils permettent d’avoir un point de vue un peu plus affûté sur les cas d’usage à mettre en place soi-même.
Après il faut tout de même avoir un point de vigilance lors de la réflexion sur les cas d’usage possibles. Quand on commence à être un inspiré, on peut finir par voir des cas d’usage de partout ! Il est donc toujours nécessaire de faire le tri. Pour cela il est possible de se baser sur une matrice, telle que celle-ci :
Avec cette matrice, il est possible de classer les cas d’usage en fonction de leur intérêt métier, de leur complexité technique, en termes d’infra et d’intégration dans un SI, de ROI attendu, etc. Il est alors facile d’identifier les cas d’usage peu complexes et avec une valeur ajoutée intéressante. En anglais, c’est que qu’on appelle les “Low Hanging Fruits”, c’est-à-dire les fruits les plus bas, donc les plus faciles à attraper.
L’idée est de ne pas se lancer sans réflexion, mais d’abord d’identifier et de classer les cas d’usage avant de les sélectionner.
Prérequis et précautions : ce qu’il faut savoir avant de se lancer
Le premier point de vigilance concerne la confidentialité des données. Dans les exemples cités, le prompt va potentiellement se faire sur un LLM qui n’est pas hébergé sur l’un de vos serveurs. En effet, les LLMs sont des modèles assez conséquents, qui ne peuvent le plus souvent pas être exécutés sur des serveurs tels que ceux qu’on peut provisionner ou en tout cas pas avec un prix raisonnable. On passe alors très souvent par un provider externe, ce qui pose la question de la sécurité et de l’utilisation des données transmises. Qu’advient-il de la donnée d’envoi ? Peut-elle être réutilisée ? Comment ? Est-ce qu’il y a des problématiques de RGPD ? Ce sont des considérations à avoir, sur lesquelles il faut investiguer et qui rejoignent les réflexions sur les problématiques d’infra et la complexité d’intégration. Parfois il y a aussi des providers qui proposent d’avoir son propre serveur privé. Donc le LLM est sur un serveur qui nous appartient, mais le coût est forcément plus conséquent.
Mais dans tous les cas, il y a une question de coût car il faudra payer soit le serveur, soit l’accès et la consommation du LLM, et éventuellement des bases de données vectorielles. Il faut donc être capable de calculer et d’anticiper ces coûts de maintenance.
Autre point d’attention : Comment tester un tel outil ? Un LLM, du fait qu’il ne soit pas sur un serveur sur lequel on a la main, et du fait que ce soit aussi un objet extrêmement complexe, n’est pas évident à tester. En particulier, ce n’est pas un objet pour lequel on est certain d’obtenir la réponse souhaitée. Par exemple, dans le cas de la classification on demande au modèle de répondre par 1 pour un avis positif et par 2 pour un avis négatif, mais rien n’empêche le modèle de répondre complètement autre chose et de se lancer dans une longue conversation.
Et outre le test du modèle, il y a aussi un point de vigilance à avoir sur l’interprétation et l’explication des réponses données par le modèle. C’est une problématique de plus en plus courante en intelligence artificielle, qu’on appelle l’XAI (Explainable AI). Il existe un certain nombre de contraintes qui imposent que les solutions d’IA utilisées en entreprise soient interprétables. Mais quid de l’interprétabilité pour un tel modèle avec plusieurs milliards de paramètres.
Et dans la même lignée, comment tester une solution basée sur un LLM ? Quand on livre une solution qui s’appuie sur un LLM, comment mettre en place l’ensemble des tests nécessaires ? Il y a une réflexion à avoir et il existe un fort besoin d’accompagnement cet aspect-là.
Un potentiel à cadrer
Les LLM sont des outils, certes très impressionnants, mais qui finalement ne servent qu’à faire de la complétion. En revanche, il est possible de les augmenter avec de la chaîne, donc une capacité à guider le modèle dans sa complétion, de la mémoire et des agents, donc une capacité à rendre le modèle opérant. Aujourd’hui on est donc capable de passer d’un LLM à une solution applicative.
Il faut toutefois retenir qu’il y a un sujet sur l’identification des cas d’usage. On passe très souvent de pas d’idée initiale, à trop d’idées ou des idées déjà-vu. Il y a donc un vrai besoin de réflexion pour éviter de se lancer sur des cas d’usage soit trop difficiles à atteindre, soit qui apportent peu de valeur ajoutée.
Enfin, ces solutions requièrent des précautions particulières. Il s’agit de challenges spécifiques au LLM, qu’on ne retrouve pas forcément dans les solutions du monde de la Tech en général, ni même dans les solutions de data science en particulier.
Sur le même sujet, nous vous proposons nos vidéos de notre mini-série dédiée au LLM :
Nous publions aussi régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Suivez-nous pour être notifié des prochains articles et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, YouTube, Twitch et Instagram.
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
