Partager via


Approches architecturales pour les solutions multilocataires IA et ML

Le nombre de solutions multilocataires basées sur l’intelligence artificielle (AI) et le Machine Learning (ML) ne cesse de croître. Une solution IA/ML multilocataire propose des capacités de ML à un nombre illimité de locataires. En général, les locataires ne peuvent ni voir ni partager les données d’un autre locataire, mais dans certains cas, ils peuvent utiliser les mêmes modèles que d’autres locataires.

Les architectures d’IA/ML multilocataires doivent prendre en considération les besoins en matière de données et de modèles, ainsi que les ressources de calcul nécessaires à l’entraînement des modèles et la réalisation de l’inférence à partir des modèles. Il est important de réfléchir à la façon dont les modèles d’IA/ML multilocataires sont déployés, distribués et orchestrés, et de s’assurer que votre solution est précise, fiable et scalable.

Principaux éléments et exigences à prendre en compte

Lorsque vous utilisez l’intelligence artificielle et le machine learning, il est important de prendre en compte vos besoins en matière d’entraînement et d’inférence de façon distincte. L’entraînement vise à créer un modèle prédictif à partir d’un ensemble de données. Vous effectuez l’inférence lorsque vous vous servez du modèle pour prédire quelque chose dans votre application. Chacun de ces processus présente des exigences différentes. Dans une solution multilocataire, vous devez réfléchir à la façon dont votre modèle de location influe sur chaque processus. En prenant en compte chacune de ces exigences, vous pouvez garantir la précision des résultats offerts par votre solution, son niveau de performance sous forte charge, son rapport coût-efficacité et sa scalabilité pour votre croissance future.

Isolation des locataires

Veillez à ce que les locataires n’aient pas un accès non autorisé ou indésirable aux données ou modèles d’autres locataires. Traitez les modèles avec la même sensibilité que les données brutes qui les ont été entraînés. Veillez à ce que vos locataires comprennent bien la façon dont leurs données sont utilisées pour l’entraînement des modèles et comment les modèles entraînés sur les données d’autres locataires peuvent être utilisés à des fins d’inférence sur leurs charges de travail.

Il existe trois approches courantes en matière d’utilisation de modèles ML dans les solutions multilocataires : les modèles propres au locataire, les modèles partagés et les modèles partagés ajustés.

Modèles propres au locataire

Les modèles propres au locataire sont entraînés uniquement sur les données d’un même locataire avant d’être appliqués à celui-ci. Les modèles propres au locataire sont indiqués quand les données des locataires sont sensibles ou qu’il y a peu à apprendre des données fournies par un locataire et que vous appliquez le modèle à un autre locataire. Le diagramme suivant illustre la façon dont vous pourriez créer une solution avec des modèles propres au locataire pour deux locataires :

Diagramme illustrant deux modèles spécifiques au client. Chaque modèle est entraîné avec les données d'un seul locataire. Les modèles sont utilisés pour l'inférence par les utilisateurs de ce locataire.

Modèles partagés

Dans les solutions qui utilisent des modèles partagés, tous les locataires effectuent une inférence à partir d’un même modèle partagé. Les modèles partagés peuvent être des modèles préentraînés que vous vous procurez ou obtenez auprès d’une source communautaire. Le diagramme suivant illustre la façon dont un même modèle préentraîné peut être utilisé par tous les locataires pour l’inférence :

Diagramme qui montre un seul modèle pré-entraîné. Le modèle est utilisé pour l'inférence par les utilisateurs de tous les locataires.

Vous pouvez aussi créer vos propres modèles partagés en les entraînant à partir des données fournies par tous vos locataires. Le diagramme suivant illustre un modèle partagé unique, qui est entraîné sur les données de tous les locataires :

Diagramme qui montre un modèle partagé unique formé sur les données de plusieurs locataires. Le modèle est utilisé pour l'inférence par les utilisateurs de tous les locataires.

Important

Si vous entraînez un modèle partagé à partir des données de vos locataires, vérifiez qu’ils ont bien compris que leurs données allaient être utilisées et qu’ils sont d’accord. Vérifiez que les informations d’identification sont supprimées des données de vos locataires.

