LLMOps : le MLOps appliqué aux LLM

Avec les développements récents sur les LLM, et plus particulièrement sur les derniers modèles proposés en open source ou propriétaires, de plus en plus d'entreprises ont désormais la capacité de pouvoir les intégrer dans leurs propres projets. Tout comme elles ont su adapter leur processus de développement et de déploiement de modèles de Machine Learning avec l'approche MLOps, elles commencent dorénavant à adapter cette approche pour le cas spécifiques des LLM.

Ainsi, le LLMOps permet d'hériter de toutes les bonnes pratiques du MLOps dans le cas spécifique où le modèle utilisé est un LLM. Mais contrairement au MLOps, le LLMOps dispose également de ses propres spécificités, notamment parce qu'un modèle de langage peut être plus difficile à gérer sur la partie déploiement (nécessité de GPU), mais également parce que d'autres services tiers, comme des bases de données vectorielles, peuvent être requis.

Dans cet article, nous allons voir ce qu'est l'approche LLMOps dans les grandes lignes, les éléments qui en font une spécificité par rapport au MLOps, ainsi qu'un tour d'horizon sur les principaux avantages et inconvénients.

Qu'est-ce que le LLMOps ?

Le LLMOps est une sous-catégorie de l'approche MLOps dans lequel le modèle principalement utilisé est un LLM. Cette approche qui mêle Machine Learning et Ops (operations) vise à améliorer la délivrabilité des projets Machine Learning en adoptant les bonnes pratiques d'automatisation et de séparation entre les différentes étapes.

La particularité de l'approche MLOps est que l'on retrouve deux grades phases.

• La phase d'expérimentation, où l'on cherche à construire un algorithme de Machine Learning permettant de répondre à une problématique spécifique. Cette phase contient non seulement les opérations de collecte et de transformation de données, mais aussi les étapes de modélisation (comprenant l'optimisation des modèles, leur validation et leur interprétation).
• La phase de déploiement, où l'on souhaite exposer le modèle (régulièrement sous forme d'API) sur un serveur distant dans le Cloud. Cette phase, beaucoup plus orienté développement, est plus complexe à appréhender pour des profils n'ayant pas ou peu pratiqué d'administration système et Cloud.

À lire : découvrez notre formation LLM Engineering

Ainsi, séparer ces deux phases tout en adoptant les bonnes pratiques liées au DevOps permet de favoriser les modifications de manière indépendante tout en s'assurant de la bonne continuité d'exécution du projet.

Dans l'approche LLMOps, nous allons donc spécialiser le modèle comme étant un LLM. Ainsi, les entreprises peuvent ré-utiliser des processus qu'elles avaient déjà mises en place pour le développement et le déploiement optimisé de modèles de Machine Learning, mais en les déclinant pour le cas spécifiques des LLM.

En revanche, bien qu'un LLM reste un modèle de Machine Learning au sens général (algorithme prédictif), celui-ci nécessite des briques bien particulières qui ne peuvent être traitées directement par l'approche MLOps, qui se veut plus classiques et plus généraliste, indépendant du modèle sous-jacent utilisé.

Spécificités du LLMOps

Comme nous venons de le voir, la configuration ou le déploiement d'un LLM nécessite plus d'étapes intermédiaires qu'un modèle de Machine Learning plus classique.

• Infrastructure et scalabilité : la plupart des LLM sont coûteux en termes de ressources, et requièrent très souvent des GPU pour proposer des temps d'inférence corrects. Ce type d'architecture avec GPU nécessite à la fois plus d'investissements financiers (car les GPU sont beaucoup plus chers que les machines virtuelles sans GPU), mais également plus de configuration côté serveurs pour pouvoir suivre la demande et assurer une certaine scalabilité en fonction des pics d'utilisation.
• Prompt Engineering : en utilisant des frameworks comme LangChain, il peut être nécessaire de construire toute une logique adaptée aux besoins spécifiques des LLM, comme la création de chaînes de pensées, la gestion des conversation et des flux échangés entre des agents. Plutôt qu'un algorithme apportant une réponse à une entrée particulière, un LLM peut être intégré sous forme d'une application qui dispose de beaucoup plus de fonctionnalités.
• Gestion des artifacts : une application qui exécute un LLM a besoin de plusieurs artifacts (fichiers, métadonnées) à sa disposition, comme les poids qui constituent le réseau de neurones, ou encore un tokenizer, qui a pour rôle de convertir un contenu en langage naturel vers des tokens pour être ensuite convertis en vecteurs via un embedding. Dans le but de découpler les phases d'expérimentation et de déploiement, il est donc pertinent d'utiliser un système de stockage afin de faciliter l'inter-opérabilité entre ces deux phases.
• Services tiers : bien souvent, les LLM utilisent des bases de données vectorielles comme Pinecone pour stocker et effectuer des requêtes sur des embeddings particuliers. D'autre services, comme des bases en mémoire cache avec Redis seront nécessaires pour la mémoire à long terme, notamment pour modéliser des flux de conversation.
• Monitoring et feedback humain : ces modèles nécessitent également la surveillance continue des performances ou la détection des dérives. Cela est d'autant plus important que si le LLM est sujet à des hallucinations et qu'il est directement accessible à des utilisateurs lambda. Dans telle situation, il est primordial de pouvoir analyser a posteriori les réponses qui ont été générées par le modèle, et de récupérer un maximum de feedback humain pour pouvoir le spécialiser par la suite.

