En esta página, se explican los pasos para preparar una IA contra lavado de dinero suponiendo que ya configuraste una instancia y preparaste los cambios necesarios conjuntos de datos.
Descripción general de las etapas
El proceso para preparar un modelo se aborda en las siguientes tres etapas:
Etapa 1: Configura un motor, lo que incluye seleccionar la fuente de los hiperparámetros:
- Ajuste: Ajuste automático de hiperparámetros
- Heredar: hereda hiperparámetros de una configuración de motor anterior que se creó con una versión de motor anterior dentro del mismo versión de ajuste. Este parámetro de configuración te permite evitar tener que volver a ajustar cada vez que adoptas un modelo nuevo. versión del motor de búsqueda.
Crea una configuración de motor almacena los resultados del ajuste o la herencia Recurso de EngineConfig.
Etapa 2: Genera un modelo
Crea un modelo activa el entrenamiento, almacenando los resultados como Recurso de modelo.
Etapa 3: Evalúa un modelo
Crea resultados de pruebas retrospectivas que evalúa el rendimiento del modelo durante un período específico de meses, da como resultado una Recurso BacktestResult. Opcionalmente, crear resultados de predicción te permite evaluar las salidas por parte del modelo.
Una vez que hayas completado las etapas anteriores y el rendimiento del modelo satisfaga tus necesidades, consulta la orientación en las secciones Generar puntuaciones de riesgo y explicabilidad y Prepárate para la gobernanza de modelos y riesgos.
Antes de comenzar
Antes de comenzar, necesitarás lo siguiente:
- Uno o más conjuntos de datos
- Un elemento seleccionado versión de motor para usar
Requisitos del conjunto de datos
Para obtener orientación detallada sobre el modelo de datos y el esquema, consulta las páginas de Cómo preparar datos para la IA contra el lavado de dinero. En esta sección, se explica cómo asegurarte de que los conjuntos de datos que se usan en el ajuste, el entrenamiento y la evaluación del motor funcionan bien en conjunto.
Intervalos de tiempo de los conjuntos de datos
Cada conjunto de datos que se usa para el ajuste, el entrenamiento, la evaluación retrospectiva y las operaciones de predicción debe contener datos válidos para un intervalo de tiempo que finalice al final de la última el mes calendario anterior al end_time especificado en la llamada a la API. La duración de este intervalo depende de la tabla, la versión de Engine y la operación. El mínimo se trata en detalle en el artículo Comprende el alcance y la duración de los datos.
Por ejemplo, para el ajuste del motor con las versiones v004.004, la tabla de transacciones debe abarcar al menos 30 meses.
La configuración de un motor, el entrenamiento y la evaluación (simulación retrospectiva) se pueden completar con un solo conjunto de datos. Consulta la siguiente imagen. Para garantizar un buen rendimiento en producción evitando el sobreajuste, debes asegurarte de que el período utilizado para la evaluación (es decir, la creación de resultados de la prueba retrospectiva) sea posterior al período utilizado para el entrenamiento (es decir, la creación de un modelo).
Por ejemplo, si se usan 3 puntos para backtesting y períodos hasta el final febrero de 2024 para la capacitación (es decir, la hora de finalización a principios de marzo de 2024), podría utilizar períodos hasta finales de mayo de 2024 para hacer pruebas retrospectivas (es decir, la hora de finalización a principios de junio de 2024).
Coherencia con el conjunto de datos
Cuando se usan diferentes conjuntos de datos para el ajuste, el entrenamiento y la evaluación del motor etapas, hacen que los conjuntos de datos sean coherentes en qué campos se propagan y cómo se completen. Esto es importante para la estabilidad y el rendimiento de los modelos contra el lavado de dinero.
Del mismo modo, para obtener una puntuación de riesgo de alta calidad, el conjunto de datos que se usa para crear resultados de predicción con un modelo debe ser coherente con el conjunto de datos que se usa para entrenar ese modelo.
En particular, asegúrate de lo siguiente:
- Se usa la misma lógica para propagar cada campo. Cambiar la lógica que se usa para propagar un campo puede introducir sesgos de atributos entre el entrenamiento del modelo y la predicción o evaluación.
- Se propaga la misma selección de campos RECOMENDADOS. Por ejemplo: quitar un campo que se propagó durante el entrenamiento de modelos puede generar atributos que el modelo necesita para estar sesgado o faltante durante la evaluación o para la predicción.
Se usa la misma lógica para proporcionar valores. En la PartySupplementaryData, se usa la misma lógica para proporciona valores para cada campo
party_supplementary_data_id.- Se usan los mismos datos, pero con diferentes
party_supplementary_data_idde salida, hace que el modelo use datos de forma incorrecta. Por ejemplo, un campo específico usa el ID5en el PartySupplementaryData para un conjunto de datos, pero usa el ID7de otro conjunto de datos. - Quitar un valor
party_supplementary_data_iden el que se basa un modelo puede tener efectos impredecibles. Por ejemplo, el ID3se usa en la tabla PartySupplementaryData de un conjunto de datos, pero se omite de otro.
- Se usan los mismos datos, pero con diferentes
Ahora tienes un conjunto de datos listo para el ajuste, el entrenamiento y la evaluación del motor. Nota que las operaciones del modelo pueden tardar decenas de horas. Para obtener información sobre cómo verificar si una operación aún se está ejecutando o se completó (con errores o de forma correcta) ver Administra operaciones de larga duración.