Partage via

GenAIOps pour les praticiens MLOps

  • Article

Cet article fournit des recommandations aux équipes de charge de travail qui disposent déjà d’investissements en opération de machine learning (MLOps) et souhaitent les étendre pour intégrer l’IA générative dans leur charge de travail. Pour opérationnaliser une charge de travail d’IA générative, vous devez compléter vos investissements MLOps avec les Ops d’IA générative (GenAIOps, parfois appelées LLMOps). Cet article présente des modèles techniques communs aux charges de travail de machine learning traditionnelles et d’IA générative, ainsi que des modèles spécifiques à l’IA générative. L’article vous aide à comprendre où vous pouvez appliquer les investissements existants en opérationnalisation et où il faut les étendre.

La planification et l’implémentation d’un MLOps et genAIOps font partie d’un domaine de conception principal dans les charges de travail IA sur Azure. Pour obtenir un arrière-plan sur la raison pour laquelle ces charges de travail ont besoin d’opérations spécialisées, consultez MLOps et GenAIOps pour les charges de travail IA sur Azure dans Azure Well-Architected Framework.

Modèles techniques d'IA générative

Les charges de travail d'IA générative diffèrent des charges de travail de machine learning traditionnelles de quelques façons :

  • Concentrez-vous sur les modèles génératifs. Les charges de travail en machine learning traditionnelles se concentrent sur l’entraînement de nouveaux modèles destinés à accomplir des tâches spécifiques. Les charges de travail d’IA générative exploitent des modèles génératifs capables de répondre à une plus grande variété de cas d’utilisation et, parfois, sont multimodaux.

  • Concentrez-vous sur l’extension des modèles. L’atout principal en machine learning traditionnel est le modèle déployé. L'accès au modèle est fourni au code client dans un ou plusieurs workloads, mais celui-ci ne fait pas partie du processus MLOps. Avec les solutions d’IA générative, un aspect essentiel est l’invite fournie au modèle génératif. La requête doit être composée et peut contenir des données provenant d'un ou de plusieurs magasins de données. Le système qui orchestre la logique, les appels aux différents back ends, génère la requête et les appels au modèle génératif fait partie du système d'IA générative que vous devez gouverner avec GenAIOps.

Bien que certaines solutions d’IA générative utilisent des pratiques de machine learning traditionnelles telles que l’entraînement et l’ajustement fin des modèles, elles introduisent toutes de nouveaux modèles que vous devriez standardiser. Cette section présente une vue d'ensemble des trois grandes catégories de modèles techniques pour les solutions d'IA générative :

  • Pré-entraînement et réglage précis
  • Ingénierie d’invite
  • Génération augmentée par récupération (RAG)

Formation et mise au point des modèles linguistiques

Actuellement, de nombreuses solutions d'IA générative utilisent des modèles linguistiques de base existants qui ne nécessitent pas de réglage fin avant utilisation. Cependant, certains cas d’utilisation peuvent bénéficier d’un réglage précis d’un modèle de base ou de l’entraînement d’un nouveau modèle d’IA générative, comme un petit modèle de langage (SLM).

L’entraînement d’un nouveau SLM et le réglage précis d’un modèle de base génératif reposent logiquement sur les mêmes processus que l’entraînement de modèles de machine learning traditionnels. Ces processus devraient utiliser vos investissements MLOps existants.

Ingénierie d’invite

L’ingénierie des invites inclut tous les processus impliqués dans la génération d’une invite envoyée comme entrée à un modèle génératif. Il y a généralement un orchestrateur qui contrôle un workflow qui génère la requête. L'orchestrateur peut faire appel à un nombre quelconque de magasins de données pour recueillir des informations, comme les données de mise à la terre, et appliquer la logique requise pour générer la requête la plus efficace. L’orchestrateur est ensuite déployé sous forme de point de terminaison API auquel le code client d’une application intelligente accède.

Le schéma suivant présente une architecture pour l’ingénierie de l’invite.

Schéma illustrant une architecture pour l’ingénierie de l’invite.

