Planificar proyectos de AA es diferente a planificar proyectos típicos de ingeniería de software. Los proyectos de AA son típicamente no lineales y tienen distintos grados de incertidumbre. Requieren un enfoque iterativo y una mentalidad experimental.
Incertidumbre del proyecto
La planificación en las primeras etapas puede ser difícil porque, por lo general, el mejor enfoque no es evidente al comenzar un proyecto. Esta incertidumbre inherente hace que estimar los plazos sea difícil.
En una competencia reciente de Kaggle, se ilustra la incertidumbre de los proyectos de AA. En las primeras semanas de una competencia, participaron 350 equipos. Algunos equipos pudieron aumentar la calidad de predicción de las comparativas del 35% al 65%. Durante las dos semanas siguientes, la cantidad de equipos que trabajaban en el problema aumentó de 350 a 1,400. Sin embargo, el mejor modelo solo alcanzó una calidad de predicción del 68%.
En la Figura 3, se ilustra la incertidumbre en el desarrollo del AA, ya que se muestra el aumento significativo en el esfuerzo, pero solo las ganancias mínimas en la calidad del modelo.
Figura 3. Durante un período de dos semanas, la cantidad de equipos que trabajaban en el problema se incrementó en un factor de 4, pero la calidad del modelo se mantuvo casi igual, lo que resaltó la dificultad de estimar el esfuerzo de una solución de AA.
En otras palabras, más de mil equipos, cada uno de los cuales experimentó con una variedad de transformaciones de datos, hiperparámetros y arquitecturas, solo lograron producir un modelo con una calidad de predicción del 68%.
En un ejemplo de la industria, se ilustra la no linealidad de los proyectos de AA, en los que los resultados no son proporcionales a las entradas. Dos equipos tardaron varios meses en entrenar un modelo con una calidad de predicción del 90%. Sin embargo, varios equipos demoraron más de cinco años en preparar el modelo para la producción con una calidad de predicción del 99.9%.
En estos ejemplos, se destaca que el AA listo para la producción es un proceso exploratorio que requiere una mentalidad tanto científica como de ingeniería.
Enfoque experimental
En la mayoría de los casos, el desarrollo del AA se parece más a realizar experimentos que a practicar la ingeniería de software tradicional. El AA requiere probar diferentes características y arquitecturas, y ajustar los hiperparámetros de manera adecuada. Por definición, no se garantiza que los experimentos sean exitosos. Debido a esto, es mejor planificar el uso de un framework experimental.
Veamos un plan típico de ingeniería de software para ver en qué se diferencia de un plan de proyecto de AA.
Planificación de proyectos de ingeniería de software
En un plan de ingeniería de software típico, debes definir los requisitos, describir los componentes, estimar el esfuerzo y programar el trabajo. Hay un camino definido con claridad hacia una solución. Por ejemplo, los ingenieros suelen saber con un alto grado de certeza qué tareas deben completar para compilar una aplicación que cumpla con las especificaciones de diseño.
Cuando predicen el tiempo que llevará completar una tarea, pueden estimar el trabajo en función de proyectos similares. Aunque se presentan desafíos invariables, como dependencias desconocidas o requisitos cambiantes, que pueden dificultar la estimación a veces, por lo general, existe una ruta clara hacia la solución.
Por el contrario, los proyectos de AA no suelen tener una ruta clara hacia el éxito.
Planificación de proyectos de AA
Para la mayoría de los proyectos de AA, encontrarás la mejor solución si experimentas con varios enfoques en un proceso de prueba y error. Por lo general, no sabrás cuál es la solución óptima para tu problema antes de intentar resolverlo. Por ejemplo, la arquitectura de la solución óptima podría ser un modelo lineal simple, una red neuronal o posiblemente un árbol de decisión. Solo si pruebas cada enfoque, podrás descubrir la mejor solución.
Esta ambigüedad dificulta la planificación. Como dijimos antes, es difícil predecir el esfuerzo que requerirá un proyecto de AA. Solo si intentas resolver el problema, puedes tener una mejor idea de la cantidad de tiempo y recursos que puede requerir una solución.
Las siguientes son estrategias recomendadas para planificar el trabajo del AA:
Organiza el trabajo en un plazo determinado. Establece plazos claros para completar las tareas o intentar una solución en particular. Por ejemplo, puedes asignar dos semanas para determinar si puedes acceder al tipo correcto de datos. Si puedes obtener los datos, podrías designar dos semanas más para ver si un modelo simple indica que una solución de AA es factible. Si un modelo simple falla, podrías destinar dos semanas más a probar una red neuronal. Al final de cada período, tendrás más información para determinar si seguir aplicando recursos al problema vale la pena.
Determina el alcance de los requisitos del proyecto. Si una solución de AA parece prometedora, pero no es una característica fundamental de tu producto o servicio, revisa sus requisitos. Por ejemplo, cuando planificas el trabajo del trimestre siguiente, puedes probar una solución muy simple. Luego, en los trimestres siguientes, es posible que planifiques mejorar la solución de forma iterativa. Muchos equipos llegaron a soluciones de AA impactantes mediante la implementación de una solución de AA mediante mejoras incrementales en un horizonte de tiempo más prolongado.
Proyecto de pasante o empleado de Google nuevo. Dirigir y guiar a un pasante o empleado de Google nuevo para que pruebe una solución de AA puede ser una buena manera de comenzar a explorar un espacio nuevo con resultados desconocidos. Una vez que el proyecto finalice, tendrás una mejor idea del esfuerzo que requerirá una solución de AA y de los enfoques potencialmente prometedores que se deberán aplicar, o si los recursos deben destinarse a otro lugar.
Con cualquier estrategia, lo más sabio es fallar rápido. Intenta primero abordar los enfoques con los costos más bajos, pero posiblemente con el mayor beneficio. Si el enfoque funciona, has encontrado una buena solución. Si no es así, no has desperdiciado mucho tiempo y recursos.
A medida que los equipos adquieran experiencia y se expongan a ejecutar experimentos, podrán estimar mejor el esfuerzo que puede requerir un experimento, lo que hará que la planificación sea más predecible. Sin embargo, el resultado de un experimento casi siempre será desconocido, por lo que no se puede estimar de antemano la cantidad de experimentos necesarios para encontrar la mejor solución.
Planificar enfoques con una mentalidad experimental ayuda a preparar a tu equipo para el éxito. Cuando un enfoque conduce a un callejón sin salida, en lugar de desanimarse, los miembros del equipo comprenden que eso es parte del proceso de encontrar una solución de AA. Lo más importante es que, si analizas con las partes interesadas la incertidumbre inherente al desarrollo del AA, puedes establecer expectativas más realistas.
Recuerda
Aprender a planificar múltiples enfoques de AA, probabilísticamente, requiere tiempo y experiencia. Es posible que el plan de tu proyecto requiera actualizaciones frecuentes. Considéralo un documento dinámico en constante evolución a medida que tu equipo experimenta con varios enfoques. Si te enfocas en las siguientes ideas clave, aumentarás tus posibilidades de éxito:
- Estima el costo y las probabilidades de éxito de cada enfoque.
- Intenta con una cartera de enfoques.
- Identifica las lecciones aprendidas y trata de mejorar el sistema una cosa a la vez.
- Planifica para las fallas.
En ocasiones, un enfoque inicial conduce a un avance. Es posible que alguien descubra un error en la canalización de generación de datos o en la división de validación y entrenamiento. Con una buena planificación y una documentación exhaustiva, aumentas la probabilidad de que encuentres un modelo que resuelva el problema del negocio antes de lo esperado.