Ingesta de streaming con Amazon SageMaker Feature Store para tomar decisiones respaldadas por ML casi en tiempo real

Por Paul Hargis, Arunprasath Shankar, Megan Leoni y Mark Roy

Las empresas utilizan cada vez más machine learning (ML) para tomar decisiones casi en tiempo real, como colocar un anuncio, asignar un controlador, recomendar un producto o incluso fijar precios dinámicos de productos y servicios. Los modelos de ML hacen predicciones dado un conjunto de datos de entrada conocido como características o features, y los científicos de datos pasan fácilmente más del 60% de su tiempo diseñando y construyendo estos features. Además, las predicciones altamente precisas dependen del acceso oportuno a los valores de los mismos que cambian rápidamente con el tiempo, agregando aún más complejidad al trabajo de crear una solución altamente disponible y precisa. Por ejemplo, un modelo para una aplicación de viaje compartido puede elegir el mejor precio para un viaje desde el aeropuerto, pero solo si conoce el número de solicitudes de viaje recibidas en los últimos 10 minutos y el número de pasajeros que se proyecta aterrizar en los próximos 10 minutos. Un modelo de enrutamiento en una aplicación de call center puede elegir el mejor agente disponible para una llamada entrante, pero sólo es efectivo si conoce los clics más recientes de la sesión web del cliente.

Aunque el valor empresarial de las predicciones de ML casi en tiempo real es enorme, la arquitectura necesaria para ofrecerlas de forma fiable, segura y con buen rendimiento es complicada. Las soluciones necesitan updates de alto rendimiento y recuperación de baja latencia de los valores de features más recientes en milisegundos, algo que la mayoría de los científicos de datos no están preparados para ofrecer. Como resultado, algunas empresas han gastado millones de dólares inventando su propia infraestructura propietaria para la administración de features. Otras empresas han limitado sus aplicaciones de ML a patrones más simples, como la inferencia batch, hasta que los proveedores de ML proporcionaran soluciones más completas disponibles para feature stores online.

Para hacer frente a estos desafíos, Amazon SageMaker Feature Store ofrece un repositorio central totalmente gestionado para ML, lo que facilita el almacenamiento y recuperación de features de forma segura, sin tener que crear y mantener su propia infraestructura. Amazon SageMaker Feature Store le permite definir grupos de funciones, utilizar la ingestión por batch y/o streaming,  recuperar los valores de features más recientes con latencia de milisegundos de un solo dígito para obtener predicciones en línea de gran precisión y extraer conjuntos de datos correctos puntuales para la formación. En lugar de crear y mantener estas capacidades de infraestructura, obtendrá un servicio totalmente administrado que se amplía a medida que crecen sus datos, permite compartir funciones entre equipos y permite que los científicos de datos se centren en crear grandes modelos de ML destinados a casos de uso empresariales que cambian el juego. Ahora los equipos pueden escribir funciones robustas una vez y reutilizarlas muchas veces en una variedad de modelos que pueden ser construidos por diferentes equipos.

En esta publicación se muestra un ejemplo completo de cómo puede vincular la creación de funciones de streaming con Amazon SageMaker Feature Store para tomar decisiones respaldadas por ML-en casi tiempo real. Mostramos un caso de uso de detección de fraude de tarjetas de crédito que actualiza las características agregadas de una transmisión en vivo de transacciones y utiliza recuperaciones de características de baja latencia para ayudar a detectar transacciones fraudulentas. Pruébalo usted mismo visitando nuestro repositorio de código.

Caso de uso de fraude de tarjetas de

Los números de tarjetas de crédito robadas se pueden comprar a granel en la deep web a partir de fugas anteriores o hacks de organizaciones que almacenan estos datos confidenciales. Los estafadores compran estas listas de tarjetas e intentan realizar tantas transacciones como sea posible con los números robados hasta que la tarjeta sea bloqueada. Estos ataques de fraude suelen ocurrir en un corto período de tiempo, y esto se puede detectar fácilmente en transacciones históricas porque la velocidad de las transacciones durante el ataque difiere significativamente del patrón de gasto habitual del titular de la tarjeta.

