Le Retrofit de la Gen AI dans vos applications

Introduction

L'arrivée des LLM et de la GenAI est une avancée spectaculaire dans l’informatique. Pour la première fois un système informatique peut répondre à un large éventail de problèmes sans y avoir été programmé (approche classique) ou y avoir été entraîné de manière spécifique (IA prédictive). La GenAI fait passer l’IA de l’ère du spécifique, fait sur mesure à l’ère du générique. De l’ère du spécialiste du deep learning à celui du spécialiste du prompt. Il devient possible d’ajouter à nos applications des fonctionnalités d’IA en appelant un service “sur étagère” et en lui indiquant ce que l’on souhaite faire sans avoir à développer et entraîner un modèle spécifique.

Après l’avènement des assistants GenAI où l’utilisateur interagit directement avec l’IA, la prochaine étape est l’intégration directe de la GenAI au sein des applications. L’utilisateur ne sait pas si une IA classique, une GenIA ou un programme classique fait le travail, l’utilisateur ne crée pas de prompt. Il utilise son application qui gère les appels genAI de manière autonome via API.

Intégrer la Gen AI dans un produit n’est pas fondamentalement différent de l’intégration d’un modèle d’IA discriminant sur étagère voire de n’importe quel service API si nous sommes un peu taquins. Cependant la qualité des données utilisées dans votre application se doit d’être irréprochable. À défaut la GenAI peut amplifier les risques dûs à l’utilisation d’une donnée de mauvaise qualité. Dans la suite de cet article nous faisons le postulat que la qualité de la donnée est acquise.

Comment ajouter des capacités d'IA génératives à vos applications et produits ?

Lorsque vous évaluez comment l'IA générative pourrait être appliquée aux besoins de vos clients ou utilisateurs, vous devez mettre en balance la promesse de nouvelles capacités avec la complexité, les coûts et les contraintes liés à la mise en œuvre de ces technologies.

Nous allons illustrer ici avec un cas simplifié: la mise en place d’une recherche en langage naturel (NLS: Natural Language Search) sur un site e-commerce. Le site est déjà en production et souhaite offrir une expérience “conversational shopping” à ses clients. Avec le NLS, faire ses achats se veut proche d’une interaction avec un vendeur de magasin. Les clients peuvent donner une description même vague de ce dont ils ont besoin au lieu des mots exacts nécessaires pour trouver un article, et l'IA comprendra l'intention et suggérera des options appropriées.

Nous avons fait le choix délibéré de nous appuyer sur le cas d’un site à destination du grand public même si notre recommandation est de commencer à intégrer l’IA générative en priorité sur des applications à destination d’utilisateurs internes ou B2B. Ce choix de site de e-commerce nous permet d’utiliser des notions fonctionnelles connues de tous : produit, recherche, panier, paiement. La fonctionnalité de recherche étant une constante dans toute application de gestion, notre cas d’utilisation peut aisément être transposé à toute application interne ou B2B.

Use case: Un client cherche un produit sur un site e-commerce avec des détails qui vont au-delà du nom de produit par exemple en précisant une caractéristique (dimension, prix, origine, date de disponibilité….). Par exemple: “un canapé en tissu bleu, de longueur maximale 1,8m”. Cette recherche ne retourne aucun résultat aujourd’hui sur un site comme La Redoute

Dans un cas de recherche plus classique, un client peut commettre une erreur de saisie dans le descriptif du produit. Dans l’exemple ci-dessous sur le site de la Fnac une recherche d’un “laptop avec une capacité de disque de 512Gb” ne retourne aucun résultat, alors que si on remplace le “b” de “Gb” par un “o” pour “Go” on a des résultats.

La promesse de ce use case est d'interpréter la demande de l’utilisation et la retranscrire en requête technique pour sélectionner les produits qui correspondent au besoin interprété.

Quand on se lance dans un produit utilisant la GenAI il y a quelques étapes clés à intégrer dans la réflexion est notamment pour les architectes.

A. Start with why

