Risoluzione dei problemi relativi a Watson Machine Learning

L'esecuzione di un esperimento su serie temporali con AutoAI per la previsione delle anomalie non va a buon fine

La funzione che permetteva di prevedere le anomalie nei risultati di un esperimento su serie temporali non è più supportata. Quando si tenta di eseguire un esperimento esistente, vengono visualizzati messaggi di errore relativi alla mancanza di librerie di runtime. Ad esempio, potresti visualizzare questo errore:

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

Si tratta di un comportamento previsto, poiché i runtime per la previsione delle anomalie non sono supportati. Non esiste alcuna soluzione alternativa a questo problema.

AutoAI Il notebook di inferenza per un esperimento RAG supera i limiti del modello

A volte, quando si esegue un notebook di inferenza generato per un esperimento RAG ( AutoAI ), è possibile che venga visualizzato il seguente errore:

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

L'errore indica che mancano i limiti del token necessari per l'inferenza del modello di base utilizzato per l'esperimento. Per risolvere il problema, individua la funzione default_inference_function e sostituisci get_max_input_tokens con il numero massimo di token per il modello. Ad esempio:

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

Il valore massimo dei token per il modello è riportato nella tabella dei modelli di base supportati disponibile all'indirizzo watsonx.ai.

L'addestramento di un esperimento AutoAI fallisce con le credenziali dell'ID del servizio

Se si sta addestrando un esperimento AutoAI usando la chiave API per il serviceID, l'addestramento potrebbe fallire con questo errore:

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

Un modo per risolvere questo problema è eseguire l'esperimento con le proprie credenziali utente. Se si desidera eseguire l'esperimento con le credenziali del servizio, seguire questi passaggi per aggiornare i ruoli e i criteri per l'ID del servizio.

1. Apri il tuo account serviceID su IBM Cloud.
2. Creare un nuovo serviceID o aggiornare l'ID esistente con il seguente criterio di accesso:
   • Tutti i servizi di gestione degli account IAM con i ruoli di revisore di chiavi API, creatore di chiavi API utente, visualizzatore, operatore ed editor. L'ideale sarebbe che creassero una nuova chiave API per questo ServiceId.
3. La politica aggiornata avrà il seguente contenuto:
4. Eseguire nuovamente l'addestramento con le credenziali per il serviceID aggiornato.

La richiesta di predizione per il modello di serie temporali AutoAI può andare in time out con troppe nuove osservazioni

Una richiesta di predizione può andare in time out per un modello di serie temporali distribuito AutoAI se sono passate troppe nuove osservazioni. Per risolvere il problema, procedere in uno dei seguenti modi:

• Ridurre il numero di nuove osservazioni.
• Estendere i dati di addestramento utilizzati per l'esperimento aggiungendo nuove osservazioni. Quindi, rieseguire l'esperimento AutoAI delle serie temporali con i dati di allenamento aggiornati.

Membri di classe insufficienti nei dati di addestramento per l'esperimento AutoAI

I dati di addestramento per un esperimento AutoAI devono avere almeno 4 membri per ogni classe. Se i tuoi dati di formazione non hanno un numero sufficiente di membri in una classe, riscontrerai questo errore:

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

Per risolvere il problema, aggiornare i dati di addestramento per rimuovere la classe o aggiungere più membri.

Le distribuzioni batch che utilizzano volumi di dati di grandi dimensioni come input potrebbero non riuscire

Se si sta calcolando il punteggio di un lavoro batch che utilizza grandi volumi di dati come origine di input, il lavoro potrebbe non riuscire a causa delle impostazioni di timeout interne. Un sintomo di questo problema potrebbe essere un messaggio di errore simile al seguente esempio:

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.

Se il timeout si verifica quando si calcola il punteggio della distribuzione batch, è necessario configurare la limitazione del timeout a livello di query dell'origine dati per gestire i job di lunga durata.

Le informazioni di timeout a livello di query per le origini dati sono le seguenti:

Per evitare che le distribuzioni batch non vengano eseguite correttamente, partizionare il dataset o diminuirne la dimensione.

Sicurezza per i caricamenti di file

I file caricati tramite l'interfaccia utente di Watson Studio o Watson Machine Learning non vengono convalidati o sottoposti a scansione per il contenuto potenzialmente dannoso. Si consiglia di eseguire il software di sicurezza, ad esempio un'applicazione antivirus, su tutti i file prima del caricamento per garantire la sicurezza dei contenuti.

Le distribuzioni con specifiche software limitate non riescono dopo un aggiornamento

Se si esegue l'aggiornamento a una versione più recente di IBM Cloud Pak for Data e si distribuisce un'applicazione R Shiny creata utilizzando specifiche software limitate in modalità FIPS, la distribuzione non riesce.

