Cómo construir una herramienta de seguimiento de experimentos [Lecciones de los ingenieros detrás de Neptune]

'Construcción de una herramienta de seguimiento de experimentos' [Lecciones de los ingenieros de Neptune]

Como ingeniero de MLOps en tu equipo, a menudo te encargan mejorar el flujo de trabajo de tus científicos de datos agregando capacidades a tu plataforma de ML o construyendo herramientas independientes para que las utilicen.

El seguimiento de experimentos es una de esas capacidades. Y dado que estás leyendo este artículo, es probable que los científicos de datos a los que apoyas hayan buscado ayuda. Los experimentos que realizan están aumentando de escala y volviéndose cada vez más complejos; hacer un seguimiento de sus experimentos y asegurarse de que sean reproducibles se ha vuelto más difícil.

Construir una herramienta para gestionar experimentos puede ayudar a tus científicos de datos;

  • 1
    Hacer un seguimiento de los experimentos en diferentes proyectos,
  • 2
    Guardar metadatos relacionados con el experimento,
  • 3
    Reproducir y comparar resultados a lo largo del tiempo,
  • 4
    Compartir resultados con compañeros de equipo,
  • 5
    O enviar salidas de experimentos a sistemas posteriores.

Este artículo es un resumen de lo que hemos aprendido al construir y mantener uno de los rastreadores de experimentos más populares durante los últimos cinco años.

Basado en los conocimientos de nuestro propio Piotr Łusakowski (arquitecto), Adam Nieżurawski (líder técnico de back-end) y otros ingenieros en neptune.ai, aprenderás:

  • Cómo desarrollar los requisitos para tu herramienta de seguimiento de experimentos,
  • Cuáles son los componentes de una herramienta de seguimiento de experimentos ideal y cómo cumplen con los requisitos,
  • Cómo arquitecturar la capa del backend de una herramienta de seguimiento de experimentos.
  • Consideraciones técnicas para construir una herramienta de seguimiento de experimentos.

El enfoque de esta guía es darte los bloques de construcción necesarios para construir una herramienta que funcione para tu equipo. Este artículo no cubre las consideraciones tecnológicas para construir una herramienta de seguimiento de experimentos o escribir código para construir una.

Nos centraremos en los bloques de construcción porque cualquier código escrito no será importante en una semana, y es probable que cualquier herramienta sea olvidada después de seis meses.

Desarrollando los requisitos para una herramienta de seguimiento de experimentos

En el lado del desarrollo, hay tres problemas principales que resuelves al construir una herramienta de seguimiento de experimentos, que incluyen:

  • Ayudar a tus científicos de datos a manejar metadatos y linaje de artefactos desde los orígenes de los datos y modelos.
  • Proporcionar a tus científicos de datos una interfaz para monitorear y evaluar el rendimiento de los experimentos para la toma de decisiones efectiva y la depuración.
  • Brindar a tus científicos de datos una plataforma para hacer un seguimiento del progreso de sus proyectos de ML.
Tres razones por las que necesitas construir una herramienta de seguimiento de experimentos

Manejar metadatos y linaje de artefactos desde los orígenes de los datos y modelos

Una herramienta de seguimiento de experimentos puede ayudar a tus científicos de datos a rastrear el linaje de los artefactos del experimento desde los orígenes de los datos y modelos, almacenar los metadatos resultantes y gestionarlos. Debe ser posible localizar de dónde provienen los datos y modelos para un experimento, para que tus científicos de datos puedan explorar los eventos del experimento y los procesos que los llevaron.

Esto desbloquea dos beneficios significativos:

  • Reproducibilidad: Asegurar que cada experimento que tus científicos de datos ejecutan sea reproducible.
  • Explicabilidad: Asegurarse de que puedan explicar los resultados de sus experimentos.

Asegurando resultados de experimentos reproducibles

Los resultados de un experimento deben ser fáciles de reproducir para que tus científicos de datos puedan colaborar mejor entre ellos y con otros equipos y tener un buen flujo de trabajo. Considera la reproducibilidad como la ejecución del mismo código con la misma configuración de entorno y en los mismos datos para obtener los mismos o resultados similares.

Para que la reproducibilidad funcione, debes construir componentes que hagan un seguimiento de los metadatos del experimento (como los parámetros, resultados, archivos de configuración, versiones de modelos y datos, etc.), cambios de código y las configuraciones del entorno de entrenamiento de los científicos de datos (o infraestructura).