Les cas d’usage GenAI n'échappent pas aux bonnes pratiques du product management. Concentrez vous sur la valeur pour les utilisateurs et le ROI pour vos sponsors. Les PoC sont monnaie courante mais le passage à l’échelle se heurte régulièrement à la réalité économique et aux contraintes d’architecture et de sécurité imposées par votre organisation. L’écosystème GenAI évoluant très rapidement, travaillez avec vos architectes (entreprise, solution, data, sécurité) pour la conception d’une application “production ready”.

Nous ne pouvons que vous rappeler les fondamentaux suivants

1. Identifier les utilisateurs du service et les clients (ceux qui paient le service)
2. Un modèle d’IA générative est-il la meilleure solution ? Pouvez vous faire sans GenAI?
3. Comment l’IA générative change-t-elle votre expérience utilisateur (UX) ?
4. Quelles sont vos contraintes internes (économiques, techniques, organisationnelles…) et réglementaires?

B. Intégrer les modèle GenAI dans votre application avec un couplage faible pour faciliter l'évolutivité et les itérations futures

__

__ Le coeur de l’architecture existante simplifiée comprend:

• Un Back For Front pour servir les utilisateurs web et mobile avec la même architecture, en suivant le paradigme headless.
• Un back e-commerce pour la gestions des commandes,
• Un back PIM (Product Information Management) pour la gestion des informations produit
• Un back WMS (Warehous Management System) pour la gestion des stocks en entrepôt et la préparation des livraisons.
• Un CMS (Content Management System) pour le contenu éditorial
• Une API gateway pour la gestion des intéractions avec l'extérieur.

Le site passe par des partenaires pour tout ce qui est en dehors du cœur de métier: paiement, livraison, réclamation…

Pour répondre aux use cases utilisant la GenAI, nous introduisons un nouveau composant AI Facade dans cette architecture. Ce back est doté de capacité d’orchestration et de raisonnement. C’est typiquement ce qu’on peut faire avec un framework comme LangChain.

B.1 Pourquoi un nouveau composant?

Il est fondamental lorsque l’on crée des systèmes d’information d’avoir des responsabilités clairement définies pour chacun des composants. Dans l’architecture présentée, le Back For Front est responsable d’implémenter de la logique applicative, liée aux interactions de l’utilisateur, en se reposant sur les systèmes métiers internes ou externes (WMS, eCommerce, paiement…). Dans notre cas d'espèce, sa responsabilité est d’orchestrer des appels sur les différents systèmes métiers afin d’obtenir une liste de produits. Les appels aux services de GenAI pour répondre à notre cas métier implique des pré-traitements, en particulier pour générer le prompt et des post traitements pour analyser la ou les réponses des systèmes appelés. Toute cette logique est “métier” et n’est pas de la responsabilité du BFF. Elle pourrait d’ailleurs être utilisée dans un autre contexte que l’application de e-commerce. Il est donc pertinent d’introduire un nouveau composant en charge d’effectuer une recherche de produits à partir d’une chaîne de caractère via de la GenAI.

Cette manière de procéder n’est pas spécifique à la GenIA et a de nombreux avantages:

• Développement: ce découplage limite l’impact sur sur le cycle de delivery des autres parties de la solution existante qui peut continuer à évoluer de manière indépendante. Pas d’impact sur le time to market.
• Testabilité: ce composant autonome peut être testé de manière autonome.
• Surveillance: En cas de problème critique sur le comportement GenAI on peut imaginer de mettre sur Off cette partie sans trop impacter le reste du site e-commerce.
• Isolation technique: l'AI Facade sera certainement dans une nouvelle stack technologique (python) et on peut imaginer faire monter une équipe dédiée dans un premier temps comme enabler de tous les uses cases GenAI.
• Isolation des fournisseurs: ce composant joue le rôle d'adaptateur, il contient la logique spécifique à notre métier (élaboration d’un prompt) et ensuite peut appeler différents fournisseurs suivant l’évolution du marché, ou même des LLMs internes.

