Partager via

GenAIOps pour les praticiens MLOps

  • Article

Cet article fournit des conseils aux équipes de charge de travail qui ont des investissements MLOps existants et qui souhaitent étendre ces investissements pour inclure l'IA générative dans leur charge de travail. Pour opérationnaliser une charge de travail d'IA générative, vous devez étendre vos investissements MLOps avec GenAIOps (parfois connu sous le nom étroit de LLMOps). Cet article décrit les schémas techniques communs entre les charges de travail de machine learning traditionnel et d'IA générative, ainsi que les schémas spécifiques à l'IA générative. L'article vous aide à comprendre où vous pouvez appliquer les investissements existants en matière d'opérationnalisation et où vous devez étendre ces investissements.

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 :

  • Se concentrer sur les modèles génératifs - Les charges de travail traditionnelles de machine learning sont centrées sur la formation de nouveaux modèles entraînés à effectuer des tâches spécifiques. Les charges de travail d'IA générative consomment des modèles génératifs qui peuvent être utilisés pour répondre à une plus grande variété de cas d'utilisation et, dans certains cas, sont multimodaux.

  • Se concentrer sur l'extension des modèles - La ressource clé du machine learning traditionnel est le modèle déployé. L'accès au modèle est fourni au code client dans une ou plusieurs charges de travail, mais la charge de travail ne fait pas partie du processus MLOps. Avec les solutions d'IA générative, une facette clé de la solution est la requête qui est 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 traditionnelles d'apprentissage automatique, telles que la formation et le réglage fin des modèles, elles introduisent toutes de nouveaux modèles que vous devez normaliser. 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 fin
  • 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. Cela dit, il existe des cas d'utilisation qui peuvent bénéficier et bénéficient effectivement de l'affinement d'un modèle de base ou de la formation d'un nouveau modèle d'IA générative, tel qu'un petit modèle de langage (SLM).

La formation d'un nouveau SLM ou l'affinement d'un modèle génératif de base sont logiquement les mêmes processus que la formation de modèles de machine learning traditionnels. Ces processus devraient utiliser vos investissements MLOps existants.

Ingénierie d’invite

L'ingénierie des requêtes comprend tous les processus impliqués dans la génération d'une requête qui est envoyée en 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 à n'importe quel nombre de magasins de données pour recueillir des informations, telles que 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é en tant que point de terminaison de l'API auquel accède le code client dans une application intelligente.

Diagramme montrant l'architecture de l'ingénierie des requêtes.

Figure 1. Architecture technique de la requête

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

  • classification ;
  • Traduction
  • Résumé
  • la génération augmentée par récupération, qui est abordée 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 l'ingénierie des requêtes dont l'objectif est d'utiliser des données spécifiques à un domaine comme données de 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 peut nécessiter un raisonnement sur des données spécifiques à votre entreprise, à vos clients ou à votre domaine. Avec les solutions RAG, vos données sont interrogées et les résultats sont fournis au modèle de langage dans le cadre de la requête, généralement par le biais d'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.

Diagramme montrant l'architecture de génération augmentée par récupération (RAG).

Figure 2 : Architecture de génération augmentée par la recherche (RAG)

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

Dans cette section, nous examinons les aspects clés suivants des phases de boucle interne et externe pour les modèles techniques d'IA générative afin de voir où vous pouvez appliquer vos investissements MLOps existants et où vous devez les étendre :

DataOps

Les MLOps et les GenAIOps utilisent tous deux les fondamentaux des DataOps pour créer des workflows extensibles et reproductibles afin de s'assurer que les données sont nettoyées, transformées et formatées correctement pour l'expérimentation et l'évaluation. La reproductibilité des workflows et le versionnage des données sont des fonctionnalités importantes pour les DataOps pour tous les schémas techniques, tandis que les sources, les types et l'intention des données dépendent des schémas.

Formation et mise au point

Ce modèle technique devrait utiliser pleinement les investissements DataOps que vous avez réalisés dans le cadre de votre mise en œuvre MLOps. La reproductibilité et la version des données vous permettent d'expérimenter avec différentes données d'ingénierie des fonctionnalités, de comparer les performances des différents modèles et de reproduire les résultats.

RAG et ingénierie des requêtes

