Cambio de turno en la fábrica de robots – O’Reilly

¿Cuál dirías que es el trabajo de un desarrollador de software? Un laico, un desarrollador de nivel de entrada o incluso alguien que contrata a desarrolladores le dirá que el trabajo es para… bueno… escribir software. Bastante simple.

Un practicante experimentado le dirá algo muy diferente. Dirían que el trabajo implica escribiendo algún software, seguro. Pero en el fondo se trata de la propósito de software Averiguar qué tipo de problemas son susceptibles de automatización a través del código. Saber qué construir y, a veces, qué no construir porque no proporcionará valor.

Incluso pueden resumirlo así: “mi trabajo es detectar for() bucles y if/then declaraciones en la naturaleza.”

Afortunadamente, aprendí esto al principio de mi carrera, en un momento en que todavía podía referirme a mí mismo como desarrollador de software. Las empresas crean o compran software para automatizar el trabajo humano, lo que les permite eliminar trabajos existentes o ayudar a los equipos a lograr más. Por lo tanto, le corresponde a un desarrollador de software detectar qué partes de la actividad humana se pueden automatizar adecuadamente a través del código y luego construir eso.

Esta mentalidad me ha seguido en mi trabajo en ML/AI. Porque si las empresas usan código para automatizar las reglas comerciales, usan ML/AI para automatizar decisiones.

Dado eso, ¿cuál diría que es el trabajo de un científico de datos (o ingeniero de ML, o cualquier otro título similar)?

Compartiré mi respuesta en un momento. Pero primero, hablemos del flujo de trabajo típico de ML.

La construcción de modelos

Una tarea común para un científico de datos es construir un modelo predictivo. Ya conoce el ejercicio: extraiga algunos datos, divídalos en características, introdúzcalos en uno de los diversos algoritmos de scikit-learn. Sin embargo, la primera ronda nunca produce un gran resultado. (Si es así, sospecha que la variable que está tratando de predecir se ha mezclado con las variables utilizadas para predecirla. Esto es lo que se conoce como «fuga de características».) Así que ahora modifica los parámetros del clasificador y vuelve a intentarlo. en busca de un mejor rendimiento. Intentará esto con algunos otros algoritmos y sus respectivos parámetros de ajuste, tal vez incluso rompa TensorFlow para construir una red neuronal personalizada en el camino, y el modelo ganador será el que se dirija a la producción.

Se podría decir que el resultado de este ejercicio es un modelo predictivo de rendimiento. Eso es cierto. Pero al igual que la pregunta sobre el papel del desarrollador de software, hay más para ver aquí.

Colectivamente, sus intentos le enseñan sobre sus datos y su relación con el problema que está tratando de resolver. Piense en lo que le dicen los resultados del modelo: «Tal vez un bosque aleatorio no sea la mejor herramienta para dividir estos datos, pero XLNet sí lo es». Si ninguno de sus modelos funcionó bien, eso le indica que su conjunto de datos (su elección de datos sin procesar, selección de características e ingeniería de características) no es apto para el aprendizaje automático. Tal vez necesite un conjunto de datos sin procesar diferente desde el cual comenzar. O las funciones necesarias simplemente no están disponibles en los datos que ha recopilado, porque este problema requiere el tipo de matiz que viene con una larga trayectoria profesional en este dominio del problema. Descubrí que este aprendizaje es un aspecto valioso, aunque a menudo subestimado y subestimado, del desarrollo de modelos ML.

En segundo lugar, este ejercicio de construcción de modelos fue… ¿bastante tedioso? Lo archivaría como «aburrido, repetitivo y predecible», que son mis tres señales de que es hora de automatizar una tarea.

  • Aburrido: No estás aquí por el modelo en sí; usted está después de los resultados. ¿Qué tan bien se desempeñó? ¿Qué me enseña eso sobre mis datos?
  • Repetitivo: Está probando varios algoritmos, pero haciendo más o menos lo mismo cada vez.
  • Previsible: Los clasificadores de scikit-learn comparten una interfaz similar, por lo que puede invocar el mismo train() llame a cada uno mientras pasa el mismo conjunto de datos de entrenamiento.

