A lo largo de esta serie de artículos, he cotejado los distintos tipos de IA (IA Gen y IA "antigua", incluido el aprendizaje automático/ML, el procesamiento del lenguaje natural/PLN, etc.), ya que los componentes de IA de una solución suelen ajustarse todos a un patrón similar, en concreto, el de una entrada definida procedente del negocio (por ejemplo, datos estructurados o texto de consulta) que da lugar a una salida concreta (por ejemplo, datos numéricos predichos o texto generado), que fluye a través del resto de la solución y, en última instancia, hacia el negocio.
Sin embargo, llegados a este punto, merece la pena hacer un breve paréntesis para destacar la principal diferencia entre la IA Gen y otras variedades, en concreto cómo se desarrolla el modelo, ya que tiene importantes implicaciones para las fases prácticas de desarrollo e implantación de una solución de IA.
Los modelos tradicionales de IA, como los que se desarrollan en los proyectos de ML, toman un conjunto de datos de entrenamiento (a menudo obtenidos para este fin concreto) y los combinan con un algoritmo seleccionado para este mismo fin, lo que da como resultado un modelo entrenado específico para los datos en los que se ha entrenado y la aplicación para la que se ha desarrollado. Volviendo al ejemplo de la identificación de la pérdida de clientes del artículo anterior, en este caso los datos serían específicos de esa organización, con el modelo resultante adaptado a ese caso de uso concreto.
Esta descripción pasa por alto los detalles del proceso de desarrollo de un modelo de ML con el que muchos científicos de datos e ingenieros de ML están muy familiarizados. Por ejemplo, uno de los primeros obstáculos a los que se enfrentarán será conseguir los datos necesarios para entrenar un modelo, lo que a menudo puede suponer un reto en muchas organizaciones. Los pasos siguientes requieren explorar los datos, identificar los algoritmos y enfoques adecuados y, a continuación, entrenar y probar las distintas iteraciones del modelo. Todo esto puede llevar mucho tiempo y ser tedioso, a menudo considerado un arte además de una ciencia y, lo peor de todo, ¡el científico de datos puede descubrir que no hay ninguna señal en los datos y que es imposible construir un modelo para predecir el fenómeno que esperaban poder predecir!
Sin embargo, una de las ventajas de los enfoques tradicionales de IA, como el ML, es que existen procesos (relativamente) maduros y bien definidos para desarrollar y probar estos modelos y luego implementarlos en la producción (por ejemplo, este documento de 2014 fue una especie de "llamada a las armas" para muchos profesionales en esta área). Esto no quiere decir que no haya retos, y hay muchas incertidumbres (ciertamente en relación con los proyectos de software normales), pero una vez que el modelo ha sido debidamente probado y aprobado (es decir, que "funciona"), puede desplegarse, siguiendo las diversas recomendaciones de mejores prácticas de MLOps.
Por otro lado, los enfoques de IA Generativa parten de un modelo general preentrenado (gran modelo lingüístico o, más genéricamente, "modelo básico"), que se adapta a la aplicación concreta mediante el suministro de información diferente en la solicitud (por ejemplo, el texto de la solicitud o información organizativa específica), con el fin de manipular el resultado del modelo básico de la forma deseada.
Una vez más, esta descripción de alto nivel omite muchos detalles. Por ejemplo, la fase en la que se parte de un modelo básico probablemente implique iterar sobre diferentes modelos preentrenados, así como sobre indicaciones (y datos contextuales) para hacerse una idea de si la idea es posible. A continuación, puede haber una fase de planteamiento del problema para asignar la solución al problema de negocio, seguida de la recopilación y el procesamiento de datos. Esencialmente, es más fácil crear rápidamente un prototipo de solución, ya que se ha eliminado la necesidad de datos de formación, pero el planteamiento del problema para asignar la solución al negocio puede ser menos fácil de entender, puede tener que adaptarse a esa solución en particular y, por lo tanto, llevar más tiempo. Del mismo modo, la comprobación del rendimiento del modelo/solución también puede ser menos comprensible (a diferencia de las métricas estándar utilizadas en ML, como la precisión o la recuperación) y, por lo tanto, también llevará más tiempo; lo mismo ocurre con el despliegue y la supervisión, de nuevo debido a la naturaleza más personalizada de la solución.
.webp "GFT Blog: Overview")