By eugenio yan, Ciencias aplicadas en Amazon, Escritor y orador.

Recientemente, me encontré con un hilo de Reddit sobre los diferentes roles en la ciencia de datos y el aprendizaje automático: científico de datos, científico de decisiones, científico de datos de productos, ingeniero de datos, ingeniero de aprendizaje automático, ingeniero de herramientas de aprendizaje automático, arquitecto de inteligencia artificial, etc.

Encontré este preocupante. Es difícil ser eficaz cuando el proceso de ciencia de datos (elaboración de problemas, ingeniería de datos, aprendizaje automático, implementación / mantenimiento) se divide entre diferentes personas. Conduce a una sobrecarga de coordinación, a la difusión de responsabilidades y a la falta de una visión general.

EN MI HUMILDE OPINIÓN, Creo que los científicos de datos pueden ser más efectivos siendo de extremo a extremo.. Aquí, discutiré el beneficios y contra argumentos, cómo se vuelven de un extremo a otro, y las experiencias de Stitch Fix y Netflix.

Desde el principio (identifica el problema) hasta el final (resuélvelo)

Puede que te hayas encontrado con algo similar etiquetas y definiciones, como:

• Generalista: Centrado en roles (PM, BA, DE, DS, MLE); alguna connotación negativa
• Completa pila: Centrado en la tecnología (Spark, Torch, Docker); popularizado por desarrolladores full-stack
• Unicornio: Centrado en la mitología; creía que no existía

Encuentro que estas definiciones son más prescriptivas de lo que prefiero. En cambio, tengo una definición simple (y pragmática): un científico de datos de un extremo a otro puede identificar y resolver problemas con datos para generar valor. Para lograr el objetivo, usarán tantos (o tan pequeños) sombreros como sea necesario. También aprenderán y aplicarán cualquier tecnología, metodología y proceso que funcione. A lo largo del proceso, hacen preguntas como:

• ¿Cuál es el problema? ¿Por qué es importante?
• ¿Podemos solucionarlo? ¿Cómo deberíamos solucionarlo?
• Cual es el valor estimado? ¿Cuál fue el valor real?

Procesos de ciencia de datos

Otra forma de definir la ciencia de datos de un extremo a otro es a través de procesos. Estos procesos suelen ser complejos y los he dejado fuera de la discusión principal. No obstante, aquí hay algunos en caso de que sienta curiosidad:

• CRISP-DM: Proceso estándar entre industrias para la minería de datos (1997).
• KDD: Descubrimiento de conocimiento en bases de datos.
• TDSP: Team Data Science Process, propuesto por Microsoft en 2018.
• DSLP: Proceso del ciclo de vida de la ciencia de datos.

No se preocupe si estos procesos parecen pesados ​​y abrumadores. No tiene que adoptarlos al por mayor: comience poco a poco, mantenga lo que funcione y adapte el resto.

.

Más contexto, iteración más rápida, mayor satisfacción

Para la mayoría de los roles de ciencia de datos, ser más integral mejora su capacidad para generar un impacto significativo. (No obstante, hay  También soy miembro del cuerpo docente de World Extreme Medicine (WEM) y embajadora europea de igualdad para The Transformational Travel Council (TTC). En mi tiempo libre, soy una incansable aventurera, escaladora, patrona de día, buceadora y defensora de la igualdad de género en el deporte y la aventura. En XNUMX, fundé Almas Libres, una ONG nacida para involucrar, educar y empoderar a mujeres y niñas a través del deporte urbano, la cultura y la tecnología. que se centran en el aprendizaje automático).

Trabajar de un extremo a otro proporciona un mayor contexto. Si bien los roles especializados pueden aumentar la eficiencia, reduce el contexto (para el científico de datos) y conduce a soluciones subóptimas.

El truco para olvidar el panorama general es mirar todo de cerca. - Chuck Palahniuk

Es difícil diseñar una solución holística sin el contexto completo del problema anterior. Digamos que la conversión ha disminuido y un PM genera una solicitud para mejorar nuestro algoritmo de búsqueda. Sin embargo, ¿qué está causando la disminución en primer lugar? Puede haber varias causas:

