Incluso con una pila perfecta de herramientas de MLOps, los equipos aún luchan por entregar productos de ML. Entonces, si las herramientas no son la única pieza del rompecabezas, ¿qué queda? En mi última publicación , argumento que las piezas restantes son Cultura y Proceso.

Profundicemos en el proceso de MLOps , en particular, algunas de las piezas fundamentales en las que la mayoría de los equipos se equivocan . ¿Cómo es un proceso de MLOps exitoso y cómo pueden los profesionales individuales de ML ayudar a construir ese proceso?

TL;RD

• Comience con un producto, no con un modelo
• Inspeccione los datos en producción , no en su almacén
• Comience de manera simple: con datos y modelos
• Asociarse con ingenieros

Comience con un producto ML

Quizás la práctica más importante que permite proyectos de ML exitosos es diseñar un producto , no un modelo . Una de las mayores trampas que he visto en docenas de empresas es entregar "proyectos" a los equipos de datos, en lugar de involucrarlos en la fase de diseño del producto.

Para construir un producto ML exitoso, tres partes interesadas deben participar en el diseño del producto:

• PM / Business Stakeholder : ¿Cómo es el éxito?
• Persona ML : ¿Qué es (probablemente) posible con ML?
• Ingeniero de producto : ¿Qué es factible y cuáles son las limitaciones?

Algunos ejemplos de equipos mal alineados:

• La persona de ML optimiza la precisión del modelo (¡en lugar de los resultados comerciales!)
• Proyectos iniciados que pueden no ser factibles de resolver con ML
• El modelo no cumple con las restricciones de rendimiento en producción.
• Las características son desafiantes o imposibles de calcular en producción

• La persona de ML comprende las ventajas y desventajas de la precisión frente al tiempo de comercialización
• Supervisión construida desde el día cero para garantizar que los resultados empresariales se miden de forma coherente
• El ingeniero ayuda a la persona de ML a comprender el panorama de los datos de producción
• Los SLA modelo están claramente definidos y medidos

Este es un ejemplo de “buena alineación” en la última sección, pero merece su propia sección. Casi todos los desarrolladores de ML que he visto comienzan sus proyectos de ML con una encuesta de los datos disponibles. ¿El problema? Por lo general, examinan los datos que están disponibles para la capacitación , no los datos que estarán disponibles en la producción.

Algunos podrían preguntarse: ¿no deberían estar disponibles todos los datos disponibles para la capacitación en un sistema de producción?

La mayoría de las veces, la respuesta es sí , pero con un montón de asteriscos. ¿Con qué rapidez están disponibles esos datos? ¿Qué tan frescos son esos datos? ¿Cuánto preprocesamiento se debe realizar en los datos de producción para que sean consumibles? ¿Quién es el dueño de esos datos?

Muchos proyectos de ML se estancan debido a problemas con los datos de producción. He visto una y otra vez que existe una gran desconexión entre la persona de ML y el ingeniero de producto. Un ejemplo de dos características inocuas con requisitos radicalmente diferentes:

• El código postal de la casa de un usuario : probablemente muy simple de usar en producción. Consultar una base de datos.
• La ubicación promedio de un usuario en los últimos cinco minutos : ¡probablemente un PITA! ¿Los datos de ubicación del usuario están en Kafka Stream? ¿Qué tan fresco tiene que ser? ¡Las agregaciones de transmisión son difíciles! ¡Probablemente entrenando / sirviendo problemas de sesgo!

Comience de manera simple

Probablemente el consejo de ML más común, pero es un buen consejo. Comience con una solución simple.

Mi adición: la mayoría de la gente le dirá que comience con un modelo simple , ¡pero es igualmente importante comenzar con datos simples! Para jugar con el ejemplo anterior:

• Ubicación promedio de un usuario en los últimos cinco minutos: duro
• La ubicación más reciente de un usuario: ¡probablemente mucho más fácil!

Probablemente tome ese comercio cada vez. Siempre puede construir un V2 con la característica más elegante, y será mucho más fácil construir mejoras incrementales que enviar algo complicado la primera vez.

Asociarse con ingenieros

Lo más probable es que, si eres un científico de datos, no todas las preguntas planteadas anteriormente sean obvias de responder. La última vez que practiqué la creación de modelos ML, no tenía idea de qué era la transmisión de datos (y mucho menos cómo pensar en ello).

La solución es hacerse amigo de los ingenieros y trabajar con ellos durante el desarrollo de un modelo ML. La creación de cualquier proyecto de software no se puede hacer en un silo, y ML en un silo es aún peor. Los ingenieros pueden ayudar con "qué datos están disponibles", "qué restricciones debo conocer", "qué SLA son factibles" y más.

Trabaje con un ingeniero temprano y con frecuencia. Crearás proyectos mucho más rápido.

Conclusión

Estos pasos no son una visión integral de un proceso de MLOps: hay muchas piezas en movimiento que conducen al éxito (revisiones de código, CI/CD, monitoreo, …). Este es un punto de partida. Como se mencionó anteriormente, la mayoría de las fallas de ML que he visto son problemas de alineación. Estas pautas de proceso están destinadas principalmente a ayudarlo a alinear a su equipo para el éxito.

Necesita una base sólida para construir una práctica excepcional de MLOps.

David Hershey es inversor en Unusual Ventures , donde invierte en aprendizaje automático e infraestructura de datos. David comenzó su carrera en Ford Motor Company, donde comenzó su equipo de infraestructura de ML. Recientemente, trabajó en Tecton y Determined AI , ayudando a los equipos de MLOps a adoptar esas tecnologías. Si está construyendo una empresa de infraestructura de datos o ML, comuníquese con David en LinkedIn .