Depuis plusieurs mois, le boom des Modèles de Langage Larges (LLM) a largement démocratisé l’intégration de moteurs de prompting dans nos logiciels. Que ce soit dans les environnements de traitement de texte, de modélisation 3D, de traitement d’image, de feuilles de calcul, ou d’éditeur de code, les fenêtres flottantes permettant aux utilisateurs d’écrire des instructions en langage naturel sont entrées dans nos habitudes de travail.
L’approche WYSIWYG “What You See Is What You Get” se transforme progressivement en un “What you Say Is What You Get”. Les utilisateurs peuvent ainsi concentrer davantage d’efforts sur la formulation de leur besoin, plus que sur son implémentation.
Ce nouveau paradigme de travail permet d’améliorer la qualité du produit final, tout en réduisant la pénibilité : les actions redondantes et/ou peu plaisantes sont déléguées à une Intelligence Artificielle (IA), et l’utilisateur peut ainsi allouer davantage de temps à son domaine d’expertise.
L’architecture probabiliste des LLMs, par définition, ne permet pas une confiance aveugle dans la qualité de la génération et des erreurs sont possibles, mais l’amélioration de l’expérience utilisateur reste considérable. Pour cette raison, nous travaillons chez Obeo à l’intégration de plusieurs fonctionnalités assistées par LLM dans nos produits.
Dans cet article, nous décrivons nos premiers pas avec les LLMs, et leur intégration à Obeo SmartEA afin d’assister les Architectes d’Entreprise à la compréhension, l’interrogation, et la génération de leur référentiel d’AE.
Introduction aux LLMs
Bien qu’ils soient sur le devant des projecteurs depuis quelques mois, les modèles de langage ne sont pas nouveaux dans le domaine de l’intelligence artificielle : des modèles de langages comme n-gram existent depuis les années 1950 et peuvent être utilisés afin de prédire des séquences de mots [1].
Cependant les améliorations régulières des technologies de calcul parallèle (GPUs), ainsi que des découvertes scientifiques majeures dans le domaine de l’intelligence artificielle, comme celle des transformeurs, une architecture pour l’apprentissage profond, ont mené à la naissance de nouveaux modèles de langages : les Modèles de Langage Large (LLM) vers la fin des années 2010 [2].
Si dès 2018, les premiers LLMs pouvaient être utilisés comme des agents conversationnels “simples”, c’est surtout l’ouverture au public en 2022 des modèles de langage “text-davinci-002” et “code-davinci-002” par la société OpenAI qui ont réellement démarré un engouement populaire pour cette technologie. Ces deux modèles sont intégrés au chatbot ChatGPT, et référencés sous le nom de GPT3.5, désormais bien connu. Les LLMs deviennent rapidement un phénomène mondial, et des environnements de prompting, (i.e., des points d’entrée permettant aux utilisateurs d’écrire des instructions en langage “naturel”) sont intégrés à de nombreux logiciels afin d’assister les utilisateurs dans leurs tâches : générer du texte, du code, des images, remplacer des clics, …
Remplacer certaines tâches complexes par des entrées textuelles non soumises à une grammaire stricte est pour beaucoup une forte amélioration d’expérience utilisateur : ce dernier peut ainsi se concentrer sur la sémantique de ce qu’il désire, plutôt que sur la syntaxe avec laquelle formuler son besoin. Par exemple, il est bien plus rapide d’écrire dans Le Chat de MistralAI “Génère-moi un courrier de résiliation de mon abonnement à la salle de sport. Sois poli mais ferme.”; plutôt que d’écrire soit-même ledit courrier [3].
La difficulté d’écrire des requêtes AQL
Cette accessibilité des LLMs est une opportunité inédite d’améliorer l'expérience utilisateur des architectes d’entreprise utilisant Obeo SmartEA. En effet, l’utilisation de certaines fonctionnalités de SmartEA pourrait être fortement améliorée en mettant à disposition un environnement de prompting, permettant de décrire en langage naturel son besoin, plutôt que de le formaliser avec un langage dédié, comme Acceleo Query Language (AQL).
Un retour fréquent des utilisateurs de SmartEA concerne la difficulté d’utiliser le langage interne du logiciel AQL. AQL est utilisable dans SmartEA afin de requêter le référentiel d’architecture d’entreprise. La syntaxe est proche de celle du standard OCL : “Object Constraint Language” [4], mais avec de nouvelles fonctions et mots clés définis par SmartEA.
Les architectes d’entreprise peuvent utiliser AQL afin de filtrer et afficher les données leur référentiel, construire et exporter des tables vers Excel, vérifier la présence ou l’absence d’éléments, etc… Il est à noter néanmoins qu’AQL n’est utilisé que pour consulter le référentiel d’Architecture d’Entreprise (AE), et non pour le modifier.
AQL se conforme à une syntaxe stricte, et nécessite un temps d’apprentissage non négligeable. Certains architectes ont un besoin ponctuel d’utiliser AQL (~ 1 fois par mois). Malheureusement les utilisations clairsemées du langage, couplées à sa difficulté, peuvent dégrader l'expérience de l’utilisateur lorsque ce dernier a besoin d’effectuer des actions de filtrage et de recherche dans son référentiel d’AE.
L’utilisation de LLMs semble être un bon candidat à la résolution d’un tel problème : proposer une alternative à la rédaction de requêtes AQL dans l’écriture de prompts en langage naturel. Au lieu de composer des requêtes AQL complexes nécessitant une connaissance du langage AQL, du domaine métier, du langage Archimate, du prisme SmartEA; formaliser sa demande en langage naturel permet de se concentrer sur son besoin métier, tout en laissant SmartEA et un LLM gérer la complexité sous-jacente.
Interrogation du référentiel d’AE par le LLM
Plusieurs manières d’interroger son référentiel d’AE avec un LLM sont envisageables. Nous listons ci-dessous les approches étudiées, avant de présenter la solution implémentée dans SmartEA.
Une approche naïve consiste à agréger le référentiel d’architecture d’entreprise, le prisme SmartEA, et le besoin de l’utilisateur en langage naturel dans un message (le prompt), et d’envoyer tout ça au LLM. Néanmoins cette approche pose de nombreux problèmes :
- La fenêtre de contexte d’une requête à un LLM correspond à la quantité de texte traitable par ce LLM. Bien que large, cette fenêtre est limitée. Il est possible d’y placer de grandes quantités de données (128 000 mots et caractères pour GPT4-Turbo, ce qui équivaut à approximativement 300 pages, ou la spécification d’OCL). Il est commun que les référentiels d’architecture d’entreprise, et leurs prismes associées dépassent cette fenêtre. Enfin, plus cette fenêtre est remplie, plus il devient compliqué d’assurer la cohérence des résultats produits [5].
- Additionnellement, envoyer de grandes quantités de données à chaque requête peut avoir des impacts sur le réseau non négligeables, allonger le temps de réponse du LLM dégradant ainsi l’expérience utilisateur, et augmenter drastiquement les coûts d’exécution de requêtes.
- On peut également mentionner qu’à cause du caractère non déterministe du LLM, rien n’assure que les éléments du référentiel renvoyés soient conformes à la requête de l’utilisateur : il est effectivement assez commun que le LLM produise en sortie des éléments inexistants dans le référentiel, ou les modifie afin qu’ils soient conformes à la requête.
Les raisons énoncées précédemment font que l’approche naïve d’envoyer le référentiel d’architecture d’entreprise au LLM afin de l’interroger en langage naturel n’est pas envisageable, en tout cas pas dans l’état actuel des LLMs. Une autre approche permettant de passer outre ces limitations est donc de générer directement du code AQL à partir d’une demande utilisateur en langage naturel, dont l’interprétation dans SmartEA renvoie les résultats désirés.
Génération de code AQL par le LLM
Générer du code AQL permet de passer outre la plupart des limitations de l’approche présentée précédemment : il n’est plus nécessaire d’envoyer le référentiel d’AE au LLM, limitant ainsi la quantité de données dans la fenêtre de contexte, et réduisant ainsi considérablement la latence réseau et les coûts d’opération. Enfin, l'interprétation de la requête AQL, générée ou non par le LLM, renvoie nécessairement les données du référentiel, puisque c’est l'interpréteur Out-of-the-box de SmartEA qui est utilisé.
Ainsi, lorsque l’utilisateur formule la requête suivante en langage naturel : “Quels éléments sont obsolètes depuis le 07/06/2024”, SmartEA interroge le LLM, récupère une requête AQL et l’interprète sur le référentiel d’AE afin de proposer la liste de tous les éléments obsolètes depuis le 07/06/2024, conformément à la demande de l’utilisateur.
La requête produite est, par défaut, invisible à l’utilisateur. Néanmoins, il est possible d’afficher la requête AQL : on peut ainsi l’intégrer dans des Smart Request complexes afin d’effectuer des exports Excel de son référentiel d’AE.
Afin de maximiser la qualité des requêtes produites, plusieurs mécanismes sont intégrés au moteur de requêtage de SmartEA :
- D’abord, des techniques usuelles de Prompt Engineering (Chain-of-Thought, N-Shot learning) qui renforcent le respect de la syntaxe d’AQL, et permettent l’utilisation des services SmartEA et AQL non documentés publiquement (et donc inconnue des LLMs) [6,7].
- Une boucle de rétroaction entre l'interpréteur AQL et le LLM permet de corriger les requêtes éventuellement invalide syntaxiquement : les requêtes formulées par le LLM sont analysées par l'interpréteur AQL de SmartEA. Si des erreurs de syntaxe sont présentes, l’erreur est remontée au LLM afin d’obtenir une nouvelle requête corrigée, et ce jusqu’à ce que la requête soit valide.
- Des entrées utilisateurs sous la forme de boutons pouce ("thumb up" et "thumb down") permettent à ce dernier de confirmer que la requête produite par le LLM est valide sémantiquement ou non : c’est à dire que le code AQL produit correspond effectivement requête formulée initialement en langage naturel. Par exemple, si l’utilisateur formule la requête “Quels éléments sont obsolètes depuis le 07/06/2024”, mais que la requête AQL générée par le LLM calcule les éléments obsolète depuis le 06/07/2024 (au format US), alors il est pertinent que l’utilisateur note cette requête comme invalide sémantiquement. Il est également à noter que la requête générée par le LLM peut être modifiée par l’utilisateur si ce dernier désire l’améliorer. Il lui est possible de remonter cette amélioration au LLM afin que les générations suivantes puissent l’intégrer.
- Enfin, un historique de conversation est mis en place lors des échanges avec le LLM : Une fenêtre de contexte des derniers messages est conservée afin de pouvoir construire des requêtes complexes, ou modifier la requête précédente. Par exemple, une première requête en langage naturel pourrait formuler “Liste toutes les applications du répertoire”. Si la liste proposée est trop grande, l’utilisateur peut filtrer la requête précédente en formulant “Ne garde que celles qui commencent par ‘app_’”. Cette fonctionnalité permet de rapprocher l’outil de recherche de SmartEA d’un agent conversationnel, et ajoute de la fluidité à la création des requêtes.
Ce nouveau moteur de requêtage basé sur un modèle de langage LLMs est intégré à SmartEA dès la version SmartEA 8.2.
Travaux en cours
D’autres études sur l’utilisation de LLMs dans les produits Obeo sont en cours. Effectivement, l'expérience utilisateur peut être considérablement améliorée en remplaçant des actions fastidieuses par un moteur basé sur du prompting (ou même un chatbot !). Parmi les travaux en cours, on peut mentionner l’utilisation d’un chatbot pour faciliter la recherche d’informations dans la documentation embarquée de nos produits, et l’utilisation d’IA générative pour la création et l’édition des diagrammes.
En effet, la documentation embarquée dans un produit comme SmartEA peut être compliquée à utiliser lors d’un premier contact. De nombreux manuels PDF sont mis à la disposition des utilisateurs : guides d’administration, d’utilisation, de développement, ArchiMate, BPMN2, AQL… Si bien qu’il peut être compliqué pour des utilisateurs finaux de retrouver certaines informations techniques.
L’utilisation d’une architecture de LLM basée sur un RAG (Retrieved Augmented Generation) est pertinente pour assister l’utilisateur à la recherche documentaire. Les informations proposées par le LLM sont ainsi limitées exclusivement à la documentation PDF disponible dans SmartEA, et ce dernier peut même sourcer précisément ses informations :
- Utilisateur : "Comment générer un diagramme ArchiMate ?"
- Chatbot : "D’après le guide Administrateur SmartEA page 48, il est possible de décrire un template de génération de diagramme ArchiMate dans le prisme SmartEA, …"
Une évolution de SmartEA intégrant un agent conversationnel permettant de documenter les utilisateurs est envisageable dans un futur proche, et serait une amélioration conséquente de l'expérience utilisateur.
Enfin, des travaux d’intégration d’IA générative pour la génération et l’édition de diagrammes et d’entités débuteront dès Janvier 2025 dans SmartEA. Pouvoir formaliser son besoin en langage naturel et déléguer la génération des entités à un LLM serait un gain de temps considérable.
De nombreuses actions utilisateur lors de la création et l’édition de diagrammes peuvent être redondantes : cliquer / glisser des objets métiers ArchiMate, créer des relations entre deux entités, transformer des entités, ajouter des nouveaux attributs, …
Toutes ces actions pourraient être remplacées par un prompt dans une fenêtre dédiée, limitant largement la quantités de clics nécessaires aux architectes d’entreprise pour définir leur référentiel d’EA.
Conclusion
Notre montée en compétence sur les récents LLMs ainsi que les premiers résultats obtenus sont très encourageants. En plus des travaux effectués et en cours sur SmartEA, d’autres études et travaux d’intégration d’IA à nos produits seront effectués dans un futur proche : compréhension du domaine, méta-modélisation, restructuration du référentiel, audit des données, …
L’expérience utilisateur est cruciale, et son amélioration guide les évolutions de nos produits. Si l’intégration d’IA peut améliorer cette expérience utilisateur de façon importante, il devient alors nécessaire d’implémenter de telles fonctionnalités.
Sources
[1] Shannon, Claude E. "The redundancy of English." Cybernetics; Transactions of the 7th Conference, New York: Josiah Macy, Jr. Foundation. 1951.
[2] Ashish Vaswani, “Attention Is All You Need”, 2017
[4] Object Management Group (OMG); Object Constraint Language Specification, Version 1.3, March 2000
[5] Wei, Jason; Tay, Yi; Bommasani, Rishi; Raffel, Colin; Zoph, Barret; Borgeaud, Sebastian; Yogatama, Dani; Bosma, Maarten; Zhou, Denny; Metzler, Donald; Chi, Ed H.; Hashimoto, Tatsunori; Vinyals, Oriol; Liang, Percy; Dean, Jeff; Fedus, William. "Emergent Abilities of Large Language Models". Transactions on Machine Learning Research. ISSN 2835-8856. 2023.