Ad esempio, le distribuzioni che utilizzano le specifiche software shiny-r3.6 e shiny-r4.2 non funzionano dopo l'aggiornamento da IBM Cloud Pak for Data versione 4.7.0 a 4.8.4 o successiva. Potresti ricevere il messaggio di erroreError 502 - Bad Gateway .

Per evitare che la distribuzione fallisca, aggiorna la specifica ristretta per la risorsa distribuita per utilizzare la specifica software più recente. Per ulteriori informazioni, vedere Gestione di specifiche o framework software obsoleti. Puoi anche eliminare la distribuzione dell'applicazione se non ti serve più.

La creazione di un lavoro per un flusso SPSS Modeler in uno spazio di distribuzione non riesce

Durante il processo di configurazione di un lavoro batch per il flusso SPSS Modeler in uno spazio di distribuzione, la mappatura automatica delle risorse di dati con la rispettiva connessione potrebbe fallire.

L'operazione non va a buon fine perché il processo non riesce a individuare una risorsa dati o una connessione con lo stesso nome nello spazio di distribuzione. Per risolvere l'errore relativo alla mappatura automatica, segui questi passaggi:

1. Controlla i dettagli del tuo processo di distribuzione per verificare se manca una risorsa dati o una connessione, oppure se il flusso non fa riferimento alla risorsa dati corretta.

2. Fare clic su Crea per salvare i progressi e uscire dalla finestra di configurazione Nuovo lavoro.

3. Se una risorsa dati o una connessione non è presente nello spazio di distribuzione, individuala nel progetto e trasferiscila nello spazio di distribuzione.

4. Se il flusso " SPSS Modeler " non fa riferimento alla risorsa dati o alla connessione corretta, aggiorna il flusso " SPSS Modeler " nell'area del progetto e promuovilo nuovamente nell'area di distribuzione.

5. Nello spazio di distribuzione, clicca sulla scheda "Jobs" e seleziona il tuo job del flusso " SPSS Modeler " per.

6. Nella pagina dei dettagli del lavoro, clicca sull'icona Modifica per verificare la mappatura delle tue risorse di dati e delle connessioni.

7. Se l'errore è stato risolto, puoi riprendere la configurazione delle impostazioni del tuo lavoro nella finestra di dialogo Nuovo lavoro. Per ulteriori informazioni, vedere Creazione di lavori di distribuzione per i flussi SPSS Modeler

   

La distribuzione di un modello di fondazione personalizzato da uno spazio di distribuzione non riesce

Quando si crea un'installazione client per un modello di fondazione personalizzato dallo spazio di distribuzione, l'installazione client potrebbe fallire per diversi motivi. Seguire questi suggerimenti per risolvere i problemi comuni che si possono incontrare quando si distribuiscono i modelli di fondazione personalizzati da uno spazio di distribuzione.

Caso 1: il valore del parametro è fuori intervallo

Quando si crea un'installazione client per un modello di fondazione personalizzato dallo spazio di distribuzione, è necessario assicurarsi che i valori dei parametri del modello di base rientrino nell'intervallo specificato. Per ulteriori informazioni, vedere Proprietà e parametri per i modelli di fondazione personalizzati. Se si immette un valore che non rientra nell'intervallo specificato, si potrebbe verificare un errore.

Ad esempio, il valore del parametro max_new_tokens deve essere inferiore a max_sequence_length. Quando si aggiornano i valori dei parametri del modello di base, se si immette un valore per max_new_tokens maggiore o uguale al valore di max_sequence_length (2048), si potrebbe verificare un errore.

L'immagine seguente mostra un esempio di messaggio di errore: Value must be an integer between 20 and 1000000000000000 and be greater than 'Max New Tokens'.

Se i valori predefiniti per i parametri del modello danno luogo a un errore, contattare l'amministratore per modificare il registro del modello nel CR watsonxaiifm.

Caso 2: Tipo di dati non supportato

È necessario assicurarsi di selezionare un tipo di dati supportato dal modello di fondazione personalizzato. Quando si aggiornano i valori dei parametri del modello di base, se si aggiorna il tipo di dati per il modello distribuito con un tipo di dati non supportato, la distribuzione potrebbe fallire.

Ad esempio, il modello LLaMA-Pro-8B-Instruct-GPTQ supporta solo il tipo di dati float16. Se si distribuisce il modello LLaMA-Pro-8B-Instruct-GPTQ con float16 Enum, quindi si aggiorna il parametro Enum da float16 a bfloat16, la distribuzione fallisce.

Se il tipo di dati selezionato per il modello di fondazione personalizzato dà luogo a un errore, è possibile sovrascrivere il tipo di dati per il modello di fondazione personalizzato durante la creazione dell'installazione client o contattare l'amministratore per modificare il registro del modello in watsonxaiifm CR.

