True ML Talks #2: Flujo de trabajo de aprendizaje automático en Stitch Fix

Diseñado para la velocidad: ~ 10 ms de latencia, incluso bajo carga
¡Una forma increíblemente rápida de crear, rastrear e implementar sus modelos!
- Gestiona más de 350 RPS en solo 1 vCPU, sin necesidad de ajustes
- Listo para la producción con soporte empresarial completo
Recibimos una respuesta muy alentadora a nuestro primer episodio de True ML Talks. En esta serie, profundizamos en el proceso de aprendizaje automático de algunas de las principales empresas de aprendizaje automático y, en el episodio de hoy, hablamos con Stefan Krawczyk.
Stefan está creando DagWorks, una plataforma colaborativa de código abierto para que los equipos de ciencia de datos creen y mantengan oleoductos modelo, conectándose a la infraestructura de datos y MLOP existentes (lea su Lanzamiento de YC). Cuenta con más de 15 años de experiencia en empresas como Nextdoor, LinkedIn y Stitch Fix en el campo de los datos y el aprendizaje automático. Anteriormente, dirigió el equipo de Model Lifecycle en Stitch Fix, donde adquirió una amplia experiencia en la creación de herramientas de autoservicio para una plataforma interna de aprendizaje automático mLOps. También es conferenciante habitual y autor del popular marco de código abierto Hamilton.
📌
Nuestras conversaciones con Stefan girarán en torno a cuatro temas clave:
1. Casos de uso del aprendizaje automático para la empresa.
2. Cómo está estructurado el equipo de Stitch Fix para optimizar los resultados empresariales.
3. Los desafíos a los que se enfrenta la creación del aprendizaje automático se combinan con los desafíos específicos que surgen en relación con la industria.
4. Una descripción general de las innovaciones de vanguardia aplicadas durante el proceso de creación y escalado de la infraestructura de aprendizaje automático.
Mira el episodio completo a continuación:
ML Usecases @Stitch Fix: un servicio de estilismo personal en línea
- Sistema de recomendación → Modelos de previsión y simulación, que proporcionan un desglose de los rangos de tamaño y asignación.
- Predicción y simulación → Cuando los compradores deciden la cantidad de ropa que van a comprar, deben determinar las tallas y la población a la que van a servir. Esto implica pronosticar una cascada de cosas que las personas usan internamente para ayudarlas a simular o pronosticar. El equipo de algoritmos de Stitch Fix crea modelos para este propósito, proporcionando un desglose de los rangos de tamaño y asignación. Lea más sobre esto aquí
- Sistema interno de planificación de recursos empresariales → Básicamente, Stitch Fix ha creado su propio sistema ERP interno utilizando algoritmos. Este sistema ayuda a planificar el inventario, el almacenamiento y la optimización de las tarifas de envío. Lea más acerca de esto aquí.
- Optimización de rutas a través del almacén → Stitch Fix cuenta con un equipo que optimiza las rutas por el almacén, garantizando que se tome el camino más corto para recoger los pedidos. Esta optimización ayuda a minimizar el costo y el tiempo de procesamiento de los pedidos.
- Logística de almacén → El equipo de algoritmos de Stitch Fix también trabaja para optimizar el proceso de recogida de ropa de las papeleras para satisfacer los pedidos. Stitch Fix puede ahorrar costes y minimizar los tiempos de procesamiento de los pedidos al acelerar este proceso.
Flujo de trabajo del sistema ML en Stitch Fix
Stitch Fix tiene dos equipos que trabajan en sus sistemas de aprendizaje automático (ML): los equipos de plataforma y ciencia de datos.
- Equipo de ciencia de datos: El equipo de ciencia de datos, organizado en verticales que ayudan a diferentes partes de la empresa, tiene la tarea de crear modelos para ayudar a otros equipos de la empresa a tomar decisiones.
- Equipo de plataforma: El equipo de la plataforma crea abstracciones y herramientas para que los científicos de datos no tengan que diseñar tanto para realizar su trabajo. El equipo se divide en varios componentes, como Spark, Hadoop, Kafka, la infraestructura, el sistema de orquestación y los entornos. También hay un equipo responsable de la pila de recomendaciones y de la implementación de los microservicios, así como de las pruebas A/B y la experimentación. El equipo se centra en los elementos de operacionalización, como facilitar el entrenamiento, la implementación y el mantenimiento de los modelos.
👉
El equipo de ciencia de datos es responsable de ser propietario de los modelos y de los resultados. El equipo de la plataforma garantiza la disponibilidad de la infraestructura de implementación y sus componentes.
No hubo ninguna «transferencia» del modelo entre el equipo de ciencia de datos y el equipo de la plataforma. Esto ayuda a obtener muchas más iteraciones con el modelo.
Gestión de la asignación de infraestructura
La asignación de la infraestructura la gestiona el equipo de la plataforma, que generalmente era el propietario de las cuotas de lo que estaba disponible. Los científicos de datos podían solicitar nodos u otros clústeres de Spark en una interfaz de usuario. Se llevan a cabo algunas actividades de contabilidad para garantizar que los costos no se disparen sin justificación. El equipo de la plataforma intentó que las personas pudieran obtener lo que querían fácilmente sin tener que trabajar demasiado, y había equipos que se hacían cargo de las cuotas y se aseguraban de que los costos se mantuvieran bajo control.
Desafíos únicos en aprendizaje automático y MLOps en Stitch Fix
- En Stitch Fix, hay más de 100 científicos de datos que trabajan en el desarrollo de modelos. Dado que cada científico de datos es propietario de un modelo que tiene una vida útil media de al menos dos años, había muchos equipos que creaban muchos modelos, por lo que conseguir que un equipo fuera el propietario era todo un desafío. El equipo de plataformas de StitchFix ha creado muchas soluciones internamente y solo ha comprado unas cuantas debido a la heterogeneidad de las bibliotecas y los marcos utilizados. La estandarización habría facilitado algunas plataformas, pero los diferentes equipos tenían diferentes problemas y bibliotecas que se adaptaban mejor a esos problemas. El equipo de plataformas de StitchFix tuvo que crear sus propias soluciones, como Model Envelope y Hamilton, porque no había soluciones de código abierto que se ajustaran bien a sus necesidades.
- Si bien es fácil crear modelos, alguien tiene que mantener todos los ETL y, si alguien deja la empresa, puede causar problemas. Desechar el código es un derroche, y los nuevos miembros del equipo pierden tiempo hasta que puedan descubrir y entender lo que había antes que ellos. Además, dado que las personas suelen basarse en los modelos de otros equipos para utilizarlos como funciones, existen interdependencias entre los ETL que deben tenerse en cuenta.
«Una de las razones por las que me quedé tanto tiempo en Stitch Fix fue precisamente por esos desafíos y por descubrir cómo resolverlos». - Stefan
Innovaciones en la plataforma Stitch Fix ML
- Modelos de sobres: El equipo de plataforma de Stitch Fix creó un sistema que permitía a los científicos de datos empaquetar sus modelos con otros componentes necesarios y enviarlos fácilmente. Es un sistema basado en API que captura muchas cosas y, con un botón y una configuración adicional, los científicos de datos pueden implementar sus modelos en producción en menos de una hora. El sistema también permitía realizar trabajos por lotes y facilitaba la ejecución de modelos de forma distribuida en Spark.
- ETL basados en la configuración: El equipo de plataforma de Stitch Fix utilizó YAML y Jinja para permitir a los científicos de datos describir el proceso ETL, que incluía código SQL y Python para el ajuste del modelo. La idea era resumir el sistema de orquestación y permitir al equipo de la plataforma intercambiar diferentes componentes del contenedor Docker, lo que facilitaba la administración y el mantenimiento del código base.
- Hamilton: Hamilton es un micromarco declarativo para describir los flujos de datos. El equipo de plataformas de Stitch Fix lo desarrolló para facilitar la ingeniería de funciones, especialmente para la previsión de series temporales, donde es fácil utilizar miles de funciones. Hamilton ayuda a estructurar el problema, de forma similar a DBT para SQL, pero para las transformaciones de Python. Permite describir el flujo de datos sin administrar los scripts de Python. Las funciones declaran un flujo de datos y las definiciones se pueden compartir y ejecutar fácilmente en contextos online y offline.
👉
Para el intercambio de componentes de Docker, el equipo de la plataforma intentó crear una API dorada en la que los científicos de datos pudieran describir lo que querían que sucediera sin tener que preocuparse por las dependencias de la plataforma. Esto se hizo mediante canalizaciones de modelos basadas en la configuración, en las que los científicos de datos podían proporcionar texto que contuviera subconjuntos de cambios. De este modo, el equipo de la plataforma podía cambiar las cosas sin necesidad de que el equipo de científicos de datos actualizara o mejorara sus contenedores Docker. El equipo de la plataforma también podría actualizar los registros o la metainformación sin que los usuarios tuvieran que volver a implementar o reescribir sus procesos. Esto eliminó la necesidad de que los equipos administraran y actualizaran las cosas y permitió al equipo de la plataforma administrar y actualizar las cosas de manera más eficiente sin necesidad de migrar por parte del equipo de científicos de datos.
Mejorar el tiempo de construcción y depuración de contenedores Docker en el desarrollo remoto: estrategias empleadas en Stitch Fix
- Almacenamiento en caché para acelerar la creación de contenedores - El equipo de plataforma de Stitch Fix intentó acelerar la creación de contenedores docker almacenando en caché las bibliotecas y los entornos que se utilizaban con frecuencia. Por ejemplo, agregaron el almacenamiento en caché para garantizar que, si volvían a necesitar los mismos requisitos, no fuera necesario volver a instalarlos. También guardaron los archivos del entorno, los comprimieron y, a continuación, los recuperaron para acelerar el proceso.
- Desarrollo local para minimizar el tiempo de construcción y depuración de contenedores - El equipo de plataforma de Stitch Fix alentó a los desarrolladores a desarrollar localmente o a buscar formas de evitar esperar a que se complete el ciclo de creación, ejecución y depuración del contenedor Docker. Permitieron que se ejecutaran bucles locales para cada una de las etapas de la ETL. Para ello, utilizaron algunos datos para almacenarlos en caché para los desarrolladores, entre otras funciones de usabilidad. Este enfoque ayudó a acelerar el proceso de desarrollo y depuración.
- Exploración de nuevos enfoques para mejorar el tiempo de construcción y depuración de contenedores - Si bien el equipo de plataforma de Stitch Fix intentó mejorar el tiempo de compilación y depuración mediante el almacenamiento en caché y el desarrollo local, reconocieron que el proceso podría ser más rápido. Algunos desarrolladores están trabajando en cambios en Docker para mejorar este proceso, especialmente en el caso de los modelos. Este enfoque implica cambiar Docker y reiniciarlo para hacerlo mejor y más eficiente.
Recomendaciones de herramientas MLOps de Stefan Krawczyk
Es importante elegir herramientas basadas en el impacto empresarial y los SLA. Las cosas que se pueden hacer con un solo nodo deben optimizarse con un sistema de orquestación. En el caso del control de versiones de datos y los registros de modelos, puede funcionar guardar elementos en S3 en una estructura de rutas estructuradas y almacenar los metadatos con ellos. En lo que respecta al registro de modelos, las herramientas de código abierto como MLFlow deberían ayudar, pero también hay soluciones de administración alojadas como TrueFoundry.
Es importante tener un sistema de pruebas A/B en la pila para comprender el valor que su modelo aporta a su negocio. Esto ayudará a tomar decisiones sobre dónde invertir en las prácticas de MLOps en función del impacto que tenga su modelo.
Recomendación de herramientas MLOPS
- Tenga en cuenta la heterogeneidad en las bibliotecas y los marcos: si hay una heterogeneidad significativa en las bibliotecas y los marcos utilizados, puede ser necesario crear soluciones internas, ya que es posible que no haya soluciones estándar que se ajusten a sus necesidades.
- La estandarización puede facilitar algunas plataformas: si bien los diferentes equipos pueden tener diferentes problemas, la estandarización de ciertas herramientas y procesos puede facilitar Plataformas MLOps más fácil de construir y mantener.
- ¿No tiene soluciones de código abierto que se ajusten a sus necesidades? Cree las suyas propias: si no hay soluciones de código abierto que se adapten bien a sus necesidades, puede ser necesario crear sus propias soluciones, como Model Envelope y Hamilton, para alcanzar sus objetivos de MLOps.
Desafíos relacionados con ETL en el aprendizaje automático
En el aprendizaje automático, Extraer, Transformar y Cargar (ETL) es un proceso fundamental para transformar los datos sin procesar en información valiosa. Sin embargo, la ETL en los sistemas de aprendizaje automático plantea varios desafíos que deben abordarse.
Los ETL de los sistemas de aprendizaje automático pueden quedarse en silencio debido a los cambios iniciales, lo que dificulta que los profesionales de los datos rastreen las entradas del modelo, lo que dificulta el mantenimiento de los ETL. La complejidad de los ETL también aumenta con el tiempo, lo que dificulta que los equipos puedan mantenerse al día.
DagWorks: una plataforma ETL de código abierto para equipos de ciencia de datos
Para resolver los desafíos mencionados en la sección anterior, DagWorks está creando una plataforma ETL de código abierto para los equipos de ciencia de datos que reduce su dependencia de la ingeniería, el código abierto es el que Hamilton mencionó anteriormente. Hamilton permite a los profesionales de datos sin experiencia en ingeniería de software escribir código para ponerlo en producción y gestionar los artefactos ETL de aprendizaje automático en su infraestructura actual. Hamilton también ofrece un almacén central de definiciones de funciones y un sistema de distribución, lo que facilita la depuración y se puede utilizar en casos de cumplimiento normativo.
Hamilton está diseñada para ser una capa de abstracción que se puede usar con varias herramientas de orquestación, como Airflow o Argo. Stefan cree que los científicos de datos no deberían preocuparse por la topología del lugar donde funcionan las cosas y, en cambio, centrarse en crear modelos e iteraciones. DagWorks está intentando encontrar formas y abstracciones para facilitar el cambio de proveedores de calidad de datos sin tener que reescribir las cosas.
Si bien Hamilton complementa herramientas como Metaflow, no intenta reemplazarlas. Por el contrario, permite a las personas ser más productivas al utilizar esos sistemas, ya que les permite modelar lo microscópico de una tarea. En general, DagWorks está intentando facilitar a los equipos de ciencia de datos la gestión y el mantenimiento de los artefactos ETL de aprendizaje automático.
A continuación se muestran algunas lecturas interesantes de Stefan y su equipo:
Lo que aprendí construyendo plataformas en Stitch Fix
Lea nuestra publicación anterior de la serie
Sigue viendo el TrueML serie youtube y leyendo todo el TrueML serie de blogs.
True Foundry es un PaaS de implementación de aprendizaje automático sobre Kubernetes para acelerar los flujos de trabajo de los desarrolladores y, al mismo tiempo, permitirles una flexibilidad total a la hora de probar e implementar modelos, al tiempo que garantiza una seguridad y un control totales para el equipo de Infra. A través de nuestra plataforma, permitimos a los equipos de aprendizaje automático implementar y supervisar modela en 15 minutos con un 100% de confiabilidad, escalabilidad y la capacidad de revertirse en segundos, lo que les permite ahorrar costos y lanzar los modelos a la producción más rápido, lo que permite obtener un verdadero valor empresarial.
TrueFoundry AI Gateway ofrece una latencia de entre 3 y 4 ms, gestiona más de 350 RPS en una vCPU, se escala horizontalmente con facilidad y está listo para la producción, mientras que LitellM presenta una latencia alta, tiene dificultades para superar un RPS moderado, carece de escalado integrado y es ideal para cargas de trabajo ligeras o de prototipos.
La forma más rápida de crear, gobernar y escalar su IA

















.png)


.webp)




.webp)







