Visão geral da preparação de modelos

Nesta página, mostramos as etapas para preparar um modelo de IA antilavagem de dinheiro, supondo que você já configurou uma instância e preparou os conjuntos de dados necessários.

Visão geral das etapas

O processo de preparação de um modelo é abordado nas três etapas a seguir:

• Estágio 1: configurar um mecanismo, incluindo a seleção da origem de hiperparâmetros:

  • Ajuste: ajuste automático de hiperparâmetros
  • Herdar: herde hiperparâmetros de uma configuração de mecanismo anterior criada com uma versão anterior do mecanismo na mesma versão de ajuste. Essa configuração permite evitar novos ajustes sempre que você adotar uma nova versão do mecanismo do modelo.

  Criar uma configuração de mecanismo armazena os resultados do ajuste ou da herança em um recurso EngineConfig.

• Estágio 2: gerar um modelo

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

• Estágio 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. Opcionalmente, 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-se para a governança de modelo e risco.

Antes de começar

Antes de começar, você precisará do seguinte:

• Um ou mais conjuntos de dados
• Uma versão de mecanismo selecionada a ser usada.

Requisitos do conjunto de dados

Para orientações detalhadas sobre o modelo e o esquema de dados, consulte as páginas em Preparar dados para IA antilavagem de dinheiro. Nesta seção, mostramos 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 crie snapshots dos dados, as operações da IA antilavagem de dinheiro lerão as tabelas do BigQuery sempre que uma operação usar o conjunto de dados. Portanto, as alterações no conjunto de dados podem afetar o ajuste, o treinamento, os backtesting e as previsões.

Intervalos de tempo do conjunto de dados

O intervalo de tempo mínimo dos conjuntos de dados para cada operação é abordado em Entender o escopo e a duração dos dados. Em resumo, uma janela de lookback de 0 a 24 meses é necessária, 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 (a janela de tempo principal de 18 meses e a janela de 24 meses para a 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 para avaliação (ou seja, criar resultados de backtest) que seja independente e mais recente do que a janela de tempo principal para treinamento (ou seja, para criar 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 com quais campos são preenchidos e como eles são preenchidos. Isso é importante para a estabilidade e o desempenho do modelo antilavagem de dinheiro.

Da mesma forma, para uma pontuação de risco de alta qualidade, o conjunto de dados usado para criar os resultados de 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 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 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 para cada campo party_supplementary_data_id.

  • Usar os mesmos dados, mas com valores party_supplementary_data_id diferentes, faz com que o modelo use 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 de 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 (com falha ou com êxito), consulte Gerenciar operações de longa duração.