La siguiente tabla muestra una secuencia de transacciones de una tarjeta de crédito donde el titular de la tarjeta primero tiene un patrón de gasto genuino y luego experimenta un ataque de fraude a partir del 4 denoviembre.

Para este post, entrenamos a un modelo ML para detectar este tipo de comportamiento mediante features que describen el patrón de gasto de una tarjeta individual, como el número de transacciones o el importe medio de transacción de esa tarjeta en una determinada ventana de tiempo. Este modelo protege a los titulares de tarjetas del fraude en el punto de venta detectando y bloqueando transacciones sospechosas antes de que el pago pueda completarse. El modelo realiza predicciones en un contexto de baja latencia y en tiempo real y se basa en la recepción de cálculos de características actualizados, para que pueda responder a un ataque de fraude continuo. En un escenario real, las características relacionadas con los patrones de gasto del titular de la tarjeta solo formarían parte del conjunto de features del modelo, y podemos incluir información sobre el comerciante, el titular de la tarjeta, el dispositivo utilizado para realizar el pago y cualquier otro dato que pueda ser relevante para detectar fraudes.

Debido a que nuestro caso de uso se basa en la elaboración de perfiles de los patrones de gasto de una tarjeta individual, es crucial que podamos identificar tarjetas de crédito en un flujo de transacciones. La mayoría de los datasets de detección de fraude disponibles públicamente no proporcionan esta información, por lo que utilizamos la biblioteca Python Faker para generar un conjunto de transacciones que abarcan un período de 5 meses. Este conjunto de datos contiene 5,4 millones de transacciones distribuidas en 10.000 números de tarjeta de crédito únicos (y falsos) y está intencionalmente desbalanceado para que coincida con la realidad del fraude de tarjetas de crédito (solo el 0,25% de las transacciones son fraudulentas). Variamos el número de transacciones por día por tarjeta, así como los importes de las transacciones. Consulte nuestro repositorio de código para más detalles.

Descripción general de la solución

Queremos que nuestro modelo de detección de fraude clasifique las transacciones con tarjetas de crédito al notar una ráfaga de transacciones recientes que difiere significativamente del patrón de gasto habitual del titular de la tarjeta. Suena bastante simple, pero ¿cómo lo construimos?

El siguiente diagrama muestra nuestra arquitectura general de soluciones. Creemos que este mismo patrón funcionará bien para una variedad de casos de uso de agregación de streaming. A alto nivel, el patrón implica las siguientes cinco piezas. Nos sumergimos en más detalles sobre estos en secciones siguientes:

1. Almacén de funciones: utilizamos Amazon SageMaker Feature Store para proporcionar un repositorio de funciones con escrituras de alto rendimiento y lecturas seguras de baja latencia, utilizando valores de features organizados en varios grupos de entidades.
2. Ingestión por batches: la ingestión de batches toma las transacciones históricas de tarjetas de crédito etiquetadas y crea las características agregadas y los ratios necesarios para formar el modelo de detección de fraude. Utilizamos un trabajo de procesamiento de Amazon SageMaker y el container built-in de Spark para calcular los conteos semanales agregados y los promedios del importe de las transacciones e ingestarlos en el feature store para utilizarlos en la inferencia en línea.
3. Formación e implementación de modelos : este aspecto de nuestra solución es sencillo. Utilizamos Amazon SageMaker para entrenar un modelo utilizando el algoritmo XGBoost integrado en funciones agregadas creadas a partir de transacciones históricas. El modelo se implementa en un endpoint de SageMaker, donde gestiona las solicitudes de detección de fraude en transacciones activas.
4. Ingestión de streaming : una aplicación de Amazon Kinesis Data Analytics calcula las características agregadas de un flujo de transacciones y una función de AWS Lambda actualiza el online feature store.
5. Predicciones de transmisión : por último, realizamos predicciones de fraude en una secuencia de transacciones, utilizando AWS Lambda para extraer funciones agregadas del online feature store. Utilizamos los datos más recientes de funciones para calcular las relaciones de transacción y luego llamar al punto final de detección de fraude.

