Solucionar problemas de tempo de execução watsonx.ai
Siga estas dicas para solucionar problemas comuns que você pode encontrar ao trabalhar com o watsonx.ai Runtime.
Solução de problemas do AutoAI
- O notebook de inferência doAutoAI para um experimento RAG excede os limites do modelo
- O treinamento de um experimento AutoAI falha com as credenciais de ID de serviço
- A solicitação de previsão para o modelo de série temporal AutoAI pode expirar com muitas observações novas
- Membros de classe insuficientes nos dados de treinamento para o experimento AutoAI
- Não é possível abrir ativos do Cloud Pak for Data que requerem watsonx.ai
Solução de problemas de implementações
As implementações em lote que usam grandes volumes de dados como entrada podem falhar
As implementações com especificações de software restritas falham após uma atualização
Falha ao criar um trabalho para um fluxo SPSS Modeler em um espaço de implantação
A execução de um trabalho de implementação falha devido à remoção das credenciais da tarefa
Solução de problemas do AutoAI
Siga estas dicas para resolver problemas comuns que você pode encontrar ao trabalhar com o AutoAI.
A execução de um experimento de série temporal AutoAI com falha na previsão de anomalias
O recurso de previsão de anomalias nos resultados de um experimento de série temporal não é mais suportado. A tentativa de executar um experimento existente resulta em erros por falta de bibliotecas de tempo de execução. Por exemplo, você pode ver este erro:
The selected environment seems to be invalid: Could not retrieve environment. CAMS error: Missing or invalid asset id
O comportamento é esperado, pois não há suporte para os tempos de execução da previsão de anomalias. Não há solução alternativa para esse problema.
O notebook de inferência do AutoAI para um experimento RAG excede os limites do modelo
Às vezes, ao executar um notebook de inferência gerado para um experimento AutoAI RAG, você pode receber este erro:
MissingValue: No "model_limits" provided. Reason: Model <model-nam> limits cannot be found in the model details.
O erro indica que os limites de token para inferir o modelo de base usado para o experimento estão faltando. Para resolver o problema, localize a função ' default_inference_function e substitua ' get_max_input_tokens pelo número máximo de tokens do modelo. Por exemplo:
model = ModelInference(api_client=client, **params['model"])
# model_max_input_tokens = get+max_input_tokens(model=model, params=params)
model_max_input_tokens = 4096
Você pode encontrar o valor máximo de token para o modelo na tabela de modelos de fundação suportados disponíveis no watsonx.ai.
O treinamento de um experimento AutoAI falha com as credenciais de ID de serviço
Se você estiver treinando um experimento AutoAI usando a chave de API para o serviceID, o treinamento poderá falhar com esse erro:
User specified in query parameters does not match user from token.
Uma maneira de resolver esse problema é executar o experimento com suas credenciais de usuário. Se você quiser executar o experimento com credenciais para o serviço, siga estas etapas para atualizar as funções e políticas do ID do serviço.
- Abra o site serviceID em IBM Cloud.

- Crie um novo serviceID ou atualize o ID existente com a seguinte política de acesso:
- Todos os serviços de gerenciamento de contas IAM com as funções Revisor de chaves de API, Criador de chaves de API do usuário, Visualizador, Operador e Editor. O ideal é que eles criem uma nova apikey para esse ServiceId.

- Todos os serviços de gerenciamento de contas IAM com as funções Revisor de chaves de API, Criador de chaves de API do usuário, Visualizador, Operador e Editor. O ideal é que eles criem uma nova apikey para esse ServiceId.
- A política atualizada terá a seguinte aparência:

- Execute o treinamento novamente com as credenciais do serviceID atualizado.
A solicitação de previsão para o modelo de série temporal AutoAI pode expirar com muitas observações novas
Uma solicitação de previsão pode expirar em um modelo de série temporal AutoAI implantado se houver muitas observações novas. Para solucionar esse problema, escolha uma das soluções a seguir:
- Reduzir o número de novas observações.
- Amplie os dados de treinamento usados para o experimento adicionando novas observações. Em seguida, execute novamente o experimento de série temporal AutoAI com os dados de treinamento atualizados.
Membros de classe insuficientes em dados de treinamento para o experimento AutoAI
Os dados de treinamento para um experimento do AutoAI devem ter pelo menos 4 membros para cada classe Se seus dados de treinamento tiverem um número insuficiente de membros em uma classe, você encontrará esse erro:
ERROR: ingesting data Message id: AC10011E. Message: Each class must have at least 4 members. The following classes have too few members: ['T'].
Para resolver o problema, atualize os dados de treinamento para remover a classe ou incluir mais membros..
Não é possível abrir ativos do Cloud Pak for Data que requerem watsonx.ai
Se estiver trabalhando no contexto do Cloud Pak for Data, não será possível abrir ativos que exijam um contexto de produto diferente, como o watsonx.ai. Por exemplo, se você criar um experimento de AutoAI para um padrão RAG usando watsonx.ai, não poderá abrir esse ativo quando estiver no contexto do Cloud Pak for Data. No caso de experimentos AutoAI, você pode visualizar o tipo de treinamento na lista de ativos. Você pode abrir experimentos com aprendizado de máquina do tipo, mas não com geração aumentada por recuperação do tipo.
Solução de problemas de implementações
Siga estas dicas para resolver problemas comuns que você pode encontrar ao trabalhar com implantações do watsonx.ai Runtime.
Implementações em lote que usam grandes volumes de dados como entrada podem falhar
Se você estiver escoragem de uma tarefa em lote que usa grandes volumes de dados como a origem de entrada, a tarefa poderá falhar devido às configurações de tempo limite interno Um sintoma desse problema pode ser uma mensagem de erro semelhante ao exemplo a seguir:
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 o tempo limite ocorrer quando você escorar sua implementação em lote, deverá configurar a limitação de tempo limite do nível de consulta da origem de dados para manipular tarefas de longa execução.
As informações de tempo limite de nível de consulta para origens de dados são as seguintes:
| Origem de dados | Limitação de tempo de nível de consulta | Limite de tempo padrão | Modificar limite de tempo padrão |
|---|---|---|---|
| Apache Cassandra | True | 10 segundos | Defina os parâmetros " read_timeout_in_ms e " write_timeout_in_ms no arquivo de configuração Apache Cassandra ou no URL de conexão Apache Cassandra para alterar o limite de tempo padrão. |
| Cloud Object Storage | Não | N/D | N/D |
| Db2 | True | N/D | Configure o parâmetro QueryTimeout para especificar a quantidade de tempo (em segundos) que um cliente aguarda a conclusão de uma execução de consulta antes que um cliente tente cancelar a execução e retornar o controle para o aplicativo. |
| Hive via Execution Engine for Hadoop | True | 60 minutos (3600 segundos) | Defina a propriedade " hive.session.query.timeout no URL conexão para alterar o limite de tempo padrão. |
| Microsoft SQL Server | True | 30 segundos | Configure a opção de configuração do servidor QUERY_TIMEOUT para alterar o limite de tempo padrão.. |
| MongoDB | True | 30 segundos | Configure o parâmetro maxTimeMS nas opções da consulta para alterar o limite de tempo padrão |
| MySQL | True | 0 segundos (sem limite de tempo padrão) | Defina a propriedade " timeout no URL de conexão ou nas propriedades do driver JDBC para especificar um limite de tempo para sua consulta. |
| Oracle | True | 30 segundos | Configure o parâmetro QUERY_TIMEOUT no driver Oracle JDBC para especificar a quantidade máxima de tempo que uma consulta pode executar antes de ser cancelada automaticamente. |
| PostgreSQL | Não | N/D | Configure a propriedade queryTimeout para especificar a quantidade máxima de tempo que uma consulta pode executar. O valor padrão da propriedade queryTimeout é 0. |
| Snowflake | True | 6 horas | Configure o parâmetro queryTimeout para alterar o limite de tempo padrão |
Para evitar que suas implementações em lote falhem, particionar seu conjunto de dados ou diminuir seu tamanho..
Segurança para uploads de arquivo
Os arquivos que você carrega por meio do watsonx.ai Studio ou do watsonx.ai Runtime UI não são validados ou verificados quanto a conteúdo potencialmente malicioso. É recomendado que você execute software de segurança, como um aplicativo antivírus, em todos os arquivos antes de fazer upload para garantir a segurança de seu conteúdo.
As implantações com especificações de software restritas falham após uma atualização
Se você atualizar para uma versão mais recente do IBM Cloud Pak for Data e implantar um ativo de aplicativo R Shiny que foi criado usando especificações de software restritas no modo FIPS, a implantação falhará.
Por exemplo, as implementações que usam as especificações de software ' shiny-r3.6 e ' shiny-r4.2 falham após a atualização do IBM Cloud Pak for Data versão 4.7.0 para 4.8.4 ou posterior. Você pode receber a mensagem de erroError 502 - Bad Gateway .
Para evitar que sua implantação falhe, atualize a especificação restrita do seu ativo implantado para usar a especificação de software mais recente. Para obter mais informações, consulte Gerenciando especificações ou estruturas de software desatualizadas. Você também pode excluir a implantação do seu aplicativo se não precisar mais dele.
Falha ao criar um trabalho para um fluxo SPSS Modeler em um espaço de implantação
Durante o processo de configuração de um trabalho em lote para o fluxo do SPSS Modeler em um espaço de implantação, o mapeamento automático de ativos de dados com suas respectivas conexões pode falhar.

Ele falha porque o trabalho não consegue encontrar um ativo de dados ou uma conexão com o mesmo nome no espaço de implementação. Para corrigir o erro com o mapeamento automático, siga estas etapas:
Revise os detalhes do seu trabalho de implementação para determinar se o ativo de dados ou a conexão está faltando ou se o fluxo não está fazendo referência ao ativo de dados correto.
Clique em " Criar para salvar seu progresso e sair da caixa de diálogo de configuração " Novo emprego.
Se um ativo de dados ou conexão não estiver em seu espaço de implantação, localize-o em seu projeto e promova-o para o espaço de implantação.
Se o fluxo SPSS Modeler não estiver fazendo referência ao ativo de dados ou à conexão correta, atualize o fluxo SPSS Modeler no espaço do projeto e promova-o novamente no espaço de implementação.
Em seu espaço de implantação, clique na guia Jobs e selecione o trabalho de fluxo SPSS Modeler para.
Na página de detalhes do trabalho, clique no ícone Editar
para verificar o mapeamento de seus ativos de dados e conexões.Se o erro tiver sido corrigido, você poderá retomar o processo de definição das configurações do trabalho na caixa de diálogo Novo trabalho. Para obter mais informações, consulte Criação de trabalhos de implantação para fluxos SPSS Modeler

Falha na conversão de um modelo de LightGBM para ONNX
Se você usar uma função objetiva sem suporte para converter seus modelos LightGBM para o formato ONNX, a implantação poderá falhar. Por exemplo, se você usar uma função objetiva não suportada na definição do site lightgbm.Booster, poderá ter problemas com a conversão.
Para resolver esse problema, certifique-se de usar uma função objetiva compatível ao converter os modelos do LightGBM para o ONNX.
O exemplo de código a seguir mostra como substituir a função objetiva sem suporte na definição do site lightgbm.Booster por uma função compatível com o site convert_lightgbm.
lgb_model = lightgbm.Booster(model_str=lgb_model.model_to_string().replace('<unsupported_objective_function>', '<compatible_objective_function>'))
A execução de um trabalho de implementação falha devido à remoção das credenciais da tarefa
Para aumentar a segurança, são necessárias credenciais de tarefa para criar implementações e executar trabalhos. Se você executar um trabalho de implementação depois de remover suas credenciais de tarefa, o status da implementação ou do trabalho permanecerá em um status intermediário devido à indisponibilidade do token da API, que é necessário para atualizar o status do trabalho no serviço de trabalhos da plataforma.
Como resultado, o pod de tempo de execução não conseguirá gerar um token de usuário, fazendo com que o trabalho permaneça no estado running indefinidamente.
Para resolver esse problema, você deve recriar as credenciais da tarefa que removeu anteriormente e excluir a implantação ou o trabalho existente que permanece em um status intermediário.