L'objectif des données dans les solutions RAG est de fournir des données de base qui sont présentées au modèle linguistique dans le cadre d'une requête. 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 segmentage des documents ne font pas partie des DataOps dans les MLOps traditionnels, vous devez donc étendre à la fois votre architecture et vos opérations. Les pipelines de données peuvent lire des données provenant de plusieurs sources disparates avec des données structurées et non structurées. Ils peuvent également écrire les données transformées vers différentes cibles. Vous devez étendre votre architecture pour inclure les magasins de données que vous utilisez pour les données de base. Les magasins de données les plus courants pour ces modèles sont les magasins vectoriels comme Azure AI Search. Comme pour l'entraînement et la mise au point, vous pouvez tirer parti des pipelines Azure Machine Learning ou d'autres outils de pipelining de données pour orchestrer les étapes du segmentage. 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

Dans le cadre de la boucle interne, l'expérimentation est le processus itératif de construction, d'évaluation (abordé dans la section suivante) 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.

Formation et mise au point

Lorsque vous affinez un modèle de langage existant ou que vous formez un petit modèle de langage, vous pouvez utiliser vos investissements MLOps actuels. Par exemple, les pipelines Azure Machine Learning offrent une boîte à outils robuste pour mener des expériences de manière efficace et efficiente. Ces pipelines vous permettent de gérer l'ensemble du processus de mise au point, du prétraitement des données à la formation et à l'évaluation des modèles.

RAG et ingénierie des requêtes

L'expérimentation des charges de travail d'ingénierie des requêtes et de 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. Votre charge de travail nécessite un orchestrateur, c'est-à-dire un système qui sait comment exécuter la logique, appeler les magasins de données pour obtenir les informations requises, comme les données de mise à la terre, générer des requêtes, appeler les modèles de langage, etc. Les magasins de données et les index des magasins font également partie de la charge de travail. Vos opérations doivent être étendues pour régir ces aspects de la charge de travail.

Il existe de multiples dimensions à expérimenter pour les solutions d'ingénierie des requêtes, notamment différentes instructions, personas, exemples, contraintes et techniques avancées comme le chaînage des requêtes. Lorsque vous expérimentez des solutions RAG, il existe d'autres domaines à expérimenter, notamment les suivants :

  • Stratégie de segmentation
  • Comment et quoi 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 indiqué dans DataOps, les clés de l'expérimentation sont la reproductibilité et la version des données. Un bon cadre d'expérimentation vous permet de stocker des entrées, telles que des modifications d'hyperparamètres ou des requêtes, ainsi que des sorties à utiliser lors de l'évaluation de l'expérience.

Comme pour votre environnement MLOps existant, vous pouvez tirer parti de frameworks tels que les pipelines Azure Machine Learning. Les pipelines Azure Machine Learning ont des fonctionnalités qui prennent en charge l'indexation, l'intégration avec des magasins de vecteurs tels que Azure AI Search. Votre environnement GenAIOps peut tirer parti de ces fonctionnalités des pipelines et les combiner avec des fonctionnalités de flux d'invite qui gèrent l'ingénierie des requêtes 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 vous fournit les commentaires nécessaires pour affiner votre solution ou valider que l'itération actuelle répond à vos besoins. 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.

Formation et mise au point

L'évaluation de modèles d'IA générative affinés ou entraînés doit utiliser vos investissements MLOps existants. Par exemple, si vous utilisez les pipelines Azure Machine Learning pour orchestrer la formation de vos modèles d'apprentissage automatique, vous pouvez profiter des mêmes fonctionnalités d'évaluation pour affiner les modèles de langage de fondation ou former de nouveaux petits modèles de langage. Ces fonctionnalités incluent l'utilisation de la composante Evaluate Model qui calcule les mesures d'évaluation standard pour des types de modèles spécifiques et compare les résultats entre les modèles.

RAG et ingénierie des requêtes

Vous devez étendre vos investissements MLOps existants pour évaluer les solutions d'IA générative. Vous pouvez tirer parti d'outils tels que le flux d'invite qui offre un cadre robuste pour l'évaluation. Les flux d'invites permettent 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 modèles linguistiques (LLM). Cette approche structurée permet de comparer côte à côte différentes configurations, telles que des ajustements d'hyperparamètres ou des variations architecturales, afin d'identifier la configuration optimale pour des tâches spécifiques.