Envisagez une solution si un locataire s’oppose à ce que ses données servent à entraîner un modèle destiné à être appliqué à un autre locataire. Par exemple, auriez-vous la possibilité d’exclure les données d’un certain locataire du jeu de données d’entraînement ?

Modèles partagés ajustés

Vous pouvez aussi choisir de vous procurer un modèle de base préentraîné pour le faire évoluer par des ajustements afin de le rendre applicable à chacun de vos locataires, à partir de leurs propres données. Le diagramme suivant illustre cette approche :

Diagramme qui montre un modèle de base pré-entraîné spécialisé pour chaque locataire, avec ses propres données. Les modèles sont utilisés pour l'inférence par les utilisateurs de ce locataire.

Extensibilité

Réfléchissez aux effets de la croissance de votre solution sur votre utilisation de composants IA et ML. « Croissance » peut renvoyer à une augmentation du nombre de locataires, de la quantité de données stockées pour chaque locataire, du nombre d’utilisateurs et du volume de demandes envoyées à votre solution.

Entraînement : les ressources nécessaires à l’entraînement de vos modèles varient en fonction de plusieurs facteurs. Ces facteurs peuvent être le nombre de modèles dont vous avez besoin pour l’entraînement, la quantité de données avec laquelle vous entraînez les modèles ou encore la fréquence à laquelle vous entraînez ou réentraînez les modèles. Si vous créez des modèles propres au locataire, vos besoins en ressources de calcul et en stockage croîtront probablement à mesure que le nombre de locataires augmentera. Si vous créez des modèles partagés et les entraînez à partir des données de tous vos locataires, il est moins probable que les ressources destinées à l’entraînement évolueront au même rythme que le nombre de locataires. Cependant, une accroissement de la quantité globale de données d’entraînement aura un impact sur les ressources consommées pour l’entraînement des modèles partagés et propres au locataire.

Inférence : les ressources nécessaire à l’inférence sont généralement proportionnelles au nombre de demandes qui accèdent aux modèles pour l’inférence. Plus le nombre de locataires augmente, plus le nombre de demandes a également des chances d’augmenter.

L’utilisation de services Azure qui assurent une bonne scalabilité constitue une bonne pratique générale. Sachant que les charges de travail IA/ML ont tendance à utiliser des conteneurs, Azure Kubernetes Service (AKS) et Azure Container Instances (ACI) sont souvent privilégiés pour les charges de travail IA/ML. AKS s’avère généralement un bon choix en termes de scalabilité et permet une mise à l’échelle dynamique des ressources de calcul en fonction de la demande. Si, pour les petites charges de travail, ACI constitue une plateforme de calcul facile à configurer, sa mise à l’échelle n’est pas aussi simple qu’AKS.

Performances

Prenez en considération les exigences de performances pour les composants IA/ML de votre solution, aussi bien pour l’entraînement que pour l’inférence. Il est important de clarifier vos besoins en matière de latence et de performances pour chaque processus, de façon à pouvoir établir des mesures et à apporter les amélioration nécessaires.

Entraînement : l’entraînement se présente souvent sous la forme d’un processus de traitement par lots, ce qui signifie qu’il n’est pas forcément aussi sensible aux performances que les autres parties de votre charge de travail. Cependant, vous devez veiller à provisionner suffisamment de ressources pour assurer un entraînement de modèle efficace, y compris lorsque vous procédez à une mise à l’échelle.

Inférence : l’inférence est un processus sensible à la latence, qui demande souvent une réponse rapide voire en temps réel. Même si vous n’avez pas besoin d’assurer une inférence en temps réel, veillez à surveiller le niveau de performance de votre solution et à utiliser les services appropriés pour optimiser votre charge de travail.

Envisagez d’utiliser les capacités de calcul hautes performances d’Azure pour vos charges de travail d’IA et de ML. Azure propose différents types de machines virtuelles et d’autres instances matérielles. Déterminez si l’utilisation de processeurs, de GPU, de FPGA ou d’autres environnements à accélération matérielle pourrait profiter à votre solution. Par ailleurs, Azure assure une inférence en temps réel au moyen de GPU NVIDIA, y compris des serveurs d’inférence NVIDIA Triton. Pour les besoins en calcul de faible priorité, envisagez d’utiliser des pools de nœuds spot AKS. Pour en savoir plus sur l’optimisation des services de calcul dans une solution multilocataire, consultez Approches architecturales pour le calcul dans les solutions multilocataires.