Caso 3: il valore del parametro è troppo elevato

Se si immette un valore molto grande per i parametri max_sequence_length e max_new_token, si potrebbe verificare un errore. Ad esempio, se si imposta il valore di max_sequence_length come 1000000000000000, si ottiene il seguente messaggio di errore:

Impossibile distribuire il modello di fondazione personalizzato. L'operazione non è riuscita a causa di 'max_batch_weight (19596417433) non abbastanza grande per (prefill) max_sequence_length (1000000000000000)'. Riprova l'operazione. Se il problema persiste, contatta l'assistenza di IBM.

È necessario assicurarsi di inserire un valore per il parametro che sia inferiore al valore definito nel file di configurazione del modello (config.json).

Caso 4: model.safetensors il file viene salvato con librerie non supportate

Se il file model.safetensors per il modello di fondazione personalizzato utilizza un formato di dati non supportato nell'intestazione dei metadati, la distribuzione potrebbe fallire.

Ad esempio, se importi il OccamRazor/mpt-7b-storywriter-4bit-128g modello di base personalizzato da Hugging Face nel tuo spazio di distribuzione e crei una distribuzione online, la distribuzione potrebbe non andare a buon fine. Questo perché il file model.safetensors per il modello OccamRazor/mpt-7b-storywriter-4bit-128g è salvato con save_pretrained, che è una libreria non supportata. Potrebbe essere visualizzato il seguente messaggio di errore:

L'operazione non è riuscita a causa dell'oggetto 'NoneType' che non ha l'attributo 'get'.

È necessario assicurarsi che il modello di fondazione personalizzato sia salvato con la libreria transformers supportata.

Caso 5: l'implementazione di un modello " Llama 3.1" non va a buon fine

Se la distribuzione del modello Llama 3.1 non riesce, provare a modificare il contenuto del file config.json del modello:

1. Trovare la voce eos_token_id.
2. Cambia il valore della voce da un array a un intero.

Quindi provare a distribuire nuovamente il modello.

La valutazione di un'installazione client in Watson OpenScale non riesce

Quando si configura Watson OpenScale per valutare un'installazione client nello spazio di distribuzione, le impostazioni di configurazione potrebbero fallire a causa di richieste di predizione non riuscite. Si potrebbe ricevere il codice di errore 504 con il seguente messaggio di errore:

Errore durante la configurazione dei monitor OpenScale per una dashboard esistente

Come soluzione, sospendere la distribuzione utilizzando l'endpoint suspend e riprovare la previsione. Utilizzate il seguente esempio di codice per sospendere la previsione e ripristinare l'installazione:

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'

L'implementazione di un modello di base personalizzato non va a buon fine e segnala la mancanza tokenizer.json di un file

Se il modello di base personalizzato che si desidera distribuire non contiene un tokenizer.json file, la distribuzione fallisce con il seguente messaggio:

Deployment creation failed because tokenizer.json file was not found in the model directory. Add tokenizer.json to your model directory and retry the deployment.

Per risolvere il problema:

1. Prima di distribuire il modello, imposta l'operatore wml in modalità manutenzione:

   `oc patch wmlbase wml-cr -n <instance-namespace>  --type=merge  -p '{"spec":{"ignoreForMaintenance": true}}'`
   

2. Apri il wmlruntimemanager file ` ConfigMap ` in modalità di modifica:

   oc edit cm wmlruntimemanager -n cpd-instance-name
   

3. require_tokenizer_json = falseSotto model_requirements, aggiungere:

   model_requirements {
         require_tokenizer_json = false
         mistral {
           tokenizer_mode {
             enable = true
             allowed_arch = [ "mistral", "pixtral", "mistral3" ]
           }
         }
       }
   

4. Salva e chiudi il file « ConfigMap ».

5. Riavvia il wml-deployment-manager:

   oc rollout restart deploy wml-deployment-manager -n <instance-namespace>
   

6. Distribuire il modello.

7. Una volta distribuito il modello, riportare la wml modalità operatore alla modalità normale:

oc patch wmlbase wml-cr -n <instance-namespace>  --type=merge  -p '{"spec":{"ignoreForMaintenance": false}}'

L'inferenza del payload in linea per l'estrazione del testo non va a buon fine a causa di limitazioni delle risorse

Se si utilizza la funzione "Document Understanding" di Watson, un riferimento al payload in linea potrebbe non funzionare correttamente, generando il seguente errore:

failed to process text extraction event, no response detected from runtime

L'errore può essere causato da riavvii rilevati durante l'esecuzione a causa del superamento della capacità delle risorse.