Cette catégorie de modèles techniques peut répondre à de nombreux cas d'utilisation, notamment

  • Classification.
  • Traduction.
  • Résumé.
  • Retrieval-augmented generation, qui est abordé dans la section suivante.

Génération augmentée par récupération

La génération augmentée par récupération (RAG) est un modèle architectural qui utilise la conception de prompts pour intégrer des données spécifiques au domaine comme base pour un modèle de langage. Le modèle de langage est formé à partir d'un ensemble spécifique de données. Votre charge de travail pourrait nécessiter un raisonnement sur des données spécifiques à votre entreprise, vos clients ou votre domaine. Dans les solutions RAG, vos données sont interrogées, et les résultats sont intégrés à l’invite envoyée au modèle de langage, généralement via une couche d’orchestration.

Une mise en œuvre RAG courante consiste à décomposer vos documents en segments et à les stocker dans un magasin vectoriel avec des métadonnées. Les magasins de vecteurs, tels que Azure AI Search, vous permettent d'effectuer des recherches de similarités textuelles et vectorielles afin d'obtenir des résultats pertinents sur le plan contextuel. Les solutions RAG peuvent également utiliser d'autres magasins de données pour renvoyer des données de mise à la terre.

Le schéma suivant illustre une architecture RAG :

Schéma illustrant une architecture RAG.

Extension des MLOps pour les modèles techniques d'IA générative

Cette section décrit les aspects clés des phases de boucle interne et externe pour les modèles techniques d’IA générative et vous aide à comprendre où vous pouvez appliquer vos investissements MLOps existants et où il faut les étendre :

DataOps

Les MLOps et les GenAIOps reposent sur les fondamentaux du DataOps pour créer des flux de travail extensibles et reproductibles garantissant que les données sont nettoyées, transformées et correctement formatées pour l’expérimentation et l’évaluation. La reproductibilité des flux de travail et la gestion des versions des données sont des caractéristiques importantes du DataOps pour tous les modèles techniques. Les sources, les types et l’intention des données dépendent du modèle.

Entraînement et réglage précis

Ce modèle technique doit tirer pleinement parti des investissements DataOps que vous avez réalisés dans le cadre de votre implémentation MLOps. La reproductibilité et la gestion des versions des données vous permettent d’expérimenter avec différentes données d’ingénierie des fonctionnalités, de comparer la performance des différents modèles et de reproduire les résultats.

RAG et ingénierie des requêtes

L’intention des données dans les solutions RAG est de fournir des données de référence présentées au modèle de langage dans le contexte d'une sollicitation. Les solutions RAG nécessitent souvent le traitement de documents volumineux en une collection de segments de bonne taille et sémantiquement pertinents, et la persistance de ces segments dans un magasin vectoriel. Pour plus de détails, voir Conception et développement d'une solution RAG. La reproductibilité et le versionnage des données pour les solutions RAG vous permettent d'expérimenter différentes stratégies de segmentation et d'intégration, de comparer les performances et de restaurer les versions précédentes.

Les pipelines de données pour le chunking des documents ne font pas partie du DataOps dans les MLOps traditionnels, il vous faut donc étendre votre architecture et vos opérations. Les pipelines de données peuvent extraire des données provenant de sources diverses incluant des données structurées et non structurées. Ils peuvent également écrire les données transformées vers différentes destinations. Vous devez étendre votre architecture pour inclure les entrepôts de données que vous utilisez pour les données de référence. Les magasins de données courants pour ces modèles sont des magasins vectoriels comme AI Search.

Comme pour l’entraînement et le réglage précis, vous pouvez utiliser les pipelines Azure Machine Learning ou d’autres outils de pipelines de données pour orchestrer les étapes de chunking. Vous pouvez tirer parti des flux d'invite dans les pipelines Azure Machine Learning pour traiter et enrichir vos données de manière cohérente et reproductible. Vous devez également étendre vos opérations pour maintenir la fraîcheur et la validité des index de recherche dans vos magasins de données.

Expérimentation

L'expérimentation, qui fait partie de la boucle interne, est le processus itératif de création, d'évaluation et d'affinage de votre solution. Les sections suivantes traitent de l'expérimentation pour les modèles techniques d'IA générative les plus courants.