Feature store

Los modelos ML se basan en features bien diseñados que provienen de una variedad de orígenes de datos, con transformaciones tan simples como un cálculo de media o tan complicadas como una canalización de varios pasos que lleva horas de tiempo de cálculo y codificación compleja. Amazon SageMaker Feature Store permite la reutilización de estas funciones entre equipos y modelos, lo que mejora la productividad de los científicos de datos, acelera el time to market y garantiza la coherencia del modelo.

Cada entidad dentro de SageMaker Feature Store se organiza en una agrupación lógica denominada grupo de entidades. Usted decide qué grupos de entidades necesita para sus modelos. Cada uno puede tener docenas, cientos o incluso miles de características. Los grupos de entidades se administran y escalan de forma independiente, pero todos están disponibles para la búsqueda y descubrimiento en equipos de científicos de datos responsables de muchos modelos de ML independientes y casos de uso.

Los modelos  de ML a menudo requieren features de varios grupos de entidades. Un aspecto clave de un grupo de entidades es la frecuencia con la que sus valores deben actualizarse o insertarse para el entrenamiento o la inferencia posteriores. Algunas entidades se actualizan mensualmente otras semanalmente, y un subconjunto de entidades se debe transmitir al feature store casi en tiempo real. Transmitir todas las actualizaciones de funciones llevaría a una complejidad innecesaria, e incluso podría reducir la calidad de las distribuciones de datos al no darle la oportunidad de eliminar valores atípicos.

En nuestro caso de uso, creamos un grupo de características llamado cc-agg-batch-fg para las características agregadas de tarjetas de crédito actualizadas por batch, y otro llamado cc-agg-fg para funciones de streaming. El grupo de entidades por batch se actualiza todas las noches y proporciona entidades agregadas que miran hacia atrás en una ventana de tiempo de una semana. El nuevo cálculo de agregaciones de una semana en transacciones de streaming no ofrece señales significativas y sería un desperdicio de recursos.

Por el contrario, nuestro grupo de funciones cc-agg-fg debe actualizarse en streaming, ya que ofrece los últimos recuentos de transacciones y los importes medios de transacción mirando hacia atrás en un plazo de 10 minutos. Sin la agregación de streaming, no podríamos detectar el típico patrón de ataque de fraude de una rápida secuencia de compras.

Al aislar los features que se vuelven a calcular cada noche, podemos mejorar el rendimiento de ingestión de nuestras funciones de streaming. La separación nos permite optimizar la ingestión de cada grupo de forma independiente. Al diseñar para sus propios casos de uso, tenga en cuenta que los modelos que requieren entidades de un gran número de grupos de entidades pueden realizar varias consultas al feature store en paralelo para evitar agregar latencia excesiva a un flujo de trabajo de predicción en tiempo real.

Los grupos de features para nuestro caso de uso se ven en el siguiente diagrama.

Cada grupo de entidades debe tener un feature utilizado como identificador de registro (para esta publicación, el número de la tarjeta de crédito). El identificador de registro actúa como clave principal para el grupo de entidades, lo que permite búsquedas rápidas y uniones entre grupos de entidades. También se requiere una entidad de tiempo de evento, que permite al almacén de entidades realizar un seguimiento del historial de valores de entidad a lo largo del tiempo. Esto se vuelve importante cuando se mira hacia atrás el estado de las entidades en un punto específico en el tiempo.