• Producto: ¿Los productos fraudulentos o de mala calidad reducen la confianza del cliente?
• Canalizaciones de datos: ¿se ha visto comprometida la calidad de los datos o hay retrasos / interrupciones?
• Actualización del modelo: ¿El modelo no se actualiza con regularidad o correctamente?

La mayoría de las veces, el problema y la solución se encuentran afuera del aprendizaje automático. Una solucion para mejorar el algoritmo perdería la causa raíz.

Del mismo modo, es arriesgado desarrollar una solución sin ser consciente de las limitaciones de ingeniería y productos posteriores. No tiene sentido:

• Construyendo un recomendador en tiempo casi real si la infraestructura y el ingeniero no pueden soportarlo
• Construyendo un recomendador de scroll infinito si no encaja en nuestro producto y aplicación

Al trabajar de punta a punta, los científicos de datos tendrán el contexto completo para identificar los problemas correctos y desarrollar soluciones utilizables. También puede conducir a ideas innovadoras que los especialistas, con su contexto limitado, podrían pasar por alto. En general, aumenta la capacidad de generar valor.

Se reducen los gastos generales de comunicación y coordinación. Con múltiples roles viene una sobrecarga adicional. Veamos un ejemplo de un ingeniero de datos (DE) que limpia los datos y crea características, un científico de datos (DS) que analiza los datos y entrena el modelo, y un ingeniero de aprendizaje automático (MLE) que lo implementa y mantiene.

Lo que un programador puede hacer en un mes, dos programadores pueden hacerlo en dos meses. - Frederick P. Brooks

El DE y el DS necesitan Comunicarse sobre qué datos están (y no están) disponibles, cómo deben limpiarse (por ejemplo, valores atípicos, normalización) y qué características deben crearse. De manera similar, DS y MLE deben analizar cómo implementar, monitorear y mantener el modelo, así como con qué frecuencia debe actualizarse. Cuando surjan problemas, necesitaremos tres personas en la sala (probablemente con un PM) para clasificar la causa raíz y los siguientes pasos para solucionarlo.

También conduce a una coordinación adicional, donde los cronogramas deben alinearse a medida que se ejecuta el trabajo y se transmite en un enfoque secuencial. Si DS quiere experimentar con datos y funciones adicionales, tendremos que esperar a que DE ingiera los datos y cree las funciones. Si un nuevo modelo está listo para las pruebas A / B, tendremos que esperar a que el MLE (lo convierta en código de producción) e implementarlo.

Si bien el trabajo de desarrollo real puede llevar días, la comunicación de ida y vuelta y la coordinación pueden llevar semanas, si no más. Con los científicos de datos de un extremo a otro, podemos minimizar esta sobrecarga y evitar que los detalles técnicos se pierdan en la traducción.

(Pero, ¿puede un DS de un extremo a otro realmente hacer todo eso? Creo que sí. Si bien el DS puede no ser tan competente en algunas tareas como un DE o MLE, podrá realizar la mayoría de las tareas de manera eficaz. Si es necesario ayuda con el escalado o el endurecimiento, siempre pueden obtener ayuda de DE y MLE especializados).

El costo de la comunicación y la coordinación

Richard Hackman, psicólogo de Harvard, demostró que el número de relaciones en un equipo es N (N-1) / 2, donde N es el número de personas. Esto conduce a un crecimiento exponencial de los enlaces, donde:

• Un equipo de puesta en marcha de 7 tiene 21 enlaces para mantener
• Un grupo de 21 (es decir, tres equipos iniciales) tiene 210 enlaces
• Un grupo de 63 tiene casi 2,000 enlaces.

En nuestro ejemplo simple, solo teníamos tres roles (es decir, seis enlaces). Pero como se incluye un PM, BA y miembros adicionales, esto conduce a un crecimiento más grande que lineal en los costos de comunicación y coordinación. Por lo tanto, mientras que cada miembro adicional aumenta la productividad total del equipo, el aumento de los gastos generales significa que la productividad crece a un ritmo decreciente. (De Amazon equipos de dos pizzas son una posible solución a esto.)