Entraînement et réglage précis

Lorsque vous réglez avec précision un modèle de langage existant ou entraînez un petit modèle de langage, vous pouvez tirer parti de vos investissements MLOps actuels. Par exemple, les pipelines Azure Machine Learning offrent un ensemble d’outils pour mener des expériences de manière efficace et efficiente. Ces pipelines vous permettent de gérer l’ensemble du processus d’ajustement fin, depuis le prétraitement des données jusqu’à l’entraînement et l’évaluation du modèle.

RAG et ingénierie des requêtes

L'expérimentation avec l'ingénierie des requêtes et les charges de travail RAG nécessite d'étendre vos investissements MLOps. Pour ces modèles techniques, la charge de travail ne se termine pas avec le modèle. La charge de travail nécessite un orchestrateur, qui est un système capable d’exécuter une logique, d’appeler des sources de données pour obtenir des informations requises telles que les données de base, générer des invites, appeler des modèles de langage, et plus encore. Les magasins de données et les index des magasins font également partie de la charge de travail. Il vous faut étendre vos opérations pour gérer ces aspects de la charge de travail.

Vous pouvez expérimenter sur plusieurs dimensions pour les solutions d'ingénierie des requêtes, y compris différentes instructions, personas, exemples, contraintes et techniques avancées comme le chaînage des requêtes. Lorsque vous expérimentez des solutions RAG, vous pouvez le faire dans d'autres domaines :

  • Stratégie de segmentation
  • Quoi et comment enrichir les segments.
  • Votre modèle d'intégration
  • Configuration de votre index de recherche
  • Recherches à effectuer (vecteur, texte intégral, hybride, et ainsi de suite)

Comme expliqué dans DataOps, la reproductibilité et la gestion des versions des données sont essentielles pour l’expérimentation. Une bonne infrastructure d’expérimentation vous permet de stocker des entrées, telles que les modifications apportées aux hyperparamètres ou aux invites, ainsi que les sorties à utiliser lorsque vous évaluez l’expérimentation.

Comme dans votre environnement MLOps actuel, vous pouvez profiter de frameworks tels que les pipelines Azure Machine Learning. Les pipelines Azure Machine Learning disposent de fonctionnalités supportant l’indexation en s’intégrant à des magasins de vecteurs comme AI Search. Votre environnement GenAIOps peut tirer parti de ces fonctionnalités de pipeline et les combiner avec des fonctionnalités de flux d'invite qui gèrent l'ingénierie des invites et la logique de prétraitement personnalisée.

Évaluation et expérimentation

L'évaluation est essentielle dans le processus d'expérimentation itératif qui consiste à construire, évaluer et affiner votre solution. L’évaluation de vos modifications fournit les retours nécessaires pour affiner vos ajustements ou valider que l’itération actuelle répond à vos exigences. Les sections suivantes traitent de l'évaluation dans la phase d'expérimentation pour les modèles techniques d'IA générative les plus courants.

Entraînement et réglage précis

Pour évaluer les modèles d’IA générative ajustés ou entraînés, vous devriez tirer parti de vos investissements MLOps existants. Par exemple, si vous utilisez les pipelines Azure Machine Learning pour orchestrer l’entraînement de vos modèles de machine learning, vous pouvez exploiter les mêmes fonctionnalités d’évaluation pour ajuster finement les modèles de base ou entraîner de nouveaux petits modèles de langage. Ces fonctionnalités incluent le composant Evaluate Model, qui calcule des métriques d’évaluation conformes aux standards de l’industrie pour des types de modèles spécifiques et compare les résultats entre modèles.

RAG et ingénierie des requêtes

Il faut étendre vos investissements MLOps existants pour évaluer les solutions d’IA générative. Vous pouvez utiliser des outils tels que prompt flow, qui fournit un cadre pour l’évaluation. Le flux d'invites permet aux équipes de définir une logique d'évaluation personnalisée en spécifiant des critères et des mesures pour évaluer les performances de diverses variantes d'invites et de grands modèles de langage (LLM). Cette approche structurée vous permet de comparer côte à côte différentes configurations, telles que des variations d’hyperparamètres ou d’architecture, afin d’identifier la configuration optimale pour des tâches spécifiques.

