Tester et évaluer des charges de travail IA sur Azure
L’objectif du test dans les charges de travail IA est de garantir la qualité lorsqu’une modification est introduite dans le système. Les tests peuvent vérifier si la charge de travail répond aux cibles identifiées et répond aux attentes des utilisateurs. Elle empêche également les régressions de qualité. Ce processus comprend l’exécution de tests dans différents domaines fonctionnels et l’évaluation de la qualité des fonctionnalités, de la gestion de la charge, de la prévisibilité et d’autres critères en fonction des exigences de charge de travail.
Les résultats des tests fournissent des points de données critiques pour les décisions telles que si les composants IA sont prêts pour la mise en production et quelles références SKU ou fonctionnalités sont appropriées. En outre, les tests peuvent servir de système de notification pour les défaillances et aider à détecter les problèmes en production par le biais de tests de routine ou synthétiques.
Azure Well-Architected Framework décrit une méthodologie de test complète. Vous devez utiliser différents types de tests à différents stades du cycle de vie de développement et entre différents composants et flux système. Sans ces tests, les modifications déployées peuvent dégrader la qualité du système. Par exemple, des erreurs de code mineures peuvent devenir des défaillances système volumineuses. Le comportement du système peut devenir imprévisible ou produire des résultats biaisés en raison de la nature non déterministe des systèmes IA. En outre, l’allocation de ressources peut être inefficace, et les données utilisateur réelles ou les ressources système peuvent être exploitées, car ces systèmes sont vulnérables à des abus.
Vous devez concevoir et développer des ressources de charge de travail à l’esprit avec des tests. Par exemple, lorsque vous effectuez des manipulations de données et redéfinissez les données sources pour l’ingénierie des fonctionnalités, respectez les bonnes pratiques de codage et assurez-vous de structurer le code pour prendre en charge les tests. Cette stratégie inclut la conception du code pour faciliter les tests unitaires efficaces et isoler les tests de la fonctionnalité du code et de ses dépendances. Dans cet exemple, vous devez concevoir un système qui peut effectuer dans un environnement de test avec des données de test suffisamment représentatives en termes de volume et de ressemblance.
Vous devez déployer des composants de charge de travail en production en toute sécurité. Une partie des pratiques de déploiement sécurisées de toute charge de travail est un test stratégique pour garantir un comportement correct avant que les utilisateurs ou les données consomment le système. Les tests stratégiques sont essentiels pendant le déploiement initial et au fur et à mesure que le système évolue et subit des modifications de code ou d’infrastructure. Testez toutes les modifications proposées dans le code et l’infrastructure liés à l’IA avant de déployer les modifications en production.
Cet article se concentre sur l’application de cette méthodologie aux aspects ia de l’architecture. Comment effectuer ces tests n’est pas dans l’étendue.
Recommandations
Voici le résumé des recommandations fournies dans cet article.
| Recommandation | Description |
|---|---|
| Définissez les métriques de réussite pour votre stratégie de test. | Comme tout autre type de test de charge de travail, vous devez capturer et analyser les métriques appropriées pour un test donné pour vous assurer que votre test fournit des insights utiles sur votre charge de travail IA. ▪ Définir des métriques de réussite |
| Effectuez des tests de bout en bout de vos pipelines d’ingestion et de traitement des données tout au long du cycle de vie du développement. | Les tests peuvent valider les données et vous aider à vous assurer que le processus de manipulation des données fonctionne comme prévu. Incorporez les tests au début de la phase de conception pour garantir la qualité des données et les choix de dimensionnement appropriés. Développez des tests unitaires pour du code personnalisé pendant le développement et effectuez des tests de production en temps réel pour détecter les problèmes et valider les fonctionnalités. ▪ Ingestion des données de test |
| Exécutez des tests pour les travaux d’entraînement pour vous assurer que les scripts sont appelés et fonctionnent comme prévu. | Les tests de charge et de performances peuvent fournir un aperçu du choix et du dimensionnement du calcul adapté à l’exécution des travaux. Les tests unitaires peuvent valider l’utilitaire du code et intercepter les régressions lorsque les dépendances sont mises à jour. ▪ Tester le flux de travail d’entraînement |
| Évaluez et testez le modèle pour éviter la duplication dans les données d’entraînement, d’évaluation et de test. | Pour vous assurer que les données sources ne sont pas entièrement utilisées pour l’entraînement, vous devez réserver des données uniques pour l’évaluation du modèle et les tests finaux. Ces sous-ensembles ne sont pas inclus dans le processus d’entraînement réel. ▪ Évaluer et tester le modèle |
| Testez le point de terminaison d’inférence. | Effectuez des tests de charge sur le point de terminaison que votre serveur d’inférence héberge et choisissez des références SKU GPU en fonction de ces résultats de test. Pour les points de terminaison hébergés par platform as a service (PaaS), testez le débit et les défaillances potentielles. Ces points de terminaison sont accessibles. Effectuez donc des tests de sécurité appropriés pour empêcher les situations de jailbreakage. ▪ Tester le point de terminaison d’inférence |
| Testez la justesse de la conception d’index afin que les requêtes produisent des résultats pertinents. | Les tests fonctionnels et d’intégration vous permettent de vous assurer que les données sont précises et que les tests de schéma d’index vérifient la compatibilité descendante. Vous devez tester les étapes de prétraitement pour la qualité. Les tests de charge déterminent les références SKU appropriées pour les ressources et les contrôles de sécurité protègent la confidentialité des données. ▪ Tester les données de base |
| Testez l’orchestrateur pour valider ses fonctionnalités et sa sécurité. | Effectuez des tests unitaires, fonctionnels, d’intégration et d’exécution, y compris les tests de mode de charge et d’échec, pour garantir les performances et la fiabilité. Les tests de sécurité et de sécurité du contenu sont également essentiels pour protéger le système et les données. ▪ Tester l’orchestrateur |
| Testez la dégradation du modèle. | La dégradation du modèle est un problème inévitable qui affecte la plupart des charges de travail IA. Le test de la dérive des données et des concepts peut vous aider à intercepter la dégradation précoce du modèle et à atténuer le problème avant qu’il n’affecte négativement votre charge de travail. ▪ Empêcher la désintégration du modèle |
Définir des métriques de réussite
Nous vous recommandons d’avoir une base de référence et de mesurer la puissance prédictive du modèle à l’aide de métriques bien définies. Voici quelques métriques courantes.
La précision représente le rapport entre les instances prédites correctement et le nombre total d’instances dans le jeu de données de test. Il s’agit d’une mesure courante des performances globales du modèle.
La précision est le rapport des prédictions positives vraies à la somme des vrais positifs et des faux positifs. Il est utile lorsque la réduction des faux positifs est importante, comme dans les diagnostics médicaux, par exemple.
La sensibilité mesure le rapport des vrais positifs à la somme des vrais positifs et des faux négatifs. Il est utile d’éviter les faux négatifs, ou les cas pertinents manquants, est essentiel.
La spécificité calcule le rapport des vrais négatifs à la somme des vrais négatifs et des faux positifs. Il est pertinent lorsque vous optimisez les prédictions négatives précises.
Remarque
Lorsque vous définissez des métriques de réussite pour les modèles de régression, envisagez d’ajouter les métriques suivantes :
L’erreur absolue moyenne (MAE) mesure la différence absolue moyenne entre les valeurs prédites et les valeurs réelles. Calculez-le en prenant la moyenne des différences absolues entre chaque valeur réelle et sa valeur prédite correspondante. MAE est moins sensible aux valeurs hors norme par rapport à MSE et RMSE.
L’erreur moyenne carrée (MSE) mesure la différence carrée moyenne entre les valeurs réelles et les valeurs prédites. Calculez-le en prenant la moyenne des différences carrées entre chaque valeur réelle et sa valeur prédite correspondante. MSE pénalise les erreurs plus volumineuses que MAE, car les erreurs sont carrées.
L’erreur moyenne moyenne racine (RMSE) est la racine carrée du MSE. Il fournit une mesure de l’erreur absolue moyenne entre les valeurs réelles et prédites, mais dans les mêmes unités que les données d’origine. RMSE est plus sensible aux valeurs hors norme par rapport à MAE, car elle place les erreurs avant d’effectuer une moyenne.
Ingestion des données de test
Les pipelines de données, tels que l’extraction, la transformation et la charge (ETL), le déplacement et la manipulation des données. Testez la partie ETL de la charge de travail pour vous assurer qu’elle ingère les données de manière fiable et que les données sont de haute qualité et acceptables pour l’analyse et l’ingénierie des caractéristiques. Assurez-vous que le nettoyage et le traitement des données incluent des tests pour confirmer que la manipulation des données fonctionne comme prévu.
Les tests doivent être intégrés tout au long du cycle de vie, y compris la conception, le développement et les étapes de production.
Tester pour faciliter les choix de conception
Lorsque vous rassemblez des exigences pour la charge de travail, une étape de prise de décision clé consiste à choisir une option technologique spécifique viable pour votre conception.
En fonction de vos exigences et critères d’acceptation ETL, effectuez des tests fonctionnels exploratoires pour sélectionner le produit le plus approprié, ses références SKU et ses fonctionnalités qui effectuent les tâches prévues. La preuve de concept, la preuve de technologie et les tests de capacités sont essentiels pour déterminer si vous choisissez la technologie appropriée et si elle est dimensionnée de manière appropriée.
Pour les scénarios où vous incorporez l’IA dans une architecture existante, testez la façon dont la nouvelle technologie peut s’intégrer au système actuel.
Les exigences de charge de travail initiales peuvent changer. Supposons que l’entreprise prévoit la croissance et que le système doit gérer deux fois les requêtes utilisateur régulières. Cette attente nécessite une planification appropriée de la capacité. Nous vous recommandons de tester de manière proactive la façon dont le système répond aux données supplémentaires et d’effectuer des ajustements pilotés par les données pour le dimensionnement existant ou faire de nouveaux choix de produit. Pour les tests de capacité, nous vous recommandons de combiner des tests fonctionnels avec des tests de charge et de performances et d’utiliser des synthétiques pour simuler des conditions réalistes.
Tester pour garantir la qualité du code
Lorsque le code est inclus, assurez-vous qu’il passe par des tests unitaires et qu’il n’est pas libéré en cas d’échec. Par exemple, il est courant d’avoir du code personnalisé qui s’exécute dans le cadre de l’ingestion. Il existe également du code utilisé pour le nettoyage et le traitement des données. Exécutez des tests unitaires pour vous assurer que le code se comporte en fonction de sa conception et que la manipulation des données fonctionne comme prévu.
Exécutez des tests dans le cadre de votre pipeline d’intégration continue et de livraison continue.
Tester dans le système en direct
Les tests fonctionnels doivent s’étendre au système en direct. Si ces tests échouent, envisagez de déclencher des alertes pour lancer des enquêtes immédiates, si nécessaire. Voici quelques exemples :
Exécutez des tests planifiés pour vérifier que le volume correct de données a été collecté si les données sont ingérées selon une planification définie avec une quantité attendue.
Exécutez des tests qui détectent des problèmes de données, tels que des valeurs manquantes ou des données en double, et effectuent des vérifications d’intégrité des données de base. Si les données contiennent des informations temporelles qui indiquent son actualisation, ces tests peuvent vérifier ces informations et empêcher potentiellement les processus en aval d’utiliser des données obsolètes.
Vérifiez la disponibilité des dépendances externes. Par exemple, un travail de nettoyage des données peut appeler un autre service pour extraire des tables ou prétraiter. Exécutez des tests pour vous assurer qu’ils sont disponibles, car leur indisponibilité peut affecter le processus ETL.
Une autre façon de tester la justesse du système ETL en production consiste à effectuer des tests synthétiques. Le fait d’avoir des données de test connues disponibles en production est très efficace. Vous pouvez l’utiliser pour valider le traitement de bout en bout en comparant l’état de départ connu à l’état de fin attendu pour ces données. Par exemple, un document est requis pour passer par l’intelligence des documents et contient des données personnelles. L’injection d’un document synthétique peut tester que la charge de travail effectue le travail de manipulation des données comme prévu.
En outre, l’expérience en libérant différentes expériences, également appelées tests A/B, pour apprendre à partir des interactions utilisateur avant la validation complète. Les tests A/B vous aident à prévenir les régressions de qualité.
Tester les données collectées pendant l’ingestion
Dans le cadre du processus d’ingestion provenant de différentes sources de données, incluez des tests pour valider que les données d’apprentissage correspondent à vos attentes.
L’entraînement d’un modèle Machine Learning avec des données incomplètes ou endommagées peut être contre-productif. Cela peut entraîner des efforts gaspiller et entraîner un modèle qui ne parvient pas à effectuer de prédictions significatives. Vos pipelines d’ingestion et de prétraitement des données incluent des tests de qualité en tant que points de contrôle. Ces tests peuvent vous aider à vérifier que vos données s’alignent sur les attentes que vous définissez lors de l’analyse des données et de l’ingénierie des fonctionnalités.
La liste suivante inclut quelques exemples de cas de test :
Testez l’exhaustivité. Testez la quantité attendue de données d’apprentissage pour vérifier l’exhaustivité du jeu de données. Ce test garantit que vous fournissez suffisamment de données pour entraîner le modèle.
Testez les informations critiques. Si l’entraînement est basé sur des entités connues, telles que des enregistrements ou des identificateurs spécifiques, testez le jeu de données pour vous assurer que ces entités sont présentes. Cette validation garantit que les informations critiques ne sont pas manquantes.
Testez les données non pertinentes. Les données ingérées ne doivent pas contenir d’entrées non pertinentes ou erronées. Le processus d’ingestion des données doit filtrer ces données.
Testez l’actualisation. L’actualisation des données ingérées ne doit pas affecter la puissance prédictive du modèle. Vérifiez que les données reflètent des informations raisonnablement actuelles et ne sont pas obsolètes des exécutions précédentes. Par exemple, si vous attendez que les données incluent des enregistrements de la semaine dernière, mais qu’il n’existe aucun enregistrement de ce type après l’importation des données, ce qui peut indiquer un échec de l’importation ou un problème d’actualisation des données dans le système source.
Effectuer des tests de routine
L’ingestion des données constitue une préoccupation importante en matière d’ingestion de données et de débit. L’évaluation continue pendant les opérations est nécessaire pour éviter les goulots d’étranglement des performances. Cette évaluation continue doit faire partie de vos processus opérationnels plutôt que d’un test unique. L’objectif est de s’assurer que l’équipe de charge de travail ne manque pas ses objectifs au niveau du service.
Considérez une situation où la surveillance indique une dégradation des performances. Pour atténuer ces conditions, réévaluez et optimisez les processus ETL. Après avoir apporté des modifications, les tests de performances peuvent vous aider à vous assurer que les modifications répondent au débit requis.
Remarque
Les tests et la surveillance ont des objectifs différents. Effectuez des tests pour évaluer les modifications potentielles apportées au système, généralement avant d’implémenter des modifications. Effectuer une surveillance continue pour évaluer l’intégrité globale du système.
Tester le flux de travail d’entraînement
Entraîner un modèle à l’aide de code personnalisé, tel que des scripts PyTorch, qui effectuent le travail d’entraînement réel. Ces scripts s’exécutent sur le calcul, comme dans les notebooks ou les travaux Azure Machine Learning, qui nécessitent également des ressources de mémoire et de mise en réseau. Nous vous recommandons de tester la charge pendant la phase de conception pour évaluer les besoins de calcul et vous assurer que les références SKU proposées conviennent. Vous avez souvent besoin de tests manuels pour déterminer la meilleure configuration pour exécuter efficacement la charge de travail dans la limite de temps.
Écrivez les scripts à l’aide de Kits de développement logiciel (SDK) spécialisés, qui gèrent la plupart des tâches. Toutefois, étant donné que les scripts sont toujours du code, vous devez intégrer des tests unitaires dans le cadre du développement. Ces tests vous permettent de vous assurer qu’aucune régression ne se produit lorsque vous mettez à jour les dépendances. Si le test unitaire n’est pas possible, les tests manuels sont nécessaires avant de déployer un nouveau code pour empêcher les régressions de qualité.
Ces scripts s’exécutent dans le cadre d’un flux de travail, tel qu’Azure Machine Learning Studio, qui peut fournir des informations sur le moment et la façon dont le script s’est exécuté. Mais nous vous recommandons d’exécuter des tests d’intégration pour vous assurer que ces scripts sont appelés de manière fiable.
Évaluer et tester le modèle
Remarque
L’évaluation et les tests de modèle sont souvent utilisés de manière interchangeable, mais ils doivent être considérés comme des processus distincts qui utilisent des jeux de données distincts. L’évaluation est une activité itérative que vous effectuez pendant la phase de développement. Il se concentre sur l’expérimentation pour trouver le meilleur modèle avec le bon niveau de réglage. Il inclut l’ajustement des hyperparamètres, des configurations ou des fonctionnalités, puis l’évaluation du modèle en fonction de différentes métriques. Après avoir identifié le meilleur modèle, effectuez des tests pendant le déploiement.
Les tests incluent la vérification de l’ensemble du système, y compris le modèle paramétré et les composants non-IA, pour vérifier qu’ils fonctionnent correctement, intègrent bien et fournissent les résultats attendus conformément aux normes de qualité. Évaluez un modèle in situ en même temps que d’autres composants de la charge de travail. Le processus inclut l’envoi de requêtes au modèle, l’évaluation de ses réponses et la prise d’une décision d’accès ou de non-déplacement en fonction des données de test. Bien que les tests ne soient pas modifiables avant la production, nous vous recommandons également d’effectuer des tests en production à l’aide de données réelles et de données synthétiques.
Utiliser des données pour évaluer et tester
En règle générale, il existe trois jeux de données clés partitionnés à partir des données sources : l’entraînement, l’évaluation et les tests.
Utilisez le jeu de données d’entraînement, qui est généralement le plus grand sous-ensemble, pour entraîner le modèle. Utilisez un autre jeu de données pour l’évaluation pour affiner le modèle par le biais d’un processus itératif en évaluant différentes permutations. Après avoir trouvé une permutation satisfaisante, testez-la sur le jeu de données de test.
Tous les jeux de données doivent contenir des données de haute qualité pour réduire le bruit. Vos cas de test sur l’ingestion des données et les pipelines de prétraitement peuvent servir de points de contrôle de qualité. Un manque d’échantillons peut également être attribué à des données de faible qualité. Utilisez des données synthétiques pour équilibrer et obtenir l’uniformité dans le jeu de données. Cette approche est utile pour former des modèles comme les modèles de détection des fraudes, où les instances de fraude réelles sont rares, ce qui rend difficile l’obtention d’une puissance statistique suffisante pour les prédictions fiables.
Pour éviter les biais dans les prédictions, gardez tous les jeux de données distincts. Vous ne devez pas utiliser les données d’apprentissage pour l’évaluation, et vous ne devez pas utiliser les données d’évaluation pour les tests. Réservez des données uniques pour l’évaluation du modèle et les tests finaux.
Utiliser les métriques d’évaluation
L’entraînement d’un modèle et la sélection du bon modèle pour la production sont des processus interdépendants. Vous devez choisir un modèle initialement, mais il peut changer après l’expérimentation et l’évaluation.
L’évaluation du modèle suit une boucle d’expérimentation qui évalue de nombreuses permutations de modèles, de paramètres et de fonctionnalités à l’aide de métriques. Ces métriques fournissent des évaluations scientifiques, que vous devez comparer de manière itérative entre différentes versions et configurations pour déterminer le meilleur modèle. Pour plus d’informations, consultez Métriques d’évaluation.
Une approche similaire s’applique aux modèles IA génératifs. Disposer de processus qui évaluent et quantifient les résultats de l’expérience utilisateur en fonction des performances du modèle. Par exemple, l’étendue est l’une des métriques clés qui quantifient la façon dont le modèle s’aligne sur les données sources. La pertinence est une autre métrique importante qui indique la pertinence de la réponse à la requête. Pour obtenir des exemples de métriques, consultez Évaluation et surveillance des métriques pour l’IA générative.
Évaluez différents types de modèles à l’aide de différentes métriques. L’importance de chaque métrique peut varier en fonction du scénario. Hiérarchiser les métriques en fonction du cas d’usage. Par exemple, l’équité est cruciale dans l’IA responsable. Malgré de bons tests, les modèles peuvent toujours présenter un biais injuste en raison de données sources biaisées. Les résultats peuvent être élevés dans la pertinence, mais faible en équité. Intégrer des évaluations d’équité dans le processus pour garantir des résultats non biaisés.
L’IA générative s’intègre au code d’orchestration, à la logique de routage et à un index pour la génération augmentée par récupération (RAG), ce qui complique l’évaluation. Bien que vous deviez évaluer les modèles individuellement à l’aide de métriques, il est également important d’évaluer d’autres composants système.
Tester le modèle
Le réglage précis est essentiellement testé, car il modifie un modèle préentraîné pour modifier son comportement. Elle nécessite de commencer par une base de référence pour comprendre les performances initiales du modèle. Après réglage précis, réévaluez les performances du modèle pour s’assurer qu’il répond aux normes de qualité. Tenez compte des métriques d’évaluation courantes suivantes :
L’état de base fait référence à l’alignement du modèle avec les données sources. Un modèle ancré génère des réponses cohérentes avec la réalité.
La pertinence indique la pertinence de la réponse à une question donnée. Une réponse hautement fondée peut manquer de pertinence s’il ne répond pas directement à la question.
La similarité mesure la similarité entre un texte de données source et la réponse générée. Le modèle a-t-il utilisé une formulation précise ? Un manque de gouvernance éditoriale peut réduire le score de similarité.
La récupération indique l’efficacité des requêtes d’index. Évaluez l’alignement des données d’index récupérées avec la question. Les données non pertinentes de la recherche d’index réduisent ce score. Les scores de récupération plus élevés indiquent une variabilité inférieure, car ils s’appuient uniquement sur les requêtes d’index.
La fluidité est liée à l’utilisation du vocabulaire. Si le modèle adhère à un guide de style et présente du contenu dans le format approprié, il peut être fluide même s’il manque de base ou de pertinence.
La cohérence évalue si la parole du modèle circule naturellement et de manière cohérente. Elle évalue si la conversation se sent comme un véritable échange.
Tester les hyperparamètres
Les paramètres de modèle dépendent des décisions de conception spécifiques à l’application. Dans le cadre de la conception de votre application, choisissez le modèle et les paramètres en fonction des cas d’usage de votre charge de travail. Le processus de test dispose d’une boucle interne itérative où les données d’entraînement sont comparées aux données de test pour vérifier que le modèle s’entraîne sur le jeu de données prévu. En outre, les paramètres sont paramétrés afin que le modèle puisse effectuer des prédictions avec un niveau acceptable de précision.
Compromis. La boucle interne inclut les coûts de calcul de l’apprentissage du modèle et le coût de l’évaluation par le biais de tests. Vous devez prendre en compte le temps nécessaire à l’entraînement et au test du modèle dans cette boucle. Attendez-vous que le processus de test prenne plus de temps que le processus d’entraînement. Vous pouvez effectuer des tests initiaux sur un sous-ensemble de données d’apprentissage pour déterminer si le modèle produit des résultats raisonnables. Vous pouvez progressivement effectuer un scale-up de ce jeu de données de test sur le jeu de données complet.
Tester le point de terminaison d’inférence
Un point de terminaison d’inférence est l’API REST qui permet d’accéder aux modèles pour effectuer des prédictions. Il s’agit de l’interface où vous envoyez des données dans le cadre de la requête et obtenez une réponse qui contient les résultats du modèle. Le point de terminaison est hébergé sur le calcul, qui peut être PaaS comme Azure OpenAI Service ou un serveur d’inférence non Microsoft, tel que le serveur d’inférence NVIDIA Triton, TorchServe et BentoML. Dans les scénarios PaaS, le fournisseur de services gère le test dans une certaine mesure. Toutefois, si vous hébergez le point de terminaison, traitez-le comme n’importe quelle autre API et testez-le soigneusement.
Bien que vous testiez le modèle pendant l’entraînement et l’évaluation, le test du point de terminaison d’inférence implique de s’assurer que les mécanismes autour de ce modèle, tels que le traitement des demandes, la création de réponse, la mise à l’échelle et la coordination entre les instances, fonctionnent correctement. Créez un plan de test complet qui couvre les cas d’usage en fonction de vos besoins. Cette section décrit quelques exemples de cas de test et de types de test à prendre en compte.
Considérations relatives aux tests pour les serveurs d’hébergement d’inférence
Il est important de comprendre les caractéristiques de charge du calcul et de valider les performances par le biais de tests de charge. Ces actions vous aident à choisir des technologies lorsque vous concevez ou optimisez l’architecture. Par exemple, différents serveurs d’inférence ont des caractéristiques de performances variables. Le code consomme des cycles d’UC et de la mémoire à mesure que le nombre de connexions simultanées augmente. Découvrez comment votre code et les ressources de calcul s’exécutent dans des conditions de charge standard et de pointe. Le test de charge Azure est une bonne option pour les tests de charge et peut générer une charge de volume élevée. D’autres options open source, comme Apache JMeter, sont également populaires. Envisagez d’appeler ces tests directement à partir de votre environnement. Par exemple, Machine Learning s’intègre bien au test de charge.
Une autre décision clé est le choix des fonctionnalités GPU. De nombreux modèles nécessitent des GPU pour une inférence efficace en raison de leur conception. Le test de charge vous permet de comprendre les limites de performances d’une référence SKU GPU et d’empêcher le surprovisionnement, ce qui constitue des considérations financières importantes.
Pour les plateformes d’hébergement non PaaS, la sécurité est cruciale, car l’API est exposée publiquement. Il est important de s’assurer que le point de terminaison n’est pas exploité ou compromis, ce qui peut compromettre l’ensemble du système. Incluez ce point de terminaison dans le cadre de vos tests de sécurité de routine, ainsi que d’autres points de terminaison publics. Envisagez d’effectuer des tests, tels que des tests d’intrusion, sur le système en direct. Un autre aspect de la sécurité est la sécurité du contenu. Votre code peut appeler des API spécialisées qui détectent le contenu dangereux dans la charge utile de requête et de réponse. Azure AI Content Safety peut être appelé à partir de vos tests pour faciliter les tests de sécurité du contenu.
Pour connaître les stratégies clés, consultez Recommandations pour les tests de sécurité.
Considérations relatives aux tests pour les points de terminaison d’inférence PaaS
Le client doit s’attendre à des erreurs lorsqu’il envoie des requêtes au point de terminaison d’inférence sur le service PaaS. Les défaillances peuvent se produire en raison de la surcharge du système, de l’annulation de la réponse des back-ends et d’autres conditions d’erreur. Effectuez une analyse du mode d’échec sur le service et testez ces défaillances potentielles. L’analyse du mode d’échec est requise pour concevoir et implémenter des stratégies d’atténuation dans le code client. Par exemple, les API Azure OpenAI limitent les demandes en retournant un code de réponse d’erreur HTTP 429. Le client doit gérer cette erreur à l’aide de mécanismes de nouvelle tentative et de disjoncteurs. Pour plus d’informations, consultez Recommandations pour effectuer une analyse du mode d’échec.
Le test des services PaaS peut vous aider à sélectionner des références SKU de service, car vous comprenez les coûts associés, tels que le paiement à l’utilisation ou le calcul préprovisionné. Utilisez des calculatrices de prix Azure pour évaluer les charges de travail, la fréquence et l’utilisation des jetons pour déterminer les meilleures options de facturation et de calcul. Simuler des charges de travail avec des références SKU à faible coût et justifier des options haut de gamme telles que les unités de débit approvisionnées (PTU) pour Azure OpenAI.
Les tests de charge ne sont pas aussi pertinents pour le calcul de paiement à l’utilisation, car, avec une capacité infinie, vous ne rencontrez pas de problèmes. Le test valide les limites et les quotas. Nous vous déconseillons de tester la charge pour le calcul de paiement à l’utilisation, car il s’agit d’une dépense financière importante. Toutefois, vous devez effectuer un test de charge pour vérifier le débit, qui est mesuré en jetons par minute ou en requêtes par minute. Contrairement aux API standard qui considèrent les métriques comme la taille de la requête, cette approche évalue les charges de travail en fonction des jetons pour déterminer l’utilisation. La clé consiste à comprendre le nombre d’utilisateurs actifs et à mesurer le débit en conséquence. Pour plus d’informations, consultez Mesurer votre débit.
Utiliser des contrôles de sécurité
Que vous utilisiez un serveur d’inférence ou une option PaaS, la sécurité est votre responsabilité. Avec les points de terminaison d’API, il est essentiel de tester les contrôles de sécurité de contenu et de jailbreakage. Assurez-vous que ces contrôles ne peuvent pas être contournés et fonctionnent comme prévu. Par exemple, l’envoi d’un élément bloqué connu peut vous aider à vérifier si les contrôles de sécurité sont en place et fonctionnent correctement avant le déploiement. Envisagez d’exécuter ces tests en fonction des besoins ou de les intégrer dans le processus de mise en production.
Il est important de tester si le système peut exposer par inadvertance des informations qu’il ne doit pas. Par exemple, le système ne doit pas exposer les informations personnelles dans la charge utile de réponse. En outre, testez pour vous assurer qu’un client ne peut pas accéder aux points de terminaison destinés à d’autres identités. Effectuez des tests de sécurité pour vérifier que l’API, avec ses mécanismes d’authentification et d’autorisation, ne fuite pas d’informations confidentielles et conserve une segmentation appropriée des utilisateurs.
Tester les données de base
La conception des données influence l’efficacité d’un modèle génératif et les données de base sont le composant essentiel. Les données de base fournissent davantage de contexte pour améliorer la pertinence de la réponse. Il est indexé avant d’atteindre le modèle. Cet index est accessible en temps réel, car l’utilisateur attend une réponse.
Effectuez des tests de bout en bout et incorporez ce processus dans le cadre de la conception des données. Implémentez un processus de test qui évalue et quantifie les résultats de l’expérience du client en fonction des performances, de l’orchestration, de l’index, du prétraitement et des données sources du modèle. Surveillez et mesurez les métriques de qualité de manière itérative. Voici quelques éléments à prendre en compte :
Testez soigneusement le traitement des données à l’aide de tests fonctionnels et d’intégration. Vérifiez que les données sont chargées comme prévu et que toutes les données sont présentes.
Testez le schéma d’index pour la compatibilité descendante. Vous devez tester toute modification apportée à un document ou à un champ pour vous assurer que la nouvelle version peut toujours prendre en charge les versions précédentes des données.
Avant que les données ne sont indexées, elles sont préparées pour réduire le bruit et le biais et permettre une interrogation efficace. Ce processus inclut le prétraitement, la segmentation et le calcul des incorporations, et chaque étape enregistre les données dans le contexte ou les fichiers de l’index. Un pipeline d’orchestration, tel que des ensembles de compétences fournis par Azure AI Search, effectue ces étapes. Vous devez tester le code d’orchestration pour vous assurer qu’aucune étape n’est manquée et que les données traitées sont de haute qualité.
Les tests doivent vérifier les anciennes données, les valeurs synthétiques, les tables vides, l’actualisation des données et le traitement sur la dernière version. Si des échecs de test se produisent, vous devrez peut-être ajuster la requête de recherche et l’index. Ce processus inclut l’ajustement des filtres et d’autres éléments abordés précédemment. Vous devez considérer le test comme une activité itérative.
Les index sont des performances complexes et des requêtes peuvent varier en fonction de la structure d’index, ce qui nécessite une estimation de charge. Les tests de charge appropriés peuvent aider à déterminer les différentes références SKU pour le stockage, le calcul et d’autres ressources disponibles pour prendre en charge vos besoins.
Vous devez tester tous les contrôles de sécurité. Par exemple, les données peuvent être partitionnés dans des documents distincts. Chaque partition a des contrôles d’accès. Vous devez tester correctement ces contrôles pour protéger la confidentialité.
Tester l’orchestrateur
Un composant clé d’une application RAG est l’orchestrateur central. Ce code coordonne différentes tâches liées à la question initiale de l’utilisateur. Les tâches d’orchestrateur nécessitent généralement une compréhension de l’intention de l’utilisateur, d’une connexion à l’index pour rechercher des données de base et d’appeler le point de terminaison d’inférence. Si les agents doivent effectuer des tâches, telles que l’appel d’API REST, ce code gère ces tâches dans le contexte.
Vous pouvez développer du code d’orchestration dans n’importe quel langage ou l’écrire à partir de zéro. Toutefois, nous vous recommandons d’utiliser des technologies telles que le flux d’invite dans Azure AI Studio ou les graphiques Acycliques dirigés d’Apache Airflow pour accélérer et simplifier le processus de développement. Le flux d’invite offre une expérience au moment du design. Utilisez-le pour modulariser des tâches en tant qu’unités et connecter des entrées et des sorties de chaque unité, formant finalement le code d’orchestration, qui représente l’ensemble du processus.
Isolez votre code d’orchestration. Développez-le séparément et déployez-le en tant que microservice avec un point de terminaison en ligne et une API REST pour l’accès. Cette approche garantit la modularité et la facilité de déploiement.
Du point de vue des tests, traitez ce code comme n’importe quel autre code et effectuez des tests unitaires. Toutefois, l’aspect le plus important est sa fonctionnalité, telle que sa logique de routage, que vous pouvez valider par le biais de tests fonctionnels et d’intégration. Testez l’ingénierie des invites pour vous assurer que le code peut détecter l’intention de l’utilisateur et acheminer les appels de manière appropriée. Il existe plusieurs frameworks et bibliothèques pour les tests, comme Scikit-learn, le module torch.testing de PyTorch, FairML pour les tests de biais et d’équité, et TensorFlow Model Analysis pour l’évaluation du modèle.
Effectuez également des tests d’exécution, tels que des tests de mode d’échec. Par exemple, testez les échecs potentiels liés aux limitations de jeton.
Certains tests d’exécution peuvent vous aider à prendre une décision. Exécutez des tests de charge pour comprendre comment ce code se comporte sous contrainte et utilisez les résultats pour la planification de la capacité. Étant donné que ce code est positionné à un point crucial dans l’architecture où il doit atteindre d’autres services, il peut aider à collecter des données de télémétrie à partir de tous ces appels. Ces données peuvent fournir des informations sur le temps consacré au traitement local par rapport aux appels réseau et à déterminer le comportement d’autres composants, tels que la latence potentielle. Les technologies telles que le flux d’invite ont des fonctionnalités de télémétrie intégrées pour faciliter ce processus. Sinon, incorporez des données de télémétrie dans votre code personnalisé.
Remarque
Le test de ce code a des implications sur les coûts. Par exemple, si vous utilisez Azure OpenAI pour héberger votre point de terminaison d’inférence, les tests de stress sont une pratique courante qui peut vous aider à déterminer les limites du système. Toutefois, les frais Azure OpenAI pour chaque appel, ce qui peut rendre coûteux les tests de stress étendus. L’une des façons d’optimiser les frais consiste à utiliser des unités de traitement inutilisées d’Azure OpenAI dans un environnement de test. Vous pouvez également simuler le point de terminaison d’inférence.
Les problèmes de sécurité s’appliquent à la fois au code d’orchestration et au modèle. Incluez les tests de jailbreakage, où l’objectif est de briser la sécurité du modèle. Les attaquants n’interagissent pas directement avec le modèle. Ils interagissent d’abord avec le code d’orchestration. Le code d’orchestration reçoit les demandes des utilisateurs et les analyse. Si le code d’orchestration reçoit une demande malveillante, il peut transférer cette requête au modèle et compromettre potentiellement le modèle.
La sécurité du contenu est un autre aspect important. Dans une application de chatbot, le code d’orchestration reçoit du texte de conversation. Dans le code, envisagez d’appeler un service de sécurité du contenu. Envoyez à la fois l’invite de l’utilisateur et le contexte de base pour l’analyse et recevez une évaluation du risque. Prompt Shields est une API unifiée qui analyse les entrées de modèle de langage volumineux et détecte les attaques à l’invite utilisateur et les attaques de document, qui sont deux types courants d’entrées contradictoires.
Le contrôle de sécurité et l’authentification sont essentiels pour un point de terminaison RESTful. Vous devez gérer l’authentification et garantir des tests approfondis.
Empêcher la désintégration du modèle
Un problème courant pour tous les modèles est un certain degré de dégradation au fil du temps. Les modifications internes et externes à la charge de travail entraînent finalement une dégradation de la qualité du modèle et de ses sorties. La désintégration du modèle se produit de deux façons :
La dérive des données se produit lorsque les données d’entrée changent. La nouvelle entrée de données rend le modèle entraîné obsolète. Par exemple, vous pouvez avoir un modèle qui prédit les modèles de vote d’une zone géographique donnée, comme un district. Si le district est redessiné et que les données démographiques de la population de ce district changent, votre modèle doit être mis à jour pour tenir compte des changements.
La dérive de concept se produit lorsque les conditions externes à la charge de travail et au changement de modèle de telle sorte que le modèle ne correspond plus à la réalité. Par exemple, vous pouvez avoir un modèle de prévision des ventes pour un produit technologique. Si un concurrent introduit de façon inattendue un produit concurrent plus avancé qui attire une attention importante du public, vous devez mettre à jour votre modèle en fonction de la façon dont les tendances des consommateurs changent.
Si possible, utilisez des tests automatisés pour détecter et évaluer la dégradation du modèle sur le cycle de vie de votre modèle. Si votre modèle prédit des valeurs discrètes, vous pouvez créer des tests pour évaluer les prédictions sur ces valeurs au fil du temps et mesurer l’écart entre les résultats attendus et réels. Complétez ce test avec la surveillance pour détecter la dérive au fil du temps en comparant les statistiques récapitulatives et les métriques de distance.
Une autre approche courante pour identifier la désintégration du modèle est la rétroaction des utilisateurs. Un exemple de commentaires des utilisateurs est un mécanisme de réponse vers le haut ou vers le bas. Le suivi des commentaires positifs et négatifs au fil du temps et la création d’une alerte lorsque vous atteignez un seuil de commentaires négatifs peut vous aider à savoir quand examiner la qualité du modèle.
Quels que soient les signaux que vous utilisez pour identifier la désintégration du modèle, l’équipe des opérations qui est avertie de la dégradation potentielle doit impliquer un scientifique des données pour rechercher le signal et déterminer si la dégradation se produit et la cause racine.
Implémenter des outils
Utilisez le collecteur de données Azure Machine Learning pour obtenir la journalisation en temps réel des données d’entrée et de sortie à partir de modèles déployés sur des points de terminaison en ligne managés ou des points de terminaison en ligne Kubernetes. Machine Learning stocke les données d’inférence journalisées dans le stockage d’objets blob Azure. Vous pouvez ensuite utiliser ces données pour la surveillance, le débogage ou l’audit des modèles, ce qui permet d’observer les performances de vos modèles déployés. Si vous déployez un modèle en dehors de Machine Learning ou sur un point de terminaison de lot Machine Learning, vous ne pouvez pas tirer parti du collecteur de données et avoir besoin d’opérationnaliser un autre processus de collecte de données.
Utilisez la surveillance des modèles Machine Learning pour implémenter la surveillance. Machine Learning acquiert des signaux de surveillance en effectuant des calculs statistiques sur les données d’inférence de production en continu et les données de référence. Les données de référence peuvent être des données d’entraînement historiques, des données de validation ou des données de vérité de terrain. En revanche, les données d’inférence de production font référence aux données d’entrée et de sortie du modèle collectées en production.
- Consultez la supervision des modèles Machine Learning pour en savoir plus sur les fonctionnalités de surveillance de Machine Learning et les métriques qu’il capture et analyse.
- Consultez les meilleures pratiques pour obtenir d’autres recommandations pour la surveillance.