Sin trazabilidad de extremo a extremo y seguimiento del linaje de los datos, es casi imposible para los científicos de datos reproducir modelos y corregir errores y canalizaciones.

Sus usuarios deben poder rastrear los cambios en el código de desarrollo del modelo (código de procesamiento de datos, código de la tubería, scripts de utilidad, etc.) que influyen directamente en cómo se ejecutan los experimentos y los resultados correspondientes.

Asegurarse de que los científicos de datos puedan explicar los resultados del experimento

Cuando los científicos de datos ejecutan experimentos y construyen modelos que satisfacen los requisitos de rendimiento esperados, también necesitan comprender los resultados para juzgar por qué su modelo realiza ciertas predicciones. Esto, por supuesto, no es cierto en todas las situaciones, pero en circunstancias en las que necesitan comprender cómo y por qué su modelo realiza predicciones, la “explicabilidad” se vuelve crucial.

No se puede agregar explicabilidad a su flujo de trabajo si no se puede rastrear de dónde provienen los datos del experimento (su linaje), cómo se procesaron, qué parámetros se utilizaron para ejecutar los experimentos y, por supuesto, cuáles fueron los resultados de esos experimentos.

Una herramienta de seguimiento de experimentos debe permitir a sus científicos de datos:

  • Examinar los experimentos de otras personas y compartir fácilmente los suyos.
  • Comparar el comportamiento de cualquiera de los experimentos creados.
  • Seguir y auditar cada experimento en busca de sesgos indeseados y otros problemas.
  • Depurar y comparar experimentos para los cuales faltan los datos de entrenamiento, el código o los parámetros.

El cumplimiento legal es otra razón por la cual la explicabilidad es esencial. Por ejemplo, el GDPR requiere que su organización recopile y realice un seguimiento de los metadatos sobre los conjuntos de datos y documente e informe cómo funcionan los modelos resultantes de los experimentos.

Monitorear y evaluar el rendimiento del experimento para la toma de decisiones efectiva

La mayor parte del tiempo, tiene sentido comparar los resultados de los experimentos realizados con diferentes versiones de conjuntos de datos y parámetros. Una solución de seguimiento de experimentos ayuda a sus científicos de datos a medir el impacto de cambiar los parámetros del modelo en los experimentos. Verán cómo cambia el rendimiento de un modelo con diferentes versiones de datos.

Por supuesto, esto sería útil para que construyan modelos de aprendizaje automático robustos y de alto rendimiento. No pueden estar seguros de que un modelo entrenado (o modelos) se generalizará a datos no vistos sin monitorear y evaluar sus experimentos. El equipo de ciencia de datos puede utilizar esta información para elegir el mejor modelo, parámetros y métricas de rendimiento.

Hacer un seguimiento del progreso de un proyecto de aprendizaje automático

Usando una solución de seguimiento de experimentos, el equipo de ciencia de datos y otras partes interesadas pueden verificar el progreso de un proyecto y ver si se dirige hacia los requisitos de rendimiento esperados.

Requisitos funcionales y no funcionales

Sería predicar al coro si dijera que se necesita mucho pensamiento para desarrollar requisitos efectivos para cualquier herramienta de software. Primero, tendría que descubrir cuáles son los requisitos en relación con el negocio y el uso del producto. Luego, debe especificar, analizar, probar y gestionarlos a lo largo del ciclo de vida del desarrollo de software.

Crear historias de usuario, analizarlas y validar los requisitos son todas partes del desarrollo de requisitos que merecen su propio artículo. Esta sección proporcionará una descripción general de las necesidades más importantes funcionales y no funcionales para una herramienta ideal para rastrear experimentos.

Comprender a sus usuarios

