Visão geral da preparação de modelos

Nesta página, você verá as etapas para preparar um modelo de IA do AML, supondo que você já tenha configurado uma instância e preparado os conjuntos de dados necessários.

Visão geral das etapas

O processo de preparação de um modelo é abordado nos três estágios a seguir:

• Estágio 1: configurar um mecanismo, incluindo ajuste automático de hiperparâmetros do mecanismo

  A criação de uma configuração de mecanismo aciona o ajuste automático de hiperparâmetros, armazenando os resultados como um recurso EngineConfig.

• Etapa 2: gerar um modelo

  A criação de um modelo aciona o treinamento, armazenando os resultados como um recurso do modelo.

• Fase 3: avaliar um modelo

  Criar resultados de backtest avalia o desempenho do modelo em um conjunto especificado de meses. O armazenamento de resultados de resumo em um recurso BacktestResult é usado. Como opção, criar resultados de previsão permite avaliar as saídas por parte do modelo.

Depois de concluir os estágios acima e o desempenho do modelo atender às suas necessidades, consulte as orientações nas seções Gerar pontuações de risco e explicabilidade e Preparar para a governança de modelo e risco.

Antes de começar

Antes de começar, você precisa do seguinte:

• Um ou mais conjuntos de dados
• Uma versão de mecanismo selecionada para usar.

Requisitos do conjunto de dados

Para orientações detalhadas sobre o esquema e o modelo de dados, consulte as páginas em Preparar dados para a IA de AML. Nesta seção, você verá como garantir que os conjuntos de dados usados no ajuste, treinamento e avaliação do mecanismo funcionem bem juntos.

Observação: a maioria das políticas de governança de modelo define um requisito para rastrear a linhagem de dados usada em todas as operações de ML, desde a configuração, o treinamento e a avaliação do mecanismo. Para garantir que os dados permaneçam inalterados, recomendamos que você crie um snapshot das tabelas do BigQuery depois que elas passarem na validação de dados. Caso você não capture dados, as operações da AML AI leem as tabelas do BigQuery sempre que uma operação usa o conjunto de dados. Portanto, as alterações no conjunto de dados podem afetar o ajuste, o treinamento, os backtesting e as previsões.

Períodos do conjunto de dados

O intervalo mínimo de conjuntos de dados para cada operação é abordado em Entender o escopo e a duração dos dados. Em resumo, é necessário ter uma janela de lookback de 0 a 24 meses, dependendo da tabela, sobre uma janela de tempo principal de pelo menos 18 meses.

Por exemplo, para o ajuste do mecanismo, a tabela Transação precisa cobrir pelo menos 42 meses, ou seja, 18 meses da janela de tempo principal e 24 meses da janela de lookback.

A configuração de um mecanismo, treinamento e avaliação (backtesting) pode ser concluída com um único conjunto de dados. Veja a imagem a seguir. Para garantir um bom desempenho de produção evitando o overfitting, use uma janela de tempo principal de avaliação (ou seja, criando resultados de backtest) que seja separada e mais recente do que a janela de tempo principal de treinamento (ou seja, criação de um modelo).

Consistência do conjunto de dados

Ao usar conjuntos de dados diferentes para os estágios de ajuste, treinamento e avaliação do mecanismo, torne os conjuntos de dados consistentes em quais campos são preenchidos e como são preenchidos. Isso é importante para a estabilidade e o desempenho do modelo de AML.

Da mesma forma, para uma pontuação de risco de alta qualidade, o conjunto de dados usado para criar os resultados da previsão com um modelo precisa ser consistente com o conjunto de dados usado para treinar esse modelo.

Especificamente, verifique o seguinte:

• A mesma lógica é usada para preencher cada campo. Alterar a lógica usada para preencher um campo pode introduzir um desvio de atributos entre o treinamento e a previsão ou avaliação do modelo.
• A mesma seleção de campos RECOMENDADOS é preenchida. Por exemplo, remover um campo preenchido durante o treinamento de modelo pode fazer com que os recursos de que o modelo depende sejam distorcidos ou ausentes durante a avaliação ou previsão.

• A mesma lógica é usada para fornecer valores. Na tabela PartySupplementaryData, a mesma lógica é usada para fornecer valores a cada campo party_supplementary_data_id.

  • Usar os mesmos dados, mas com valores party_supplementary_data_id diferentes, faz com que o modelo utilize dados incorretamente. Por exemplo, um campo específico usa o ID 5 na tabela PartySupplementaryData para um conjunto de dados, mas depois usa o ID 7 em outro conjunto de dados.
  • A remoção de um valor party_supplementary_data_id de que um modelo depende pode ter efeitos imprevisíveis. Por exemplo, o ID 3 é usado na tabela PartySupplementaryData em um conjunto de dados, mas é omitido em outro.

Agora você tem um conjunto de dados pronto para ajuste, treinamento e avaliação do mecanismo. Observe que as operações do modelo podem levar dezenas de horas. Para informações sobre como verificar se uma operação ainda está em execução ou foi concluída (falha ou bem-sucedida), consulte Gerenciar operações de longa duração.