Per risolvere il problema, prova ad aumentare il numero di copie dei pod " Watson DocumentUnderstanding" sul cluster IBMSoftware Hub, applicando una patch al watsonxaiifm CR per aumentare il numero di repliche dei pod.

spec:
    blockStorageClass: managed-nfs-storage
    fileStorageClass: managed-nfs-storage
    ignoreForMaintenance: false
    install_model_list:
    - wdu
    license:
    accept: true
    version: 10.0.0
    wdu_main_deploy_multi_replicas: 2
    wdu_multi_deploy_multi_replicas: 4

Le dimensioni consigliate per le installazioni di medie dimensioni sono:

• wdu_main_deploy_multi_replicas: 2
• wdu_multi_deploy_multi_replicas: 4

Le dimensioni consigliate per implementazioni su larga scala sono:

• wdu_main_deploy_multi_replicas: 4
• wdu_multi_deploy_multi_replicas: 8

Il watsonxaiifm servizio potrebbe rimanere bloccato nello stato "In corso" dopo l'applicazione di un nuovo file di configurazione ( ConfigMap )

Durante la registrazione di un modello di base personalizzato per la distribuzione globale, il watsonxaiifm servizio potrebbe rimanere bloccato nello stato "in corso" dopo l'applicazione di un nuovo file ` ConfigMap `.

watsonxaiifm Utilizza questo comando per verificare lo stato attuale del servizio:

oc get watsonxaiifm -n ${PROJECT_CPD_INST_OPERANDS}

Se il AGE valore è molto alto, il servizio è bloccato. Output di esempio:

NAME              VERSION   RECONCILED   STATUS   PERCENT   AGE
watsonxaiifm-cr   10.1.0    10.1.0       InProgress   55%   43h

Lo stato potrebbe anche essere Failed, con un valore molto elevato AGE :

NAME              VERSION   RECONCILED   STATUS   PERCENT   AGE
watsonxaiifm-cr   10.1.0    10.1.0       Failed   55%       43h

Potresti anche ricevere questo errore:

The error appears to be in '/opt/ansible/10.2.0/roles/watsonxaiifm/tasks/check-model.yml': line 13, column 3, but may
be elsewhere in the file depending on the exact syntax problem.

Per risolvere il problema:

1. Esegui questo comando per ottenere il WatsonxAIIFM nome del pod dell'operatore:

   oc get pods -n <operator-namespace> | grep watsonx
   

   Esempio di nome del pod: ibm-cpd-watsonx-ai-ifm-operator-6f8c86c8d8-45kfk

2. Esegui questo comando per visualizzare i log del pod dell'operatore:

   oc logs <operator-pod-name> -n <operator-namespace> -f
   

   Sostituisci <operator-pod-name> con il nome del pod ottenuto al punto 1. Cerca parole chiave come FAILED o ERROR nei log per individuare eventuali problemi.

3. Verificare che sia il Persistent Volume Claim (PVC) che WatsonxAIIFM l'operatore utilizzino la stessa classe di archiviazione.

   Per ottenere la classe di archiviazione del PVC, esegui questo comando:

   oc get pvc <pvc-name>
   

   Output di esempio:

   NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                AGE
   meta-llama-3-8b-instruct-pvc   Bound    pvc-ffa1bd5b-16b5-43cf-b344-58fb61aac86d   62Gi       RWX            ocs-storagecluster-cephfs   136m
   

   Per verificare la classe di archiviazione del cluster, esegui questo comando:

   oc describe zenservice
   

   Output di esempio:

   Spec:
     Block Storage Class:      managed-nfs-storage
     Cloud Pak Type:          data
     File Storage Class:      managed-nfs-storage
   

   In questa Spec sezione, verificare i Block Storage Class valori di e File Storage Class :

4. Verifica il file YAML di ConfigMap :

   • Verifica la presenza di errori di indentazione o di sintassi YAML non valida.
   • Confronta i valori presenti nel file ` ConfigMap ` con la configurazione di esempio per assicurarti che siano corretti.

5. Esegui questo comando per visualizzare la WatsonxAIIFM CR (risorsa personalizzata):

   oc edit watsonxaiifm
   

   Verificare che la formattazione sia corretta e che tutte le configurazioni siano valide.

6. Run this command to check whether the predictor pod is created:

   oc get po | grep predictor
   

7. Dopo aver apportato le modifiche necessarie, riavvia il WatsonxAIIFM pod dell'operatore. Riavvia il pod anche se non hai riscontrato alcun problema nei passaggi precedenti. Il riavvio potrebbe aiutare a risolvere il problema. Esegui questo comando:

   oc delete pod <operator-pod-name> -n <operator-namespace>
   

   Sostituisci <operator-pod-name> con il nome del pod ottenuto al punto 1.