Cómo implementar Inteligencia Artificial y no morir en el intento.
Carlos Secada
Fundador & CEO en Zagitas - Automatizacion de Procesos con IA | Copilotos con Gen IA | Microsoft, Celonis Partners
Las empresas luchan por crecer con proyectos de Inteligencia Artificial
Actualmente vivimos la era de la acumulación de datos y existe un deseo generalizado, y a todo nivel, por el uso innovador de la Inteligencia Artificial (IA) y su aplicación en los negocios. Tal vez sea el momento de detenerse y reflexionar sobre ese ardiente deseo de utilizar la IA en todas partes y considerar la “Ley del Instrumento” por un momento: “si lo único que tienes es un martillo, todo te parecerá un clavo”.
Dirígete a la parte final de este articulo y con 10 preguntas evalúa tu nivel de calidad en la creación de Productos con IA .
Hay muchos informes que alertan sobre los problemas que sufren las empresas al implementar o adoptar AI en sus negocios. Gartner estimó que el 60% de los proyectos de Analítica y de Inteligencia de Negocios fracasaron, y luego incluso reconoció que la realidad era peor. Según el analista de Gartner Nick Heudecker, Gartner era "demasiado conservador" con su estimación del 60% [*]. La tasa real de fracaso se acerca al 85%. Por lo tanto, si estás enfrentando algún tipo de dificultad, piensa que no estás solo y, si no lo estás pensando, piensa que podrías estar necesitando una visión realista de tu situación. De acuerdo con nuestra experiencia con clientes en diferentes sectores y países, las situaciones más frecuentes que las empresas enfrentan, podrían resumirse de la siguiente manera: (¿alguna de éstas te suena familiar?)
1. Sin experiencia pero con presupuesto: grandes inversiones y mucho interés, pero no tienen experiencia en desarrollar proyectos de Analítica avanzada de datos e Inteligencia Artificial, lo que significa que se perderá mucho tiempo antes de lograr cualquier tipo de resultados.
2. Sin soporte: Empresas sin soporte del área de negocio. Muchas buenas ideas se ponen en cola debido a la falta de implicación de las partes interesadas correctas.
3. Objetivo claro pero equipo ineficiente para desarrollarlo: los equipos trabajan duro pero no logran nada o los resultados son decepcionantes para la empresa.
4. Ambicioso: empresas con presupuesto y, a veces, recursos ilimitados, pero no están preocupados por las limitaciones de la tecnología. Esta situación podría llevar a la frustración al tratar de aplicar las soluciones a una gran escala.
5. Falta de datos: los datos están incompletos o totalmente en silos. Este tipo de empresas debe invertir primero en construir y preparar sus sistemas de datos para poder acceder a Analítica Avanzada. También podemos incluir aquí los problemas con la calidad de los datos, que no es un problema menor.
6. Teórico: empresas con un buen equipo de análisis, pero sin conocimientos sobre metodologías ágiles o ciencia de datos, y dificultades para escalar o implementar modelos en producción.
7. Ingenuo: las empresas que creen que el ML es magia. ¡Buena suerte!
¿Cómo podemos evitar las principales trampas?
El objetivo de este artículo es que sirva como fuente para la discusión, y presentar un enfoque diferente para realizar y comprender Analítica Avanzada, en su real dimensión en la arquitectura empresarial.
Piénsalo. Muchas veces la forma en que se desarrollan estos proyectos es básicamente utilizando un proveedor con un objetivo que rara vez se alinea con las prioridades de la empresa. ¿Hasta qué punto podemos tercerizar el desarrollo de un producto de datos? No es raro que el proveedor intente desarrollar el modelo más preciso o el que mejor se adapte, sin centrarse en el propósito subyacente y final de proyecto que es, por supuesto, que sea útil. ¿Han calculado cuál es la relación entre la precisión del modelo y el ROI? ¿Es relevante? No es raro terminar en una situación en la que se implementa un muy buen modelo, pero nadie es capaz de convertir eso en dinero, nuevos ingresos o ahorros de costos. Entonces, ¿hemos implementado un modelo muy bueno que es simplemente inútil? O por el contrario, ¿hemos implementado un modelo muy malo que no es mucho mejor que una predicción aleatoria para ese conjuntos de datos? ¿Quién supervisa los modelos una vez en producción? Hay demasiadas preguntas por responder…
Para resumir, las partes básicas en las que las empresas deben concentrar sus esfuerzos son: uso y aplicabilidad. Todo lo que una empresa planea construir utilizando Datos e IA debe seguir la filosofía de desarrollar un producto. Las empresas deben estar obsesionadas con su proceso de desarrollo tanto como lo están cuando crean un nuevo producto para sus clientes. Hazlo rentable o abandónalo.
Además, una empresa involucrada en un Prueba de Concepto (PoC), sólo centrándose en el componente tecnológico es muchas veces un esfuerzo incompleto que puede también conducir al fracaso, no sólo porque el modelo o los datos no son buenos, sino porque se pierde la orientación hacia el negocio. Por eso, en lugar de trabajar en piezas aisladas, lo que proponemos en este artículo es trabajar con metodologías ágiles, desarrollando versiones completas de un producto con funcionalidad limitada pero con la participación y compromiso de todas las partes interesadas. Esto no es nuevo en el mundo del software, pero aparentemente todavía no está impregnado en las mentes de quienes crean soluciones o productos basados en datos, a los que llamaremos Productos de Datos.
¿Qué necesitas para construir un Producto de Datos?
Esperemos que a estas alturas nos quede claro lo que la experiencia nos ha enseñado: no debe ser subestimada una definición clara de equipos, metodologías y responsabilidades. Esta es la razón por la que proponemos una estrategia de “delimitación” para el desarrollo de Productos de Datos. En nuestro próximo artículo profundizaremos en los detalles al respecto. Por ejemplo, de qué forma cada Flujo de Trabajo debe trabajar de forma aislada, y cómo todos los equipos pueden colaborar entre si sin crear confusión. Mientras tanto, ésta es nuestra propuesta de equipos, áreas de enfoque y quiénes deberían ser sus miembros:
(Miembros principales del equipo y áreas de enfoque.)
De la misma forma, se puede discutir mucho sobre qué metodología es mejor, pero recomendamos no perder demasiado tiempo en elegir la perfecta. Las metodologías aplicadas pueden ser las que defina tu empresa: Ágil, Proceso de Ciencia de Datos en Equipo, Sesiones de Diseño de Arquitectura, Design Thinking, Diseño de UX, solo por mencionar algunos ejemplos. Lo importante es elegir una metodología que se alinee con las habilidades de su equipo y se centre en el resultado final del negocio.
Para ilustrar la complejidad de las relaciones entre los diferentes equipos, vea la siguiente imagen, donde describimos los principales hitos y dependencias para lograr una versión completa del PoC o nuevo lanzamiento funcional.
(Flujos de Trabajo involucrados en el desarrollo de Productos de Datos.)
Conclusión
Acabamos de tocar superficialmente las razones que podrían bloquear o demorar sus proyectos de datos, hemos reconocido que muchas empresas están luchando para que sus proyectos de datos sean rentables o simplemente útiles, y hemos propuesto una forma de organizar los diferentes flujos de trabajo. ¿Que sigue?
¿Por qué no empezar a reflexionar sobre los cinco temas mencionados anteriormente y cómo tu empresa los aborda?
1. Metodología
2. Datos
3. Equipo
4. Tecnología
5. Orientación empresarial.
Y hazle a tu equipo las siguientes preguntas:
- ¿Es tu equipo capaz de mostrar resultados tangibles en un corto período de tiempo?
- ¿Están esos resultados directamente relacionados con el problema de negocio que tu equipo originalmente estaba tratando de resolver?
- ¿Las personas de negocio que están directamente vinculadas en el problema, pueden sugerir configuraciones de parámetros?
- ¿Influye la tecnología en tu decisión de alguna manera? Por ejemplo, "mi equipo se siente cómodo usando SAS, no tenemos big data, por lo que no necesitamos ninguna otra tecnología que no sea esa".
- ¿Es tu equipo consciente de la relación entre la precisión en sus modelos y el impacto monetario? Por ejemplo, ¿un 1% de precisión en sus modelos significa algo para tus objetivos de negocio?
- ¿Pueden volver a crear sus experimentos con el mismo conjunto de datos que probaron hace 3 meses y comparar sus resultados?
- ¿Está tu equipo utilizando alguna herramienta de control de fuentes? ¿Alguna herramienta de prueba? ¿Cualquier herramienta que no sean los “notebooks”? ¿Alguien está haciendo revisiones de código para el código que escribe tu equipo?
- ¿Pueden explicar los resultados de su algoritmo en caso de que en el mundo real algo salga mal? Por ejemplo, en el caso de un falso positivo otorgando un crédito, ¿pueden explicar por qué al departamento de riesgos?
- ¿Tienen procesos para poner modelos en producción? ¿Se puede realizar una prueba de carga? ¿Pruebas de rendimiento? ¿Implementar sin detener el servicio?
- ¿Tienen definido un rol de asesoría ética en tu empresa? ¿El departamento legal está al tanto de tus productos de datos?
Referencias:
Traducido por Carlos Secada del original por David Flórez Fernández y Pablo Peris