Avantages du LLMOps

Il y a bien entendu de nombreux avantages à utiliser cette approche, non seulement parce qu'elle va automatiquement hériter de tous les avantages déjà présents dans l'approche MLOps, mais aussi parce que cela permet aussi de corriger d’éventuels problèmes qui peuvent être soulevés dans les projets LLM.

Le premier avantage du LLMOps est de pouvoir assurer une délivrabilité optimale des projets exécutant des LLM, car l'ensemble du processus, de l’expérimentation jusqu'au déploiement, est cadré selon des bonnes pratiques hérités de l'approche DevOps. Puisque la partie déploiement peut être en partie automatisé, cela assure une meilleure disponibilité de modèles récents aux utilisateurs.

Une conséquence de cet avantage est donc de pouvoir innover plus rapidement et améliorer les performances, notamment grâce aux feedbacks humains. En effet, en ayant séparé les deux phases et optimisé le déploiement, les équipes de Data Scientists peuvent plus facilement se concenter sur le cœur du projet, à savoir le LLM en lui-même, plutôt que sur les outils opérationnels qui gravitent autour.

Un autre point important du LLMOps est de pouvoir gérer efficacement les différentes ressources au sein du projet. Puisque les différentes briques se veulent être le plus indépendantes possibles, chaque équipe peut se focaliser sur une ou plusieurs tâches précises, comme la disponibilité de service, la mise à disposition d'artifacts ou le stockage d'embedding sur une base vectorielle.

Enfin, cette représentation séparée offre aux équipes un contrôle plus strict sur les droits d'accès aux ressources et à la sécurité inhérente, ce qui permet potentiellement de cloisonner les rôles de chaque intervenant du projet, et de protéger des données sensibles.

Inconvénients du LLMOps

Bien que le LLMOps puisse paraître attractif, notamment lorsque l'on souhaite prévoir de nombreuses itérations ou homogénéiser les différents projets en interne, il existe également quelques inconvénients qui peuvent freiner son implémentation.

Le principal inconvénient au LLMOps, qui subsiste à l'approche MLOps de manière générale, est la complexité technique de mettre en place tous les processus adéquats. En effet, il est nécessaire de disposer d'une équipe qui dispose à la fois des compétences Data et Ops, et sur de nombreux outils. Si une équipe n'est pas encore mature sur ces sujets, elle peut rencontrer des difficultés pour implémenter de nouveaux processus.

De plus, l'approche LLMOps possède un coût d'entré plus important que pour un projet sans composant Ops. En effet, il est nécessaire de cadrer chaque étape du projet, de construire les différentes pipelines et de les automatiser ensuite. Dans le cas où de nombreuses itérations sont attendues, le coût d'entrée est absorbé par les gains obtenus à chaque mise à jour. En revanche, dans le cas contraire, le bénéfice temps investis versus efficacité technique peut être beaucoup moins intéressant.

À découvrir : notre formation LLM Engineering

Enfin, cette approche nécessite que plusieurs équipes techniques ou opérationnels collaborent à différents stades d'un projet. Cela peut devenir d'autant plus problématique lorsque le projet peut traiter des sujets critiques, comme des données sensibles ou si la finalité est un LLM qui sera à disposition du grand public.a

Conclusion

Avec le LLMOps, les entreprises sont dorénavant capables d'adopter les bonnes pratiques DevOps pour les projets incluant des LLM. Les nombreuses solutions d'offrent cette approche permettent aux entreprises d'optimiser leur processus de déploiement, et donc de proposer des solutions toujours plus pertinentes.

Il est tout de même important de garder à l'esprit que l'approche LLMOps est adéquate pour les projets à forte valeur ajouté et qui nécessite de nombreuses itérations. Comme nous l'avons abordé, cette approche robuste reste néanmoins difficile à mettre en place, du fait de la complexité technique et de l'investissement initial que cela représente.

Tout comme l'approche MLOps n'est pas figée dans le marbre, le LLMOps est d'autant plus récent, et qui n'est pas encore totalement structurés. Les prochaines années seront décisives dans le choix des outils et des patterns récurrents qui feront office de référence et de bonnes pratiques dans ce cadre précis.