Les tâches du flux d'invite capturent automatiquement les données d'entrée et de sortie tout au long du processus d'expérimentation afin de créer un dossier d'essai complet. L'analyse de ces données vous permet d'obtenir des aperçus et d'identifier des configurations prometteuses susceptibles d'éclairer les itérations futures. Vous pouvez accélérer le développement de vos solutions d’IA génératives à l’aide de flux de consignes pour effectuer des expérimentations efficaces et systématiques.

Le processus d’expérimentation est identique quel que soit le cas d’utilisation de votre solution d’IA générative. Ces cas d’utilisation incluent la classification, le résumé, la traduction et même le RAG. La différence importante réside dans les mesures que vous utilisez pour évaluer les différents cas d'utilisation. Voici quelques métriques à prendre en compte selon le cas d’utilisation.

  • Traduction : BLEU
  • Résumés : ROUGE. BLEU, BERTScore, METEOR
  • Classification : Précision, rappel, précision, entropie croisée
  • RAG : ancrage, pertinence

Remarque

Consultez l’évaluation de bout en bout des LLM pour plus d’informations sur l’évaluation des modèles de langage et des solutions RAG.

En général, les solutions d'IA génératives élargissent les responsabilités de l'équipe de machine learning, allant de la formation des modèles à l'ingénierie des prompts et à la gestion des données de base. Étant donné que l’ingénierie de l’invite ainsi que l’expérimentation et l’évaluation du RAG ne requièrent pas nécessairement des data scientists, vous pourriez être tenté de confier ces fonctions à d’autres profils, comme des ingénieurs logiciels ou des ingénieurs de données. Vous rencontrerez des difficultés si vous omettez les data scientists dans le processus d'expérimentation de l'ingénierie des requêtes et des solutions RAG. D'autres rôles ne reçoivent généralement pas de formation pour évaluer scientifiquement les résultats, contrairement à de nombreux scientifiques des données. Lisez la série d'articles en sept parties Conception et développement d'une solution RAG pour comprendre la complexité de la conception de solutions d'IA générative.

Investir dans des solutions d’IA générative vous permet de décharger quelque peu vos ressources en data science. Le rôle des ingénieurs logiciels s’élargit dans ces solutions. Par exemple, les ingénieurs en logiciels sont des ressources précieuses pour gérer la responsabilité de l’orchestration dans les solutions d’IA génératives, et ils sont compétents pour configurer les métriques d’évaluation dans des outils tels que le flux de requêtes. Il est important que des data scientists examinent ce travail. Ils possèdent la formation et l’expérience nécessaires pour évaluer correctement les expérimentations.

Déploiement

Certaines solutions d’IA générative impliquent le déploiement de modèles entraînés sur mesure ou un ajustement de modèles existants, alors que d’autres non. Pour les solutions d’IA générative, il faut inclure les tâches supplémentaires de déployer les orchestrateurs et les réservoirs de données. Les sections suivantes abordent le déploiement pour les modèles techniques courants d’IA générative.

Entraînement et réglage précis

Vous devez utiliser vos investissements MLOps existants, avec quelques ajustements possibles, pour déployer des modèles d’IA générative et ajuster les modèles de base. Par exemple, pour ajuster un grand modèle de langage dans Azure OpenAI, vous devez vous assurer que vos ensembles de données d’entraînement et de validation sont au format JSONL, et vous devez uploader les données via une API REST. Vous devez également créer une tâche de réglage fin. Pour déployer un modèle de petit langage entraîné, vous pouvez tirer parti de vos investissements MLOps existants.

RAG et ingénierie des requêtes