Cette architecture est un exemple d’intégration, on pourrait en imaginer d’autres comme, par exemple, une recherche avancée réalisée au niveau du système d’information produit (PIM).

B.2 Comment cela fonctionne t-il?

Le BFF continue à jouer le rôle de médiateur des interactions client, ce que l’on appelle la logique applicative. S’il n’arrive pas à répondre de manière “classique” à une demande par exemple “un canapé bleu, de longueur maximale 1,8m disponible la semaine prochaine” alors il demande à l’AI Facade de lui “expliquer” ce que le client veut. L'AI Facade fait appel à un LLM pour interpréter la demande du client et renvoie par exemple un json que le BFF saura consommer. Rappelons qu’on ne cherche pas à faire un chat avec le client mais juste améliorer sa recherche en langage naturel. Si le LLM n’arrive pas à interpréter correctement la demande ou si aucun produit ne correspond, un message classique “aucun produit trouvé” est affiché.

Une étape de modération et d'enrichissement avec le contexte est faite par l’AI Facade pour générer le prompt pour le LLM. En effet, il faut préciser à ce dernier le format attendu par le BFF. Après enrichissement on obtiendrait par exemple le json ci dessous pour la recherche “laptop 15 pouces, 4G RAM, 512GB SSD” sur le site FNAC.

On remarque sur cet exemple que, grâce au contexte et au prompt qu’on lui a fourni, le LLM a pu corriger les unités de mesure de mémoire en Go. Dans le cas de la recherche canapé, le client a donné des indications de prix et de date de livraison. Le json est enrichi avec ces informations.

On remarque par exemple que les longueurs ont été convertie en cm. L’indication de livraison disponible la semaine prochaine a été convertie en champ de date avec début et fin. Cependant, le json généré n’est pas directement utilisable par le BFF pour trouver les bon produits.

• On n’a pas le categoryID de la catégorie “canapé” pour une recherche fiable
• On n’a pas le productID des canapés qui peuvent correspondre
• Les dates de disponibilité doivent être retrouvées dans le warehouse management system pour chaque produit

B.3 Comment limiter l’impact des évolutions du legacy?

Au gré des évolutions fonctionnelles les API ou le modèle de données du site peuvent changer. Chaque évolution peut nécessiter de mettre à jour l’enrichissement du prompt au niveau du AI Facade. D’un autre côté les produits n’ont pas tous les mêmes attributs et des nouveaux produits peuvent être ajoutés. Pour rendre l'AI Facade plus autonome nous allons lui donner accès à des outils comme le modèle de données et le swagger de notre site via un RAG (Retrieval Augmented Generation). On va aussi lui faire jouer un rôle d’architecte applicatif qui a le droit d’accomplir certaines tâches et possède en l’occurrence les autorisations nécessaires. Nous ne développerons pas plus dans cet article la partie gestion des accès et des autorisations pour les rôles joués par l'AI Facade.

Le RAG est le mécanisme en vogue pour utiliser les données propre à un système ou à une entreprise pour répondre à un prompt. Il est souvent utilisé dans des cas d’usage de chatbot. Le fonctionnement du RAG est présenté dans cet article et nous détaillons dans celui ci sa mise en oeuvre pour le Helpdesk d’OCTO

La vectorisation de la documentation et de la base de données Product Information par exemple va permettre à l’AI Facade de se faire une représentation dynamique de la structure attendue par le BFF. On suppose que cette documentation existe, sinon elle peut être faite automatiquement par des outils de marché ou par un LLM. L’exemple ci-dessous à été généré automatiquement par chatGPT. L’utilisation du RAG dans notre cas pour auto-générer les fichiers pour le BFF doit faire l’objet de surveillance et test approfondi. Ce cas d’usage du RAG n’est pas courant.

Exposer de la documentation interne à un LLM n’est pas du goût de tout le monde. Des raisons de confidentialité ou de coût peuvent vous amener à privilégier un fournisseur à un autre ou une solution hébergée localement dans votre SI.

C. Choisir son fournisseur et ses modèles GenAI

