Esta página mostra as etapas para preparar uma IA antilavagem de dinheiro caso você já tenha configurado uma instância e preparado os eventos conjuntos de dados.
Visão geral dos estágios
O processo de preparação de um modelo é abordado nos três estágios a seguir:
Fase 1: Configure um mecanismo, incluindo a seleção da fonte dos hiperparâmetros:
- Ajuste: ajuste automático de hiperparâmetros
- Herdar: herdar hiperparâmetros de uma configuração de mecanismo anterior criada com uma versão anterior do mecanismo no mesmo versão de ajuste. Esta configuração permite evitar novos ajustes sempre que você adota um novo modelo do Compute Engine.
Como criar uma configuração de mecanismo armazena os resultados de ajuste ou herança em uma Recurso EngineConfig.
Fase 2: Gerar um modelo
Como criar um modelo aciona o treinamento, armazenando os resultados Recurso Model.
Fase 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. Opcionalmente, Como criar resultados de previsão e permite avaliar as saídas do modelo.
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ê 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
O intervalo mínimo de tempo 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, além de uma janela de tempo principal de pelo menos 18 meses para cobrir todas as operações com o mesmo conjunto de dados. Conjuntos de dados mais curtos podem ser usados para operações individuais; por exemplo, se estiver reutilizando uma configuração de mecanismo e não precisar sintonização.
Por exemplo, para ajuste de mecanismos, a tabela Transaction deve ser cobrir pelo menos 42 meses (18 meses de janela de tempo principal e 24 meses para o janela de lookback).
A configuração de um mecanismo, o treinamento e a avaliação (backtesting) podem ser concluídos com um único conjunto de dados. confira a imagem a seguir. Para garantir uma boa produção desempenho ao evitar o overfitting, você deve usar uma janela de tempo central (ou seja, a criação de resultados de backtest) desconexa e mais recente do que a janela de tempo principal do treinamento, ou seja, a criação de um modelo.
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 antilavagem de dinheiro.
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.
Especificamente, verifique o seguinte:
- A mesma lógica é usada para preencher todos os campos. Mudar a lógica usada preencher um campo pode introduzir desvio de atributos entre treinamento de modelo e 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 em que o modelo depende para estar distorcido ou ausente 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, um campo específico usa o ID5
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 é omitido de outro.
- 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 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.