Conception d’applications pour les charges de travail IA sur Azure
Il existe de nombreux choix à prendre en compte lorsque vous créez une application qui a des fonctions IA. Vos exigences fonctionnelles et non fonctionnelles uniques, comme si le cas d’usage est le Machine Learning traditionnel, génératif, déterministe ou une combinaison de types d’IA, vous aidez à limiter les décisions générales relatives à votre conception. Vous allez envisager ces choix à mesure que vous passez des zones de conception de haut niveau aux zones de conception de niveau inférieur.
Comme indiqué dans l’article Prise en main, que vous utilisiez votre propre modèle ou utilisez un modèle prédéfini est l’une des premières décisions importantes à prendre. Lorsque vous utilisez un modèle prédéfini, tenez compte des points suivants :
Sources de catalogue. Explorez des référentiels tels que hugging Face Model Hub, TensorFlow Hub et le catalogue de modèles du portail Azure AI Foundry pour rechercher des modèles préentraînés. Ces plateformes fournissent un catalogue complet de modèles pour 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 votre domaine.
Pour obtenir des conseils sur le choix d’une plateforme d’hébergement, consultez Considérations relatives à l’hébergement et à l’inférence du modèle.
Cet article décrit les domaines et facteurs de conception courants à prendre en compte lorsque vous prenez des décisions sur la technologie et l’approche.
Recommandations
Le tableau suivant récapitule les 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 dorsaux pour gérer des questions transversales telles que la limitation du 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 accéder directement à vos magasins de données. Acheminer toutes les demandes de données via une couche API. Les API doivent être créées spécifiquement pour la tâche requise. |
| Isolez vos modèles. | Comme pour 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 le flux d'invite, contiennent une prise en charge native pour propager les API vers le 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 et l’authentification utilisateur, doivent être conteneurisés. Cette approche permet un déploiement et une mise à l’échelle indépendants et facilite les mises à jour et la maintenance plus efficaces.
Modèles d'IA. Conteneurisez 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 pour empêcher les conflits de version et garantir 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 des données, 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 prennent en charge l’infrastructure, comme les bases de données et les couches de mise en cache, peuvent également tirer parti de la conteneurisation. Le conteneurisation de ces services 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 associés à cette opération. Vous pouvez choisir de colocaliser les composants pour les raisons suivantes :
Sensibilité à la latence. Colocaliser des composants IA avec d’autres services, comme l’hébergement d’API, quand une faible latence est importante. Par exemple, si vous avez besoin d’une inférence en temps réel 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 accélérer le traitement et l’inférence.
L’utilisation des ressources. Si des composants spécifiques ont des besoins en ressources complémentaires, comme le processeur et la mémoire, la colocalisation 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 à prendre en compte lorsque vous décidez s’il faut colocaliser des composants. Vous risquez de perdre la possibilité de déployer ou de mettre à l’échelle des composants indépendamment. Vous pouvez également augmenter le risque de défaillance en augmentant le rayon potentiel de déflagration des incidents.
Évaluer l’utilisation d’orchestrateurs dans des solutions d’IA génératives
Un orchestrateur gère un flux de travail en coordonnant la communication entre les différents composants de la solution IA qui serait autrement difficile à 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, telles que le routage des résultats vers différents modèles, doivent être prises dynamiquement en fonction des sorties du modèle.
La mise à l’échelle et la gestion des ressources. Vous devez gérer l’allocation de ressources pour les applications à volume élevé à l’aide de la mise à l’échelle de modèles basée sur la demande.
Gestion de l'état. Vous devez gérer l’état et la mémoire des interactions utilisateur.
Récupération de 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, un orchestrateur est essentiel. L’orchestrateur achemine les données et les demandes 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 fournissent des fonctionnalités liées au contexte. Ils partagent de nombreuses caractéristiques avec les microservices et effectuent des tâches conjointement avec un orchestrateur. L’orchestrateur peut publier des tâches à un pool d’agents, ou les agents peuvent enregistrer des capacités auprès de l’orchestrateur. Les deux approches permettent à l’orchestrateur de déterminer 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 qui a plusieurs fonctionnalités évolutives pouvant être intégrées à l’expérience pour ajouter plus de compétences et de données de base au flux au fil du temps.
Pour les charges de travail complexes qui ont de nombreux agents, il est plus efficace de permettre aux agents de collaborer dynamiquement plutôt que 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 que Gestion des API Azure abstraient les fonctions des API, ce qui dissocie les dépendances entre le service demandeur et l’API. Les passerelles d’API offrent les avantages suivants aux charges de travail IA :
Multiples microservices. Les passerelles vous aident à gérer plusieurs points de terminaison de modèle IA lorsque vous devez appliquer des stratégies cohérentes, telles que la limitation de débit et l’authentification.
Gestion du trafic. Les passerelles vous aident à gérer efficacement les applications à trafic élevé en gérant les demandes, en mettant en cache les réponses et en distribuant les charges.
Sécurité. Les passerelles fournissent un contrôle d’accès centralisé, une journalisation et une protection contre les menaces pour les API derrière la passerelle.
Utiliser des modèles de conception d’application IA
Plusieurs modèles de conception courants ont été établis dans le secteur pour les applications IA. Vous pouvez les utiliser pour simplifier votre conception et votre implémentation. Ces modèles de conception sont les suivants :
Assemblage de modèles. 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 atténuant les faiblesses des modèles individuels.
Architecture de microservices. La séparation des composants en services déployables indépendamment améliore l’extensibilité et la facilité de maintenance. Elle 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 aux composants découplés et au traitement en temps réel de rendre le système plus réactif et adaptable à la modification des données.
Modèles RAG et stratégies de segmentation
Le modèle de génération de Retrieval-Augmented (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 série d’articles sur la conception et le développement d'une solution RAG pour 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 pour s’assurer que les données les plus récentes sont toujours utilisées. Il est utile dans les scénarios qui nécessitent un contexte en temps réel, mais il peut introduire une latence.
Précalculé (en cache). Cette méthode implique la mise en cache des résultats de récupération pour réduire les temps de réponse en servant des données précalcalées. Il convient aux scénarios à forte demande où des données cohérentes peuvent être stockées. Les données peuvent ne pas refléter les informations les plus actuelles, ce qui peut entraîner des problèmes 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 développez une solution RAG série. Voici quelques recommandations supplémentaires à prendre en compte :
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 préservation 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 la façon dont ils contribuent à la sortie.
Quand utiliser des modèles de conception
Envisagez d’utiliser ces modèles de conception lorsque votre cas d’usage répond à la condition décrite :
Flux de travail complexes. Lorsque vous avez des flux de travail ou des interactions complexes 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'évolutivité. Si la demande sur votre application varie, un modèle tel que les microservices permet aux composants individuels de s’adapter indépendamment aux charges variables sans affecter les performances globales du système.
applications pilotées par les données. Si votre application nécessite une gestion complète 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 ces modèles de conception. Ces applications doivent être conçues par souci de simplicité. De même, si vous avez des contraintes de ressources (budget, temps ou nombre d’entre eux), l’utilisation d’une conception simple 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 frameworks et bibliothèques est étroitement lié à la conception d’applications. Ils affectent les performances, la scalabilité et la facilité de maintenance. Toutefois, les exigences de conception peuvent limiter vos choix d’infrastructure. Par exemple, l’utilisation du SDK de noyau sémantique encourage souvent une conception basée sur des microservices où chaque agent ou fonction est encapsulé dans son propre service. Tenez compte de ces facteurs lorsque vous choisissez des infrastructures et des bibliothèques :
Exigences en matière d'application. Les exigences 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 nécessite une faible latence, vous devrez peut-être utiliser une infrastructure qui a des fonctionnalités asynchrones.
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 formats de données nécessaires, vous devrez peut-être reconsidérer la conception ou choisir 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 une infrastructure moins familière peut entraîner une augmentation du temps de développement et de la complexité, de sorte que vous souhaiterez peut-être utiliser 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 lorsque 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, de nombreuses applications IA présentent des défis uniques qui nécessitent une considération particulière. Il est parfois difficile ou même impossible de conserver les listes de contrôle d’accès (ACL) via le système sans nouveau développement.
Voir Guide de conception d'une solution sécurisée d'inférence RAG multitenant pour savoir comment ajouter des métadonnées de sécurité aux documents et aux segments. Ce découpage peut être basé sur des groupes de sécurité ou des constructions organisationnelles similaires.
Prendre en compte les exigences non fonctionnelles
Votre charge de travail peut avoir des exigences non fonctionnelles qui présentent des défis en raison de facteurs inhérents aux technologies IA. Voici quelques exigences non fonctionnelles courantes et leurs défis :
La latence de l'inférence du modèle et les délais d'attente. Les applications IA nécessitent souvent des réponses en temps réel ou quasiment en temps réel. La conception pour une faible latence est cruciale. Il 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 requêtes. De nombreux services IA imposent des limites sur le nombre de jetons ou le débit des requêtes, en particulier avec les modèles basés sur le cloud. La conception pour ces limitations nécessite une gestion minutieuse des tailles d’entrée, le traitement par lots de requêtes 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.
Les 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 de l’utilisation et de création de rapports qui facilitent les modèles de rétrofacturation. Ces fonctionnalités permettent aux organisations d’allouer les coûts avec précision dans les différents services. La gestion de la rétrofacturation est généralement gérée par une passerelle API, comme Azure API Management.