Pour le RAG et l'ingénierie des requêtes, il existe des préoccupations supplémentaires, notamment la logique d'orchestration, les modifications apportées aux magasins de données comme les index et les schémas, et les modifications apportées à la logique du pipeline de données. La logique d’orchestration est généralement encapsulée dans des frameworks tels que le flux d’invite, Semantic Kernel ou LangChain. Vous pouvez déployer l’orchestrateur sur différentes ressources de calcul, y compris celles sur lesquelles vous déployez actuellement des modèles personnalisés. Consultez l'architecture de chat de bout en bout Azure OpenAI pour des exemples de déploiement du flux d'invite soit vers des points de terminaison en ligne gérés par Azure Machine Learning, soit vers Azure App Service. Pour déployer sur App Service, l’architecture de chat Azure OpenAI conditionne le flux et ses dépendances dans un conteneur, ce qui augmente la portabilité et la cohérence entre différents environnements.

Les déploiements de modifications sur les ressources de base de données, telles que les changements de modèles de données ou d’index, sont de nouvelles tâches à gérer dans les GenAIOps. Une pratique courante lorsque l'on travaille avec de grands modèles de langage consiste à utiliser une passerelle devant le LLM.

De nombreuses architectures IA génératives qui consomment des modèles de langage hébergés par la plateforme, comme ceux servis depuis Azure OpenAI, incluent une passerelle comme Azure API Management. Les cas d’utilisation de la passerelle incluent la répartition de charge, l’authentification et la surveillance. La passerelle peut jouer un rôle dans le déploiement de modèles nouvellement formés ou affinés, ce qui vous permet de déployer progressivement de nouveaux modèles. L’utilisation d’une passerelle, associée à la gestion des versions des modèles, vous permet de minimiser les risques lors du déploiement des changements et de revenir à des versions antérieures en cas de problème.

Les déploiements d’éléments spécifiques à l’IA générative, tels que l’orchestrateur, doivent suivre des procédures opérationnelles adéquates, telles que :

  • Des tests rigoureux, incluant des tests unitaires.
  • Tests d’intégration.
  • Tests A/B.
  • Des tests de bout en bout.
  • Des stratégies de déploiement progressif, telles que les déploiements canari ou blue/green.

Comme les responsabilités de déploiement pour les applications d’IA générative dépassent le simple déploiement des modèles, vous pourriez avoir besoin de profils supplémentaires pour gérer le déploiement et la surveillance de composants tels que l’interface utilisateur, l’orchestrateur et les réservoirs de données. Ces rôles sont souvent alignés sur les ensembles de compétences de l’ingénieur DevOps.

Inférence et surveillance

L'inférence est le processus qui consiste à transmettre des données à un modèle formé et déployé, qui génère ensuite une réponse. Vous devriez surveiller à la fois l'apprentissage automatique traditionnel et les solutions d'IA générative selon trois perspectives : la surveillance opérationnelle, l'apprentissage à partir de la production et la gestion des ressources.

Surveillance opérationnelle

La surveillance opérationnelle est le processus d’observation du fonctionnement continu du système, incluant les opérations de données (DataOps) et l’entraînement des modèles. Ce type de surveillance recherche des écarts, incluant les erreurs, les variations des taux d’erreur et les modifications des temps de traitement.

Pour l’entraînement et l’ajustement des modèles, vous observez généralement les opérations de données relatives au traitement des données de fonctionnalités, à l’entraînement des modèles et à leur ajustement. La surveillance de ces processus de boucle interne devrait tirer parti de vos investissements MLOps et DataOps existants.

Pour l'ingénierie de requête dans les solutions d'IA générative, vous avez des préoccupations de surveillance supplémentaires. Vous devez surveiller les pipelines de données qui traitent les données de base ou d'autres données utilisées pour générer des requêtes. Ce traitement peut inclure des opérations sur les réservoirs de données telles que la création ou la reconstruction d’index.

Tirer des enseignements de la production

Un aspect essentiel à surveiller pendant la phase d’inférence est de tirer des enseignements de la production. La surveillance des modèles d'apprentissage automatique traditionnels effectue le suivi des métriques telles que l'exactitude, la précision et le rappel. Un objectif clé est d’éviter le décalage de prédiction. Les solutions qui utilisent des modèles génératifs pour effectuer des prédictions, par exemple en utilisant un modèle GPT pour la classification, devraient tirer parti de vos investissements existants en surveillance MLOps.

