Cómo hacer que sus científicos e ingenieros de datos remen en la misma dirección


A medida que los modelos de aprendizaje automático evolucionan lentamente, los científicos de datos y los ingenieros de datos necesitan trabajar juntos, pero a menudo trabajan para diferentes propósitos. Por ridículo que parezca, he visto que los modelos tardan meses en llegar a la producción porque los científicos de datos esperaban a que los ingenieros de datos construyeran sistemas de producción que coincidieran con el modelo mientras que los ingenieros de datos esperaban que los científicos de datos los modelaran. crear trabajado con los sistemas de producción.

Un artículo anterior de VentureBeat informó que el 87% de los proyectos de aprendizaje automático no llegan a producción, y una combinación de problemas de datos y falta de colaboración fueron factores importantes. Por el lado de la colaboración, la tensión entre los ingenieros de datos y los científicos de datos, y cómo trabajan juntos, puede crear frustraciones y retrasos innecesarios. Si bien la alineación del equipo y el desarrollo de la empatía pueden aliviar estas tensiones, la adopción de algunas tecnologías MLOps en evolución puede ayudar a aliviar los problemas en la raíz.

Definición del problema

Antes de abordar las soluciones, queremos explicar el problema con más detalle. Los científicos e ingenieros (de datos y otros) siempre han sido como perros y gatos, aceite y agua. Una simple búsqueda en la web de "científicos versus ingenieros" lo lleva a un largo debate sobre qué grupo es más prestigioso. Los ingenieros tienen la tarea de diseño, operación y mantenimiento, por lo que se enfocan en los sistemas más simples, eficientes y confiables posibles. Los científicos, por otro lado, deben hacer todo lo posible para crear los modelos más precisos para que puedan acceder a todos los datos y manipularlos de formas únicas y sofisticadas.

En lugar de centrarme en las diferencias, me resulta mucho más productivo reconocer que son inmensamente valiosas y pensar en cómo podemos aprovechar al máximo cada uno de sus talentos. Al centrarse en las cosas que unen a los científicos de datos y los ingenieros de datos, un compromiso con la información oportuna y de alta calidad y los sistemas bien diseñados, ambas partes pueden fomentar un entorno más colaborativo. Al comprender las debilidades de cada uno, los dos equipos pueden desarrollar empatía y comprensión para facilitar la colaboración. También hay nuevas herramientas y sistemas que pueden ayudar a cerrar la brecha entre estos dos campamentos y ayudarlos a encontrarse más fácilmente en el medio.

MLOps

MLOps es un campo emergente que aplica las ideas y principios de las prácticas de DevOps al ecosistema de ciencia de datos y aprendizaje automático de EE. UU. Alivia a los ingenieros de datos de crearlos y mantenerlos, y ofrece a los científicos de datos flexibilidad y libertad. Esta es una solución beneficiosa para todos. Echemos un vistazo a algunos problemas comunes y las herramientas que surgen para resolverlos de manera más efectiva.

Orquestación de modelos. El primer obstáculo importante al intentar poner un modelo en producción es la implementación: ¿dónde se fabrica, cómo se aloja y cómo se gestiona? Este es en gran parte un problema técnico. Entonces, cuando tiene un equipo de científicos de datos e ingenieros de datos, generalmente depende de los ingenieros de datos.

Este sistema toma semanas, si no meses, para construir – tiempo que los ingenieros de ML o los datos podrían haber dedicado a mejorar los flujos de datos o mejorar los modelos. Las plataformas de orquestación de modelos estandarizan los marcos para la entrega de modelos y facilitan mucho este paso. Si bien empresas como Facebook pueden invertir recursos en plataformas como FBLearner para gestionar la orquestación de modelos, es menos factible para empresas más pequeñas o emergentes. Afortunadamente, han surgido sistemas de código abierto para manejar el proceso, a saber, MLFlow y KubeFlow. Ambos sistemas utilizan la contenedorización para administrar el lado de la infraestructura de la implementación del modelo.

tiendas de características. El segundo gran obstáculo para llevar un modelo del laboratorio a producción son los datos. A menudo, los modelos se entrenan con datos históricos que se almacenan en un almacén de datos pero se consultan con datos de una base de datos de producción. Las discrepancias entre estos sistemas hacen que los modelos funcionen mal o no funcionen en absoluto y, a menudo, requieren un desarrollo de datos significativo para volver a implementar cosas en la base de datos de producción.

Personalmente, he pasado semanas desarrollando y creando prototipos de funciones poderosas que nunca llegaron a producción porque los ingenieros de datos no tenían el ancho de banda para producirlas. Los almacenes de características, o almacenes de datos diseñados específicamente para ayudar en el entrenamiento y la producción de modelos de aprendizaje automático, intentan abordar este problema asegurándose de que los datos y las características creadas en el laboratorio estén inmediatamente listos para la producción. Los científicos de datos tienen la tranquilidad de que sus modelos se están construyendo y los ingenieros de datos no tienen que preocuparse de que dos sistemas diferentes estén en perfecta armonía. Empresas más grandes como Uber y Airbnb han construido sus propias tiendas de artículos (Michelangelo y ZipLine, respectivamente), pero han surgido proveedores que venden soluciones listas para usar. Logical Clocks, por ejemplo, ofrece una tienda de características para su plataforma Hopsworks. Y mi equipo en Kaskada está construyendo un almacén de características para datos basados ​​en eventos.

DataOps. No hay experiencia sobre cómo cambiarlo a altas horas de la noche porque su modelo se comporta de manera extraña. Después de revisar brevemente el Servicio de modelos, llega a la conclusión inevitable: algo ha cambiado con los datos.

He tenido variaciones en la siguiente conversación más veces de las que me gustaría admitir:

  • Ingeniero de datos: “Su modelo arroja errores. ¿Por qué está roto? “
  • Científico de datos:“ No es que el flujo de datos esté roto y necesite ser reparado. "
  • Ingeniero de datos:" Bien, avíseme qué flujo de datos y puedo solucionarlo. "
  • Científico de datos:" No sé cuál es el problema, solo que hay uno ".

Encontrar el problema es como encontrar una aguja en un pajar. Afortunadamente, se están introduciendo nuevos marcos y herramientas que pueden configurar el monitoreo y la prueba de datos y fuentes de datos y ahorrar un tiempo valioso. Great Expectations es una de esas nuevas herramientas para mejorar la creación, documentación y monitoreo de bases de datos. Databand.ai es otra compañía que ingresa al espacio de monitoreo de la canalización de datos. De hecho, la compañía tiene una excelente publicación de blog aquí que analiza más de cerca por qué las soluciones tradicionales de monitoreo de tuberías para la ingeniería de datos y la ciencia de datos no funcionan.

Conclusión

Mediante el uso de herramientas para reducir la complejidad de las consultas y aumentando la empatía y la confianza entre los científicos de datos y los ingenieros de datos. Se puede potenciar a los científicos de datos sin imponer una carga excesiva a los ingenieros de datos. Ambos equipos pueden concentrarse en lo que hacen mejor y en lo que disfrutan de su trabajo en lugar de luchar entre ellos. Estas herramientas pueden ayudar a transformar una relación combativa en una relación colaborativa en la que todos sean felices.

Max Boyd es director de ciencia de datos en Kaskada. Ha construido e implementado modelos como científico de datos e ingeniero de aprendizaje automático en varias empresas emergentes de tecnología en el área de Seattle en los sectores de recursos humanos, finanzas y bienes raíces.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *