Identification et résolution des incidents Watson Machine Learning

L'exécution d'une AutoAI expérience de séries chronologiques avec prédiction d'anomalies échoue

La fonctionnalité permettant de prédire les anomalies dans les résultats d'une expérience de série chronologique n'est plus prise en charge. La tentative d'exécution d'une expérience existante entraîne des erreurs dues à des bibliothèques d'exécution manquantes. Par exemple, vous pourriez voir cette erreur :

The selected environment seems to be invalid: Could not retrieve environment. CAMS error: Missing or invalid asset id

Ce comportement est normal, car les durées d'exécution pour la prédiction des anomalies ne sont pas prises en charge. Il n'existe aucune solution pour contourner ce problème.

AutoAI Le cahier d'inférence pour une expérience RAG dépasse les limites du modèle

Parfois, lorsque vous exécutez un notebook d'inférence généré pour une expérience AutoAI RAG, vous pouvez obtenir cette erreur :

MissingValue: No "model_limits" provided. Reason: Model <model-nam> limits cannot be found in the model details.

L'erreur indique que les limites de jetons pour l'inférence du modèle de base utilisé pour l'expérience sont manquantes. Pour résoudre le problème, trouvez la fonction default_inference_function et remplacez get_max_input_tokens par le nombre maximal de jetons pour le modèle. Exemple :