Sí, esto requiere una for() círculo. Y los científicos de datos que provienen de un entorno de desarrollo de software han escrito bucles similares a lo largo de los años. Eventualmente se topan con GridSearchCV, que acepta un conjunto de algoritmos y combinaciones de parámetros para probar. El camino es el mismo en ambos sentidos: configuración, inicio del trabajo, marcharse. Obtenga sus resultados en pocas horas.

Creación de un bucle Better for() para ML

Todo esto nos lleva al aprendizaje automático automatizado o autoML. Hay varias implementaciones, desde AWS de grado industrial Piloto automático de SageMaker y la nube de Google IA de vérticea las ofertas de jugadores más pequeños, pero, en pocas palabras, algunos desarrolladores detectaron lo mismo for() bucle y construyó una interfaz de usuario elegante en la parte superior. Cargue sus datos, haga clic en un flujo de trabajo, váyase. Obtenga sus resultados en pocas horas.

Si es un científico de datos profesional, ya tiene el conocimiento y las habilidades para probar estos modelos. ¿Por qué querría que AutoML construya modelos para usted?

  • Compra tiempo y espacio para respirar. Una solución de autoML puede producir una solución «suficientemente buena» en solo unas pocas horas. En el mejor de los casos, obtendrá un modelo que puede poner en producción ahora mismo (corto tiempo de comercialización), lo que le dará tiempo a su equipo para personalizar algo más (para obtener un mejor rendimiento). En el peor de los casos, el rendimiento del modelo es terrible, pero solo tomó unos pocos clics del mouse para determinar que este problema es más complicado de lo que esperaba. O que, solo tal vez, sus datos de entrenamiento no son buenos para el desafío que tiene entre manos.
  • Es conveniente. Malditamente conveniente. Especialmente cuando considera cómo ciertos proveedores de Big Cloud tratan el autoML como una vía de acceso al alojamiento modelo. Se necesitan unos pocos clics para construir el modelo, luego otros pocos clics para exponerlo como punto final para su uso en producción. (¿AutoML es el anzuelo para el alojamiento de modelos a largo plazo? Podría serlo. Pero esa es una historia para otro día). En relación con el punto anterior, una empresa podría pasar de «datos sin procesar» a «servir predicciones en datos en vivo» en un jornada laboral única.
  • Tienes otro trabajo que hacer. No solo estás construyendo esos modelos por construirlos. Debe coordinarse con las partes interesadas y los gerentes de productos para determinar qué tipos de modelos necesita y cómo integrarlos en los procesos de la empresa. Y es de esperar que no le pidan específicamente un modelo, sino que le pidan que use los datos de la empresa para abordar un desafío. Debe dedicar tiempo de calidad a comprender todos esos datos a través de la lente del modelo comercial de la empresa. Eso conducirá a una limpieza de datos adicional, selección de características e ingeniería de características. Esos requieren el tipo de contexto y matiz que las herramientas de autoML no tienen (y no pueden) tener.

El software tiene hambre, también puede alimentarlo

Recuerde la vieja frase de Marc Andreessen que El software se está comiendo el mundo.?

Cada vez más empresas e industrias importantes se ejecutan en software y se entregan como servicios en línea, desde películas hasta agricultura y defensa nacional. Muchos de los ganadores son empresas de tecnología empresarial al estilo de Silicon Valley que están invadiendo y derribando estructuras industriales establecidas. Durante los próximos 10 años, espero que muchas más industrias se vean interrumpidas por el software, con nuevas empresas de Silicon Valley líderes en el mundo haciendo la disrupción en la mayoría de los casos.

Estos fueron los primeros días en que los desarrolladores detectaron esos for() bucles y if/then construcciones en la naturaleza. Si su negocio dependía de una regla estricta o de una secuencia predecible de eventos, alguien estaba obligado a escribir el código para hacer el trabajo y colocarlo en unas pocas docenas de servidores para escalarlo.

Y tenía sentido. A la gente no le gustaba hacer el trabajo de esclavos. Lograr que el software tome las partes no tan divertidas separó las tareas según la capacidad: repetición incansable para las computadoras, contexto y atención especial a los detalles para los humanos.

