| News

Cómo la industria de la IA olvidó dos de sus mejores ideas

Y qué puede aprender del concreto romano.

Cómo la industria de la IA olvidó dos de sus mejores ideas [Imagen base: Adobe Stock]

El progreso tecnológico se suele contar como una historia de acumulación. Imaginamos que cada generación hereda todo lo que aprendió la anterior y le añade algo nuevo.

La realidad es menos ordenada.

A veces las tecnologías no desaparecen porque hayan fracasado. Desaparecen porque la arquitectura que las rodea cambia, los incentivos se mueven o un nuevo paradigma capta la atención de todos. Años después, la industria descubre que dejó algo valioso en el camino.

El concreto romano ofrece un ejemplo útil. Investigadores que estudian estructuras antiguas han reconstruido técnicas que le daban al material una durabilidad inusual y que, al parecer, permitían que las grietas se “sanaran” mediante reacciones que involucraban fragmentos de cal. Ese conocimiento no fue refutado. Simplemente dejó de formar parte de la práctica constructiva habitual y tuvo que ser recuperado siglos después mediante la arqueología y la ciencia de materiales. Investigadores del MIT han descrito cómo el “mezclado en caliente” podría explicar estas propiedades.

La IA empresarial podría estar viviendo un episodio similar. La industria no solo ha fallado en inventar la arquitectura correcta. También ha empujado silenciosamente dos de sus ideas más útiles hacia los márgenes: la orientación a objetos duradera y el aprendizaje por refuerzo.

Lo primero que olvidamos: se supone que los objetos deben vivir

La programación orientada a objetos nunca se trató solo de clases y herencia. Su intuición fundamental era más concreta: un objeto combina identidad, estado y comportamiento. Representa algo que existe, recuerda su condición y sabe qué operaciones pueden modificarlo.

Eso resultó particularmente adecuado para el software empresarial. Un cliente, un contrato, una cuenta, un pedido o un reclamo de seguro no era simplemente una fila de datos. Era una entidad con identidad, relaciones, estado y comportamiento permitido.

Luego llegó la computación en la nube, y algo sutil cambió.

Los sistemas nativos de la nube suelen diseñarse para no tener estado (“stateless”). El cómputo no debería depender de la máquina particular que atiende una solicitud, porque esa máquina puede desaparecer, ser reemplazada o verse acompañada por cientos de instancias idénticas. AWS recomienda explícitamente eliminar el estado de los componentes individuales para que las cargas de trabajo puedan escalar horizontalmente y recuperarse de fallas. Microsoft, de forma similar, describe los datos de sesión web como información efímera que debería almacenarse en una caché o base de datos externa, en lugar de confiarse al propio proceso de la aplicación.

Ese es un compromiso de ingeniería perfectamente sensato. También es una retirada filosófica.

El objeto puede seguir existiendo en el código fuente, pero su estado duradero ya no vive junto a su comportamiento. Está distribuido entre bases de datos, cachés, almacenes de objetos, filas, flujos de eventos y sistemas de orquestación. Cada solicitud tiene que reconstruir suficiente de la realidad del objeto para hacer algo útil, y luego devolver su estado a la infraestructura externa antes de que el cómputo desaparezca.

No abolimos la orientación a objetos. Debilitamos una de sus propiedades más profundas.

Con el tiempo, compensamos esto con mapeadores objeto-relacionales, almacenes de sesión, event sourcing, brokers de mensajes, cachés distribuidas, motores de flujo de trabajo y una pequeña montaña de código de conexión (“glue code“). Ninguna de estas tecnologías está mal encaminada. Resuelven problemas reales generados por la escala y la distribución. Pero, en conjunto, revelan lo que ocurrió: la persistencia dejó de ser una propiedad natural del objeto computacional y se convirtió en un problema de ingeniería que lo rodea.

Eso importa enormemente para la IA empresarial.

Un sistema de IA que actúa dentro de una empresa necesita más que acceso a documentos y APIs. Necesita entidades duraderas cuyas identidades, estados, relaciones, permisos y transiciones válidas permanezcan coherentes a lo largo del tiempo. Un cliente debe seguir siendo el mismo cliente a través de las interacciones. Un proceso debe sobrevivir a las interrupciones. Un contrato debe conservar sus restricciones. Un agente debe saber no solo qué ocurrió en una conversación, sino qué cambió en el mundo operativo.

Los sistemas actuales suelen llamar a esto “memoria”. Pero la memoria no es un modelo de objetos. La memoria puede recuperar fragmentos del pasado. Un modelo de objetos define qué existe y cómo se le permite cambiar. Anthropic, por ejemplo, presentó la capacidad de Claude de recurrir a conversaciones de semanas o meses atrás como un avance importante. Y para un chatbot, lo fue. Pero, desde la perspectiva del software empresarial, ese hito suena extrañamente modesto.

Un cliente, un contrato, un reclamo o un proceso de ventas de nueve meses no debería mantenerse coherente durante un mes. Debería mantenerse coherente mientras exista. El modelo no necesita tener permanentemente cada token anterior dentro de su contexto activo. El sistema subyacente necesita identidad y estado duraderos, con el contexto relevante reconstruido cada vez que la inteligencia actúa. Un mes de memoria es impresionante para un chatbot. Pero para el software empresarial, es una fecha de caducidad.

La IA empresarial tiene una inteligencia extraordinaria en la superficie y una realidad operativa fragmentada por debajo.

