wAIsh it: El cuidado de tu ropa bajo control con AI Builder

Una de las tareas que más me gusta de mi trabajo es diseñar soluciones y detectar procesos de negocio para llevarlos a la Power Platform. Incluso en mi tiempo libre, a cualquier situación cotidiana rápidamente le busco la resolución más Power ⚡️

Un día iba a meter un vestido a la lavadora cuando me di cuenta que quizás era más delicado de lo que recordaba y decidí mirar su etiqueta. Sorpresa: la corté tiempo atrás; normalmente siempre elo hago, me molestan mucho y algunos fabricantes tienden a ponerlas en los peores sitios… En ese momento pensé: qué bien me iría una aplicación donde pudiera guardar el tratado de toda mi ropa. Podría referenciarlo por una fotografía de la prenda o por nombre. Luego me surgió otra duda en la cabeza: a veces ni siquiera recuerdo lo que significan los símbolos de esas etiquetas…

Le fui dando vueltas y en ese momento me surgió una idea: Crearía la aplicación, le añadiría Inteligencia Artificial y así reduciría el tiempo de consulta. ¡AI Builder al rescate! Además, sería la manera perfecta para poner la detección de objetos de AI Builder a prueba.

Empezando

Definí las dos funcionalidades principales:

Poder hacer una fotografía a una prenda de ropa, que la aplicación me reconociera de qué prenda se trataba y me listara sus cuidados
Poder hacer una fotografía a una etiqueta de lavado de una prenda, que la aplicación me reconociera los símbolos y me explicara qué significaba cada uno.

Tenía que definir entonces con qué prendas realizaba la Prueba Piloto y qué símbolos serían los escogidos para formar parte del segundo modelo. Abrí mi armario e hice un poco de análisis hasta que estos fueron los resultados:

Para el primer modelo 8 prendas de ropa, cada una con su razón de ser. Dos vestidos, cada uno de una forma y con un estampado distinto, pero con las características comunes de ser vestidos. Un pañuelo con distintos estampados y una forma totalmente irregular. Una blusa ligera de tejido vaporoso y estampado muy muy claro. Un blazer azul oscuro. Un jersey vintage con un estampado bastante característico incluso impide a veces la visibilidad total de las mangas. Por último, una falda y un top con exactamente el mismo estampado: fondo negro con lunares blancos. Las piezas de ropa tienen la particularidad que es muy difícil fotografiarlas en dos situaciones distintas y que salga exactamente la misma forma 😊

Para el segundo modelo: 11 modelos de símbolos, los más comunes y suficientemente variados en simple análisis a mi armario.

A partir de aquí empezó la diversión. Decidí que el modelo de las piezas de ropa sería más completo que el de los símbolos, proporcionando en versión final de entrenamiento 306 imágenes de las 8 prendas de ropa y 98 de los iconos (fui mejorando el modelo para ir viendo como la puntuación subía según añadía más imágenes). El primero cumpliría el umbral recomendado de 50 imágenes por objeto y el segundo solo llegaría al mínimo de 15.

Diseñar el modelo de datos

Una vez definidos cómo serían mis dos modelos de AI, antes de generarlos tenía que crear las entidades en mi CDM. Si bien a los modelos podemos proporcionarles el nombre de los objetos a mano, me interesaba que la información la sacara de la base de datos. Al fin y al cabo, esta información también formaría parte de mi aplicación.

Creé 2 entidades: Treatment (los cuidados de la ropa) y Item (la pieza de ropa) con los siguientes atributos (super sencillo, ya veis):

Además, creé una tercera entidad que representaba la relación N:M bajo el nombre de Treatment_Item. Ahí guardé por cada pieza de ropa, qué cuidados le correspondían (es decir, la Lookup de Treatment con Lookup de Item).

Una vez definidos los modelos y cargados los datos (con un .CSV) pasé a crear los dos modelos. Escribí una entrada sobre cómo se crean y entrenan los modelos de detección deobjetos en AI Builder. Echadle un ojo si queréis más información al respecto.

Resultado: 93/100 de fiabilidad en 5a versión del modelo de las prendas de ropa y fiabilidad de 47/100 en 2a versión (fue duro etiquetar tantos iconos) del modelo de símbolos de tratado.

Una vez los modelos ya estaban listos 🙌🏻 Tocó desarrollar la aplicación.

¡Deberéis esperar a segunda parte de la entrada para saber cómo lo hice!

Hasta este momento me encontré con algunas situaciones que me gustaría exponeros a modo de conclusión:

Si nos equivocamos (error ortográfico) en el nombre de uno de los objetos trabajando con entidades, el error no se puede reparar, aunque cambiemos el nombre y volvamos a entrenar el modelo. La etiqueta ya está guardada con el nombre erróneo en el modelo de AI Builder. Se supone que al re-entrenar el modelo puedes cambiarle el nombre, pero sin éxito. Desconozco si es un bug o de momento es un caso no contemplado.

Las entidades creadas por AI Builder son solo de lectura, si te ocurre algo como el punto anterior de momento no hay manera de “meter mano” y enmendar el problema

No puedo crear submodelos (en el caso de detección de objetos) algo que sí está disponible en la predicción. No puedo configurar parámetros que ayuden al modelo a reducir las posibles opciones de detección. Sería genial que yo hubiera podido clasificar los objetos del primer modelo según si son vestidos, blusas o pantalones en general (algo que sí podríamos hacer en un servicio cognitivo totalmente desarrollado por nosotros).

Tras hacer unas pruebas, el modelo de ropa era capaz de diferenciar entre las prendas con el mismo estampado, aunque estuvieran juntas. El modelo reconoce el pañuelo de seda en cualquier posición y colocación, fabuloso.

Tras hacer unas pruebas, el modelo de símbolos es muy fiable, aunque tenga baja puntuación. Confunde símbolos no introducidos en el modelo con otros que sí están (por ejemplo confunde el símbolo de lavar a 60º con el de 30º). Era un resultado esperado.

Sería fantástico poder acceder al modelo generado por AI Builder. Al final todo queda en casa 😊 Y todo el algoritmo de atrás está almacenado seguramente en Azure. Del mismo modo que podemos empezar una Logic App a partir de un Flow de Power Automate, sería fantástico darle una base (creada por un agente de negocio) al desarrollador que en Azure y con servicios cognitivos podría aumentarle la complejidad.