Dans le mesure où l’entraînement de modèle suppose de nombreuses interactions avec vos magasins de données, il est également important de prendre en compte votre stratégie de données et le niveau de performance proposé par votre couche Données. Pour plus d’informations sur la multilocation et les services de données, consultez Approches architecturales pour le stockage et les données dans les solutions multilocataires.

Envisagez de profiler le niveau de performance de votre solution. Par exemple, Azure Machine Learning propose des capacités de profilage que vous pouvez exploiter au moment de développer et d’instrumenter votre solution.

Complexité de l’implémentation

Quand vous créez une solution destinée à utiliser l’IA et le ML, vous pouvez choisir d’utiliser des composants prédéfinis ou de créer des composants personnalisés. Vous avez deux décisions importantes à prendre. La première porte sur la plateforme ou le service que vous allez utiliser pour l’IA et le ML. La deuxième consiste à déterminer si vous allez utiliser des modèles préentraînés ou bien créer vos propres modèles personnalisés.

Plateformes : les services Azure que vous pouvez utiliser pour vos charges de travail IA et ML sont nombreux. Par exemple, Azure Cognitive Services et Azure OpenAI Service proposent des API pour assurer l’inférence sur des modèles prédéfinis, et Microsoft gère les ressources sous-jacentes. Si Azure Cognitive Services vous permet de déployer rapidement une nouvelle solution, ce service vous offre moins de contrôle sur la façon dont l’entraînement et l’inférence s’effectuent, et il ne convient pas nécessairement à tous les types de charge de travail. En revanche, Azure Machine Learning est une plateforme qui vous permet de créer, entraîner et utiliser vos propres modèles ML. Azure Machine Learning procure contrôle et flexibilité, mais accentue la complexité de votre conception et de votre implémentation. Passez en revue les produits et technologies de machine learning de Microsoft pour choisir une approche de façon avisée.

Modèles : même si vous n’utilisez pas un modèle complet fourni par un service comme Azure Cognitive Services, vous pouvez quand même accélérer votre développement en utilisant un modèle préentraîné. Si un modèle préentraîné ne répond pas précisément à vos besoins, vous pouvez le développer en appliquant une technique appelée apprentissage de transfert ou ajustement. L’apprentissage de transfert vous permet de développer un modèle existant et de l’appliquer à un autre domaine. Par exemple, si vous créez un service de recommandations musicales multilocataire, vous pouvez envisager d’utiliser un modèle de recommandations musicales préentraîné et d’utiliser l’apprentissage de transfert pour entraîner le modèle en fonction des goûts musicaux d’un utilisateur déterminé.

En utilisant des plateformes de ML prédéfinie comme Azure Cognitive Services, Azure OpenAI Service, ou encore un modèle préentraîné, vous pouvez considérablement réduire vos coûts de recherche et de développement initiaux. L’utilisation de plateformes prédéfinies peut vous faire gagner plusieurs mois de recherche et vous éviter d’avoir à recruter des scientifiques de données hautement qualifiés pour entraîner, concevoir et optimiser des modèles.

Optimisation des coûts

En général, les coûts induits par les charges de travail IA et ML sont largement imputables aux ressources de calcul nécessaires à l’entraînement et à l’inférence des modèles. Consultez Approches architecturales pour le calcul dans les solutions multilocataires pour savoir comment optimiser le coût de votre charge de travail de calcul en fonction de vos besoins.