Dependiendo de la estructura de su equipo y la configuración organizativa, es posible que tenga diferentes usuarios que requieran una herramienta de seguimiento de experimentos. Pero idealmente, los científicos de datos serían los usuarios de su herramienta de seguimiento de experimentos. A grandes rasgos, estos son los trabajos que sus científicos de datos querrían hacer con una herramienta de seguimiento de experimentos:

  • Ver ejecuciones de entrenamiento del modelo en vivo: Cuando entrenan modelos en servidores remotos o lejos de su computadora, quieren ver las ejecuciones de entrenamiento del modelo en vivo para poder reaccionar rápidamente cuando las ejecuciones fallan o analizar los resultados cuando se completan.
  • Ver todos los metadatos de entrenamiento del modelo en un solo lugar: Cuando trabajan en un proyecto con un equipo o por sí mismos, quieren tener todos los metadatos de construcción de modelos en una ubicación para poder encontrar rápidamente los mejores metadatos de modelos siempre que los necesiten y tener la seguridad de que siempre estarán allí.
  • Comparar ejecuciones de entrenamiento del modelo: Cuando tienen diferentes versiones de modelos entrenados, quieren comparar modelos y ver cuáles funcionaron mejor, qué parámetros funcionaron y cuáles fueron las diferencias de entradas/salidas.

Requisitos funcionales

En la sección anterior, aprendió sobre los problemas que resuelve con una herramienta de seguimiento de experimentos; estos también son los trabajos que se deben realizar para construir una herramienta de seguimiento de experimentos funcional.

Para comenzar a diseñar un software de seguimiento de experimentos, debe desarrollar requisitos funcionales que representen lo que una herramienta de seguimiento de experimentos ideal debería hacer. He categorizado los requisitos funcionales en la tabla a continuación, mostrando la necesidad en función de los trabajos que sus usuarios deben realizar y cómo debería ser la característica resultante.

Necesidad

Característica

Integración perfecta con herramientas en el ecosistema.

Integrarse con marcos de ML que uses para experimentación (entrenamiento de modelos y herramientas de datos).

Integrarse con orquestadores de flujo de trabajo y herramientas de CI/CD (si tu stack está en este nivel).

Soporte para múltiples tipos de datos para registro de metadatos.

Registrar tipos de datos simples como enteros, flotantes, cadenas, etc.

Registrar tipos de datos complejos como series de flotantes, cadenas, imágenes, archivos y directorios de archivos.

Consumir los metadatos registrados (tanto programáticamente como a través de la interfaz de usuario).

Ver una lista de ejecuciones y detalles de ejecución, como la versión de datos en la que se entrenó, parámetros del modelo, métricas de rendimiento, artefactos, propietario, duración y la hora en que se creó.

Ordenar y filtrar experimentos por atributos. Por ejemplo, es posible que desees mostrar solo las ejecuciones entrenadas en la versión X del conjunto de datos Y con una precisión superior a 0.93, agruparlas por los usuarios que las crearon y ordenarlas por hora de creación.

Comparar diferentes experimentos para ver cómo diferentes parámetros, arquitecturas de modelo y conjuntos de datos afectan la precisión del modelo, el costo de entrenamiento y la utilización de hardware.

Requisitos no funcionales

Los requisitos no funcionales para una herramienta de seguimiento de experimentos deben incluir:

Calidad

Descripción

Confiabilidad

No quieres que tu herramienta de seguimiento de experimentos provoque fallos en los trabajos de entrenamiento, eso podría ser costoso y, por supuesto, debería ser un factor decisivo.

Rendimiento

Las APIs e integraciones deben tener baja latencia para no ralentizar los trabajos de entrenamiento y los pipelines de ML (que cuestan dinero).

Eficiencia

La arquitectura y las tecnologías deben estar optimizadas para ser rentables, ya que tus usuarios pueden ejecutar y rastrear muchos experimentos, y los costos pueden acumularse rápidamente.

Escalabilidad

El ML solo seguirá creciendo en importancia dentro de tu organización. No quieres terminar en una situación en la que necesites reescribir un sistema debido a algunos atajos que tomaste al principio cuando solo un científico de datos lo estaba usando.

Robustez

Necesitas un modelo de datos elástico que admita:Tamaños y estructuras de equipo variables (solo un científico de datos, o tal vez un equipo conformado por un científico de datos, 4 ingenieros de aprendizaje automático, 2 ingenieros de DevOps, etc.).Flujos de trabajo variables para que los usuarios puedan decidir qué quieren rastrear. Algunos solo rastrearán la fase posterior al entrenamiento. Otros querrán rastrear pipelines completos de transformaciones de datos, y otros monitorearán modelos en producción.Paisaje en constante cambio: el modelo de datos debe poder admitir todos los nuevos marcos y herramientas de ML en el ecosistema. Sin eso, tus integraciones podrían volverse rápidamente complicadas y difíciles de mantener.

Requisitos para la integración externa: La integración debe configurarse para que el software pueda recopilar metadatos sobre los conjuntos de datos que los usuarios utilizarán para experimentos.