Aumenta la tasa de iteración y aprendizaje. Con mayor contexto y menos gastos generales, ahora podemos iterar, fallar (leer: aprender) y entregar valor más rápido.

Esto es especialmente importante para desarrollar datos y productos algorítmicos. A diferencia de la ingeniería de software (un oficio mucho más maduro), no podemos hacer todo el aprendizaje y el diseño antes de comenzar a construir; nuestros planos, arquitecturas y patrones de diseño no están tan desarrollados. Por lo tanto, la iteración rápida es esencial para el ciclo de diseño, construcción y aprendizaje.

Hay una mayor propiedad y responsabilidad. Tener el proceso de ciencia de datos dividido entre varias personas puede conducir a la difusión de la responsabilidad y, lo que es peor, a la holgazanería social.

Un anti-patrón común observado es "tirar sobre la pared. " Por ejemplo, el DE crea características y lanza una tabla de base de datos al DS, el DS entrena un modelo y envía el código R al MLE, y el MLE lo traduce a Java a producción.

Si las cosas se pierden durante la traducción o si los resultados son inesperados, ¿quién es el responsable? Con una sólida cultura de propiedad, todos dan un paso al frente para contribuir en sus respectivos roles. Pero sin él, el trabajo puede degenerar en cubrirse el culo y señalar con el dedo mientras el problema persiste y los clientes y la empresa sufren.

Hacer que el científico de datos de un extremo a otro asuma la propiedad y la responsabilidad de todo el proceso puede mitigar esto. Deben estar capacitados para actuar de principio a fin, desde el problema y la entrada del cliente (es decir, datos brutos) hasta la salida (es decir, el modelo implementado) y los resultados medibles.

Difusión de la responsabilidad y holgazanería social

Difusión de la responsabilidad: Es menos probable que asumamos la responsabilidad y actuemos cuando hay otros presentes. Los individuos sienten menos responsabilidad y urgencia de ayudar si sabemos que hay otros que también están observando la situación.

Una forma de esto es el Efecto del espectador, Donde Gatito Genovese fue apuñalada fuera del edificio de apartamentos al otro lado de la calle de donde vivía. Si bien hubo 38 testigos que vieron o escucharon el ataque, ninguno llamó a la policía ni la ayudó.

Holgazanería social: Hacemos menos esfuerzo cuando trabajamos en grupo que cuando trabajamos solos. En la década de 1890, Ringelmann hizo que las personas tiraran de cuerdas tanto por separado como en grupos. Midió la fuerza con la que tiraban y descubrió que los miembros de un grupo tendían a hacer menos esfuerzo para tirar de una cuerda que los individuos solos.

Para (algunos) científicos de datos, puede conducir a una mayor motivación y satisfacción laboral., cual es estrechamente ligada a la autonomía, el dominio y el propósito.

• Autonomía: Al poder resolver problemas de forma independiente. En lugar de esperar y depender de otros, los científicos de datos de un extremo a otro pueden identificar y definir el problema, construir sus propias canalizaciones de datos e implementar y validar una solución.
• Maestría: En el problema, solución, resultado de principio a fin. También pueden recoger el dominio y la tecnología según sea necesario.
• Propósito: Al estar profundamente involucrados en todo el proceso, tienen una conexión más directa con el trabajo y los resultados, lo que lleva a un mayor sentido de propósito.

Pero también necesitamos expertos especializados

Sin embargo, ser de punta a punta no es para todos (y para todos los equipos), por razones como:

Querer especializarse en el aprendizaje automático, o tal vez en un nicho específico en el aprendizaje automático, como la generación de texto neuronal (lea: Imprimación GPT-3). Si bien ser de un extremo a otro es valioso, también necesitamos expertos de clase mundial en investigación e industria que superen los límites. Gran parte de lo que tenemos en ML provino de la academia y de los esfuerzos de investigación pura.

