L'exécution d'une expérience de série temporelle AutoAI avec prédiction d'anomalie échoue

La fonction permettant de prédire les anomalies dans les résultats d'une expérience de série temporelle n'est plus prise en charge. La tentative d'exécution d'une expérience existante entraîne des erreurs dues à l'absence de bibliothèques d'exécution. Par exemple, vous pouvez 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 pas de solution à ce problème.

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

Parfois, lors de l'exécution d'un cahier 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 des jetons pour déduire le modèle de base utilisé pour l'expérience sont manquantes. Pour résoudre le problème, recherchez la fonction " default_inference_function et remplacez " get_max_input_tokens par le nombre maximal de jetons pour le modèle. Par 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 pouvez trouver la valeur maximale du jeton pour le modèle dans le tableau des modèles de fondation pris en charge disponibles avec watsonx.ai

L'entraînement d'une expérience AutoAI échoue avec les informations d'identification du service

Si vous formez une expérience AutoAI en utilisant la clé API pour le serviceID, formation peut échouer avec cette erreur :

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

Une façon de résoudre ce problème est d'exécuter l'expérience avec vos identifiants d'utilisateur. Si vous souhaitez exécuter l'expérience avec des informations d'identification pour le service, suivez ces étapes pour mettre à jour les rôles et les stratégies pour l'identifiant du service.

1. Ouvrez votre serviceID sur IBM Cloud.
2. Créez un nouvel serviceID ou mettez à jour l'identifiant existant avec la politique d'accès suivante :
   • Tous les services de gestion de compte IAM avec les rôles suivants : réviseur de clé API, créateur de clé API d'utilisateur, visualiseur, opérateur et éditeur. L'idéal est de créer un nouvel apikey pour ce ServiceId. '
3. La politique mise à jour se présente comme suit :
4. Exécutez à nouveau la formation avec les informations d'serviceID mis à jour.

La demande de prédiction pour le modèle de séries temporelles de l AutoAI peut être interrompue si le nombre de nouvelles observations est trop élevé

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

• Réduire le nombre de nouvelles observations.
• Étendre les données de formation utilisées pour l'expérience en ajoutant de nouvelles observations. Ensuite, relancez l'expérience AutoAI sur les séries temporelles avec les données de formation mises à jour.

Membres de classe insuffisants dans les données d'entraînement pour l'expérimentation AutoAI

Les données d'entraînement d'une expérimentation AutoAI doivent comporter au moins 4 membres pour chaque classe. Si vos données d'entraînement ne contiennent pas un nombre suffisant 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 des volumes de données volumineux en tant qu'entrée risquent d'échouer

Si vous évaluez un travail par lots qui utilise de grands volumes de données comme source d'entrée, le travail risque d'échouer en raison de paramètres de délai d'attente internes. Un symptôme de cet incident 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'attente se produit lorsque vous évaluez votre déploiement par lots, vous devez configurer la limitation du délai d'attente au niveau de la requête de la source de données pour gérer les travaux à exécution longue.

Les informations de délai d'attente de niveau requête pour les sources de données sont les suivantes:

Pour éviter que vos déploiements par lots échouent, partitionnez votre fichier 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 de watsonx.ai Studio ou watsonx.ai Runtime ne sont pas validés ou analysés pour détecter des contenus potentiellement malveillants. Il est recommandé d'exécuter un logiciel de sécurité, tel qu'une application antivirus, sur tous les fichiers avant de les télécharger afin d'assurer la sécurité de votre contenu.

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

Si vous mettez à niveau vers une version plus récente d'IBM Cloud Pak for Data et déployez une ressource applicative R Shiny qui a été créée en utilisant des spécifications logicielles restreintes en mode FIPS, votre déploiement échoue.

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

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

La création d'une tâche pour un flux SPSS Modeler dans un espace de déploiement échoue

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

Pour corriger l'erreur de mappage automatique des ressources de données et des connexions, procédez comme suit :

1. Cliquez sur Créer pour enregistrer votre progression et quitter la boîte de dialogue Configuration d'un nouveau travail.

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

3. Dans la page des détails du travail, cliquez sur l'icône " Editer " pour mettre à jour manuellement le mappage de vos ressources de données et de vos connexions.

4. Après avoir mis à jour le mappage des ressources de données et des connexions, vous pouvez reprendre le processus de configuration des paramètres de votre travail dans la boîte de dialogue Nouveau travail. Pour plus d'informations, voir Création de tâches de déploiement pour les flux de SPSS Modeler