Visão geral da preparação do modelo

Esta página orienta você nas etapas para preparar um modelo de IA de AML, assumindo que você já configurou uma instância e preparou os conjuntos de dados necessários.

Visão geral das fases

O processo de preparação de um modelo é dividido em três etapas:

• Etapa 1: configure um mecanismo, incluindo a seleção da origem dos hiperparâmetros:

  • Ajuste: ajuste automático de hiperparâmetros
  • Herdar: herda 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 evita que você precise fazer ajustes toda vez que adotar uma nova versão do motor de modelo.

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

• Etapa 2: gerar um modelo

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

• Etapa 3: avaliar um modelo

  Criar resultados de backtest avalia a performance do modelo em um conjunto especificado de meses, armazenando resultados de resumo em um recurso BacktestResult. Como alternativa, criar resultados de previsão permite avaliar as saídas do modelo por parte.

Depois de concluir as etapas anteriores e a performance 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 modelos e riscos.

Antes de começar

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

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

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 a IA antilavagem de dinheiro. Esta seção aborda como garantir que os conjuntos de dados usados no ajuste, treinamento e avaliação do mecanismo funcionem bem juntos.

Intervalos de tempo do conjunto de dados

Cada conjunto de dados usado para operações de ajuste, treinamento, backtesting e previsão precisa conter dados válidos para um período que termine no final do último mês completo antes do end_time especificado na chamada de API. A duração desse período depende da tabela, da versão do mecanismo e da operação. O intervalo de tempo mínimo é abordado em detalhes em Entender o escopo e a duração dos dados.

Por exemplo, para o ajuste do mecanismo com versões do mecanismo v004.004, a tabela de transações precisa abranger pelo menos 30 meses.

A configuração de um mecanismo, treinamento e avaliação (backtesting) pode ser concluída com um único conjunto de dados. Consulte a imagem a seguir. Para garantir um bom desempenho de produção evitando o ajuste excessivo, verifique se o período usado para avaliação (ou seja, a criação de resultados de backtest) é posterior ao período usado para treinamento (ou seja, a criação de um modelo).

Por exemplo, se você usar três períodos para backteste e usar períodos até o fim de fevereiro de 2024 para treinamento (ou seja, o horário de término no início de março de 2024), poderá usar períodos até o fim de maio de 2024 para backteste (ou seja, o horário de término no início de junho de 2024).

Consistência do conjunto de dados

Ao usar conjuntos de dados diferentes para os estágios de ajuste, treinamento e avaliação do mecanismo, faça com que os conjuntos de dados sejam consistentes em quais campos são preenchidos e como eles 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 resultados de previsão com um modelo precisa ser consistente com o conjunto de dados usado para treinar esse modelo.

Em particular, verifique o seguinte:

• A mesma lógica é usada para preencher cada campo. Mudar a lógica usada para preencher um campo pode introduzir uma distorção de recursos entre treinamento de modelo e a previsão ou avaliação.
• A mesma seleção de campos RECOMENDADOS é preenchida. Por exemplo, remover um campo que foi preenchido durante treinamento de modelo pode fazer com que os atributos em 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 de party_supplementary_data_id diferentes, faz com que o modelo use os dados incorretamente. Por exemplo, um campo específico usa o ID 5 na tabela PartySupplementaryData para um conjunto de dados, mas usa o ID 7 em outro conjunto de dados.
  • A remoção de um valor party_supplementary_data_id em 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. As operações de modelo podem levar dezenas de horas. Para saber como verificar se uma operação ainda está em execução ou foi concluída (falhou ou teve sucesso), consulte Gerenciar operações de longa duração.