Existe una cita muy común para describir la inteligencia artificial: “La inteligencia artificial es como el sexo adolescente. Todo el mundo habla de ello, nadie sabe realmente cómo hacerlo, todo el mundo cree que los demás lo hacen y en consecuencia, todos dicen que lo hacen.”
Si buscas en internet, sueles encontrar dos tipos de perfiles con sus enfoques. Por un lado, unos llenos de teoría y fórmulas matemáticas que nadie entiende, por otro lado, gurús profetizando sobre la aplicación de la inteligencia artificial como un futuro revolucionario, que te ayudará a bajar los costes de producción, como una solución que funciona perfectamente y mejor que las personas. En teoría, estos dos perfiles tienen razón en sus respectivos puntos de vista, pero en la práctica si de forma individual intentan llevar un proyecto al mundo real, muy probablemente fracasarían.
El modelo simple del ciclo de vida de un proyecto de Machine Learning contiene 5 etapas: definir los objetivos de negocio, acceder, entender y limpiar los datos, construir el modelo de Machine Learning, desplegar el modelo, iterar. La definición de los objetivos las realizaría un perfil de negocio con conocimientos técnicos, nuestro “Hannibal Smith”. Si no disponemos de tal perfil, tendremos una persona de negocio asistida por el data scientist. Quien mejor que “M.A. Baracus” para escarbar entre las diferentes fuentes de información y extraer los datos y entenderlos, él se hace llamar data engineer o back-end. Cuando M.A. tiene los datos se los entrega “Félix”, nuestro sofisticado y refinado data scientist. Felix se encarga de crear un modelo de ML (Machine Learning) que explotará lo máximo posible esos datos para los objetivos que ha definido Hannibal. En la siguiente etapa tenemos a “Murdock”, nuestro MLOps. Dentro de su mundo de locura se encarga de desplegar en servicios en la nube o de integrar en una solución software el modelo que ha creado Felix. Finalmente, cuando se completa la misión, lo que hacemos es iterar para ir mejorando el modelo, mantener la calidad esperada, añadir nuevos componentes o cambiarlo por otros.
Una buena aproximación para organizar estos equipos y llevar proyectos de inteligencia artificial es utilizar metodologías como Seis sigma, en especial por su proceso de 5 etapas DMAIC (o su variante de 6 etapas DMADOV) y por el reparto de roles. Concretamente, los roles de champions (altos directivos) y los black belt (expertos técnicos). En el mundo ideal, esos dos roles serían la misma persona (un directivo con conocimientos técnicos) y con eso garantizamos el buen camino del proyecto, pero en el mundo real ese perfil apenas existe. Como consecuencia ambos perfiles deben trabajar a un mismo nivel en la toma de decisiones de las 5 etapas. De esa manera, se consigue llegar a soluciones que le sirven al cliente (conocimiento del champion) con un enfoque viable debido a los requisitos del problema y de los recursos disponibles (conocimiento del black belt).
“La inteligencia artificial es como el sexo adolescente. Todo el mundo habla de ello, nadie sabe realmente cómo hacerlo, todo el mundo cree que los demás lo hacen y en consecuencia, todos dicen que lo hacen”
Pongamos un ejemplo clásico, un almacén de frutas y verduras. En este almacén hay un punto donde se deben separar tomates, naranjas y manzanas. En la actualidad en ese punto hay una persona haciendo esa división, pero hace más falta en otro punto por lo que se plantean una división automática. ¿Qué debería buscar el champion? Al disponer del conocimiento del negocio sabe que hay gran variedad en una misma fruta o verdura. Debe averiguar si se quiere para todas las variantes de naranjas (tamaños y formas), si llegarán diferentes variedades de manzana (colores) o si los tomates llegan desde el principio hasta el final de la temporada (cambio de color según el momento). Debe estudiar sobre qué presupuesto se puede mover el cliente, que ocurre si la máquina clasifica mal ¿el cliente sufrirá un gran impacto? ¿La propia naturaleza del trabajo del cliente puede corregir ese error? ¿Qué KPIs vamos a mejorar? ¿Cómo se evalúan estos KPIs? ¿Cuál es la calidad mínima esperada?… Por otro lado, tenemos el black belt. Este sabe los requisitos y limitaciones de la tecnología y se preguntaría cosas como ¿Qué velocidad de clasificación estamos hablando, segundos o milisegundos? ¿Estamos limitados por el hardware del cliente? ¿De cuánta cantidad de datos disponemos y de qué tipo son? ¿En qué entorno se busca la solución, al aire libre o en un interior?
Cada uno de forma individual puede generar muchas ideas posibles, pero requieren del otro para eliminar las que no son viables. Es en este punto donde muchas empresas no llegan a ver la luz en proyectos de inteligencia artificial. De nada sirve que el black belt cree una solución donde por la naturaleza del trabajo del cliente esta solución no aporte valor, ni tampoco sirve venderle al cliente una solución que técnicamente no se puede desarrollar.
Una metodología que no es buena para este tipo de soluciones, son las llamadas Ágiles, por poner un ejemplo Scrum. No cuadran debido a la propia naturaleza de ambos, son opuestas. Uno de los objetivos principales de Scrum es el desarrollo incremental en lugar de una planificación y ejecución completa del producto. En general, un proyecto de inteligencia artificial es como construir un puente, analizas el entorno, estudias la carga que debe soportar, la resistencia al viento, se hacen los planos, se construye bajo la guía de estos.
Y claro, en la práctica esto es un inconveniente para las metodologías ágiles. Un modelo de Machine Learning al fin y al cabo es un componente software que se integrará en muchas ocasiones dentro de una solución software. Lo más probable es que el desarrollo de esta solución software siga una metodología ágil, en consecuencia, llega el conflicto. Eso no significa que en ningún caso ambas partes no puedan ir de la mano, puede hacerse, pero bajo ciertas circunstancias. Por ejemplo, si las bases de la primera iteración están bien asentadas bajo una planificación completa del producto, las consecuentes iteraciones pueden aproximarse mejor a un entorno ágil. O si en vez de definir un producto lo que queremos es experimentar con la tecnología para conocer sus requisitos y límites o ver como afecta en algún producto, también puede hacerse mediante metodologías ágiles. Y al igual que pasaba con el champion de Seis sigma, aquí el Product Owner debería tener conocimientos técnicos. Como este perfil es extraño, hay que buscar una buena colaboración entre eI Product Owner y los desarrolladores.
Escojas un camino u otro, de la mejor forma que puedas, al final tienes que adaptarte al propio flujo de trabajo de MLOps, uno de los temas de moda, pero esto lo haremos en el siguiente episodio del equipo A de los datos.