En cada grupo de features, rastreamos el número de transacciones por tarjeta de crédito única y su importe medio de transacción. La única diferencia entre nuestros dos grupos es la ventana de tiempo utilizada para la agregación. Utilizamos una ventana de 10 minutos para la agregación de streaming y una ventana de 1 semana para la agregación batch.

Con Amazon SageMaker Feature Store, tiene la flexibilidad de crear grupos de entidades que estén únicamente offline, solo online o tanto online como offline. Una feature store online proporciona escrituras de alto rendimiento y consultas de baja latencia, ideales para inferencia en línea. Un feature store offline se proporciona mediante Amazon S3, lo que otorga a las empresas un storage altamente escalable, con un historial completo de valores de features, particionado por grupo de entidades. Un offline feature store es ideal para los casos de uso de entrenamiento y predicción batch.

Cuando se habilita un grupo de entidades para que alimente un feature store tanto offline como online, SageMaker sincroniza automáticamente los valores de las entidades a un offline store, añadiendo continuamente los valores más recientes para darle un historial completo de valores a lo largo del tiempo. Otra ventaja de los grupos de features que están tanto en línea como fuera de línea es ayudar a evitar el problema del entrenamiento y el sesgo de inferencia. SageMaker le permite alimentar tanto el entrenamiento como la inferencia con los mismos valores de función transformados, lo que garantiza la coherencia para impulsar predicciones más precisas. El foco en nuestra publicación es demostrar la transmisión de funciones en línea, por lo que implementamos grupos de funciones solo en línea.

Ingestión batch

Para materializar nuestras entidades batch, creamos una canalización de entidades que se ejecuta como un trabajo de preprocesamiento de Amazon SageMaker que corre cada noche. El trabajo tiene dos responsabilidades: producir el conjunto de datos para entrenar nuestro modelo y rellenar el grupo de entidades batch con los valores más actualizados para las entidades agregadas de 1 semana, como se muestra en el siguiente diagrama:

Cada transacción histórica utilizada en el conjunto de entrenamiento se enriquece con características agregadas para la tarjeta de crédito específica involucrada en la transacción. Miramos hacia atrás sobre dos sliding windows separadas: 1 semana atrás, y los 10 minutos anteriores. Las entidades reales utilizadas para entrenar el modelo incluyen las siguientes relaciones de estos valores agregados:

• amt_ratio1 = avg_amt_last_10m/avg_amt_last_1w
• amt_ratio2 = transaction_amount/avg_amt_last_1w
• ratio de cuenta = núm_trans_last_10m/núm_trans_last_1w

Por ejemplo, la tercera relación es el recuento de transacciones de los 10 minutos anteriores dividido por el recuento de transacciones de la última semana. Nuestro modelo de ML puede aprender patrones de actividad normal frente a actividad fraudulenta a partir de estas proporciones, en lugar de depender de recuentos brutos e importes de transacciones. Los patrones de gasto en diferentes tarjetas varían mucho, por lo que las relaciones normalizadas proporcionan una mejor señal al modelo que las cantidades agregadas en sí mismas.

Puede que se pregunte por qué nuestro trabajo batch está calculando features con una retrospección de 10 minutos. ¿No es eso sólo relevante para la inferencia en línea? Necesitamos la ventana de 10 minutos sobre transacciones históricas para crear un conjunto de datos de entrenamiento preciso. Esto es fundamental para garantizar la coherencia con la ventana de transmisión de 10 minutos que se utilizará casi en tiempo real para permitir la inferencia en línea.