Au moment de planifier vos coûts d’IA et de ML, prenez en considération les points suivants :

  • Déterminez les références SKU de calcul à utiliser pour l’entraînement. Pour cela, reportez-vous aux recommandations pour Azure Machine Learning à titre d’exemple.
  • Déterminez les références SKU de calcul à utiliser pour l’inférence. Pour obtenir un exemple d’estimation de coûts pour l’inférence, reportez-vous aux recommandations pour Azure Machine Learning.
  • Supervisez votre utilisation. En observant l’utilisation de vos ressources de calcul, vous pouvez déterminer s’il est nécessaire d’accroître leur capacité en déployant différentes références SKU ou de les mettre à l’échelle à mesure que vos besoins évoluent. Consultez Supervision d’Azure Machine Learning.
  • Optimisez votre environnement de clustering de calcul. Quand vous utilisez des clusters de calcul, supervisez leur utilisation ou configurez la mise à l’échelle automatique pour effectuer un scale-down au niveau des nœuds de calcul.
  • Partagez vos ressources de calcul. Déterminez si vous pouvez optimiser le coût de vos ressources de calcul en les partageant entre plusieurs locataires.
  • Tenez compte de votre budget. Déterminez si votre budget est fixe et supervisez votre consommation en conséquence. Vous pouvez définir des budgets pour éviter les dépassements et pour allouer des quotas en fonction de la priorité des locataires.

Approches et modèles à prendre en compte

Azure offre un ensemble de services pour permettre les charges de travail IA et ML. Plusieurs approches architecturales sont couramment utilisées dans les solutions multilocataires : utilisation de solutions IA/ML prédéfinies, création d’une architecture IA/ML personnalisée à l’aide d’Azure Machine Learning et utilisation de l’une des plateformes d’analytique Azure.

Utiliser des services IA/ML prédéfinis

Une bonne pratique consiste à essayer d’utiliser des services IA/ML prédéfinis, dans la mesure du possible. Tel est le cas, par exemple, si votre organisation envisage l’IA/ML et qu’elle souhaite une intégration rapide avec un service utile. De même, vous pouvez avoir des besoins limités qui ne vous imposent pas d’entraîner et développement des modèles ML. Les services ML prédéfinis vous permettent d’utiliser l’inférence sans créer et entraîner vos propres modèles.

Azure propose plusieurs services offrant une technologie d’IA et ML dans divers domaines, notamment la compréhension du langage, la reconnaissance vocale, la connaissance, la reconnaissance de documents et de formulaires, et la vision par ordinateur. Parmi les services IA/ML prédéfinis d’Azure, citons Azure Cognitive Services, Azure OPenAI Service, Recherche cognitive Azure et Azure Form Recognizer. Chaque service propose une interface simple pour l’intégration ainsi qu’une collection de modèles préentraînés et testés. En tant que services gérés, ils offrent des contrats de niveau de service et demandent une configuration ou une gestion continue limitées. Vous n’avez pas besoin de développer ou de tester vos propres modèles pour utiliser ces services.

Dans la mesure où la plupart des services ML gérés n’imposent pas de données ou d’entraînement de modèles, l’isolation des données de locataires n’est généralement pas un problème. Cependant, quand vous utilisez la Recherche cognitive dans une solution multilocataire, consultez Modèles de conception pour les applications SaaS multilocataires et Recherche cognitive Azure.

Tenez compte des besoins de mise à l’échelle des composants de votre solution. Par exemple, la plupart des API dans Azure Cognitive Services prennent en charge un nombre maximum de demandes par seconde. Si vous déployez une seule ressource Cognitive Services à partager entre vos différents locataires, vous serez peut-être amené à procéder à une mise à l’échelle avec plusieurs ressources à mesure que le nombre de locataires évoluera.

Notes

Certains services gérés vous permettent d’effectuer l’entraînement avec vos propres données, notamment le service Custom Vision, l’API Visage, les modèles personnalisés Form Recognizer et des modèles OpenAI prenant en charge la personnalisation et l’ajustement. Quand vous utilisez ces services, il est important de prendre en compte les exigences d’isolation des données de vos locataires.

Architecture IA/ML personnalisée