Andreessen escribió ese artículo hace más de una década, pero aún se mantiene. El software continúa acaparando las tareas aburridas, repetitivas y predecibles del mundo. Es por eso que el software se está comiendo la IA.

(No se sienta mal. AI también está comiendo software, como con Copiloto de GitHub. Sin mencionar, algunas formas de expresión creativa. Difusión estable, ¿cualquiera? La lección más importante aquí es que la automatización es una bestia hambrienta. A medida que desarrollemos nuevas herramientas para la automatización, traeremos más tareas al alcance de la automatización).

Dado eso, supongamos que es un científico de datos en una empresa que adoptó una herramienta de autoML. Un avance rápido de unos meses. ¿Qué ha cambiado?

Tu equipo se ve diferente

La introducción de autoML en sus flujos de trabajo ha destacado tres roles en su equipo de datos. El primero es el científico de datos que proviene de un entorno de desarrollo de software, alguien que probablemente sería llamado «ingeniero de aprendizaje automático» en muchas empresas. Esta persona se siente cómoda hablando con bases de datos para extraer datos y luego llamando a Pandas para transformarlos. En el pasado entendieron las API de TensorFlow y Torch para construir modelos a mano; hoy dominan las API del proveedor de autoML para entrenar modelos y saben cómo revisar las métricas.

El segundo es el profesional experimentado en ML que realmente sabe cómo construir y ajustar modelos. Ese modelo del servicio autoML suele ser bueno, pero no Excelente, por lo tanto, la empresa todavía necesita a alguien que pueda arremangarse y exprimir los últimos puntos porcentuales de rendimiento. Los proveedores de herramientas ganan dinero adaptando una solución a los desafíos más comunes, ¿verdad? Eso deja muchos nichos que las populares soluciones de autoML no pueden o no quieren manejar. Si un problema requiere una técnica nueva y brillante, o una gran red neuronal ramificada, alguien de su equipo debe manejar eso.

Estrechamente relacionado está el tercer rol, alguien con una sólida formación en investigación. Cuando los algoritmos bien conocidos y bien respaldados ya no corten la mostaza, deberá inventar algo completo o traducir ideas de un trabajo de investigación. Su proveedor de autoML no ofrecerá eso solución por un par de años más, así que es su problema resolverlo si lo necesita hoy.

Tenga en cuenta que una persona suficientemente experimentada puede cumplir múltiples roles aquí. También vale la pena mencionar que una gran tienda probablemente necesitaba personas en los tres roles incluso antes de que autoML fuera una cosa.

(Si le damos la vuelta a eso: además de los FAANG y los fondos de cobertura, pocas empresas tienen tanto la necesidad como el capital para financiar una función de investigación de ML en curso. Este tipo de departamento proporciona rendimientos muy irregulares, la gran ganancia ocasional que marca largos tramos de “lo estamos investigando”).

Eso nos lleva a una omisión notoria de esa lista de funciones: los científicos de datos que se centraron en construir modelos básicos. Las herramientas de AutoML están haciendo la mayor parte de ese trabajo ahora, de la misma manera que los paneles o visualizaciones básicos ahora son el dominio de las herramientas de autoservicio como AWS QuickSight, Google Data Studio o Tableau. Las empresas seguirán necesitando avanzado Modelado de ML y visualización de datos, claro. Pero ese trabajo va a los practicantes avanzados.

De hecho, casi todo el trabajo de datos es más adecuado para la gente avanzada. AutoML realmente tomó un bocado de sus contrataciones de nivel de entrada. Simplemente no hay mucho que puedan hacer. Solo las tiendas más grandes tienen el ancho de banda para realmente poner a alguien al día.

Dicho esto, aunque la estructura del equipo ha cambiado, todavía tienes un equipo de datos cuando se usa una solución de autoML. Una empresa que se toma en serio la ML/IA necesita científicos de datos, ingenieros de aprendizaje automático y similares.

Has refinado tu noción de «PI»

El código escrito para crear la mayoría de los modelos de ML ya era una mercancía. Todos estamos llamando a las mismas bibliotecas de Pandas, scikit-learn, TensorFlow y Torch, y estamos haciendo el mismo baile de «convertir datos en formato tabular, luego alimentar al algoritmo». El código que escribimos se ve muy similar en todas las empresas e incluso industrias, ya que gran parte se basa en la semántica de llamadas de esas herramientas de código abierto.