Les solutions qui utilisent des modèles génératifs pour raisonner sur des données d’ancrage utilisent des métriques telles que l’ancrage, la complétude, l’utilisation et la pertinence. L’objectif est de s’assurer que le modèle répond entièrement à la requête et fonde sa réponse sur le contexte. Ici, il convient de prévenir des problèmes tels que le dérèglement des données. Vous voulez vous assurer que les données d’ancrage et l’invite fournies au modèle sont le plus pertinentes possible par rapport à la requête de l’utilisateur.

Les solutions qui utilisent des modèles génératifs pour des tâches non prédictives, telles que les solutions RAG, bénéficient souvent des retours des utilisateurs finaux pour évaluer l’utilité ressentie. Les interfaces utilisateur peuvent recueillir des retours tels que des pouces levés ou baissés, et vous pouvez utiliser ces données pour évaluer périodiquement les réponses.

Un modèle courant pour les solutions d'IA générative consiste à déployer une passerelle devant les modèles génératifs. L'un des cas d'utilisation de la passerelle est la surveillance des modèles fondamentaux. Vous pouvez utiliser la passerelle pour enregistrer les requêtes d'entrée et la sortie.

Un autre domaine clé à surveiller pour les solutions génératives est la sécurité du contenu. L'objectif est de modérer les réponses et de détecter les contenus nuisibles ou indésirables. Azure AI Content Safety Studio est un exemple d’outil que vous pouvez utiliser pour modérer le contenu.

Gestion des ressources

Les solutions génératives qui utilisent des modèles exposés en tant que service, comme Azure OpenAI, présentent des préoccupations de gestion de ressources différentes de celles des modèles que vous déployez vous-même. Pour les modèles exposés en tant que service, l’infrastructure ne constitue pas une préoccupation. Vous vous intéressez plutôt au débit de votre service, à votre quota et au throttling. Azure OpenAI utilise des tokens pour la facturation, le throttling et les quotas. Vous devez surveiller l'utilisation des quotas pour la gestion des coûts et l'efficacité des performances. Azure OpenAI vous permet de journaliser l’utilisation des tokens.

Outillage

De nombreux praticiens MLOps se sont standardisés sur une boîte à outils permettant d’organiser diverses activités d’automatisation, de suivi, de déploiement, d’expérimentation, etc., afin d’abstraire les préoccupations communes et les détails d’implémentation de ces processus. Une plateforme unifiée commune est MLflow. Avant de rechercher de nouveaux outils pour soutenir les modèles GenAIOps, vous devriez examiner vos outils MLOps existants afin d’en évaluer la compatibilité avec l’IA générative. Par exemple, MLflow prend en charge un large éventail de fonctionnalités pour les modèles de langage.

Modèles de maturité MLOps et GenAIOps

Vous avez peut-être utilisé le modèle de maturité MLOps pour évaluer la maturité de vos opérations de machine learning et de votre environnement actuels. À mesure que vous étendez vos investissements MLOps pour les charges de travail d'IA générative, vous devriez utiliser le modèle de maturité GenAIOps pour évaluer ces opérations. Vous pourriez être tenté de combiner les deux modèles de maturité, mais nous recommandons de mesurer chacun séparément. MLOps et GenAIOps évolueront indépendamment l'un de l'autre. Par exemple, vous pourriez être au niveau quatre dans le modèle de maturité MLOps mais au niveau un pour l’IA générative.

Résumé

Lorsque vous commencez à étendre vos investissements MLOps pour inclure l’IA générative, il est important de comprendre que vous n’avez pas besoin de repartir de zéro. Vous pouvez utiliser vos investissements MLOps existants pour certains des modèles techniques d’INTELLIGENCE artificielle générative. Le réglage fin des modèles génératifs en est un excellent exemple. Il existe des domaines des solutions d’IA générative, tels que l’ingénierie de l’invite et le RAG, qui constituent de nouveaux processus, ce qui nécessite d’étendre vos investissements opérationnels existants et d’acquérir de nouvelles compétences.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes