Investigadores de NTU Singapore reducen de meses a una hora el desarrollo de software de toma de decisiones

Un equipo de la Universidad Tecnológica de Nanyang, en Singapur (NTU Singapore), ha presentado un framework de IA que ensambla automáticamente software complejo para la toma de decisiones. Según los investigadores, desarrollar un sistema así exigía antes meses de trabajo de especialistas muy concretos. Ahora basta con aproximadamente una hora. Si la cifra se confirma en la práctica, supone una reducción del plazo de dos órdenes de magnitud.

Qué se sabe del desarrollo

La descripción publicada ofrece pocos detalles, y conviene dejarlo claro desde el principio. De ella se desprende que el framework asume una tarea que suele resolver la combinación de un experto del dominio y un ingeniero: convertir el planteamiento de un problema en un programa funcional que elige acciones dentro de unas restricciones y unos objetivos dados. Ejemplos clásicos de este tipo de software son la planificación de rutas, los horarios, la asignación de recursos y la gestión de inventarios. El anuncio no indica cuáles de ellos cubre el framework.

Los hechos clave que pueden darse por establecidos:

• Desarrollador: NTU Singapore.
• Qué se automatiza: la creación de software complejo para la toma de decisiones.
• Plazo anterior: meses de trabajo de ingeniería especializada.
• Plazo declarado con el framework: alrededor de una hora.
• Tipo de sistema: framework de IA. Se desconoce si en su base hay un modelo de lenguaje grande.

Por qué estos sistemas tardan meses en construirse

El cuello de botella no es escribir código en sí. Primero hay que formalizar el programa de decisión: definir las variables, las restricciones y la función objetivo; después, elegir un algoritmo adecuado, configurarlo y validarlo con datos reales. Cada paso requiere personas que entiendan a la vez el problema de negocio y el aparato matemático. Hay pocas personas así, y las iteraciones con el cliente alargan el proyecto.

Si el framework realmente se encarga de la formalización y de la selección del solver, el ahorro no está en las líneas de código, sino en el ciclo de aprobaciones. Por eso el plazo declarado de una hora resulta atrevido: de momento no está claro si incluye la validación del resultado o solo la generación de una primera versión.

Qué falta en el comunicado

La cifra de «alrededor de una hora» dice poco sin contexto. Faltan respuestas a las preguntas de las que depende todo el valor del trabajo:

• En qué tareas y en qué cantidad se hicieron las mediciones.
• Si se comparó el resultado con una solución escrita por una persona, en términos de calidad y coste de las soluciones encontradas.
• Cuánta preparación manual se necesita como entrada: una descripción de la tarea en lenguaje natural, una especificación formal o datos ya preparados.
• Cómo se comporta el sistema ante restricciones no estándar y cómo detecta sus propios errores.
• Si el código está disponible y en qué forma se publicará el trabajo.

Hasta que aparezca un artículo o un preprint con estos datos, conviene evaluar el resultado con cautela. La generación automática de software de resolución falla con más frecuencia precisamente en las restricciones poco evidentes: el modelo produce un programa que funciona y resulta convincente, pero que incumple una regla que nadie formuló en voz alta.

Qué comprobar antes de implantarlo

Para las empresas que tienen sus propias tareas de planificación y optimización, el orden práctico de actuación es este. Primero, tomen una tarea ya resuelta con una referencia conocida y comparen con ella el resultado del ensamblado automático. Después, comprueben cómo reacciona la herramienta ante un cambio de condiciones: añadan una restricción nueva y vean si hace falta reensamblar desde cero. Por último, evalúen quién revisará los resultados. Si la respuesta es «nadie», la hora de desarrollo se convierte en un riesgo, no en un ahorro.

Vale la pena seguir la publicación del trabajo completo de NTU Singapore. Ahí deberían aparecer los benchmarks, las limitaciones del enfoque y las condiciones de acceso, y por ellos se verá si el plazo de desarrollo se ha reducido para todas las tareas o solo para las demostrativas, elegidas por su comodidad.