Nadie alcanza la grandeza convirtiéndose en generalista. No perfeccionas una habilidad diluyendo tu atención en su desarrollo. La única forma de pasar al siguiente nivel es concentrarse. - John C. Maxwell

Falta de interés. No todo el mundo está dispuesto a interactuar con clientes y empresas para definir el problema, recopilar requisitos y redactar documentos de diseño. Del mismo modo, no todo el mundo está interesado en la ingeniería de software, el código de producción, las pruebas unitarias y las canalizaciones de CI / CD.

Trabajando en grandes sistemas de alto apalancamiento donde la mejora del 0.01% tiene un impacto gigante. Por ejemplo, comercio algorítmico y publicidad. En tales situaciones, se requiere una hiper-especialización para lograr esas mejoras.

Otros también han argumentado por qué los científicos de datos deberían especializarse (y no ser de un extremo a otro). Aquí hay algunos artículos para proporcionar equilibrio y contraargumentos:

• Por qué no debería ser un generalista de ciencia de datos
• Por qué todos los científicos de datos deben especializarse
• ¿Quiere un trabajo en ciencia de datos? He aquí por qué debería especializarse

La mejor manera de aprenderlo es aprendiendo haciendo

Si todavía está interesado en volverse más integral, ahora discutiremos cómo hacerlo. Antes de eso, sin entrar en tecnologías específicas, estos son los grupos de habilidades que los científicos de datos de extremo a extremo usan comúnmente:

• Producto: comprender los problemas del cliente, definir y priorizar los requisitos
• Comunicación: facilite entre equipos, obtenga aceptación, redacte documentos, comparta resultados
• Ingeniería de datos: mueva y transforme datos del punto A al B
• Análisis de datos: comprender y visualizar datos, pruebas A / B e inferencia
• Aprendizaje automático: lo habitual más experimentación, implementación y métricas
• Ingeniería de software: prácticas de código de producción que incluyen pruebas unitarias, documentos, registro
• Dev Ops: Containerización básica y competencia en la nube, herramientas de creación y automatización

(Esta lista no es obligatoria ni exhaustiva. La mayoría de los proyectos no los requieren todos).

Aquí hay cuatro formas en las que puede acercarse a ser un científico de datos de un extremo a otro:

Estudie los libros y cursos adecuados. (Está bien, esto es no aprender haciendo, pero todos tenemos que empezar por algún lado). Me centraría en cursos que cubran conocimiento tácito en lugar de herramientas específicas. Si bien no me he encontrado con este tipo de materiales, he escuchado buenas críticas sobre Aprendizaje profundo de pila completa.

Haz tus propios proyectos de principio a fin para conocer de primera mano todo el proceso. A riesgo de simplificarlo demasiado, aquí hay algunos pasos que tomaría con sus habilidades asociadas.

Escucho y olvido. Veo y recuerdo. Lo hago y lo entiendo. - Confucio

Empiece por identificar un problema para resolver y determinar la métrica de éxito (PRODUCTO). Entonces, encuentra algunos datos en bruto (es decir, no datos de competencia de Kaggle); esto le permite limpiar y preparar los datos y crear características (ingeniería de datos). A continuación, pruebe varios modelos de aprendizaje automático, examine las curvas de aprendizaje, las distribuciones de errores y las métricas de evaluación (Ciencia de los datos).

Evalúe el rendimiento de cada modelo (p. Ej., Latencia de consulta, huella de memoria) antes de elegir uno y escribir un clase de inferencia a su alrededor para la producciónIngeniería de software). (Es posible que también desee crear una interfaz de usuario simple). Luego, colóquelo en contenedores e impleméntelo en línea para que otros lo usen a través de su proveedor de nube preferido (operaciones de desarrollo).

Una vez hecho esto, haga un esfuerzo adicional para compartir su trabajo. Puedes escribir un artículo para tu sitio o hablar sobre él en una reunión (la comunicación). Muestre lo que encontró en los datos mediante gráficos y tablas significativas (análisis de los datos). Comparta su trabajo en GitHub. Aprendiendo y trabajar en público es una excelente manera de obtener comentarios y encontrar colaboradores potenciales.

