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

Solução de problemas de implementações

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.

  1. Abra o site serviceID em IBM Cloud. Localização da página da política de serviceID
  2. 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. Atualização da política e das funções de um serviceID
  3. A política atualizada terá a seguinte aparência: Política de serviceID atualizada
  4. 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:

Informações sobre limitação de tempo no nível de consulta para origens de dados
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.

A imagem mostra que o mapeamento automático de ativos de dados e conexões está falhando

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:

  1. 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.

  2. Clique em " Criar para salvar seu progresso e sair da caixa de diálogo de configuração " Novo emprego.

  3. 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.

  4. 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.

  5. Em seu espaço de implantação, clique na guia Jobs e selecione o trabalho de fluxo SPSS Modeler para.

  6. Na página de detalhes do trabalho, clique no ícone Editar Imagem do ícone de edição para verificar o mapeamento de seus ativos de dados e conexões.

  7. 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

    A imagem mostra que o mapeamento automático de ativos de dados e conexões foi bem-sucedido

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.