El dataset de formación resultante del trabajo de preprocesamiento se puede guardar directamente como CSV para entrenar modelos, o puede ser ingestado masivamente en un grupo de entidades offline que se puede utilizar para otros modelos y por otros equipos de ciencia de datos para abordar una amplia variedad de otros casos de uso. Por ejemplo, podemos crear y rellenar un grupo de entidades llamado cc-transactions-fg. Nuestro trabajo de entrenamiento puede entonces extraer un conjunto de datos específico basado en las necesidades de nuestro modelo, seleccionando intervalos de fechas específicos y un subconjunto de features de interés. Este enfoque permite a varios equipos reutilizar grupos de entidades y mantener un menor número de canalizaciones de funciones, lo que da lugar a importantes ahorros de costos y mejoras de productividad a lo largo del tiempo. Esta notebook de ejemplo muestra el patrón de uso de SageMaker Feature Store como un repositorio central del que los científicos de datos pueden extraer datasets de entrenamiento.

Además de crear un conjunto de datos de entrenamiento, utilizamos la API PutRecord para poner las agregaciones de entidades de 1 semana en el almacén de entidades online todas las noches. El código siguiente muestra cómo colocar un registro en un grupo de entidades online dados valores de entidad específicos, incluidos un identificador de registro y una hora de evento:

record = [{'FeatureName': 'cc_num', 
              'ValueAsString': str(cc_num)},
             {'FeatureName':'avg_amt_last_1w', 
              'ValueAsString': str(avg_amt_last_1w)},
             {'FeatureName':'num_trans_last_1w', 
              'ValueAsString': str(num_trans_last_1w)}]
event_time_feature = {
                 'FeatureName': 'trans_time',
                 'ValueAsString': str(int(round(time.time())))}
record.append(event_time_feature)
response = feature_store_client.put_record(
    FeatureGroupName=’cc-agg-batch-fg’, Record=record)

Los ingenieros de ML a menudo crean una versión separada del código de ingeniería de features online basado en el código original escrito por científicos de datos para entrenamiento de modelos. Esto puede ofrecer el rendimiento deseado, pero es un paso adicional de desarrollo e introduce más posibilidades de descalce entre entrenamiento e inferencia. En nuestro caso de uso, mostramos cómo usar SQL para agregaciones puede permitir que un científico de datos proporcione el mismo código tanto para batch como para streaming.

Ingestión de streaming

Amazon SageMaker Feature Store ofrece consultas de un solo dígito en milisegundos de funciones precalculadas y también puede desempeñar un papel eficaz en soluciones que requieren la ingestión de streaming. Nuestro caso de uso demuestra ambos. La retrospección semanal se maneja como un grupo de entidades precalculado, materializado cada noche como se muestra anteriormente. Ahora vamos a sumergirnos en cómo calculamos las entidades agregadas sobre la marcha durante una ventana de 10 minutos y las ingerimos en la store de entidades para una posterior inferencia en línea.

Puede realizar la ingestión de streaming utilizando Apache Kafka o un flujo de datos de Amazon Kinesis, aplicando transformación y agregación de features y enviando el resultado al feature store. Para los equipos cómodos con Java, Apache Flink es un framework popular para la agregación de streaming. Sin embargo, para los científicos de datos con habilidades de Java limitadas, SQL es una opción mucho más accesible.

En nuestro caso de uso, escuchamos un flujo de datos de Kinesis de transacciones con tarjetas de crédito y usamos una sencilla aplicación Kinesis Data Analytics SQL para crear funciones agregadas. Una función de AWS Lambda ingiere esas características en el feature store para su posterior uso en el momento de la inferencia. Establecer la aplicación SQL es sencillo. Usted elige una secuencia de origen, define una consulta SQL e identifica un destino (para nuestro caso de uso, una función Lambda).

Para producir recuentos agregados y cantidades medias mirando hacia atrás en una ventana de 10 minutos, utilizamos la siguiente consulta SQL en la secuencia de entrada:

SELECT STREAM "cc_num",
               COUNT(*) OVER LAST_10_MINUTES,
               AVG("amount") OVER LAST_10_MINUTES
FROM transactions WINDOW LAST_10_MINUTES AS (PARTITION BY "cc_num" RANGE INTERVAL '10' MINUTE PRECEDING)

