Bien débuter son projet d’IA générative

Une stratégie en cinq phases

Néanmoins, Laurent Daudet, président, CTO et cofondateur de la startup LightOn constate que les entreprises se posent encore de nombreuses questions pour tenter d’adopter cette technologie en pratique. Pour ce faire, il convient, selon lui, d’établir un flux de travail en cinq phases afin de structurer les enjeux et les réponses à apporter.

1. Établir le ou les cas d’usage (et la gouvernance de données)

Ce flux de travail commence par les cas d’usage. « Il faut partir de cas d’usage et (c’est extrêmement important) établir une métrique quantitative pour mesurer le succès », souligne le président et CTO de LightOn. « Par exemple, une des exigences peut être : “avec mon système de question-réponse, je veux que l’on puisse trouver l’information dans 80 % des cas en moins de quinze secondes” ».

Encore faut-il comprendre les cas d’usage les plus pertinents des grands modèles de langage.

« Dès que vous avez du texte en entrée et du texte en sortie, les LLM peuvent automatiser tout ou partie des tâches à effectuer », résume-t-il.

Voilà pour la théorie. En pratique, ces modèles sont actuellement utilisés pour générer des contenus : des courriels marketing, des fiches produits personnalisées suivant les cibles et les supports, des maquettes, des modèles de courriers administratifs, etc.

Ils peuvent aussi être utilisés en complément ou en remplacement d’un chatbot, dans le cadre de la relation client.

Néanmoins, le cas d’usage le plus réclamé par les prospects et les clients de LightOn « est la mise en place de systèmes de questions-réponses sur des corpus documentaires ».

Là encore, beaucoup de départements peuvent représenter des points d’entrée pour lancer des projets d’IA générative. De son côté, LightOn observe que les unités commerciales responsables de la relation client et les services de R&D dotés de grosses bases documentaires sont des candidats idéaux.

 « Dans les départements R&D de grands groupes, les ingénieurs doivent faire avec des systèmes de recherche par mots-clés assez rudimentaires », illustre Laurent Daudet. « Ils n’arrivent pas à trouver l’information, ils ne savent pas ce qu’ils ont produit il y a dix ans ».

Évidemment, il faut définir une base de connaissances qui permettra de cerner le périmètre du cas d’usage. Cela nécessite de poser les enjeux de gouvernance de données.

« Il y a beaucoup de questions concernant la confidentialité des données. Est-ce un enjeu ou non ? », pose Laurent Daudet.

La réponse, de but en blanc, s’avère peu satisfaisante, mais réaliste. « Cela dépend du cas d’usage ». Pour la génération de fiches produits, le risque semble moindre que pour l’accès aux données internes de l’entreprise, « notamment quand il est question des données RH et financières ».

2. Déploiement

En fonction de la nature et des sources de données, l’entreprise peut choisir l’environnement de déploiement ainsi que les connecteurs nécessaires.

« Voulez-vous utiliser une solution SaaS ? Localisée en Europe ? Localisée aux États-Unis ? Voulez-vous un déploiement on-premise ? Du cloud privé ? », liste le dirigeant.

Les clients de LightOn se posent déjà la question du déploiement en production. « Combien d’utilisateurs puis-je servir ? Comment bien dimensionner mon infrastructure ? » Les mesures quantitatives, le périmètre du cas d’usage et le budget de l’entreprise détermineront les réponses à ces interrogations. Les fournisseurs, les intégrateurs, les cabinets de conseil et les éditeurs sont à même d’évaluer les besoins pour leurs clients.

Il est néanmoins difficile de mesurer le retour sur investissement à cette étape, constate Laurent Daudet. « Louer un tenant privé OpenAI sur Azure, on voit combien cela coûte, en revanche, il n’est pas toujours simple de calculer le ROI ».

Puis, se pose la question du choix du LLM. Il existe actuellement des centaines de modèles de langage, propriétaires ou open source, commercialement viables ou non.

« Si vous êtes une entreprise, vous devez choisir votre stratégie. Toutes les stratégies se valent tant que c’est un choix bien compris et bien pensé », résume Laurent Daudet. « Vous pouvez faire le choix du tout propriétaire, mais vous êtes totalement dépendant de la technologie et des conditions commerciales des fournisseurs. Cela peut être très efficace, mais c’est une boîte noire », argue-t-il.

« Vous pouvez décider de tout faire en open source, mais dans ce cas il faut des compétences extrêmement pointues », nuance le dirigeant. « Des acteurs comme LightOn se posent en intermédiaire ».