model = ModelInference(api_client=client, **params['model"])
# model_max_input_tokens = get+max_input_tokens(model=model, params=params)
model_max_input_tokens = 4096

Vous trouverez la valeur maximale du jeton pour le modèle dans le tableau des modèles de base pris en charge disponibles avec watsonx.ai.

La formation d'une AutoAI expérience échoue avec les informations d'identification du service ID

Si vous entraînez une AutoAI expérience à l'aide de la clé API pour serviceID, l'entraînement, l'opération peut échouer et générer l'erreur suivante :

User specified in query parameters does not match user from token.

Une façon de résoudre ce problème consiste à exécuter l'expérience avec vos identifiants utilisateur. Si vous souhaitez exécuter l'expérience avec les informations d'identification du service, procédez comme suit pour mettre à jour les rôles et les stratégies pour l'ID du service.

1. Ouvrez votre serviceID sur IBM Cloud.
2. Créez un nouvel identifiant serviceID ou mettez à jour l'identifiant existant avec la politique d'accès suivante :
   • Tous les services de gestion des comptes IAM avec les rôles de vérificateur de clé API, créateur de clé API utilisateur, lecteur, opérateur et éditeur. Idéalement, il serait préférable qu'ils créent une nouvelle clé API pour cela ServiceId.
3. La politique mise à jour se présentera comme suit :
4. Relancez la formation avec les informations d'identification mises à jour serviceID.

La demande de prédiction pour le modèle AutoAI de série chronologique peut expirer si le nombre de nouvelles observations est trop important

Une demande de prédiction peut expirer pour un modèle de série chronologique AutoAI déployé si trop de nouvelles observations sont transmises. Pour résoudre ce problème, procédez de l'une des manières suivantes :

• Réduire le nombre de nouvelles observations.
• Étendez les données d'entraînement utilisées pour l'expérience en ajoutant de nouvelles observations. Ensuite, relancez l'expérience AutoAI de séries chronologiques avec les données d'entraînement mises à jour.

Nombre insuffisant de membres de classe dans les données d'entraînement pour AutoAI l'expérience

Les données d'entraînement pour une AutoAI expérience doivent comporter au moins 4 membres pour chaque classe. Si vos données d'entraînement contiennent un nombre insuffisant de membres dans une classe, vous rencontrerez l'erreur suivante :

ERROR: ingesting data Message id: AC10011E. Message: Each class must have at least 4 members. The following classes have too few members: ['T'].

Pour résoudre le problème, mettez à jour les données d'entraînement afin de supprimer la classe ou d'ajouter d'autres membres.

Les déploiements par lots qui utilisent de grands volumes de données comme entrée peuvent échouer

Si vous évaluez un travail par lots qui utilise de grands volumes de données comme source d'entrée, le travail peut échouer en raison des paramètres de délai d'attente internes. Un symptôme de ce problème peut être un message d'erreur similaire à l'exemple suivant :

Incorrect input data: Flight returned internal error, with message: CDICO9999E: Internal error occurred: Snowflake sQL logged error: JDBC driver internal error: Timeout waiting for the download of #chunk49(Total chunks: 186) retry=0.

Si le délai d'expiration survient lorsque vous évaluez votre déploiement par lots, vous devez configurer la limitation du délai d'expiration au niveau de la requête de la source de données afin de gérer les tâches longues.

Les informations relatives au délai d'expiration au niveau de la requête pour les sources de données sont les suivantes :

Pour éviter l'échec de vos déploiements par lots, partitionnez votre ensemble de données ou réduisez sa taille.

Sécurité pour les téléchargements de fichiers

Les fichiers que vous téléchargez via l'interface utilisateur Watson StudioWatson Machine Learning ou ne sont pas validés ni analysés à la recherche de contenu potentiellement malveillant. Il est recommandé d'utiliser un logiciel de sécurité, tel qu'un antivirus, sur tous les fichiers avant leur téléchargement afin de garantir la sécurité de votre contenu.

Les déploiements avec des spécifications logicielles restreintes échouent après une mise à niveau

Si vous effectuez une mise à niveau vers une version plus récente de IBM Cloud Pak for Data et déployez un élément d'application R Shiny créé à l'aide de spécifications logicielles restreintes en mode FIPS, votre déploiement échouera.

Par exemple, les déploiements qui utilisent les spécifications shiny-r3.6 logicielles shiny-r4.2 et échouent après la mise à niveau de IBM Cloud Pak for Data la version 4.7.0 vers 4.8.4 ou une version ultérieure. Vous pourriez recevoir le message d'erreur Error 502 - Bad Gateway.

Pour éviter que votre déploiement échoue, mettez à jour la spécification restreinte de votre ressource déployée afin d'utiliser la dernière spécification logicielle. Pour plus d'informations, consultez la section Gestion des spécifications ou des cadres logiciels obsolètes. Vous pouvez également supprimer le déploiement de votre application si vous n'en avez plus besoin.

La création d'un travail pour un SPSS Modeler flux dans un espace de déploiement échoue

Au cours du processus de configuration d'un travail par lots pour votre SPSS Modeler flux dans un espace de déploiement, le mappage automatique des ressources de données avec leur connexion respective peut échouer.

L'opération échoue car le travail ne parvient pas à trouver une ressource de données ou une connexion portant le même nom dans l'espace de déploiement. Pour corriger l'erreur liée au mappage automatique, procédez comme suit :

1. Vérifiez les détails de votre tâche de déploiement afin de déterminer si la ressource de données ou la connexion est manquante ou si le flux ne fait pas référence à la bonne ressource de données.

2. Cliquez sur Créer pour enregistrer votre progression et quitter la boîte de dialogue Nouvelle configuration de tâche.

3. Si une ressource de données ou une connexion ne se trouve pas dans votre espace de déploiement, recherchez-la dans votre projet et transférez-la vers l'espace de déploiement.

4. Si le SPSS Modeler flux ne fait pas référence à la ressource de données ou à la connexion correcte, mettez à jour le SPSS Modeler flux dans l'espace de projet et transférez-le à nouveau vers l'espace de déploiement.

5. Dans votre espace de déploiement, cliquez sur l'onglet Jobs et sélectionnez votre job SPSS Modeler de flux pour.

6. Dans la page des détails du travail, cliquez sur l'icône Modifier pour vérifier le mappage de vos ressources de données et de vos connexions.

7. Si l'erreur a été corrigée, vous pouvez reprendre le processus de configuration des paramètres de votre tâche dans la boîte de dialogue Nouvelle tâche. Pour plus d'informations, consultez Création de tâches de déploiement pour SPSS Modeler les flux.

   

Évaluation d'un déploiement dans Watson OpenScale échoue

Lorsque vous configurez Watson OpenScale pour évaluer un déploiement dans votre espace de déploiement, vos paramètres de configuration peuvent échouer en raison d'échecs dans les demandes de prédiction. Vous pouvez recevoir le code d'erreur 504 accompagné du message d'erreur suivant :

Erreur lors de la configuration OpenScale des moniteurs pour un tableau de bord existant

Pour contourner ce problème, suspendez le déploiement à l'aide du suspend point de terminaison et réessayez la prédiction. Utilisez l'exemple de code suivant pour suspendre la prédiction et récupérer le déploiement :

curl -k -X POST '/ml/v4/deployments/deployment-id/suspend?space_id=&version=2020-09-01' -H 'content-type: application/json' -H 'Authorization: Bearer $token'