En este ejemplo, observe que la última fila tiene un recuento de cuatro transacciones en los últimos 10 minutos desde la tarjeta de crédito que termina en 1248, y un importe medio de transacción correspondiente de 200,00€. La consulta SQL es consistente con la utilizada para impulsar la creación de nuestro conjunto de datos de entrenamiento, lo que ayuda a evitar el sesgo de formación y de inferencia.

A medida que las transacciones se transmiten a la aplicación SQL, la aplicación envía los resultados agregados a nuestra función Lambda, como se muestra en el siguiente diagrama. La función Lambda toma estos features y rellena el grupo de entidades cc-agg-fg .

La actualización de valores de entidad en el almacén de entidades desde Lambda se realiza mediante una simple llamada a la API PutRecord. La siguiente es la pieza central del código de Python para almacenar las features agregadas:

record = [{'FeatureName': 'cc_num', 
           'ValueAsString': str(cc_num)},
          {'FeatureName':'avg_amt_last_10m', 
           'ValueAsString': str(avg_amt_last_10m)},
          {'FeatureName':'num_trans_last_10m', 
           'ValueAsString': str(num_trans_last_10m)},
          {'FeatureName': 'evt_time', 
           'ValueAsString': str(int(round(time.time())))}]
featurestore_runtime.put_record(FeatureGroupName='cc-agg-fg', 
                                Record=record)

Preparamos el registro como una lista de pares de valores, incluyendo la hora actual como hora del evento. La API de SageMaker Feature Store garantiza que este nuevo registro siga el esquema que identificamos cuando creamos el grupo de entidades. Si ya existía un registro para esta clave principal, ahora se sobrescribe en la tienda en línea.

Predicciones de streaming

Ahora que tenemos la ingestión de streaming para mantener el almacén de características actualizado con los valores de features más recientes, veamos cómo hacemos predicciones de fraude.

Creamos una segunda función Lambda que utiliza un flujo de datos de Kinesis como trigger. Para cada nuevo evento de transacción, recuperamos las entidades de tipo batch y streaming de SageMaker Feature Store, calculamos las relaciones e invocamos el extremo del modelo de SageMaker para realizar la predicción como se muestra en el siguiente diagrama.

Utilizamos el siguiente código para consultar valores de entidad a petición del feature store antes de llamar al endpoint del modelo de SageMaker:

featurestore_runtime =  
        boto3.client(service_name='sagemaker-featurestore-runtime')
response = featurestore_runtime.get_record(
		FeatureGroupName=feature_group_name, 
        RecordIdentifierValueAsString=record_identifier_value)

Finalmente, con el vector de entidad de entrada del modelo ensamblado, llamamos al endpoint del modelo para predecir si una transacción de tarjeta de crédito específica es fraudulenta:

sagemaker_runtime =  
    boto3.client(service_name='runtime.sagemaker')
request_body = ','.join(features)
response = sagemaker_runtime.invoke_endpoint(
    EndpointName=ENDPOINT_NAME,
    ContentType='text/csv',
    Body=request_body)
probability = json.loads(response['Body'].read().decode('utf-8'))

En el ejemplo anterior, el modelo regresó con una probabilidad del 98% de que la transacción específica fuera fraudulenta, y fue capaz de aprovechar los features agregados de entrada casi en tiempo real, basados en los 10 minutos más recientes de transacciones en esa tarjeta de crédito.

Viéndolo funcionar de punta a punta

Para demostrar el flujo de trabajo completo completo de nuestra solución, simplemente enviamos transacciones con tarjeta de crédito a nuestro stream de Kinesis. Nuestra agregación automatizada de funciones de streaming funcionará, manteniendo una vista casi en tiempo real de los recuentos y cantidades de transacciones en SageMaker Feature Store, con una sliding window de 10 minutos. Estas variables se combinan con las features agregadas de 1 semana que ya se ingerían en el batch feature store, lo que nos permite hacer predicciones de fraude en cada transacción.