Arquitectura del sistema de seguimiento de experimentos

Un sistema de seguimiento de experimentos ideal tendrá tres (3) capas:

  • 1
    Frontend/UI.
  • 2
    Backend.
  • 3
    Biblioteca del cliente (API / integración en el ecosistema).

Una vez que comprendas qué hacen estos componentes y por qué los necesitamos, podrás construir un sistema adaptado a tus necesidades de seguimiento de experimentos.

Interacciones entre las diferentes capas del software de seguimiento de experimentos

Construyendo la capa frontal del sistema de experimentos

La capa frontal intercepta la mayoría de las solicitudes de los usuarios y las envía a los servidores de backend para ejecutar cualquier lógica de seguimiento de experimentos. Dado que la mayoría de tus solicitudes y respuestas deben pasar por la capa frontal, recibirá mucho tráfico y deberá ser capaz de manejar el mayor nivel de concurrencia.

La capa frontal también es la forma en que puedes visualizar e interactuar con los experimentos que ejecutas. ¿Cuáles son las partes más importantes de la interfaz frontal de un sistema para el seguimiento de experimentos?

Visualizar metadatos del experimento

Gran parte de la experimentación en ciencia de datos se ocupa de visualizaciones, desde visualizar datos hasta monitorear en tiempo real modelos entrenados y su rendimiento. La capa frontal debe ser capaz de mostrar todo tipo de metadatos de experimentos, desde cadenas simples hasta cuadernos Jupyter incrustados, código fuente, videos e informes personalizados.

Mostrar cientos de ejecuciones con sus atributos

Quieres poder ver los detalles del experimento en cualquier momento, durante y después de una ejecución, incluyendo las propiedades relacionadas y los metadatos registrados. Dichos metadatos incluyen:

  • Algoritmos utilizados.
  • Métricas de rendimiento y resultados.
  • Duración del experimento.
  • Conjunto de datos de entrada.
  • Hora de inicio del experimento.
  • Identificador único para la ejecución.
  • Otras propiedades que puedas considerar necesarias.

También necesitarías comparar las ejecuciones en función de sus resultados y potencialmente entre experimentos.

Si es esencial para tu caso de uso, es posible que desees agregar características y atributos de explicabilidad a tu experimento utilizando esos atributos. Y, por supuesto, es posible que también desees promocionar o descargar tus modelos desde esta vista.

Tabla de ejecuciones en neptune.ai | Ver en la aplicación

Administrar el estado y optimizar el rendimiento son dos de las partes más complejas de construir el componente de interfaz de usuario. Comparar, por ejemplo, diez ejecuciones con miles de atributos cada una, muchos de los cuales deben mostrarse en gráficos dinámicos, puede causar muchos dolores de cabeza. Incluso los proyectos del tamaño de VoAGI pueden experimentar bloqueos constantes del navegador si los haces de manera ingenua.

Además del rendimiento, hay otros ajustes de interfaz de usuario que te permiten mostrar solo un subconjunto de los atributos de un proyecto, agrupar ejecuciones por atributos específicos, ordenar por otros, utilizar un editor de consultas de filtro con sugerencias y autocompletado, y más.

Backend del sistema

El backend del sistema respalda la lógica de tu solución de seguimiento de experimentos. Esta capa es donde codificas las reglas del dominio de seguimiento de experimentos y determinas cómo se crea, almacena y modifica los datos.

La interfaz frontal es uno de los clientes de esta capa. Puedes tener otros clientes, como integraciones con un registro de modelos, componentes de monitoreo de calidad de datos, etc. Lo que sería efectivo, como con la mayoría del software tradicional, sería crear servicios en esta capa y en la capa de API, de la cual aprenderás en la siguiente sección.

Para una herramienta básica de seguimiento de experimentos, debes implementar dos componentes principales del backend del sistema que deseas desarrollar:

  • 1
    Registro de usuarios, proyectos y espacios de trabajo.
  • 2
    Componente de seguimiento real.

Registro de usuarios, proyectos y espacios de trabajo

Este componente te ayuda a gestionar los usuarios de la herramienta de seguimiento de experimentos y realizar un seguimiento de sus actividades con los experimentos que ejecutan. Las principales cosas que este componente debe hacer son:

  • Gestionar la autenticación y autorización,
  • Administración y permisos del proyecto,
  • Cuotas (número de solicitudes por segundo, cantidad de almacenamiento) por proyecto o espacio de trabajo.

