Conclusiones principales

  • Como el intercambio de cifrado más grande del mundo, es fundamental que tengamos un sistema de detección de riesgos que sea rápido pero que no comprometa la precisión.

  • El desafío que encontramos fue garantizar que nuestros modelos siempre usaran información actualizada, especialmente al detectar actividad sospechosa en la cuenta en tiempo real.

  • Para lograr una mayor coherencia de funciones y una mayor velocidad de producción, ahora hacemos suposiciones razonables sobre nuestros datos y combinamos nuestros canales de procesamiento por lotes y de transmisión.

Descubra cómo nuestro proceso de ingeniería de funciones crea funciones sólidas y consistentes para detectar retiros fraudulentos en la plataforma Binance.

Dentro de nuestro proceso de aprendizaje automático (ML), sobre el cual puede obtener más información en un artículo anterior, recientemente creamos un proceso de ingeniería de funciones automatizado que canaliza datos sin procesar en funciones en línea reutilizables que se pueden compartir entre todos los modelos relacionados con el riesgo.

En el proceso de construcción y prueba de este canal, nuestros científicos de datos encontraron un problema de coherencia de características intrigante: ¿Cómo creamos conjuntos precisos de características en línea que cambian dinámicamente con el tiempo?

Considere este escenario del mundo real: un intercambio de cifrado (en este caso, Binance) está tratando de detectar retiros fraudulentos antes de que el dinero abandone la plataforma. Una posible solución es agregar una función a su modelo que detecte el tiempo transcurrido desde la última operación específica del usuario (por ejemplo, iniciar sesión o vincular un dispositivo móvil). Se vería algo como esto:

user_id|last_bind_google_time_diff_in_days|...

1|3.52|...

El desafío de la implementación

La cantidad de claves necesarias para calcular y actualizar funciones en una tienda de funciones en línea no es práctica. Usar un canal de transmisión, como Flink, sería imposible ya que solo puede calcular los usuarios con registros que ingresan a Kafka en este momento.

Como compromiso, podríamos utilizar una canalización por lotes y aceptar algún retraso. Digamos que un modelo puede obtener funciones de una tienda de funciones en línea y realizar inferencias en tiempo real en aproximadamente una hora. Al mismo tiempo, si una tienda de funciones tarda una hora en terminar de calcular e ingerir datos, la canalización por lotes resolvería, en teoría, el problema.

Desafortunadamente, hay un problema evidente: el uso de un proceso por lotes de este tipo requiere mucho tiempo. Esto hace que terminar en una hora sea inviable cuando se trata del intercambio de cifrado más grande del mundo y maneja aproximadamente cien millones de usuarios y un límite de TPS para escrituras.

Descubrimos que la mejor práctica es hacer suposiciones sobre nuestros usuarios, reduciendo así la cantidad de datos que ingresan a nuestro almacén de funciones.

Aliviar el problema con supuestos prácticos

Las funciones en línea se incorporan en tiempo real y cambian constantemente porque representan la versión más actualizada de un entorno. Con usuarios activos de Binance, no podemos darnos el lujo de utilizar modelos con funciones obsoletas.

Es imperativo que nuestro sistema detecte cualquier retiro sospechoso lo antes posible. Cualquier retraso adicional, aunque sea de unos pocos minutos, significa más tiempo para que un actor malintencionado se salga con la suya.

Entonces, en aras de la eficiencia, asumimos que los inicios de sesión recientes conllevan un riesgo relativamente mayor:

  • Descubrimos que (250 días + 0,125[3/24 de retraso] día) produce errores relativamente menores que (1 día + 0,125[3/24 de retraso] día).

  • La mayoría de las operaciones no excederán un cierto umbral; digamos 365 días. Para ahorrar tiempo y recursos informáticos, omitimos a los usuarios que no han iniciado sesión durante más de un año.

Nuestra solución

Usamos la arquitectura lambda, que implica un proceso en el que combinamos canalizaciones por lotes y de transmisión para lograr una mayor coherencia de las funciones.

¿Cómo se ve conceptualmente la solución?

  • Batch Pipeline: realiza ingeniería de funciones para una base de usuarios masiva.

  • Streaming Pipeline: soluciona el tiempo de retraso de la canalización por lotes para inicios de sesión recientes.

¿Qué sucede si se incorpora un registro a la tienda de funciones en línea entre el tiempo de retraso en la ingesta por lotes?

Nuestras funciones aún mantienen una gran coherencia incluso cuando los registros se incorporan durante el período de retraso de ingesta por lotes de una hora. Esto se debe a que la tienda de funciones en línea que utilizamos en Binance devuelve el valor más reciente según el event_time que especifique al recuperar el valor.

¡Unete a nuestro equipo!

¿Está interesado en utilizar el aprendizaje automático para salvaguardar el ecosistema criptográfico más grande del mundo y a sus usuarios? Consulte Binance Engineering / AI en nuestra página de carreras para conocer las ofertas de trabajo.

Para obtener más información, lea los siguientes artículos útiles:

  • (Blog) Uso de MLOps para crear un canal de aprendizaje automático de un extremo a otro en tiempo real

  • (Blog) Una mirada más cercana a nuestra tienda de funciones de aprendizaje automático