Il existe un nombre de plus en plus croissant de fournisseurs de modèles d'IA générative. En fonction des uses cases un modèle peut s’avérer plus pertinent qu’un autre. Globalement le modèle le plus performant aujourd’hui sera dépassé dans 2 ou 3 semaines. Il ne faut pas se focaliser sur la performance absolue mais plutôt sur la pertinence du modèle par rapport à votre cas d’usage et vos contraintes internes quitte à ce qu’il ne soit pas le plus performant quelques semaines plus tard.

Si aujourd’hui OpenAI domine le marché profitant de son “first-mover advantage” plusieurs alternatives existent pour se doter des capacités de GenAI.

• Les fournisseurs spécialisés comme Anthropic ou Mistral. Ces pure players proposent des solutions plus spécialisées (text, image, vidéo) et peuvent offrir des coûts moins élevés ou des modèles de tarification plus flexibles.
• Les cloud providers comme AWS, GCP ont renforcé leurs offres avec des capacités d'IA générative. L’intégration de ces nouveaux services à leur plateforme permet d’avoir une offre complète et bien évidement une facturation sur le même compte de votre organisation.
• Les marketplaces open source comme Hugging Face ou PyTorch Hub packagent et distribuent des modèles open source assez variés pour traiter du texte, des images, de la voix ou des vidéos.

Si votre organisation débute dans l’exploration de la valeur de GenAI alors un fournisseur spécialisé ou un cloud provider est une bonne option. Les offres sont prêtes à l’emploi et l’utilisation de la GenAI dans cette phase d’exploration peut se résumer à “faire des appels API”. Cependant le passage à l’échelle peut vite devenir coûteux si votre architecture n’est pas optimisée.

L’open source est une excellente alternative si votre organisation à les compétences pour déployer ou faire évoluer les modèles. Ces modèles particulièrement intéressants pour des raisons de coûts ou de confidentialité peuvent être déployés en parallèle d’un modèle propriétaire. Par exemple, Hugging Face propose des centaines de milliers de modèles que vous pouvez déployer localement dans votre environnement .

Dans ce cas, il faudra ajouter une logique au niveau de l’AI Facade pour préciser dans quel cas utiliser le LLM local vs le LLM du GenAI provider. Ce routage peut également se faire au niveau de l’API gateway. Dans ce cas, on peut en prime rajouter des règles de surveillance et de quota d'appels par utilisateur ou par provider.

Le monde des LLM changeant très rapidement. Vous aurez peut être la tentation de vouloir en utiliser plusieurs en parallèle pour comparer les performances ou simplement vous garder l’option de remplacer un LLM par un autre que vous jugeriez plus pertinent. La gateway permet également avec le déploiement du pattern Adapter de connecter plusieurs modèles LLM ou d’en rajouter avec un impact limité sur l’existant. En effet, cette couche introduit une abstraction pour l’AI Facade qui ne fait qu’un seul type d’appel.

Il peut être tentant avec ce pattern déployé au niveau de l’API Gateway de rajouter des règles métier dedans. Il faut éviter cela, dans ce cas, il vaut mieux que cette abstraction se fasse au niveau de l’AI Facade.

D. Tester et surveiller le comportement du modèle

La variabilité et le non déterminisme qui est inhérent à l’utilisation des modèles d’IA complique la mise au point des tests fonctionnels et exige de plus surveiller applicativement les entrées fournies à l’IA et les réponses retournées par l’IA.

Si on fait la comparaison avec une fonction qui trie une liste d’entiers (ok, très simple), on peut facilement imaginer les cas à tester : une liste avec quelques nombres, une liste vide, une liste avec le même nombre répété tout le temps, une liste avec un maximum de valeurs. De plus pour chaque exemple le résultat sera toujours le même. Lors de l’exécution on est ainsi assuré que l’on aura une liste en retour (faible variabilité) et que le résultat sera identique à ce qui a été testé pour peu que l’on donne les mêmes valeurs en entrée.