¿Qué nivel de detalle de permisos quieres implementar? Puedes elegir entre permisos granulares, roles personalizados y roles predefinidos más generales.

Componente de seguimiento

El componente de seguimiento es la lógica real de seguimiento de experimentos que debes implementar. Aquí hay algunas piezas que debes considerar implementar:

  • Almacenamiento de atributos.
  • Almacenamiento de blobs y archivos.
  • Almacenamiento de series.
  • Motor de consultas.

Almacenamiento de atributos

Tus ejecuciones tienen atributos (parámetros, métricas, muestras de datos, etc.), y necesitas una forma de asociar esos datos con las ejecuciones. Aquí es donde entra en juego el almacenamiento de atributos y la organización general de datos en una tabla, para que las búsquedas de datos sean fáciles de realizar para tus usuarios. Por supuesto, una base de datos relacional sería valiosa aquí.

¿Cuál es el nivel de consistencia que deseas? ¿Puedes aceptar una consistencia eventual? ¿O preferirías tener una consistencia fuerte a costa de una mayor latencia en la capa de API?

Almacenamiento de blobs y archivos

Algunos atributos no se ajustan fácilmente a un campo de base de datos, y necesitarías un modelo de datos para manejar esto. El almacenamiento de blobs es una solución altamente rentable. La ventaja principal es que puedes almacenar una gran cantidad de datos no estructurados. Tus usuarios pueden querer almacenar código fuente, muestras de datos (CSV, imágenes, DataFrames en pickle, etc.), pesos de modelos, archivos de configuración, etc. Esta solución resulta útil.

La consideración clave que debes hacer aquí es la rentabilidad a largo plazo del servicio de almacenamiento y el acceso de baja latencia.

Almacenamiento de series

Necesitas determinar una forma de almacenar series, especialmente series numéricas, que son atributos que requieren atención especial. Dependiendo de tu caso de uso, podrían tener decenas de miles o incluso millones de elementos. Podría ser un desafío almacenarlos de una manera que permita al usuario acceder a los datos en la interfaz de usuario. También puedes limitar el número de series que admites, digamos, a 1,000 elementos, lo cual es suficiente para muchos casos de uso.

Las consideraciones clave son:

  • 1
    Rentabilidad a largo plazo del almacenamiento.
  • 2
    El equilibrio entre funcionalidad.
  • 3
    Y la simplicidad de implementación relativa.

Motor de consultas

También necesitas agregar la función para filtrar ejecuciones con estructuras muy diferentes, lo que significa que necesitas un motor de base de datos robusto que pueda manejar este tipo de consultas. Esto es algo que una simple base de datos relacional no puede hacer de manera efectiva cuando la cantidad de datos no es trivial. Una alternativa es limitar severamente la cantidad de atributos de experimento que puedes filtrar o agrupar. Si vas a un nivel más bajo, algunos trucos y hacks de base de datos serán suficientes para resolver esto.

La consideración clave aquí es el equilibrio entre la cantidad de atributos que un usuario puede filtrar, ordenar o agrupar y la simplicidad de implementación.

Biblioteca de cliente (API e integración en el ecosistema)

En el nivel más alto, la capa de API se utiliza para proteger a los clientes de conocer la estructura, organización o incluso qué servicio expone una operación específica, lo cual es muy útil. No debería cambiar nada ni ejecutar lógica como lo hace la capa backend. En cambio, debería ofrecer una interfaz de proxy estándar que exponga los puntos finales del servicio y las operaciones de la API que se configuren para exponer.

Cuando se construye una herramienta de seguimiento de experimentos, una API cruda (nativa) generalmente no es suficiente. Para que la solución sea utilizable por los usuarios, debe integrarse sin problemas con su código. Si defines primero la capa de API, los clientes tendrán cambios mínimos, si es que tienen alguno, en respuesta a la refactorización subyacente del código base, siempre y cuando el contrato de la API no cambie.

En la práctica, esto significa que puedes tener una biblioteca (preferiblemente en Python) que haga el trabajo pesado de comunicarse con los servidores de backend para el registro y consulta de datos. Maneja reintentos y retrocesos; probablemente quieras implementar una cola persistente y asíncrona desde el principio, persistente para la durabilidad de los datos y asíncrona para que no ralentice el proceso de entrenamiento del modelo para tus usuarios.