Si votre solution nécessite des modèles personnalisés ou si vous travaillez dans un domaine qui n’est pas couvert par un service ML géré, envisagez de créer votre propre architecture IA/ML. Azure Machine Learning offre une suite de fonctionnalités destinées à orchestrer l’entraînement et le déploiement de modèles ML. Azure Machine Learning prend en charge de nombreuses bibliothèques de machine learning open source, notamment PyTorch, Tensorflow, Scikit et Keras. Vous pouvez constamment superviser les métriques de performances des modèles, détecter une dérive de données et déclencher un nouvel entraînement pour améliorer le niveau de performance des modèles. Tout au long du cycle de vie de vos modèles ML, Azure Machine Learning offre des capacités d’audit et de gouvernance grâce à un suivi et une traçabilité intégrés pour tous vos artefacts ML.

Quand vous travaillez dans une solution multilocataire, il est important de prendre en compte les exigences d’isolation de vos locataires pendant les phases d’entraînement et d’inférence. Vous devez aussi déterminer votre processus d’entraînement et de déploiement de modèles. Azure Machine Learning propose un pipeline pour entraîner les modèles et les déployer dans un environnement à utiliser pour l’inférence. Dans un contexte multilocataire, déterminez si les modèles doivent être déployés sur des ressources de calcul partagées ou si chaque locataire dispose de ressources dédiées. Concevez vos pipelines de déploiement de modèles en fonction de votre modèle d’isolation et de votre processus de déploiement de locataire.

Si vous utilisez des modèles open source, vous serez peut-être amené à entraîner à nouveau ces modèles en procédant à un apprentissage de transfert ou à un ajustement. Réfléchissez à la façon dont vous allez gérer les différents modèles et les données d’entraînement pour chaque locataire, ainsi que les versions du modèle.

Le diagramme suivant illustre un exemple d’architecture qui utilise Azure Machine Learning. L’exemple utilise l’approche d’isolation reposant sur des modèles propres au locataire.

Diagramme qui montre une architecture qui utilise Azure Machine Learning. Un espace de travail, qui contient des projets et des expériences, crée les modèles pour les locataires A, B et C. Les utilisateurs de chaque locataire accèdent à une couche d'API partagée, qui effectue l'inférence en utilisant le modèle ML approprié pour leur locataire.,

Solutions IA/ML intégrées

Azure propose plusieurs plateformes d’analytique puissantes qui peuvent être utilisées à diverses fins. Il s’agit notamment des plateformes Azure Synapse Analytics, Databricks et Apache Spark.

Vous pouvez envisager d’utiliser ces plateformes pour l’IA/ML quand vous avez besoin de mettre à l’échelle vos capacités ML pour un très grand nombre de locataires et que vous avez besoin d’une orchestration et de capacités de calcul à grande échelle. De même, vous pouvez envisager d’utiliser ces plateformes pour l’IA/ML si vous avez besoin d’une plateforme d’analytique de portée générale pour d’autres parties de votre solution, notamment pour l’analytique Données et l’intégration à la création de rapports via Microsoft Power BI. Vous pouvez déployer une plateforme unique qui couvre l’ensemble de vos besoins en matière d’analytique et d’IA/ML. Quand vous implémentez des plateformes de données dans une solution multilocataire, consultez Approches architecturales en matière de stockage et de données dans les solutions multilocataires.

Antimodèles à éviter

  • Non prise en compte des exigences d’isolation. Il est important de réfléchir soigneusement à la façon dont vous allez isoler les données et les modèles des locataires, à la fois pour l’entraînement et pour l’inférence. À défaut, vous risquez de contrevenir à des obligations légales ou contractuelles. De même, la précision de vos modèles risque d’en pâtir si vous les entraînez avec des données très différentes issues de plusieurs locataires.
  • Voisins bruyants. Déterminez si vos processus d’entraînement ou d’inférence peuvent être exposés au problème des voisins bruyants. Par exemple, si vous avez plusieurs locataires de grande taille et un seul de petite taille, veillez à ce que l’entraînement pour les locataires de grande taille ne consomme pas malencontreusement toutes les ressources de calcul et prive le locataire de petite taille. Assurez la gouvernance et la supervision des ressources pour limiter le risque que la charge de travail de calcul d’un locataire soit affectée par l’activité des autres locataires.

Contributeurs

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

Auteur principal :

  • Kevin Ashley | Ingénieur client senior, FastTrack for Azure

Autres contributeurs :

Étapes suivantes