Lo segundo que olvidamos: aprender de los resultados

La otra idea desplazada es el aprendizaje por refuerzo.

AlphaGo, de DeepMind, combinó redes neuronales profundas con aprendizaje por refuerzo para derrotar a uno de los mejores jugadores de Go del mundo. Después, AlphaZero fue más lejos: aprendió ajedrez, shogi y Go mediante partidas contra sí mismo, en lugar de imitar partidas humanas. MuZero aprendió a planificar sin que se le dieran de antemano las reglas subyacentes del entorno.

Estos sistemas demostraron algo más grande que el dominio de juegos. Mostraron cómo la inteligencia puede surgir de un ciclo repetido: actuar, observar el resultado, compararlo con un objetivo y ajustar.

Eso no es simplemente reconocimiento de patrones. Es aprender a través de la consecuencia.

Luego llegó el transformer. El artículo de 2017 “Attention Is All You Need” introdujo una arquitectura altamente paralelizable y extraordinariamente eficaz para el procesamiento de secuencias. Se convirtió en la base de la ola de IA generativa y transformó el procesamiento de lenguaje natural.

El problema no es que los transformers hayan sido un error. Fueron uno de los avances más trascendentes de la computación.

El problema es lo que le ocurrió al centro de gravedad de la industria.

La predicción se convirtió en el paradigma dominante. El aprendizaje por refuerzo no desapareció, pero se usó cada vez más alrededor de los modelos: para ajuste fino, alineación, robótica u optimización de problemas aislados. La idea más grande (que los sistemas desplegados deberían mejorar continuamente conectando sus acciones con resultados reales) quedó en segundo plano frente a la espectacular capacidad de generar lenguaje.

Nos volvimos extraordinariamente buenos produciendo respuestas plausibles y extrañamente tolerantes con sistemas que nunca descubren si esas respuestas funcionaron.

Ese es el desajuste oculto en la IA empresarial. Las empresas no solo necesitan sistemas que generen lenguaje. Necesitan sistemas que aprendan de las consecuencias.

Por qué estas dos pérdidas se refuerzan entre sí

Una empresa no es un prompt ni una sesión de chat. Es un sistema cambiante de clientes, contratos, productos, empleados, permisos, flujos de trabajo, restricciones y resultados.

Para mejorar un sistema así, la IA necesita dos cosas.

Necesita un mundo duradero en el cual actuar: entidades que persistan, procesos que preserven su estado y relaciones que se mantengan coherentes a través del tiempo.

Y necesita un mecanismo para aprender qué logran sus acciones: objetivos, observaciones, retroalimentación y la capacidad de ajustar el comportamiento futuro.

Si se quita lo primero, la empresa se vuelve difícil de representar.

Si se quita lo segundo, la empresa se vuelve imposible de optimizar continuamente.

Esto ayuda a explicar por qué gran parte de la IA empresarial todavía se siente como una interfaz ingeniosa montada sobre un runtime faltante. Puede hablar maravillosamente sobre la organización, pero no puede habitarla plenamente de manera duradera, con estado y orientada a resultados.

También explica por qué las implementaciones se vuelven artesanales. Los humanos tienen que reconstruir el contexto, conectar los sistemas, definir permisos, explicar los objetos de negocio, medir resultados y rediseñar el ciclo para cada caso de uso. El modelo aporta la inteligencia, pero la arquitectura necesaria para convertir esa inteligencia en capacidad organizacional acumulativa se ensambla a mano.

El resultado es una industria brillante para la demostración y extrañamente pobre para la acumulación.

La arquitectura que ahora necesitamos

La próxima arquitectura de IA empresarial tendrá que recuperar ambas ideas simultáneamente.

Necesitará objetos cuya identidad, estado, relaciones, permisos y comportamiento persistan de forma natural, incluso cuando la ejecución se mueva entre máquinas y escale de diez interacciones a diez millones.

Y necesitará el aprendizaje por refuerzo no solo como un método de entrenamiento previo al despliegue, sino como un mecanismo operativo: acciones que generan evidencia estructurada, evidencia conectada a resultados de negocio, y resultados que mejoran las acciones subsecuentes.

Los objetos persistentes le darían a la IA un mundo empresarial estable.

El aprendizaje por refuerzo le daría una forma de mejorar su comportamiento dentro de ese mundo.

Juntos, transformarían el software de un sistema que registra lo que la empresa hizo a un sistema que ayuda a la empresa a aprender qué funciona.

Quizás ese sea el próximo gran avance de la IA empresarial. No otra capacidad espectacular de un modelo, sino la recuperación de dos principios que la industria alguna vez comprendió y luego dejó que se distanciaran: objetos que viven, y sistemas que aprenden de las consecuencias.

Author

  • Enrique Dans

    imparte clases de Innovación en IE Business School desde 1990, ha revolucionado la educación como Asesor Senior de Transformación Digital en IE University y ahora lo hace aún más en Turing Dream. Escribe todos los días en Medium.

    View all posts

Author

  • Enrique Dans

    imparte clases de Innovación en IE Business School desde 1990, ha revolucionado la educación como Asesor Senior de Transformación Digital en IE University y ahora lo hace aún más en Turing Dream. Escribe todos los días en Medium.

    View all posts

Sobre el autor

imparte clases de Innovación en IE Business School desde 1990, ha revolucionado la educación como Asesor Senior de Transformación Digital en IE University y ahora lo hace aún más en Turing Dream. Escribe todos los días en Medium.