Dado que la herramienta de seguimiento de experimentos también necesitará funcionar con tus herramientas de datos, entrenamiento y promoción de modelos, entre otras, tu capa de API debe integrarse con las herramientas en el ecosistema de ML y datos.

El ecosistema de ML y datos evoluciona, por lo que construir una integración no es el final. Debe ser probado con nuevas versiones de las herramientas con las que funciona y actualizado cuando las APIs se vuelvan obsoletas o, con mayor frecuencia, cuando cambien sin previo aviso. También puedes resolver esto dirigiendo a los usuarios a las versiones antiguas de la integración sin obligarlos a hacer cambios en su código de experimentación.

Consideraciones para la arquitectura del software de seguimiento de experimentos (backend)

Evaluar la viabilidad es una parte significativa de construir la estructura de su sistema de seguimiento de experimentos y evaluar si lo está construyendo correctamente. Esto implica desarrollar una arquitectura de alto nivel basada en los requisitos que ha establecido.

El diseño arquitectónico debe mostrar cómo las capas y componentes que ha analizado deben encajar en una arquitectura de capas. Por “arquitectura de capas” me refiero a distinguir su arquitectura frontend de su arquitectura backend. Este artículo se centra en las consideraciones para la arquitectura backend, donde se codifica la lógica para el seguimiento de experimentos.

Una vez que comprenda su arquitectura backend, también puede seguir los principios del diseño dirigido por dominio para construir una arquitectura frontend.

Capa de arquitectura backend

Para construir la arquitectura del sistema, siga algunos principios arquitectónicos de software que ayuden a que la estructura sea lo más simple y eficiente posible. Uno de esos principios describe la modularidad. Desea que el software sea modular y esté bien estructurado para que pueda comprender rápidamente el código fuente, ahorrar tiempo en la construcción del sistema y posiblemente reducir la deuda técnica.

Su herramienta para realizar un seguimiento de los experimentos casi con seguridad evolucionará, por lo que cuando desarrolle la primera arquitectura, será algo rudimentario y simplemente algo que funcione. Debido a que su arquitectura cambiará con el tiempo, deberá seguir patrones de diseño consistentes para ahorrar tiempo en el mantenimiento y la adición de nuevas características.

Esto es lo que parece la capa de arquitectura backend para una solución básica de seguimiento de experimentos, teniendo en cuenta los requisitos y componentes mencionados anteriormente:

Arquitectura backend de una herramienta de seguimiento de experimentos ideal

Usando las partes explicadas anteriormente, puede encontrar los diferentes módulos en la arquitectura y ver cómo funcionan juntos.

Consideración arquitectónica: separar autenticación y autorización

Puede haber notado en la arquitectura que la autenticación está separada de la autorización. Dado que puede tener diferentes usuarios, querría que validen sus credenciales a través del componente de autenticación.

A través del componente de autorización, el administrador de software puede gestionar los permisos y niveles de acceso para cada usuario. Puede leer más sobre la diferencia entre autenticación y autorización en este artículo.

La parte de gestión de cuotas del componente de gestión de usuarios ayudaría a gestionar el límite de almacenamiento disponible para los usuarios.

Consideraciones que debe tener en cuenta antes de construir una herramienta de seguimiento de experimentos

Por todo lo que vale, ha aprendido a nivel más alto lo que se necesita para construir software de seguimiento de experimentos. La siguiente pregunta natural entonces sería: “¿Qué consideraciones debo tener en cuenta antes de construir una herramienta de seguimiento de experimentos?”

Bueno, tal vez esa sea una pregunta tonta y no una que haría si el software estratégico de su organización, el producto principal que ofrece, es una herramienta de seguimiento de experimentos. Si no lo es, ¡debería seguir leyendo!

Probablemente ya esté familiarizado con este dilema de desarrollo de software: construir vs. comprar. Si la herramienta de seguimiento de experimentos es el software operativo de su organización (para respaldar las operaciones regulares de los equipos de datos y aprendizaje automático), la siguiente consideración importante para responder a esta pregunta sería el nivel de madurez de su organización en términos de:

  • Experiencia,
  • Talento,
  • y recursos (tiempo y dinero).
Consideraciones al decidir si construir o comprar una herramienta de seguimiento de experimentos