Sea voluntario a través de grupos como Tipo de datos. DataKind trabaja con organizaciones sociales (por ejemplo, ONG) y profesionales de datos para abordar problemas humanitarios. Al colaborar con estas ONG, tiene la oportunidad de trabajar como parte de un equipo para abordar problemas reales con datos reales (realmente confusos).

Si bien a los voluntarios se les pueden asignar roles específicos (por ejemplo, PM, DS), siempre puede acompañarlos y observar. Verá (y aprenderá) cómo los PM se relacionan con las ONG para enmarcar el problema, definir soluciones y organizar el equipo en torno a él. Aprenderá de otros voluntarios cómo trabajar con datos para desarrollar soluciones de trabajo. Voluntariado en hackathon inmersiones de datos y a largo plazo Corporación de datos es una excelente manera de contribuir al proceso de ciencia de datos de principio a fin.

Únase a un equipo similar a una startup. Nota: Un equipo similar a una startup no es sinónimo de una startup. Hay grandes organizaciones que dirigen equipos de manera similar a una startup (por ejemplo, equipos de dos pizzas) y startups formadas por especialistas. Encuentre un equipo esbelto en el que se sienta animado y tenga la oportunidad de trabajar de principio a fin.

De un extremo a otro en Stitch Fix y Netflix

Eric Colson de Stitch Fix fue inicialmente "atraído a una división del trabajo basada en funciones por la atracción de eficiencias de proceso" (es decir, la fábrica de pines de ciencia de datos). Pero más allá del ensayo y error, descubrió que los científicos de datos de un extremo a otro eran más efectivos. Ahora, en lugar de organizar equipos de datos para especialización y productividad, Stitch Fix los organiza para aprender y desarrollar nuevos datos y productos algorítmicos.

El objetivo de la ciencia de datos no es ejecutar. Más bien, el objetivo es aprender y desarrollar nuevas capacidades comerciales. … No hay planos; estas son nuevas capacidades con incertidumbre inherente. … Todos los elementos que necesitará deben aprenderse mediante experimentación, ensayo y error e iteración. - Eric Colson

Sugiere que los roles de la ciencia de datos deberían hacerse más generales, con amplias responsabilidades agnósticas a la función técnica y optimizadas para el aprendizaje. Por lo tanto, su equipo contrata y hace crecer a generalistas que pueden conceptualizar, modelar, implementar y medir. Por supuesto, esto depende de una plataforma de datos sólida que abstraiga las complejidades de la configuración de infraestructura, el procesamiento distribuido, el monitoreo, la conmutación por error automatizada, etc.

Tener científicos de datos de extremo a extremo mejoró las capacidades de aprendizaje e innovación de Stitch Fix, permitiéndoles descubrir y desarrollar más capacidades comerciales (en relación con un equipo de especialistas).

Netflix Edge Engineering inicialmente tenía roles especializados. Sin embargo, esto generó ineficiencias en todo el ciclo de vida del producto. Las versiones de código tomaron más tiempo (semanas en lugar de días), los problemas de implementación demoraron más en detectar y resolver, y los problemas de producción requirieron múltiples comunicaciones de ida y vuelta.

En el extremo, cada área de función / producto es propiedad de 7 personas (fuente).

Para abordar esto, experimentaron con Desarrolladores de ciclo completo que estaban capacitados para trabajar durante todo el ciclo de vida del software. Esto requirió un cambio de mentalidad: en lugar de solo considerar el diseño y el desarrollo, los desarrolladores también tuvieron que considerar la implementación y la confiabilidad.

En lugar de múltiples roles y personas, ahora tenemos el ciclo completo de desarrollo (fuente).