Si ve sus modelos de ML como la suma total de algoritmos, código de unión y datos de entrenamiento, entonces la dura realidad es que sus datos eran la única propiedad intelectual única en la mezcla de todos modos. (Y eso es solo si estaba construyendo sobre datos propietarios). En el aprendizaje automático, su ventaja competitiva radica en el conocimiento del negocio y la capacidad de ejecución. No existe en el código.

AutoML lleva este punto a casa. En lugar de invocar las llamadas de código abierto scikit-learn o Keras para crear modelos, su equipo ahora pasa de las transformaciones de datos de Pandas directamente a… las llamadas API para AWS AutoPilot o GCP Vertex AI. Él for() bucle que realmente construye y evalúa los modelos ahora vive en los sistemas de otra persona. Y está disponible para todos.

Tu trabajo ha cambiado

La construcción de modelos sigue siendo parte del trabajo, de la misma manera que los desarrolladores todavía escriben mucho código. Si bien lo llamó «entrenamiento de un modelo ML», los desarrolladores vieron «un for() loop que estás ejecutando a mano”. Es hora de dejar que el código maneje ese primer paso en la construcción de modelos y deje que su función cambie en consecuencia.

¿Qué significa eso, entonces? Finalmente cumpliré la promesa que hice en la introducción. En lo que a mí respecta, el papel del científico de datos (e ingeniero de ML, etc.) se basa en tres pilares:

  • Traduciendo a números y viceversa. Los modelos de ML solo ven números, por lo que el aprendizaje automático es un juego de números que entran y salen. Las empresas necesitan personas que puedan traducir conceptos del mundo real en números (para entrenar adecuadamente los modelos) y luego traducir los resultados numéricos de los modelos a un contexto del mundo real (para tomar decisiones comerciales). ¿Tu modelo dice “el precio de esta casa debería ser $542,424.86”? Gran. Ahora es el momento de explicar a las partes interesadas cómo el modelo llegó a esa conclusión y cuánta fe deben poner en la respuesta del modelo.
  • Comprender dónde y por qué fallan los modelos: Estrechamente relacionado con el punto anterior está que los modelos son, por definición, representaciones imperfectas de fenómenos del mundo real. Al mirar a través de la lente del modelo comercial de su empresa, ¿cuál es el impacto de que este modelo sea incorrecto? (Eso es lo que riesgo de modelo enfrenta la empresa?)

    Mi amigo Roger Magoulas me recordó la vieja cita de George Box de que “todos los modelos están equivocados, pero algunos son útiles”. Roger enfatizó que debemos considerar la cita completacual es:

Dado que todos los modelos son erróneos, el científico debe estar alerta a lo que es erróneo de manera importante. No es apropiado preocuparse por los ratones cuando hay tigres en el exterior.

  • Detectar oportunidades de ML en la naturaleza: El aprendizaje automático hace bien cuatro cosas: predicción (salidas continuas), clasificación (salidas discretas), agrupación de cosas («¿qué es similar?») y detección de valores atípicos («¿dónde están las cosas raras?»). De la misma manera que un desarrollador puede detectar for() bucles en la naturaleza, los científicos de datos experimentados son expertos en detectar esos cuatro casos de uso. Pueden saber cuándo un modelo predictivo es adecuado para aumentar o reemplazar la actividad humana y, lo que es más importante, cuándo no lo es.

A veces, esto es tan sencillo como ver dónde un modelo podría guiar a las personas. Supongamos que escucha al equipo de ventas describir cómo pierden tanto tiempo persiguiendo clientes potenciales que no funcionan. El tiempo perdido significa que pierden pistas que probablemente habrían funcionado. “Ya sabes… ¿Tienes una lista de pistas anteriores y cómo fueron? ¿Y eres capaz de describirlos basándote en un puñado de atributos? Podría construir un modelo para etiquetar un trato como si se siguiera o no. Podrías usar las probabilidades emitidas junto con esas etiquetas para priorizar tus llamadas a prospectos”.