Echemos un vistazo a algunas de las preguntas que deberá hacerse al intentar tomar esta decisión.

¿Alguna vez su organización ha desarrollado una herramienta de seguimiento de experimentos?

Por ejemplo, si su organización nunca ha desarrollado un rastreador de experimentos, llevará más tiempo, prueba y error ponerse al día con los estándares de la industria, las mejores prácticas, la seguridad y el cumplimiento. Si no existe una “base” sobre la cual construir, especialmente desde su equipo de ingeniería, las construcciones chapuceras pueden quedarse cortas en comparación con los estándares de la industria y las expectativas de la empresa.

Usted y otros interesados deben considerar si una empresa puede permitirse la prueba y error o si se requiere una solución efectiva, más segura y confiable fuera de la estantería.

¿Qué talento está disponible para construir?

Si su empresa es una empresa de productos o software, es posible que ya tenga desarrolladores de software trabajando en su oferta estratégica. Debe considerar el costo de oportunidad de utilizar las habilidades de sus desarrolladores internos para construir una herramienta de seguimiento de experimentos en lugar de utilizar sus habilidades para mejorar su producto principal.

Desarrollar un rastreador de experimentos internamente podría mejorar significativamente su producto o la eficiencia del flujo de trabajo de su equipo de ML. Sin embargo, también podría llevarse las habilidades y el tiempo de sus desarrolladores para construir otras cosas que serían diferenciadores más significativos o terminar desperdiciando tiempo y esfuerzo.

¿Cuánto nos costaría construirlo?

Los costos de construir un rastreador de experimentos internamente son principalmente costos de mantenimiento. ¿La organización puede soportar el costo de mantener el software actualizado, solucionar errores y agregar nuevas características?

El presupuesto cubre la infraestructura necesaria para mantener la herramienta en funcionamiento y contratar nuevas personas en caso de que los desarrolladores originales se vayan. Piense en los efectos a largo plazo de un proyecto de desarrollo de software costoso y que consume tiempo, no solo en los ahorros a corto plazo.

Una gran parte de reducir los costos de mantenimiento es reducir la posibilidad de que surjan gastos inesperados y altos de una sola vez. En otras palabras, al igual que con los costos generales de mantenimiento, el mejor momento para gestionar el riesgo es al principio del ciclo de vida del software, cuando se determina si algo debe ser construido o externalizado.

¿Cuánto tiempo llevaría construir la herramienta de seguimiento de experimentos?

Debe considerar los costos de oportunidad. Por ejemplo, si se tarda dos meses en crear una herramienta personalizada, ¿en qué más podrías construir en ese tiempo? ¿Tomaría más de dos meses implementar el componente de seguimiento? ¿Cuántos ciclos de desarrollo tomaría construir la herramienta desde un POC hasta una versión final y estable?

Si eres parte de una empresa más grande y tienes suficientes ciclos de desarrollo para construir un rastreador de experimentos, puede que no sea un problema. ¿Qué tal cuando no lo es, especialmente un problema único para tu caso de uso? Obtener una solución lista para usar que se integre con tu stack para que puedas centrarte en construir tu software estratégico puede funcionar mejor.

Es poco probable que tengas suficientes ciclos para llegar al nivel de sofisticación y riqueza de características que necesitas de una herramienta estándar de gestión de experimentos, por lo que puede que no valga la pena dedicar tus ciclos de desarrollo a ella.

Por ejemplo, en neptune.ai, nos hemos dedicado exclusivamente en los últimos cinco años a construir un robusto almacén de metadatos para gestionar todos los metadatos de construcción de modelos para tus usuarios y rastrear sus experimentos. Hemos aprendido de los clientes y de la comunidad de ML y hemos mejorado continuamente el producto para que sea robusto en varios casos de uso y cargas de trabajo.

Codificar más rápido a expensas del diseño y la arquitectura casi siempre es la elección incorrecta. Esto es especialmente cierto si el software está en funcionamiento porque tienes menos tiempo para enfocarte en una buena arquitectura y construir las características que debe tener. Después de todo, no es un software estratégico que impacte o defina directamente tu organización.

Reflexiones finales