Para respaldar a los desarrolladores de ciclo completo, los equipos centralizados crearon herramientas para automatizar y simplificar los procesos de desarrollo comunes (por ejemplo, construir e implementar canalizaciones, monitoreo, reversiones administradas). Dichas herramientas son reutilizables en múltiples equipos, actúan como un multiplicador de fuerza y ​​ayudaron a los desarrolladores a ser efectivos durante todo el ciclo.

Con el enfoque de desarrollador de ciclo completo, Edge Engineering pudo iterar más rápido (en lugar de coordinarse entre equipos), con implementaciones más rápidas y rutinarias.

¿Funcionó para mí? Aquí están algunos ejemplos

En IBM, estaba en un equipo que creó recomendaciones de trabajo para el personal. Ejecutar toda la tubería llevó mucho tiempo. Pensé que podríamos reducir a la mitad el tiempo moviendo la preparación de datos y las canalizaciones de ingeniería de características a la base de datos. Pero el tipo de la base de datos no tuvo tiempo de probar esto. Siendo impaciente, ejecuté algunos puntos de referencia y reduje el tiempo de ejecución general en un 90%. Esto nos permitió experimentar 10 veces más rápido y ahorrar en costos de computación en producción.

Mientras construía el sistema de clasificación de Lazada, encontré que Spark era necesario para las canalizaciones de datos (debido al gran volumen de datos). Sin embargo, nuestro clúster solo admitía la API de Scala, con la que no estaba familiarizado. No queriendo esperar (por el soporte de ingeniería de datos), elegí la ruta más rápida, pero dolorosa, de averiguar Scala Spark y escribir las canalizaciones yo mismo. Esto probablemente redujo a la mitad el tiempo de desarrollo y me dio una mejor comprensión de los datos para construir un mejor modelo.

Después de una prueba A / B exitosa, descubrimos que las partes interesadas del negocio no confiaban en el modelo. Como resultado, estaban seleccionando manualmente los mejores productos para mostrar, disminuyendo las métricas en línea (por ejemplo, CTR, conversión). Para comprender más, hice viajes a nuestros mercados (por ejemplo, Indonesia, Vietnam). A través de la educación mutua, pudimos abordar sus preocupaciones y reducir la cantidad de sobrescritura manual y cosechar los beneficios.

En los ejemplos anteriores, salir del ámbito de trabajo habitual de DS y ML ayudó a ofrecer más valor, más rápido. En el último ejemplo, fue necesario desbloquear nuestros esfuerzos de ciencia de datos.

Pruébalo

Es posible que ahora no sea de un extremo a otro. Está bien, pocas personas lo están. No obstante, considere sus beneficios y vaya más cerca de él.

¿Qué aspectos mejorarían de manera desproporcionada su capacidad de desempeño como científico de datos? ¿Mayor compromiso con los clientes y las partes interesadas para diseñar soluciones más holísticas e innovadoras? ¿Crea y organiza sus propias canalizaciones de datos? ¿Mayor conocimiento de las limitaciones de ingeniería y productos para una integración e implementación más rápidas?

Visión impopular: los científicos de datos deberían ser más integrales.

Si bien esto está mal visto (¡demasiado generalista!), He visto que conduce a más contexto, iteraciones más rápidas, mayor innovación, más valor, más rápido.

Más detalles y la experiencia de Stitch Fix y Netflix 👇 https://t.co/aOBjuBSsSz

- Eugene Yan (@eugeneyan) 12 de agosto de 2020

Original. Publicado de nuevo con permiso.

Bio: Eugenio Yan (@eugeneyan) trabaja en la intersección de los datos del consumidor y la tecnología para crear sistemas de aprendizaje automático que ayuden a los clientes. Eugene también escribe sobre cómo ser eficaz en la ciencia de datos, el aprendizaje y la carrera. Actualmente, Eugene es un científico aplicado en Amazon que ayuda a los usuarios a leer más y sacar más provecho de la lectura.

Relacionado:

• ¿Qué se necesita para ser un científico de datos exitoso?
• Esto es lo que he aprendido en 2 años como científico de datos
• Ingeniero de Aprendizaje Automático vs Científico de Datos (¿Se acabó la ciencia de datos?)