LLMOps, le nouveau grand défi du DevOps orienté IA
Le MLOps a historiquement pour ambition de concevoir et maintenir les modèles de machine learning déployés sur le terrain. A l'instar du DevOps pour les applications, il passe par la maîtrise de l'ensemble du cycle de vie des modèles. Comme son nom l'indique, le LLMOps étend cette logique aux large language model (LLM). Il se traduit par des spécificités propres au déploiement de ces méga modèles de langue. Des IA dont la caractéristique principale est d'être beaucoup plus volumineuse que les réseaux de neurones artificiels traditionnels.
On distingue deux grandes catégories de LLM avec chacune leurs spécificités en termes de MLOps : les LLM géants que l'on canalisera sur un cas d'usage précis d'une part, les LLM open source, de moindre taille, qui seront réentrainés pour des projets particuliers. Dans le premier cas, on pourra contraindre le champ d'application du LLM à un domaine particulier pour lequel il a été entrainé. On pourra aussi avoir recours à la génération augmentée de récupération ou retrieval-augmented generation (RAG). Une technique qui permet d'injecter de nouveaux contenus dans la base vectorielle du modèle par le biais d'invites. Principal avantage : cela évite un réentrainement complet ou partiel. Une fois cette tâche réalisée, le modèle pourra ensuite glaner directement ses réponses au sein du corpus de contenus ainsi injectés.
Document engineering
Pour mettre en œuvre une RAG, "il sera nécessaire, en amont, de structurer les documents utilisés en les découpant en chapitres, en paragraphes, avec des titres et sous-titres. Pour ce qui est des FAQ, il faudra bien veiller à ce que les réponses soient immédiatement sous les questions correspondantes", recommande Didier Gaultier, directeur du pôle data science et intelligence artificielle au sein de l'ESN Business & Decision (groupe Orange). "Globalement, l'idéal est d'opter pour le langage de balisage Markdown. Ce travail de découpage sera gage de performance." Pour ce travail, il est conseiller de se doter d'un document store, au même titre qu'un feature store et qu'un model store qui stockent respectivement les caractéristique des modèles et les modèles en tant que tels.
"Le taux d'hallucination dépend à la fois du LLM en tant que tel, mais aussi de la nature des prompts, du corpus de documents utilisé ainsi que du contexte"
Qu'en est-il du réentrainement des LLM open source ? Ils impliqueront a minima des instances NVidia A100 équipées chacune de 80 Go de mémoire vive. "Mieux vaudra avoir peu d'instances, mais chacune dotée d'une puissance computationnelle importante. Ce point est crucial pour aboutir à un temps d'apprentissage acceptable qui ne s'étale pas sur plusieurs mois", souligne Didier Gaultier. Et Eero Laaksonen, serial entrepreneur et expert en IA d'ajouter : "Pour cette étape, on privilégiera le transfert learning pour ajouter au réseau de neurones des couches spécifiques au cas d'usage ciblé." En aval, il faudra aussi être vigilent sur la puissance mis au service de l'exécution du modèle une fois celui-ci déployé. Objectif : aboutir à un temps de latence qui soit acceptable pour les utilisateurs finaux.
L'entrainement continu
A l'état de l'art, le MLOps implique théoriquement d'entrainer les modèles de manière continue pour les enrichir au fur et à mesure des feedbacks utilisateur et de l'enrichissement de l'historique des données de contexte. Problème : les LLM sont trop volumineux pour supporter des phases de réapprentissage trop fréquentes. "Il faudra néanmoins en passer par là de temps en temps. Même si les LLM ne sont pas adaptés au training temps réel compte tenu de la puissance machine nécessaire, il sera quand même nécessaire de les mettre à jour relativement régulièrement", reconnait Didier Gaultier. "Aujourd'hui, les offres des hyperscalers ne sont pas adaptées à ce process. Mais il est fort à parier qu'elles vont évoluer à l'avenir sur ce point."
Les consultants interrogés dans le cadre de cet article recommandent tous de penser l'architecture du LLM dès le début du projet, en prenant en compte notamment les besoins potentiels de monter en puissance en termes d'apprentissage sur des modèles plus volumineux. Bref, l'infrastructure devra être évolutive en matière de dimensionnement des ressources de calcul, notamment en vue de prendre en charge des modèles avec des volumes de paramètres plus importants. Ce qui pourra d'ailleurs se révéler être un point de passage obligé pour certains cas d'usage plus ambitieux.
Une politique de versioning
Dans la même logique, il sera important de concevoir une politique de versioning. "Les versions de développement et de production des LLM devront pouvoir passer d'un environnement à l'autre sans interruption de services. Ce qui implique des outils d'automatisation", maintient Eero Laaksonen.
Dernier élément, le LLMOps implique de déployer des outils de monitoring pour évaluer la performance des modèles et suivre leur évolution au fil du temps. "Il n'existe pas encore de benchmark pour superviser le bon fonctionnement des LLM. Il sera par conséquent nécessaire de développer des indicateurs spécifiques pour suivre leur bon fonctionnement et surtout leur taux d'erreur", reconnait Didier Gaultier. "Le taux d'hallucination dépend à la fois du LLM en tant que tel, mais aussi de la nature des prompts, du corpus de documents utilisé ainsi que du contexte. Cette multiplicité de critères fait que l'hallucination ne peut être traduite sous la forme d'une mesure fiable. Mais on peut imaginer que la recherche progressera dans les mois qui viennent sur cette question."