Les requêtes du flux d'invite capturent automatiquement les données d'entrée et de sortie tout au long du processus d'expérimentation, créant ainsi un enregistrement complet des essais. 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érative en menant des expérimentations efficaces et systématiques à l'aide des flux d'invite.

Le processus d'expérimentation est le même quel que soit le cas d'utilisation de votre solution d'IA générative, comme la classification, le résumé, la traduction ou 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 exemples de mesures que vous devriez prendre en compte par 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

Pour plus d'informations sur l'évaluation des modèles linguistiques et des solutions RAG, consultez l'évaluation de bout en bout du programme LLM.

Les solutions d'IA générative, en général, étendent les responsabilités de l'équipe de machine learning de la formation des modèles à l'ingénierie des requêtes et à la gestion des données d'ancrage. Parce que l'ingénierie des requêtes et l'expérimentation et l'évaluation du RAG ne nécessitent pas nécessairement des data scientists, il est tentant de remplir ces fonctions avec d'autres rôles tels que les ingénieurs logiciels et les ingénieurs de données. Vous rencontrerez des difficultés si vous omettez les data scientists dans l'expérimentation des solutions d'ingénierie des requêtes et de RAG. Les autres fonctions ne sont généralement pas formées à l'évaluation scientifique des résultats comme le sont 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 soulager vos ressources en science des données. Le rôle des ingénieurs logiciels s'accroît dans ces solutions. Par exemple, les ingénieurs logiciels sont d'excellentes ressources pour gérer la responsabilité de l'orchestration dans les solutions d'IA générative et ils sont aptes à mettre en place les mesures d'évaluation dans des outils tels que le flux d'invite. Il est important que ce travail soit effectué sous l'œil attentif de vos data scientists. Ces derniers ont la formation et l'expérience nécessaires pour comprendre comment évaluer correctement les expériences.

Déploiement

Certaines solutions d'IA générative impliquent le déploiement de modèles formés personnalisés ou l'ajustement des modèles existants, tandis que d'autres ne le font pas. Les solutions d'IA générative ajoutent une responsabilité supplémentaire pour le déploiement des orchestrateurs et des magasins de données. Les sections suivantes traitent du déploiement des modèles techniques d'IA générative les plus courants.

Formation et mise au point

Le déploiement de modèles d'IA générative et l'ajustement des modèles fondamentaux devraient utiliser vos investissements MLOps existants, avec quelques ajustements possibles. Par exemple, pour affiner 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 charger les données via une API REST. Vous devez également créer une tâche de réglage fin. Le déploiement d'un petit modèle linguistique entraîné peut tirer parti de vos investissements MLOps existants.

RAG et ingénierie des requêtes

Pour le RAG et la requête, il existe des préoccupations supplémentaires que vous devez déployer, notamment la logique d'orchestration, les changements apportés aux magasins de données tels que les index ou les schémas, et les changements apportés à la logique du pipeline de données. La logique d'orchestration est normalement encapsulée dans des cadres tels que le flux d'invite, le noyau sémantique ou LangChain. Vous pouvez déployer l'orchestrateur vers différentes ressources de calcul, y compris les ressources vers lesquelles vous pouvez actuellement déployer des modèles personnalisés. Consultez l’architecture de référence de référence des conversations de bout en bout Azure OpenAI pour obtenir des exemples de déploiement d’un flux d’invite vers des points de terminaison en ligne managés Azure Machine Learning ou Azure App Service. Pour le déploiement sur Azure App Service, l'architecture de base du chat Azure OpenAI package le flux et ses dépendances sous forme de conteneur, une pratique qui augmente la portabilité et la cohérence dans différents environnements.

Les déploiements de modifications des ressources de base de données, telles que les changements de modèles de données ou d'index, sont de nouvelles responsabilités qui doivent être gérées dans 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 d'IA générative qui utilisent des modèles de langage hébergés sur une plateforme, comme ceux fournis par Azure OpenAI, comprennent une passerelle telle qu'Azure API Management. Les cas d'utilisation de la passerelle comprennent l'équilibrage de la charge, l'authentification, la surveillance, etc. 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 restaurer les versions précédentes en cas de problème.

Les déploiements de préoccupations spécifiques à l'IA générative, telles que l'orchestrateur, devraient suivre des procédures opérationnelles appropriées, telles que :

  • des tests rigoureux, y compris des tests unitaires
  • Tests d’intégration
  • des tests A/B
  • Tests de bout en bout
  • des stratégies de déploiement telles que les déploiements canari ou bleu/vert.