3. Écriture et gestion des prompts

Une fois que le cas d’usage et que l’infrastructure de destination ont été sélectionnés, il convient de se pencher sur les usages par les administrateurs et les métiers. Certes, les LLM peuvent être interrogés en langage naturel, mais la qualité dépend largement des prompts envoyés en entrée, selon Laurent Daudet. 

« Ce n’est pas évident de faire un bon prompt, cela s’apprend. Un nouveau métier apparaît, celui de prompt engineer, mais il n’existe pas actuellement dans les entreprises », rappelle le président de LightOn.

Il faut donc à la fois établir s’il faut recruter du personnel qualifié capable de murmurer aux oreilles des LLM, mandater les équipes « data » pour réaliser des tests afin de trouver les messages permettant d’obtenir les meilleurs résultats, puis établir les moyens pour partager ces prompts et les méthodologies d’interrogation des modèles aux unités commerciales qui en auront besoin.

« Le prompt engineering est là pour répondre aux cas d’usage », signale Laurent Daudet. En clair, un prompt permet de cerner la tâche à effectuer, la tonalité d’une réponse, sa forme. Cependant, la précision du résultat dépend, pour le moment, de la connexion à des sources de données externes. Ces intégrations peuvent se faire par API, avec certains services, ou plus généralement à partir d’une base de données vectorielle.

4. Évaluation

Dès la mise en place d’un POC, Laurent Daudet recommande de mettre en place les moyens de récolter les avis des utilisateurs. Ces avis doivent permettre aux métiers d’effectuer des retours sur l’application qui intègre un LLM, mais surtout déterminer si les SLO exprimés au lancement du projet sont respectés. « Cela permet de vérifier que j’atteins le ou les objectifs que je me suis fixés », souligne le dirigeant.

Ces retours d’informations sont à la fois manuels, par exemple pour sonder l’intérêt des usagers, mais également automatiques. Il convient d’observer le nombre de requêtes, les temps de réponse, les coûts estimés ou encore le taux d’erreur logiciel ou matériel du système.

La notation des résultats fournis par le modèle de langage peut s’avérer cruciale pour la suite d’un projet.

5. Fine Tuning

Une fois que l’on a testé un à deux mois le LLM sur étagère, c’est à ce moment-là que l’on peut décider ou non de lancer une phase de fine tuning, considère le dirigeant de LightOn.

En principe, il convient d’avoir recours au fine-tuning si et seulement si le prompt engineering ne permet pas d’obtenir des résultats satisfaisants. « Dois-je réellement exploiter le fine-tuning ? Parfois, un LLM sur étagère bien dimensionné, connecté aux bonnes sources de données vectorisées, fait très bien l’affaire », constate Laurent Daudet.

Dans le cas contraire, différentes options sont à envisager. Il existe des formes simples de réglages fins, comme l’intégration d’un corpus documentaire supplémentaire dans la base d’apprentissage d’un modèle. À cheval entre le prompt engineering et le fine-tuning, l’on peut recourir au prompt tuning afin d’intégrer les instructions les plus complexes ou certaines logiques métiers longues à expliquer « dans les couches d’entrée du LLM pour en faciliter l’usage ».

Enfin, il est possible de mettre en place un cycle d’apprentissage par renforcement avec retour d’information humain (reinforcment learning with human feedback, ou RLHF en VO). « C’est un raffinement continu effectué à partir des avis des utilisateurs sur les réponses apportées par le LLM », résume Laurent Daudet. Si cette pratique peut être en partie automatisée, elle réclame néanmoins d’entraîner des modèles de récompense et de faire appel à des experts pour infuser cette connaissance dans le LLM ou le système qui l’orchestre. C’est d’ailleurs sur le RLHF que reposent en grande partie les performances de GPT-4 et de Llama 2.

Dès lors, il faut prendre conscience que ces variantes de fine-tuning nécessitent d’évaluer les coûts humains et informatiques. « Il y a des tâches de fine-tuning pouvant être réalisées en deux heures sur quatre GPU, tandis que d’autres nécessitent trois semaines et une instance dotée de 256 GPU », illustre Laurent Daudet.

Suivant les préceptes de la mouvance MLOps, les cinq phases de cette méthodologie peuvent être répétées afin d’obtenir de meilleurs résultats. Selon toute vraisemblance, les phases de déploiement, de gestion des prompts, d’évaluation et de fine-tuning nécessiteront cette approche cyclique à l’avenir.