Otras veces se trata de liberar a las personas de trabajos que aturden la mente, como mirar cámaras de seguridad. “¿Qué pasa si construimos un modelo para detectar movimiento en la transmisión de video? Si conectamos eso a un sistema de alertas, nuestro personal podría concentrarse en otro trabajo mientras el modelo vigilaba el perímetro de la fábrica”.

Y luego, en casos excepcionales, busca nuevas formas de expresar la funcionalidad de ML. “Entonces… cuando invocamos un modelo para clasificar un documento, en realidad estamos solicitando una sola etiqueta basada en cómo se desglosan las palabras y secuencias en ese bloque de texto. ¿Y si vamos por el otro lado? ¿Podríamos alimentar un modelo con toneladas de texto y hacer que producir texto a pedido? ¿Y si eso pudiera aplicarse, por ejemplo, al código?

siempre ha sido

Desde un alto nivel, entonces, el papel del científico de datos es comprender el análisis de datos y el modelado predictivo, en el contexto de los casos de uso y las necesidades de la empresa. siempre lo ha sido La construcción de modelos estaba en tu plato porque eras el único que sabía cómo hacerlo. Al descargar parte del trabajo de creación de modelos en las máquinas, las herramientas de autoML eliminan parte de esa distracción, lo que le permite concentrarse más en los datos en sí.

Los datos son sin duda la parte más importante de todo esto. Puede considerar los algoritmos de aprendizaje automático listos para usar (disponibles como implementaciones sólidas de código abierto) y la potencia informática ilimitada (proporcionada por los servicios en la nube) como constantes. La única variable en su trabajo de aprendizaje automático, lo único en lo que puede influir en su camino hacia el éxito, son los datos en sí. Andrew Ng enfatiza este punto en su impulso por la IA centrada en datosy estoy totalmente de acuerdo.

Aprovechar al máximo esos datos requerirá que comprenda de dónde provienen, evalúe su calidad y los diseñe en características que los algoritmos puedan usar. Esta es la parte difícil. Y es la parte que aún no podemos entregar a una máquina. Pero una vez que esté listo, puede transferir esas funciones a una herramienta de autoML, su asistente de confianza que maneja el trabajo duro, para usarlos diligentemente para entrenar y comparar varios modelos.

Una vez más, el software ha comido tareas aburridas, repetitivas y predecibles. Y ha trazado una línea divisoria, separando el trabajo en función de la capacidad.

¿Adónde seguir?

Algunos científicos de datos podrían afirmar que autoML les está quitando el trabajo. (Por el momento, pasaremos por alto la ironía de alguien en tecnología que se queja de que un robot está tomando su trabajo). ¿Es eso cierto, sin embargo? Si siente que construir modelos es su trabajo, entonces sí.

Para los lectores más experimentados, las herramientas de autoML son un reemplazo hábil para sus confiables pero oxidadas herramientas de cosecha propia. for() bucles Una solución más pulida para hacer un primer paso en la construcción de modelos. Ven las herramientas de autoML, no como una amenaza, sino como un multiplicador de fuerza que pondrá a prueba una variedad de algoritmos y parámetros de ajuste mientras abordan el trabajo importante que realmente requiere experiencia y experiencia humana. Presta mucha atención a este grupo, porque tienen la idea correcta.

Los profesionales de datos que adopten las herramientas de autoML utilizarán su nuevo tiempo libre para forjar conexiones más sólidas con el modelo comercial de la empresa. Buscarán formas novedosas de aplicar el análisis de datos y los modelos de ML a los productos y desafíos comerciales, y tratarán de encontrar esas oportunidades que las herramientas de autoML no pueden manejar.

Si lleva el espíritu empresarial en la sangre, puede aprovechar ese último punto y crear una nueva empresa de autoML. Puede encontrar algo que los grandes proveedores de autoML no admiten actualmente y lo adquirirán. (Actualmente veo una oportunidad para el agrupamiento como servicio, en caso de que esté buscando ideas). O si se enfoca en un nicho que los grandes jugadores consideran demasiado limitado, puede ser adquirido por una empresa en esa industria. vertical.

El software tiene hambre. Encuentra maneras de alimentarlo.



Fuente del artículo

Deja un comentario