Étant donné que les responsabilités de déploiement des applications d'IA générative vont au-delà du simple déploiement de modèles, vous pouvez avoir besoin de rôles supplémentaires pour gérer le déploiement et la surveillance d'éléments tels que l'interface utilisateur, l'orchestrateur et les magasins 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 concerne l'observation des opérations en cours du système, y compris les opérations sur les données (DataOps) et l'entraînement des modèles. Vous recherchez les déviations, y compris les erreurs, les changements de taux d'erreur et les changements de temps de traitement.

En ce qui concerne la formation et la mise au point des modèles, vous observez généralement les opérations sur les données relatives au traitement des données de fonctionnalité, à la formation des modèles et à la mise au point. La surveillance de ces préoccupations en boucle interne devrait utiliser vos investissements existants en matière de MLOps et de DataOps.

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 mise à la terre ou d'autres données utilisées pour générer des requêtes. Ce traitement peut inclure des opérations de stockage de données telles que la construction ou la reconstruction d'index.

Tirer des enseignements de la production

L'apprentissage à partir de la production est un aspect essentiel de la surveillance au stade de l'inférence. La surveillance des modèles de machine learning traditionnels permet de suivre des mesures telles que l'exactitude, la précision et le rappel. L'un des principaux objectifs est de se prémunir contre la dérive des prédictions. Les solutions qui utilisent des modèles génératifs pour faire des prédictions, par exemple un modèle GPT pour la classification, devraient utiliser vos investissements existants en matière de surveillance MLOps.

Les solutions qui utilisent des modèles génératifs pour raisonner sur les données d'ancrage utilisent des mesures telles que l'ancrage, l'exhaustivité, l'utilisation et la pertinence. L'objectif est de s'assurer que le modèle répond pleinement à la requête et base la réponse sur son contexte. Il s'agit ici de se prémunir contre des problèmes tels que la dérive des données. Vous voulez vous assurer que les données de base et la requête que vous fournissez au modèle sont aussi pertinentes que possible pour la demande 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 de commentaires humains pour évaluer les sentiments d'utilité des utilisateurs finaux. Les interfaces utilisateur peuvent capturer des commentaires tels que des pouces levés ou baissés et ces données peuvent être utilisé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. La passerelle peut être utilisée pour journaliser les requêtes d'entrée et les sorties.

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

Pour les solutions génératives qui utilisent des modèles exposés en tant que service, comme Azure OpenAI, les préoccupations en matière de gestion des ressources sont différentes de celles des modèles que vous déployez vous-même. Vous n'êtes pas concerné par l'infrastructure, mais plutôt par le débit, le quota et la limitation de votre service. Azure OpenAI utilise le concept de jetons pour la facturation, la limitation 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 jetons.

Outillage

De nombreux praticiens MLOps ont standardisé une boîte à outils pour organiser les différentes activités autour de l'automatisation, du suivi, du déploiement, de l'expérimentation, et ainsi de suite, afin de faire abstraction des nombreuses préoccupations communes et des détails de mise en œuvre de ces processus. Une plateforme unifiée commune est MLflow. Avant de chercher de nouveaux outils pour prendre en charge les modèles GenAIOps, vous devriez examiner vos outils MLOps existants pour évaluer leur prise en charge de 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

Dans le cadre de vos investissements MLOps actuels, vous avez peut-être utilisé le modèle de maturité MLOps pour évaluer la maturité de vos opérations et environnement machine learning. À 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 vous recommandons de les mesurer indépendamment l'un de l'autre. MLOps et GenAIOps évolueront indépendamment l'un de l'autre. Par exemple, vous pouvez être au niveau 4 du modèle de maturité MLOps, mais commencer à utiliser l'IA générative et n'être qu'au niveau 1.

Résumé

Lorsque vous commencez à étendre vos investissements MLOps pour inclure l'IA générative, il est important de comprendre qu'il n'est pas nécessaire de tout recommencer. 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. Certains domaines des solutions d'IA générative, tels que l'ingénierie des requêtes et la RAG, sont de nouveaux processus nets et vous devrez étendre vos investissements opérationnels existants et 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.

Étape suivante

Azure OpenAI