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:
Fase 1: Configure um mecanismo, incluindo a seleção da fonte 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.
Como criar uma configuração de mecanismo armazena os resultados de ajuste ou herança em uma Recurso EngineConfig.
Etapa 2: gerar um modelo
Como criar um modelo aciona o treinamento, armazenando os resultados Recurso Model.
Fase 3: Avaliar um modelo
Como criar resultados de backtest avalia o desempenho do modelo em um conjunto específico de meses, armazenando resulta em uma Recurso BacktestResult. Como alternativa, criar resultados de previsão permite avaliar as saídas do modelo por parte.
Depois que você concluir os estágios iniciais e o desempenho do modelo atender às suas necessidades, consulte as orientações nas seções Gerar pontuações de risco e explicabilidade e Prepare-se para o modelo e a governança de riscos.
Antes de começar
Antes de começar, você vai precisar do seguinte:
- Um ou mais conjuntos de dados
- Um item selecionado versão do mecanismo 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. Nesta seção, abordamos como garantir que os conjuntos de dados usados no ajuste de motores, treinamento e avaliação funcionam 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 mínimo é abordado em detalhes em Entenda 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 uma boa produção desempenho ao evitar o overfitting, você deve garantir que o período usado para da avaliação (ou seja, criar resultados de backtest) é posterior ao período usado para ou seja, criar um modelo.
Por exemplo: se você estiver usando três períodos para backtest e até o fim de fevereiro de 2024 para treinamento (ou seja, horário de término no início de março de 2024), então você você pode usar períodos até o fim de maio de 2024 para fazer backtests (ou seja, 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 ajuste, treinamento e avaliação do mecanismo de dados, torne os conjuntos de dados consistentes em quais campos são preenchidos e como eles estã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, a usado para criar resultados de previsão com um modelo deve ser consistente com do conjunto de dados usado para treinar esse modelo.
Em particular, verifique o seguinte:
- A mesma lógica é usada para preencher todos os campos. Mudar a lógica usada para preencher um campo pode introduzir uma distorção de recursos entre o treinamento do 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 o treinamento do 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 PartySupplementaryData, a mesma lógica é usada para forneça valores para cada campo
party_supplementary_data_id
.- Usando os mesmos dados, mas com
party_supplementary_data_id
diferentes. faz com que o modelo use os dados incorretamente. Por exemplo, campo específico usa o ID5
no na tabela PartySupplementaryData para um conjunto de dados, mas usa o ID7
em outro conjunto de dados. - Como remover um valor
party_supplementary_data_id
de que um modelo depende podem ter efeitos imprevisíveis. Por exemplo, o ID3
é usado na tabela PartySupplementaryData em um conjunto de dados, mas não omitido de outro conjunto de dados.
- Usando os mesmos dados, mas com
Agora você tem um conjunto de dados pronto para ajuste, treinamento e avaliação do mecanismo. Observação que as operações do modelo podem levar dezenas de horas. Para mais informações sobre como Verificar se uma operação ainda está em execução ou foi concluída (com falha ou bem-sucedida) ver Gerencie operações de longa duração.