Dans notre exemple, c'est complètement différent. On peut imaginer que la description passée en entrée soit une vraie description (“un canapé bleu”), vide (“”). Mais elle pourrait aussi contenir “fais moi le résumé de ce texte : xxx”, “donne moi la liste des employés”. Le champ des possibles de nature différente est très étendu, donc la surface de test aussi. En ce qui concerne les valeurs retournées il n’y a pas de garantie “par design”. Ce n’est pas parce que notre requête sur le laptop a retourné “storage:512Go” que ce sera toujours le cas, on pourrait bien se retrouver avec un “storage:512000Kb”. Il pourrait même arriver que le json retourné ne soit pas du tout au format attendu, voire pas du tout en json.

Pour ces raisons il faut que la couche d’intégration effectue une validation des données en entrées et en sortie. Cette validation est facilitée en demandant au modèle de fournir sa réponse dans un formalisme informatique, comme le json présenté qui peut être contrôlé informatiquement.

Mais cela ne résout pas tous les problèmes, par exemple si on ajoute un attribut “descriptif” contenant un court descriptif corrigé des fautes et avec les unités explicitées on obtient pour la même requête des réponses comme “descriptif”: “Ordinateur portable de 15 pouces équipé de 4 Go de RAM et d'un disque SSD de 512 Go.” ou “descriptif”:”Ordinateur portable de 15 pouces avec 4 Go de RAM et un SSD de 512 Go”

Pour ce type de champ, il faut être capable, lors des tests fonctionnels, de valider un ensemble de réponses, et non une seule, ce qui peut être fait par exemple en vectorisant la réponse et en calculant la distance avec une réponse type. Sur la partie surveillance il faut être capable de vérifier que le descriptif ne contiendrait pas des données fantaisistes ou protégées.

Au final ces caractéristiques impliquent que

• Les tests fonctionnels doivent être plus étendus.
• Les tests fonctionnels doivent être capables de s’adapter au caractère non déterministe du retour.
• Une validation de la conformité des données d’entrée et de sortie doit faire partie du traitement d’intégration et retourner une “erreur” en cas de non conformité.

Take AWAY

L’introduction (aka retrofit ) de la GenAI sur les systèmes existants est un gisement de valeur à explorer. La GenAI permet de répondre à des anciens ou nouveaux cas d’utilisation en utilisant des technologies d’IA, sans avoir à développer et entraîner un modèle spécifique.

La réalisation des premiers cas d’utilisation est facilitée par l'utilisation de services GenAI sur étagère.

Cette mise en oeuvre est effectuée au travers d’une couche d’intégration:

• Cette couche d’intégration doit être isolée dans un/des composants ou services autonomes pour permettre de faire évoluer le système existant ou implémenter des cas d’utilisation GenAI plus poussés sans détériorer le TTM de l’application.
• Cette couche d’intégration suit le pattern façade afin de fournir à ses consommateurs une API fonctionnelle simplifiée, décorrélée des contraintes techniques liées à l’appel des systèmes d’IA : génération de prompts, appels de différents systèmes, contrôle de résultats..
• Cette logique peut être plus ou moins complexe et contenir tout un workflow d’appels (ex : RAG)
• Cette couche d’intégration doit:
  • Contenir une couche d’abstraction qui permette d’orienter vers plusieurs fournisseurs de GenAI (externe et interne) en fonction des besoins
  • Être testable via des test automatisés
  • Potentiellement fournir des systèmes de validation des réponses des GenAI

Finalement, l’intégration de la GenAI dans un produit existant n'est pas beaucoup plus complexe que l'intégration d'un autre micro-service au sein de ce produit. Ce n'est pas une révolution de votre SI ou de vos équipes. Pour réussir cette intégration il faudra appliquer les mêmes bons principes éprouvés de gestion de produit et d'architecture logicielle. Même s’il y a peu de connaissances approfondies en data science à avoir, une formation et une sensibilisation des software engineers et des data engineers est nécessaires pour comprendre les principes de fonctionnement, les risques d’hallucinations et les règles de sécurités à appliquer.