Hemos cubierto bastante en este artículo; resumamos algunas conclusiones clave:

  • El seguimiento de experimentos es una actividad intensa. El uso de las herramientas adecuadas y la automatización lo hace fácil de usar y eficiente.
  • Desarrollar requisitos efectivos para una herramienta de seguimiento de experimentos debería requerir: considerar qué usuarios aprovecharán el software y cómo se integrará con su pila de datos y sus servicios posteriores. Básicamente, pensar en los requisitos mínimos necesarios para ponerlo en marcha, sin involucrar sofisticación.
  • La capa backend del software de seguimiento de experimentos es la capa más esencial para implementar. Debe asegurarse de implementar el componente de seguimiento y el registro de espacio de trabajo para gestionar las sesiones de usuario de manera fluida.

Su objetivo al construir un rastreador de experimentos es asegurarse de proporcionar el componente para que sus usuarios registren datos de experimentos, realicen un seguimiento de esos experimentos y colaboren de manera segura en ellos. Si pueden hacerlo sin complicaciones, es probable que haya construido lo que funciona para su equipo.

En la mayoría de los casos, vemos que construir la primera versión es solo el primer paso, especialmente si no es un componente de software principal para su organización. Puede resultar difícil agregar nuevas características a medida que aumenta la lista de requisitos de usuario debido a nuevos problemas.

Usted y las partes interesadas relevantes deben considerar el valor de dedicar recursos para mantenerse al día con las necesidades de sus usuarios y, potencialmente, los estándares de la industria.

Próximos pasos

¿Entonces, ¿a dónde vas desde aquí? ¿Emocionado por construir? ¿O crees que tomar alguna solución lista para usar funcionaría?

La mayoría de las plataformas de registro de modelos que consideramos asumían una forma específica para almacenar modelos. Esto tomó la forma de experimentos, cada modelo era el siguiente en una serie. En el caso de Stitch Fix, nuestros modelos no siguen un patrón de segmentación lineal. 

Podrían aplicarse a regiones específicas, líneas de negocio, experimentos, etc., y todos ser algo intercambiables entre sí. La gestión sencilla de estas dimensiones era fundamental para cómo los científicos de datos necesitaban acceder a sus modelos.

— Elijah Ben Izzy y Stefan Krawczyk en Deployment for Free;
Una plataforma de aprendizaje automático para los científicos de datos de Stitch Fix

Esto fue Stefan Krawczyk hablando de por qué decidieron construir un registro de modelos en lugar de utilizar soluciones existentes. En el mismo contexto, a menos que tengas requisitos especiales que las soluciones de código abierto o pagas existentes no cumplan, construir y mantener una herramienta de seguimiento de experimentos puede no ser el uso más eficiente del tiempo y esfuerzo de los desarrolladores.

¿Te gustaría profundizar más o simplemente charlar sobre la construcción de un rastreador de experimentos? Ponte en contacto con nosotros; nos encantaría intercambiar experiencias.

Por supuesto, si decides omitir la construcción y en su lugar usar Neptune, siéntete libre de registrarte y probarlo primero. ¡Contáctanos si tienes alguna pregunta!

Referencias y recursos

  • Desarrollo de modelos de aprendizaje automático explicables y reproducibles con DALEX y Neptune – neptune.ai
  • ¿Deberías comprar o construir software? – YouTube

We will continue to update Zepes; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more

Inteligencia Artificial

Este boletín de inteligencia artificial es todo lo que necesitas #71

Esta semana, el presidente Joe Biden volvió a poner la regulación de la inteligencia artificial en el punto de mira a...

Inteligencia Artificial

Investigadores de NVIDIA y la Universidad de Tel Aviv presentan Perfusion una red neuronal compacta de 100 KB con un tiempo de entrenamiento eficiente.

Los modelos de texto a imagen (T2I) han inaugurado una nueva era de flexibilidad tecnológica, otorgando a los usuario...

Noticias de Inteligencia Artificial

Robot utiliza una frambuesa falsa para practicar la recolección de frutas.

Los científicos diseñaron un robot que practicó la recolección de frambuesas en una réplica de frambuesa de silicona ...

Inteligencia Artificial

Las Nuevas Implicaciones Éticas de la Inteligencia Artificial Generativa

El rápido progreso del IA generativa hace necesario implementar urgentemente salvaguardias éticas contra los riesgos ...

Inteligencia Artificial

Investigadores de Apple y CMU revelan el Aprendiz de IU Sin Fin Revolucionando la accesibilidad de las aplicaciones a través del Aprendizaje Automático Continuo

El aprendizaje automático se está integrando cada vez más en una amplia gama de campos. Su uso generalizado se extien...