Enviamos una sola transacción desde tres tarjetas de crédito diferentes. Luego simulamos un ataque de fraude a una cuarta tarjeta de crédito enviando muchas transacciones consecutivas en segundos. La salida de nuestra función Lambda se muestra a continuación. Como era de esperar, las tres primeras transacciones puntuales se pronostican como NO FRAUDE. De las 10 transacciones fraudulentas, la primera se pronostica como NOT FRAUDE, y el resto se identifican correctamente como FRAUDE. Observe cómo las funciones agregadas se mantienen actualizadas, lo que ayuda a impulsar predicciones más precisas.

Conclusión

Hemos demostrado cómo Amazon SageMaker Feature Store puede desempeñar un papel clave en la arquitectura de la solución para flujos de trabajo operativos críticos que necesitan agregación de streaming e inferencia de baja latencia. Con un almacén de entidades preparado para la empresa, puede utilizar tanto la ingesta por batch como la ingesta de streaming para alimentar grupos de entidades y acceder a valores de entidades bajo demanda para realizar predicciones en línea para obtener un valor comercial significativo. Las funciones de ML ahora se pueden compartir a escala entre muchos equipos de científicos de datos y miles de modelos ML, lo que mejora la consistencia de los datos, la precisión del modelo y la productividad de los científicos de datos. Amazon SageMaker Feature Store ya está disponible y puede probar este ejemplo completo. Cuéntenos lo que piensa.

Este artículo fue traducido del Blog de AWS en Inglés

Sobre los Autores

Paul Hargis es especialista en AI/ML, arquitecto de soluciones de Amazon Web Services (AWS). Antes de este cargo, fue arquitecto principal de Amazon Exports and Expansions, ayudando a amazon.com a mejorar la experiencia de los compradores internacionales. A Paul le gusta ayudar a los clientes a expandir sus iniciativas de aprendizaje automático para resolver problemas del mundo real. Está casado y tiene una hija que corre en los equipos de Cross Country y Track en la escuela secundaria.

Megan Leoni es arquitecta especializada en soluciones de AI/ML para AWS que ayuda a clientes de toda Europa, Oriente Medio y África a diseñar e implementar las soluciones ML. Antes de unirse a AWS, Megan trabajó como científica de datos creando e implementando modelos de detección de fraude en tiempo real.

Mark Roy es un arquitecto principal de aprendizaje automático de AWS, que ayuda a los clientes de AWS a diseñar y crear soluciones AI/ML. El trabajo de Mark cubre una amplia gama de casos de uso de ML, con un interés principal en la visión por computadora, el aprendizaje profundo y el escalado de ML en toda la empresa. Ha ayudado a empresas en muchas industrias, incluyendo Seguros, Servicios Financieros, Medios y Entretenimiento, Salud, Servicios Públicos y Manufactura. Mark posee 6 certificaciones de AWS, incluida la certificación ML Specialty Certification. Antes de unirse a AWS, Mark fue arquitecto, desarrollador y líder tecnológico durante más de 25 años, incluidos 19 años en servicios financieros.

Arunprasath Shankar es un arquitecto especializado en soluciones de inteligencia artificial y aprendizaje automático (AI/ML) con AWS, que ayuda a clientes globales a escalar sus soluciones de IA de manera eficaz y eficiente en la nube. En su tiempo libre, Arun disfruta viendo películas de ciencia ficción y escuchar música clásica.

Revisora

María Gaska es arquitecta de soluciones en AWS desde hace casi dos años. En su rol, ayuda a los clientes tanto a determinar la mejor arquitectura para sus distintas aplicaciones como a encontrar los mejores algoritmos para resolver problemas de Machine Learning e IA.

Antes de AWS, trabajó como desarrolladora de modelos de deep learning en un startup enfocado en NLP y chatbots y también como profesora full time en una coding school a cargo de un curso de data science.