Conception d’applications pour les charges de travail IA sur Azure
Il existe de nombreux choix à prendre en compte lors de la planification de la génération d’une application avec des fonctions IA. Vos exigences fonctionnelles et non fonctionnelles uniques vous aident à limiter les décisions de haut niveau relatives à votre conception, comme si le cas d’usage est le Machine Learning traditionnel, génératif, déterministe ou une combinaison de types d’IA. À mesure que vous passez des zones de conception de haut niveau aux zones de conception de niveau inférieur, il existe plusieurs choix à prendre en compte le long de la route.
Comme indiqué dans l’article Prise en main , choisir de créer votre propre modèle ou d’utiliser un modèle prédéfini est l’une des premières décisions importantes à prendre. Lorsque vous choisissez un modèle prédéfini, tenez compte des points suivants :
Sources de catalogue. Explorez les référentiels tels que Hugging Face Model Hub, TensorFlow Hub ou le catalogue de modèles Azure AI Studio pour rechercher des modèles préentraînés. Ces plateformes fournissent un catalogue complet de modèles sur différentes tâches.
Gestion des licences. Assurez-vous que les termes de licence du modèle correspondent à vos objectifs de sécurité, de conformité et d’application, en particulier si vous envisagez de distribuer l’application ou de l’intégrer à d’autres services.
Composants clés. Examinez l’architecture du modèle, les données d’apprentissage, les performances et les licences pour déterminer si elle est affinée pour votre tâche ou domaine.
Pour obtenir des conseils sur le choix d’une plateforme d’hébergement, consultez considérations relatives à la plateforme d’hébergement de modèle.
Cet article explore de nombreux domaines et facteurs de conception courants à prendre en compte lors de la prise de décisions importantes sur la technologie et l’approche.
Recommandations
Voici le résumé des recommandations fournies dans cet article.
| Recommandation | Description |
|---|---|
| Hiérarchiser les solutions prêtes à l’emploi. | Chaque fois que cela est pratique, utilisez des solutions PaaS (Platform as a Service) pour gérer les fonctions de charge de travail. Utilisez des modèles prédéfinis et préentraînés si possible pour réduire le fardeau opérationnel et de développement pour vos équipes de charge de travail et d’exploitation. |
| Fonctions et fonctionnalités abstraites loin du client. | Gardez le client aussi mince que possible en concevant des services back-end pour gérer les problèmes de réduction croisée, tels que la limitation de débit et les opérations de basculement. |
| Bloquer l’accès aux magasins de données. | Le code dans le système IA ne doit pas toucher directement vos magasins de données. Acheminer toutes les demandes de données via une couche API. Les API doivent être conçues pour la tâche spécifique requise. |
| Isolez vos modèles. | Comme les magasins de données, utilisez une couche API pour agir en tant que passerelle pour les demandes adressées au modèle. Certaines solutions PaaS telles qu’Azure OpenAI Service et Azure Machine Learning utilisent des kits SDK à cet effet. De nombreux outils, comme PromptFlow, contiennent une prise en charge native pour propager des API au service. |
| Composants de conception pouvant être déployés indépendamment. | Les modèles IA, les pipelines de données, les composants frontaux et les microservices tels que le prétraitement des données, l’extraction des fonctionnalités et l’inférence doivent être déployés indépendamment pour optimiser la flexibilité, l’extensibilité et l’opéraabilité de votre charge de travail. |
Conteneuriser des composants
Pour vous assurer que vos composants pouvant être déployés indépendamment sont entièrement autonomes et pour simplifier vos déploiements, envisagez de conteneuriser dans le cadre de votre stratégie de conception. Les composants suivants doivent être conteneurisés :
Microservices : les microservices individuels qui gèrent des fonctions spécifiques de l’application, telles que le traitement des données, l’inférence de modèle ou l’authentification utilisateur, doivent être conteneurisés. Cette approche permet un déploiement et une mise à l’échelle indépendants, ce qui facilite les mises à jour et la maintenance plus efficaces.
Modèles IA : conteneuriser des modèles IA pour vous assurer que toutes les dépendances, bibliothèques et configurations sont regroupées. Cette approche isole l’environnement de modèle du système hôte, empêche les conflits de version et garantit un comportement cohérent dans différents environnements de déploiement.
Pipelines de traitement des données : toutes les tâches de traitement des données qui précèdent ou suivent l’inférence de modèle, telles que le nettoyage, la transformation et l’extraction des fonctionnalités, doivent être conteneurisées. Cette approche améliore la reproductibilité et simplifie la gestion des dépendances.
Services d’infrastructure : les services qui fournissent une prise en charge de l’infrastructure, comme les bases de données ou les couches de mise en cache, peuvent également tirer parti de la conteneurisation. Cette approche permet de maintenir la cohérence des versions et facilite la mise à l’échelle et la gestion de ces composants.
Colocaliser des composants IA avec d’autres composants de charge de travail
Il existe plusieurs bonnes raisons de colocaliser vos composants IA avec d’autres composants de charge de travail, mais il existe des compromis avec cela. Les raisons pour lesquelles vous pouvez colocaliser sont les suivantes :
Sensibilité à la latence : colocaliser des composants IA avec d’autres services, tels que l’hébergement d’API, lorsque la faible latence est importante. Par exemple, si l’inférence en temps réel est nécessaire pour améliorer l’expérience utilisateur, le fait de placer des modèles IA proches de l’API peut réduire le temps nécessaire pour récupérer les résultats.
Proximité des données : lorsque les modèles IA nécessitent un accès fréquent à des jeux de données spécifiques, tels qu’un index de recherche, la colocalisation de ces composants peut améliorer les performances et réduire la surcharge du transfert de données pour un traitement et une inférence plus rapides.
Utilisation des ressources : si certains composants ont des besoins en ressources complémentaires, comme le processeur et la mémoire, la colocalisation de ces ressources peut optimiser l’utilisation des ressources. Par exemple, un modèle qui nécessite un calcul significatif peut partager des ressources avec un service qui a des demandes inférieures en même temps.
Compromis. Il existe des compromis avec les composants de colocalisation qui doivent être pris en compte. Vous risquez de perdre la possibilité de déployer ou de mettre à l’échelle des composants indépendamment. Vous pouvez également augmenter votre risque de dysfonctionnement en augmentant le rayon potentiel d’explosion des incidents.
Évaluer l’utilisation d’orchestrateurs dans des solutions d’IA génératives
Un orchestrateur gère le flux de travail qui coordonne la communication entre les différents composants de la solution IA qui seraient autrement difficiles à gérer dans les charges de travail complexes. Nous vous recommandons de créer un orchestrateur dans votre conception si votre charge de travail présente l’une des caractéristiques suivantes :
Flux de travail complexes : le flux de travail implique plusieurs étapes, telles que le prétraitement, le chaînage de modèles ou le post-traitement.
Logique conditionnelle : les décisions doivent être prises dynamiquement en fonction des sorties de modèle, telles que le routage des résultats vers différents modèles.
Mise à l’échelle et gestion des ressources : vous devez gérer l’allocation de ressources pour les applications à volume élevé à l’aide de la mise à l’échelle des modèles en fonction de la demande.
Gestion de l’état : vous devez gérer l’état et la mémoire des interactions utilisateur.
Récupération des données : vous devez être en mesure de récupérer des données d’augmentation à partir de l’index.
Considérations relatives à l’utilisation de plusieurs modèles
Lorsque votre charge de travail utilise plusieurs modèles, l’utilisation d’un orchestrateur est essentielle. L’orchestrateur est responsable du routage des données et des requêtes vers le modèle approprié en fonction du cas d’usage. Planifiez le flux de données entre les modèles, en vous assurant que les sorties d’un modèle peuvent servir d’entrées pour une autre. La planification peut impliquer des processus de transformation de données ou d’enrichissement.
Orchestration et agents
Pour les charges de travail d’IA génératives, envisagez de prendre une approche basée sur un agent, parfois appelée agentique, pour ajouter l’extensibilité à votre orchestration. Les agents font référence à la fonctionnalité liée au contexte, partageant de nombreuses caractéristiques de style de microservice qui effectuent des tâches conjointement avec un orchestrateur. L’orchestrateur peut publier des tâches sur un pool d’agents ou d’agents peut inscrire des fonctionnalités auprès de l’orchestrateur. Les deux approches permettent à l’orchestrateur de décider dynamiquement comment décomposer et router la requête entre les agents.
Les approches agentiques sont idéales lorsque vous disposez d’une surface d’interface utilisateur commune avec plusieurs fonctionnalités évolutives qui peuvent être connectées à cette expérience pour ajouter plus de compétences et de mise à l’avant des données au flux au fil du temps.
Pour les charges de travail complexes avec de nombreux agents, il est plus efficace de permettre aux agents de collaborer dynamiquement au lieu d’utiliser un orchestrateur pour décomposer les tâches et les affecter.
La communication entre l’orchestrateur et les agents doit suivre un modèle de file d’attente de rubriques, où les agents sont abonnés à une rubrique et que l’orchestrateur envoie des tâches via une file d’attente.
L’utilisation d’une approche agentique fonctionne mieux avec un modèle d’orchestration plutôt qu’un modèle de chorégraphie.
Pour plus d’informations, consultez Considérations relatives à la plateforme d’orchestration.
Évaluer l’utilisation des passerelles d’API
Les passerelles d’API, telles qu’Azure Gestion des API, extrayent les fonctions des API qui dissocient les dépendances entre le service demandeur et l’API. Les passerelles d’API offrent les avantages suivants aux charges de travail IA :
Plusieurs microservices : ils vous aident à gérer plusieurs points de terminaison de modèle IA et à appliquer des stratégies cohérentes, telles que la limitation de débit et l’authentification.
Gestion du trafic : ils vous aident à gérer efficacement les applications à trafic élevé en gérant efficacement les demandes, la mise en cache des réponses et la distribution des charges.
Sécurité : ils fournissent un contrôle d’accès centralisé, une journalisation et une protection contre les menaces pour les API derrière la passerelle.
Tirer parti des modèles de conception d’applications IA
Il existe plusieurs modèles de conception courants qui ont été établis dans le secteur pour les applications IA que vous pouvez utiliser pour simplifier votre conception et votre implémentation. Ces modèles de conception sont les suivants :
Ensembling de modèle : ce modèle de conception implique la combinaison de prédictions de plusieurs modèles pour améliorer la précision et la robustesse, en réduisant les faiblesses des modèles individuels.
Architecture des microservices : la séparation des composants en services déployables indépendamment améliore la scalabilité et la maintenance, ce qui permet aux équipes de travailler simultanément sur différentes parties de l’application.
Architecture pilotée par les événements : l’utilisation d’événements pour déclencher des actions permet de découpler les composants et le traitement en temps réel, ce qui rend le système plus réactif et adaptable aux modifications de données.
Modèles RAG et stratégies de segmentation
Le modèle de génération augmentée de récupération (RAG) combine des modèles génératifs avec des systèmes de récupération, ce qui permet au modèle d’accéder à des sources de connaissances externes pour améliorer le contexte et la précision. Consultez la conception et le développement d’une série de solutions RAG pour obtenir des conseils détaillés sur ce modèle. Il existe deux approches RAG :
Juste-à-temps : cette approche récupère dynamiquement les informations pertinentes au moment d’une demande, ce qui garantit que les données les plus récentes sont toujours utilisées. Il est utile dans les scénarios nécessitant un contexte en temps réel, mais peut introduire une latence.
Précalculée (mise en cache) : cette méthode implique la mise en cache des résultats de récupération, ce qui réduit les temps de réponse en servant des données précalculées. Il convient aux scénarios à forte demande dans lesquels des données cohérentes peuvent être stockées, mais peuvent ne pas refléter les informations les plus actuelles, ce qui entraîne des problèmes potentiels de pertinence.
Lorsque vous utilisez un modèle RAG, une stratégie de segmentation bien définie est essentielle pour optimiser l’efficacité des performances de votre charge de travail. Commencez par les conseils fournis dans la conception et le développement d’une série de solutions RAG. Les recommandations supplémentaires à prendre en compte sont les suivantes :
Implémentez une stratégie de segmentation dynamique qui ajuste les tailles de bloc en fonction du type de données, de la complexité des requêtes et des exigences utilisateur. Cela peut améliorer l’efficacité de récupération et la conservation du contexte.
Incorporez des boucles de commentaires pour affiner les stratégies de segmentation en fonction des données de performances.
Conservez la traçabilité des données pour les blocs en conservant les métadonnées et les identificateurs uniques qui renvoient à la source de base. La documentation de traçabilité claire permet de s’assurer que les utilisateurs comprennent l’origine des données, ses transformations et leur contribution à la sortie.
Quand utiliser des modèles de conception
Envisagez d’utiliser ces modèles de conception lorsque votre cas d’usage répond à l’une des conditions suivantes :
Flux de travail complexes : lorsque vous traitez de flux de travail complexes ou d’interactions entre plusieurs modèles IA, des modèles tels que RAG ou microservices peuvent aider à gérer la complexité et à garantir une communication claire entre les composants.
Exigences en matière d’extensibilité : si la demande sur votre application varie, l’utilisation d’un modèle tel que les microservices permet aux composants individuels de s’adapter indépendamment, en tenant compte des charges variables sans avoir d’impact sur les performances globales du système.
Applications pilotées par les données : si votre application nécessite une gestion étendue des données, une architecture pilotée par les événements peut fournir une réactivité en temps réel et un traitement efficace des données.
Remarque
Les applications ou les PC plus petits ne bénéficient généralement pas de l’adoption de l’un de ces modèles de conception et doivent être créés avec une conception simpliste. De même, si vous avez des contraintes de ressources (budget, temps ou nombre d’entre eux), l’utilisation d’une conception simpliste qui peut être refactorisé ultérieurement est une meilleure approche que l’adoption d’un modèle de conception complexe.
Choisir les infrastructures et bibliothèques appropriées
Le choix des infrastructures et des bibliothèques est étroitement lié à la conception d’applications, ce qui a un impact non seulement sur l’architecture, mais aussi sur les performances, la scalabilité et la maintenance. À l’inverse, les exigences de conception peuvent limiter les choix d’infrastructure, en créant une interaction dynamique entre les deux. Par exemple, l’utilisation du SDK de noyau sémantique (SK) encourage souvent une conception basée sur des microservices où chaque agent ou fonctionnalité est encapsulé dans son propre service. Les facteurs à prendre en compte lors du choix de frameworks et de bibliothèques sont les suivants :
Exigences de l’application : les exigences spécifiques de l’application, telles que le traitement en temps réel ou le traitement par lots, peuvent limiter le choix de l’infrastructure. Par exemple, si l’application exige une faible latence, une infrastructure avec des fonctionnalités asynchrones peut être nécessaire.
Besoins d’intégration : la conception peut nécessiter des intégrations spécifiques avec d’autres systèmes ou services. Si une infrastructure ne prend pas en charge les protocoles ou les formats de données nécessaires, il peut être nécessaire de reconsidérer la conception ou de sélectionner un autre framework.
Expertise de l’équipe : l’ensemble de compétences de l’équipe de développement peut limiter les choix d’infrastructure. Une conception qui s’appuie sur un framework moins familier peut entraîner une augmentation du temps de développement et de la complexité, invitant à sélectionner un outil plus familier.
Concevoir une stratégie pour les identités, l’autorisation et l’accès
En règle générale, vous devez aborder l’identité, l’autorisation et l’accès de la même façon que vous concevez normalement des applications. Vous devez utiliser un fournisseur d’identité, comme Microsoft Entra ID, pour gérer ces zones autant que possible. Toutefois, il existe des défis uniques pour de nombreuses applications IA qui ont besoin d’une considération particulière. La persistance des listes de contrôle d’accès (ACL) via le système est parfois difficile ou même impossible sans introduire de développement nouveau.
Passez en revue les conseils fournis dans la solution RAG mutualisée sécurisée pour apprendre à ajouter des métadonnées de découpage de sécurité aux documents et aux blocs. Ce découpage peut être basé sur des groupes de sécurité ou des constructions organisationnelles similaires.
Tenez compte des exigences non fonctionnelles
Vous pouvez avoir des exigences non fonctionnelles pour votre charge de travail qui sont difficiles en raison de facteurs inhérents aux technologies IA. Les exigences non fonctionnelles courantes et leurs défis sont les suivants :
Latence de l’inférence/délai d’attente du modèle : les applications IA nécessitent souvent des réponses en temps réel ou en quasi-temps réel. La conception pour une faible latence est cruciale, ce qui implique l’optimisation de l’architecture du modèle, des pipelines de traitement des données et des ressources matérielles. L’implémentation de stratégies de mise en cache et la garantie d’un chargement efficace du modèle sont également essentielles pour éviter les délais d’expiration et fournir des réponses en temps opportun.
Limitations du débit des jetons ou des demandes : de nombreux services IA imposent des limites sur le nombre de jetons ou le débit des requêtes, en particulier lors de l’utilisation de modèles cloud. La conception pour ces limitations nécessite une gestion minutieuse des tailles d’entrée, des demandes de traitement par lots si nécessaire, et éventuellement l’implémentation de mécanismes de limitation ou de mise en file d’attente pour gérer les attentes des utilisateurs et empêcher les interruptions de service.
Scénarios de coût et de rétrofacturation : la conception pour la transparence des coûts implique l’implémentation de fonctionnalités de suivi et de création de rapports d’utilisation qui facilitent les modèles de rétrofacturation, ce qui permet aux organisations d’allouer les coûts avec précision dans les services. La gestion des rétrofacturations est normalement gérée par une passerelle d’API, comme Azure Gestion des API.