Pilotos de IA en supply chain - Ep 159

00:00:00 Introducción a la entrevista
00:01:01 El impacto de la IA en los trabajos tradicionales
00:04:36 Automatización con IA en supply chain
00:09:08 Necesidad de un sistema unificado en 2012
00:10:30 Reinyectar decisiones en los sistemas
00:13:08 Evitar el problema de las alucinaciones en la IA
00:16:11 Impacto y retrasos debido al backlog de TI
00:20:04 Comparando la configuración de Lokad y la de otros proveedores
00:23:06 Discusión sobre las alucinaciones y confabulaciones de los LLM
00:30:38 Enfatizando el progreso sobre la perfección en la IA
00:33:00 Obteniendo información faltante y el ETA de los pedidos
00:36:17 Tareas cuantitativas y LLM en supply chain
00:38:28 El futuro de los AI Pilots en supply chain
00:41:18 El valor de las conversaciones y la automatización de tareas de bajo valor
00:44:57 Aprovechando los AI Pilots para reducir el backlog
00:49:00 AI Pilot vs copiloto y escenario de confinamiento
00:53:36 Escepticismo hacia la IA conversacional y el análisis de procesos
00:57:18 Comprender la realidad del negocio y que la IA reemplace procesos
01:00:12 Desafíos de hacer open source Envision
01:06:21 El enfoque de la IA para los cuellos de botella en supply chain
01:09:17 Ineficiencia de los comandos verbales y la automatización de pedidos
01:14:12 Supply Chain Scientist como copiloto para AI Pilot
01:17:32 Verificando la corrección de los datos y automatizando comprobaciones con LLMs
01:20:15 Haciendo que Envision sea amigable con git
01:21:14 Recursos gratuitos para aprender Envision

Resumen

En un diálogo entre el CEO de Lokad, Joannes Vermorel, y el Director de Comunicación Conor Doherty, discuten el impacto de la IA en la gestión de gestión de supply chain. Vermorel destaca los avances en IA y en los grandes modelos de lenguaje, que han revolucionado la automatización de tareas. Presenta los AI Pilots, una solución de Lokad que automatiza la toma de decisiones y las tareas administrativas, facilitada por el lenguaje de programación propietario de Lokad, Envision. Vermorel también comenta el potencial de la IA para automatizar tareas relacionadas con los datos maestros y contrasta el enfoque de Lokad con el de sus competidores. Predice que los AI Pilots se convertirán en la norma en la gestión de supply chain, llevando a mejoras significativas en la productividad. La conversación concluye con una sesión de preguntas y respuestas.

Resumen Ampliado

En una conversación reciente entre Conor Doherty, Director de Comunicación en Lokad, y Joannes Vermorel, CEO y fundador de Lokad, el dúo se adentró en el papel transformador de la inteligencia artificial (IA) en la gestión de supply chain. La discusión, una continuación de una conversación previa sobre el impacto de la IA en el empleo, se centró en el potencial de la IA para actuar como un piloto independiente para la toma de decisiones en supply chain.

Vermorel comenzó destacando el hito alcanzado con la IA generativa y los grandes modelos de lenguaje (LLMs) en 2023. Explicó que estos avances han revolucionado la automatización de tareas relacionadas con el texto, como leer correos electrónicos o categorizar quejas. El año 2023 fue particularmente significativo, pues se observó una reducción sustancial en el costo operacional de las técnicas de procesamiento de lenguaje natural para las empresas. Vermorel predijo que esto llevaría a la automatización de muchas funciones de soporte internas, con las operaciones de supply chain a la vanguardia.

Vermorel luego presentó los AI Pilots, una solución de Lokad que automatiza el proceso de toma de decisiones y se encarga de tareas administrativas mundanas. Enfatizó el enfoque único de Lokad, donde un Supply Chain Scientist puede asumir la responsabilidad completa de una iniciativa. Esto es facilitado por el lenguaje de programación propietario de Lokad, Envision, dedicado a la optimización predictiva de supply chain. Sin embargo, Vermorel admitió que Lokad había tenido dificultades previamente con la búsqueda de datos y el manejo de diversos dialectos de SQL.

La introducción de GPT-4, explicó Vermorel, ha supuesto un cambio radical para Lokad, permitiendo a la empresa automatizar la composición de consultas SQL. Estas consultas pueden luego ser revisadas por un Supply Chain Scientist y probadas para asegurar la accuracy. Este desarrollo, junto con una conexión segura de cloud-to-cloud, permite al equipo de Supply Chain Scientists de Lokad perseguir los datos de los clientes por cuenta propia, reduciendo así los retrasos.

Vermorel también destacó el potencial de los LLMs para automatizar muchas tareas relacionadas con los datos maestros, incluyendo la recolección, el monitoreo y la mejora. Contrastó el enfoque de Lokad con el de sus competidores, afirmando que Lokad generalmente involucra a menos personas en una iniciativa, con cada persona teniendo competencia a lo largo de toda la cadena. Esto, argumentó, contrasta notablemente con los competidores, que a menudo involucran a muchas más personas en una iniciativa, incluyendo gerentes de proyecto, consultores, diseñadores UX, administradores de bases de datos, especialistas en redes y programadores.

La conversación luego se centró en el papel de los Supply Chain Scientists en la validación o monitoreo de scripts generados por los LLMs. Vermorel reconoció que los LLMs a veces pueden producir resultados inexactos o “alucinados”, pero que generalmente son correctos en términos generales y pueden corregirse con algunas iteraciones a través de un bucle de retroalimentación. Sugirió que, aunque los LLMs pueden cometer errores, aún pueden proporcionar mucho valor, y que se pueden medir sus tasas de falsos positivos y falsos negativos.

Vermorel explicó además la coordinación diaria entre el Supply Chain Scientist, el AI Pilot y el cliente. El AI Pilot, compuesto por el Supply Chain Scientist, se encarga de las operaciones diarias de supply chain, gestionando los detalles de la data preparation y las decisiones de órdenes de compra. En este esquema, el cliente se asemeja al capitán, dando directrices estratégicas generales.

En términos de conclusiones para los profesionales del supply chain y los equipos ejecutivos, Vermorel predijo que en una década, los AI Pilots serán la norma en la Gestión de Supply Chain (SCM). Esto, según él, conducirá a una mejora masiva en la productividad, con una posible reducción del 90% en el número de empleados en funciones anteriores. Animó a los profesionales del supply chain a dedicar más tiempo al pensamiento estratégico y a conversaciones profundas con proveedores y clientes.

La conversación concluyó con una sesión de preguntas y respuestas, en la que Vermorel abordó cuestiones sobre una variedad de temas, incluyendo el papel de los AI Pilots en la reducción del backlog de TI, la diferencia entre un AI Pilot y un copiloto, la importancia del análisis de procesos antes de implementar un modelo de IA, los planes de Lokad para open source Envision, y cómo la IA aborda cuellos de botella aleatorios. También confirmó que Lokad está trabajando en un copiloto de Lokad y planea hacer que Envision sea más amigable con GitHub.

Transcripción Completa

Conor Doherty: Bienvenidos a Lokad live. Mi nombre es Conor. Soy el Director de Comunicación aquí en Lokad. Y me acompaña en el estudio el fundador de Lokad, Joannes Vermorel.

Conor Doherty: El tema de hoy es cómo la IA puede actuar como un piloto independiente para la toma de decisiones en supply chain. No duden en enviar sus preguntas en cualquier momento a través del chat de YouTube, y las abordaremos en aproximadamente 30-35 minutos.

Conor Doherty: Y con eso, Joannes, se me ocurre que esta conversación sobre AI Pilots en supply chain es en gran medida una extensión de aquella que tuvimos, creo, hace unas cuatro semanas, en la que hablamos sobre las implicaciones de la IA en el empleo y el futuro de los trabajos tradicionales frente a la IA en supply chain.

Conor Doherty: Así que, antes de adentrarnos en los detalles de los AI Pilots, ¿podrías ofrecer a aquellos que no lo vieron, un repaso, solo un resumen ejecutivo, cuál es nuestra perspectiva sobre los trabajos tradicionales frente a la IA en supply chain?

Joannes Vermorel: El repaso es que se ha alcanzado un hito prácticamente en 2023. Este hito es la IA generativa y, más específicamente, los grandes modelos de lenguaje (LLMs). En términos de pura investigación, es simplemente una continuación de casi cuatro o cinco décadas de mejora continua en el aprendizaje automático. Así que, si lo miras desde una perspectiva investigativa, 2023 es solo un año más dentro de una larga secuencia de progreso. Y ha habido un avance relativamente rápido en las últimas dos décadas.

Joannes Vermorel: Ahora, en 2023, lo que llega al mercado es la IA generativa empaquetada tanto para imágenes como, y más importante, para texto. Y hay un producto que popularizó esto, es ChatGPT de OpenAI. ¿Qué significa eso? Significa, de manera muy específica, que especialmente esos grandes modelos de lenguaje actúan como una máquina de plantillas universal resilient al ruido.

Joannes Vermorel: Esto significa que todas esas etapas para el software empresarial, me refiero en el contexto de los trabajadores, como los empleados de oficina en entornos corporativos, es decir, todas aquellas tareas que en el pasado no podían ser automatizadas porque teníamos que lidiar con el texto en cualquier forma o modalidad, tales como leer un correo electrónico, extraer una referencia o precio de un correo, o una cantidad, o categorizar el tipo de queja o solicitud de un socio o cliente proveedor a partir de un correo, identificar si la etiqueta de un producto es absurda, por ejemplo, si la descripción del producto literalmente falta, bueno, tenemos un problema, todas esas cosas en el pasado no se podían hacer fácilmente. Se podían hacer de otras maneras, pero no se podían automatizar con facilidad.

Joannes Vermorel: Si tuviéramos que retroceder, digamos, cinco años, la minería de texto ya existía. Ya era posible contar con clasificadores de texto y utilizar todo tipo de técnicas de procesamiento de lenguaje natural, pero eran costosas. 2023 fue un hito porque todos esos problemas, debido al grado de empaquetamiento que se logró esencialmente con GPT-4 servido a través de una API, implicaron que todas esas técnicas de NLP, técnicas de procesamiento de lenguaje natural, redujeran su costo operacional para las empresas en un factor de 100, si no de 1,000. Lo que significa que no solo el costo, sino también el tiempo requerido para simplemente configurar todo, se redujo drásticamente.

Joannes Vermorel: En resumen, y esa es mi predicción, es que muchas funciones de soporte en las empresas, que son funciones internas, que reciben datos y producen un resultado para otras divisiones, serán automatizadas. Supply chain está a la vanguardia porque no es, exactamente, una función de cara al cliente. Es, en gran medida, una función interna, importante, pero interna. Y es que los grandes modelos de lenguaje fueron la pieza faltante para automatizar, en gran medida de extremo a extremo, la gran mayoría de las operaciones mundanas en supply chain.

Joannes Vermorel: Lokad ha estado automatizando el análisis cuantitativo y el proceso de toma de decisiones cuantitativas durante una década, pero existen muchas operaciones mundanas que se realizan antes y después, y esas pueden ser automatizadas gracias a los grandes modelos de lenguaje, de forma rápida y económica.

Conor Doherty: Bueno, gracias. Y ya tenemos un video en el que hablamos, creo, durante aproximadamente una hora y media sobre ese tema, así que hoy no dedicaré más tiempo a ello, pero eso sienta las bases para el resto de la conversación. Invito cordialmente a cualquiera que desee profundizar en el tema a revisar el video anterior. Ahora, en ese sentido, AI Pilots, ¿cómo encajan en todo lo que acabas de mencionar? ¿Qué son? ¿Qué hacen en realidad?

Joannes Vermorel: En general, la IA ha sido utilizada de manera consistente durante las últimas dos décadas por los proveedores como una palabra de moda y un término paraguas para englobar lo que ofrecían. Así que, cuando digo AI Pilots, es en realidad una oferta de Lokad. Es una evolución de la oferta, probablemente la más grande que hemos tenido en años. ¿Y cuál es la diferencia? Pues, la diferencia es que un AI Pilot es algo, es un software, lo que llamamos una serie de recetas numéricas, que no solo ejecutan el proceso de toma de decisiones, es decir, ese es el aspecto puramente cuantitativo del supply chain, pues se trata literalmente de determinar exactamente cuánto ordenar, dónde asignar el stock, si es necesario subir o bajar los precios, exactamente cómo planificar la producción con todos los pasos, etc.

Joannes Vermorel: Así que eso era lo que ya estábamos haciendo, además de todo lo que ocurre antes y después en términos de tareas administrativas mundanas, que en su mayoría son de gestión de datos maestros previas al análisis de datos, y luego la ejecución de la decisión, que puede involucrar canales no estructurados como los correos electrónicos, por ejemplo, cuando se desea enviar un correo a un proveedor para solicitar que se agilice algo o, por el contrario, retrasar un pedido.

Joannes Vermorel: Y la esencia de esta oferta son, obviamente, los grandes modelos de lenguaje que Lokad no inventó, y que hemos estado utilizando de manera extensa durante 14 meses, un poco más que eso ahora. Y la clave en la forma en que opera Lokad es que debe ser un único Supply Chain Scientist capaz de asumir la responsabilidad completa de una iniciativa.

Joannes Vermorel: Para empresas muy grandes, puede que tengamos varias personas en el caso, pero a diferencia de la mayoría de nuestros competidores, normalmente no están especializadas. No es que tomemos un equipo de tres con el Sr. Database, el Sr. Algorithms y el Sr. UI y UX. Esa no es, absolutamente, la forma en que opera Lokad. Un Supply Chain Scientist es capaz de hacerlo todo de principio a fin.

Joannes Vermorel: Y esa es una de las razones por las que Lokad ha diseñado su propia tecnología de la manera en que lo ha hecho, y tenemos nuestro propio lenguaje de programación, un lenguaje de programación específico del dominio llamado Envision, dedicado a la optimización predictiva de supply chain. Puede parecer muy extraño haber creado un lenguaje de programación hecho a la medida, pero la esencia es que, y esa es una decisión que tomé en 2012, realmente necesitábamos algo unificado para que una sola persona pudiera hacer todo el proceso, de principio a fin.

Hasta hace unos años, eso consistía realmente en obtener los datos de transacciones sin procesar de los ERPs, CRMs, EDI y todos esos sistemas transaccionales, complementarlos con una serie de hojas de cálculo para todos los datos estructurados que desafortunadamente forman parte del shadow IT en lugar del IT regular, y luego elaborar las recetas numéricas para la toma de decisiones. Y esa era la responsabilidad del Supply Chain Scientist hacer todo eso, luego elaborar toda la instrumentación incluyendo dashboards e informes, para asegurarse de convencerse a sí mismo o a sí misma de que los números eran correctos pero también para tranquilizar a nuestros propios clientes sobre la validez de lo que estamos haciendo, además de todos los instrumentos para monitorear la calidad de las decisiones a lo largo del tiempo, y de la canalización para extraer los datos de los sistemas y también reinyectar las decisiones en los sistemas.

Ese era el alcance que tenía Lokad, y había dos cosas que realmente no podíamos hacer. Primero, teníamos que ser el receptor de los datos, no podíamos realmente buscarlos. Y cuando digo buscar, el Supply Chain Scientist podía solicitar los datos, no le estábamos pidiendo a las divisiones de IT de nuestros propios clientes que hicieran ningún tipo de transformación sofisticada, era simplemente volcar las tablas prácticamente, ya sabes, select * from table, bam, lo haces una vez al día y ya. Así que esos eran solo extractos súper simples, pero aún así, era básicamente la división de IT de nuestros clientes la que lo hacía.

No se esperaba que los Supply Chain Scientists buscaran en el panorama aplicativo de nuestros clientes los datos que la iniciativa necesitaba. La razón de ello era muy simple, hay como 20 dialectos SQL, por ejemplo, Oracle SQL, el dialecto T-SQL de Microsoft SQL Server, MySQL, PostgreSQL, DB2 de IBM, etc. Así que hay algo así como 20 dialectos SQL. Hasta hace unos años, un Supply Chain Scientist habría tenido una lucha inmensa solo porque, incluso si lo que esta persona quería lograr era sumamente sencillo, como volcar una sola tabla, el problema era que esta persona habría pasado literalmente decenas de horas buscando en línea para componer consultas triviales, y cada vez que aparecía un mensaje de error, era nuevamente esta persona; incluso si en general estaba familiarizada con las bases de datos SQL, habría sido, diría yo, un obstáculo masivo lidiar con dialectos de sistemas que no conocías.

En 2023, con ChatGPT, el problema está resuelto. ChatGPT, como programador asistente, no es naturalmente muy bueno para permitirte componer aplicaciones sofisticadas, pero cuando se trata de componer consultas SQL súper simples en docenas de dialectos, es muy rápido. Un Supply Chain Scientist va a solicitar que se componga una consulta SQL. Esta persona también es inteligente y revisará la consulta para asegurarse de que refleje la intención. Se trata simplemente de eliminar el obstáculo de descubrir la sintaxis, pero una vez que tienes la sintaxis correcta presentada, es prácticamente autoexplicativo.

Si quieres probarlo por ti mismo, solo pídele a ChatGPT que te dé una guía para configurar git en tu máquina y establecer un repositorio git o lo que sea, y verás qué tipo de respuesta de altísima calidad puedes obtener.

Eso realmente es un cambio radical porque significa que, de repente, Lokad, que está formando Supply Chain Scientists, puede asumir la responsabilidad de buscar los datos. Y sé que tenemos, a través de ChatGPT, las herramientas para no comprometernos en exceso diciendo que vamos a buscar los datos. Es un cambio radical. En lugar de pedirle a IT que nos envíe los datos, simplemente podemos tener una dirección IP en lista blanca y luego tener una conexión de nube a nube muy segura, y luego permitir que el equipo de Supply Chain Scientists persiga sus propios datos.

¿Por qué hace tanta diferencia? Bueno, la realidad es que, incluso si Lokad solo necesita días de trabajo para una iniciativa dada, estamos hablando quizá de 10 a 20 días de trabajo para una iniciativa considerable para obtener las 20 a 50 tablas que necesitamos; es solo volcar la tabla, sin cruces, sin joins, sin filtros sofisticados, es muy sencillo. Sin embargo, el problema es que muchos de nuestros clientes tienen sus propias divisiones de IT que cuentan con enormes atrasos. Me refiero literalmente a años de atrasos, y cuando tienes como tres años de atraso, incluso si Lokad solo pide 10 días, son 10 días más tres años de atraso, así que incluso si no estamos exactamente al final de la cola, si estamos solo en la mitad, esos 10 días de trabajo de IT pueden tardar alrededor de un año en completarse, y diría que esa fue una frustración que tuvimos, que la mayoría de las demoras que experimentábamos provenían de IT, no por incompetencia o lentitud, sino simplemente porque tenían tanto atraso que les era muy difícil asignar esos 10 días.

Así que aquí tenemos, estamos hablando de algo en lo que, en lugar de solicitar 10 o 20 días de trabajo, se trata de algo como quizás menos de un día de trabajo, algo como solo un par de horas, solo para abrir un acceso muy seguro y restringido a los pocos sistemas que necesitamos. Y luego, los Supply Chain Scientists mismos van a inspeccionar la tabla, configurar la lógica de extracción de datos y asegurarse de que las extracciones sean realmente, diría yo, de bajo impacto.

La forma en que podemos hacer eso es, típicamente, monitorizando el rendimiento. Cada vez que el rendimiento de la base de datos disminuye, significa que hay mucho movimiento en la base y, por lo tanto, normalmente se desea aliviar la presión y retrasar el proceso de recuperación de datos. Porque, por lo general, en Lokad, necesitamos actualizar los datos a diario, pero no es algo sumamente urgente. Quiero decir, de nuevo, depende. Hay algunas situaciones en las que tenemos horarios realmente ajustados, pero muy a menudo, en lo que respecta a las supply chain, si retrasamos la recuperación 30 minutos solo porque actualmente hay un pico de actividad en esta base de datos, no es un problema.

El primer bloque de compromiso es buscar los datos nosotros mismos y, de ese modo, eliminar la principal causa de retraso y acelerar enormemente las iniciativas. De nuevo, esos retrasos frecuentemente se convertían en la mayor parte del retraso para que la iniciativa de Lokad pasara a producción, simplemente esperando a que IT pudiera asignar esos días.

El segundo bloque de compromiso es la mejora de los Master Data. Y aquí, de nuevo, en el pasado, cuando te enfrentabas a un catálogo donde hay, digamos, 100.000 descripciones de productos, algunas de ellas son basura, ya sabes, tal vez el 1%. Es mucho trabajo revisar esas 100.000 referencias, identificar las descripciones o etiquetas de producto que son incorrectas o, a veces, puede ser simplemente un precio que es completamente inconsistente con la descripción. Si dice que es un tornillo y el precio es de 20.000 dólares, probablemente no sea solo un tornillo, probablemente sea otra cosa, etc. Había muchas comprobaciones básicas de consistencia que parecían obvias y simples, pero era muy difícil automatizarlas y, frecuentemente, no había alternativa más que que una persona revisara las entradas para buscar cosas que realmente estaban mal.

Con un LLM, y potencialmente un LLM que también pueda procesar imágenes, puedes hacer muchas cosas en lo que respecta a inspeccionar, monitorear y mejorar todo lo relacionado con Master Data. En el caso específico de Lokad, la parte de Master Data que es necesaria para pilotar las supply chain.

Conor Doherty: Bueno, hay mucho allí, gracias. Tengo muchas preguntas que quiero profundizar. Voy a dar un pequeño paso atrás, porque si puedo resumir todo lo que estás describiendo, y corrígeme si me equivoco, un Supply Chain Scientist con acceso a un buen LLM, puede realizar una cantidad tremenda de trabajo. Un trabajo que hasta este momento habría requerido mucho tiempo e involucrado a muchas personas. Ahora, en una configuración al estilo no-Lokad, ¿cuántas más personas estarían involucradas? ¿Cuántos más dedos en el pastel habría? Y luego se podría hablar de la eficiencia, pero solo en términos de número de personas, ¿cuál es la diferencia entre Supply Chain Scientists con LLM y, no sé, S&OP por ejemplo?

Joannes Vermorel: Nuestros clientes suelen quedarse perplejos por el hecho de que incluso una gran iniciativa cuenta con solo dos o tres personas, y siempre las mismas. Tenemos Lokad, y estoy muy orgulloso de que Lokad, como empleador, logre mantener a las personas durante bastante tiempo. Así que, en resumen, Lokad suele ser 1% de principio a fin. Si tenemos varias personas, es nuevamente para tener redundancia. Un día te concentras en esta parte del proceso y yo en otra parte, y al día siguiente cambiamos. No es que la gente no se especialice, cada persona tiene competencia a lo largo de todo el proceso. Hay algunas variaciones y algunas personas tienen alguna especialidad en particular, pero en general, las personas realmente pueden sustituirse unas a otras.

Nuestros competidores, es muy diferente. Incluso una iniciativa pequeña involucra literalmente media docena de personas. Tendrás al gerente de proyecto que está allí solo para coordinar a los demás, luego tienes al consultor, el diseñador UX, el configurador, el administrador de bases de datos, el especialista en redes y, potencialmente, un programador, un ingeniero de software para las personalizaciones que no son nativas. De nuevo, Lokad es una plataforma programática, la mayoría de nuestros competidores, sus plataformas no son programáticas. Así que, siempre que quieras tener algo que se comporte de manera programática, necesitas contar con un ingeniero de software completo que literalmente implemente, con un lenguaje de programación de propósito general como Java o Python, las partes faltantes. Entonces, Lokad realmente no es así. Diría que nuestros competidores, prácticamente por defecto, cuentan con una docena. Las iniciativas de S&OP pueden involucrar varias docenas de personas, pero no necesariamente tantos skills diferentes; son en su mayoría personas de distintos departamentos y, muy frecuentemente, no están tan impulsadas por IT.

Entonces, Lokad sería, cuando digo una persona versus una docena, lo comparo con nuestros competidores que venden APS, sistemas de planificación avanzada o sistemas de optimización de inventarios, este tipo de software empresarial.

Conor Doherty: Gracias. Y para volver a otro punto que mencionaste al inicio cuando hablaste de Supply Chain Scientists, diste el ejemplo de los diferentes dialectos SQL y luego el Supply Chain Scientist, que puede o no ser fluido en ese dialecto específico del cliente, validaría o monitorearía los scripts que se generaran automáticamente porque los LLMs ocasionalmente alucinan.

Bueno, en ese sentido, los LLMs alucinan muy a menudo. Ahora, de nuevo, está mejorando, pero puedes pedirle a un LLM con un fragmento de texto, “Encuentra esta palabra oculta, ¿la ves?” y te dirá que sí, bueno, en realidad no está. Sé que no está, ya sabes que no está. ¿Cómo, a gran escala, puedes tener seguridad y controlar la calidad cuando se trata de aprovechar los LLMs de forma automatizada?

Joannes Vermorel: Las alucinaciones, o confabulaciones como prefiero llamarlas, realmente ocurren cuando usas al LLM como una base de conocimientos de todo. Si utilizas LLMs como una base de conocimientos de todo, entonces sucede. Si pides trabajos médicos y dices, “Dame una lista de artículos sobre esta patología,” te va a dar algo que es direccionalmente correcto. Los autores, con frecuencia, existen, han publicado, tienen cosas que estaban en esta área, han publicado artículos que estaban en la misma línea, pero no del todo. Eso, de nuevo, piénsalo como si le pidieras a un científico que recordara cosas de memoria.

Es muy difícil, dirías, y si dices que tienes que hacerlo, probablemente saldrán con algo que es medianamente plausible, con nombres correctos de colegas o investigadores, títulos correctos o semi-correctos, ese tipo de cosas. Así que esa es una situación en la que obtienes confabulaciones, pero en cierto modo, lo estás buscando. Quiero decir, le estás pidiendo a los LLMs que se comporten como una base de datos de todo, por lo que es muy difícil, vas a tener este tipo de problema.

Lo mismo ocurre con los dialectos SQL, intentas eso y obtienes algo, que es aproximadamente correcto. Si pides, “Quiero leer una tabla,” va a ejecutar un “select * from table” y algo por el estilo. No te va a dar, cuando lo solicites, por ejemplo con GPT-4, algo como “drop table”. Puede darte una sintaxis que sea ligeramente inadecuada, así que pruebas tu consulta SQL, recibes un mensaje de error, haces un pequeño ajuste y funciona. Pero ves, sigue siendo direccionalmente correcta. Si pides leer la base de datos, no va a producir un comando que elimine una tabla o modifique los niveles de permiso de la base de datos.

Lo mismo ocurre cuando pides conocimientos inventados. Por ejemplo, si preguntas, “Bien, tengo un compresor industrial de 20 kilovatios de potencia, ¿cuál es su precio?” Si le preguntas a GPT, puede que diga probablemente algo como $10,000. Simplemente está estimando algo. Esto es literalmente inventado. Es plausible, pero, ¿es correcto? Probablemente no, y depende de cientos de variantes porque hay tantos compresores diferentes para diversas situaciones.

Así que, en resumen, las confabulaciones no ocurren al azar. Realmente hay tipos específicos de tareas en las que ocurren con mucha más frecuencia. Entonces diría que cuando lo buscas, cuando usas el LLM como una base de datos de todo, es mejor verificar dos veces. Puede ser extremadamente útil, te da, por ejemplo, para los dialectos SQL, una pista sobre el tipo de palabras clave que deberías utilizar, cómo es la sintaxis, y puede cometer un pequeño error, omitir una coma o algo, pero con unas pocas iteraciones, lo conseguirás. Especialmente porque una vez que tienes la consulta SQL, puedes probarla en la base de datos, ver la salida y validarla, de modo que tienes un ciclo de retroalimentación instantáneo para comprobarlo.

Si quieres detectar, por ejemplo, etiquetas de producto extrañas, etiquetas que se ven sospechosas como cuando falta la descripción del producto, esa es tu etiqueta de producto, ¿vale? y, obviamente, está mal. Pero pueden ocurrir todo tipo de errores. Por ejemplo, puedes tener una etiqueta de producto que diga “tournevis cruciforme”, que está en francés, y el problema es que está sólo en francés, es un destornillador con cabeza Phillips, creo. Y, de nuevo, puedes pedir cosas, pero en algún punto no es perfecto, es una cuestión de juicio. Un humano cometería un error de todas formas, así que no puedes esperar que el LLM sea un oráculo definitivo que responda correctamente a cada pregunta. En algún momento, si realizas una tarea como revisar los 100,000 productos de tu catálogo en busca de anomalías en las etiquetas, el LLM tendrá falsos positivos y falsos negativos, tal como ocurriría con un humano. Pero lo interesante es que puedes medir la tasa de falsos positivos y falsos negativos y luego decidir si vale la pena o no. Y muy frecuentemente, obtienes algo que es bastante bueno, algo que te aporta mucho valor, incluso si aún comete algunos errores.

Conor Doherty: Progreso, no perfección.

Joannes Vermorel: Exacto. Si puedes reducir en un 90% tus problemas de datos maestros con algo que es muy barato y que se puede reejecutar en literalmente horas sin supervisión, eso es muy bueno.

Conor Doherty: Además, está el valor del tiempo que no se gastó haciendo eso manualmente y que podrías haber dedicado a hacer algo que genere o aporte valor. Así que, nuevamente, hay impulsores directos e indirectos de valor.

Joannes Vermorel: Además, la realidad es que cuando realizas una tarea súper repetitiva durante una hora, puedes obtener cierto nivel de calidad. Pero cuando lo haces durante 100 horas —la hora 67, quiero decir, normalmente los humanos no son máquinas de rendimiento constante—, después de unas pocas horas la concentración decae y, por lo tanto, la cantidad de falsos positivos y falsos negativos probablemente se dispare, incluso con un empleado bastante diligente.

Conor Doherty: Gracias. Y quiero tener en cuenta que, de hecho, tenemos algunas preguntas de la audiencia que abordan cosas que yo iba a preguntar, así que omitiré algunos temas, pero se tratarán en las preguntas de la audiencia. Pero una última reflexión: cuando hablas de los Supply Chain Scientists, del AI Pilot —y volveremos a eso más adelante en las preguntas—, ¿cómo funciona en el día a día esa orquestación entre el Supply Chain Scientist, un AI Pilot y el cliente? ¿El cliente tiene acceso? ¿Interactúa con el LLM?

Joannes Vermorel: Normalmente, vemos que todas las recetas numéricas compuestas por los Supply Chain Scientists son el AI Pilot. Esto es lo que pilota la supply chain día a día. Funciona sin supervisión y genera las decisiones. Ahora, con los LLMs se encarga también de los detalles minuciosos de la preparación de datos y de las decisiones de PO. Por ejemplo, la pre-decision consistiría en pedir a los proveedores sus MQS. Necesitas obtener esa información; si falta o no está actualizada, debes cambiarla. Los LLMs pueden ayudarte a conseguir eso. La post-decision consistiría en enviar un correo electrónico para solicitar un ETA, es decir, el tiempo estimado de llegada, para los pedidos, si no tienes un EDI implementado o si no dispones de un puente, o bien para solicitar adelantar o posponer un pedido. Esos son los detalles minuciosos que surgen después, donde Lokad puede generar la decisión de solicitar adelantar un pedido, pero no se encarga de los pormenores que simplemente implican componer y enviar un correo electrónico.

Todo eso es prácticamente el AI Pilot y esa es la gran receta numérica que ejecuta el proceso de extremo a extremo. Todo ello es implementado por el Supply Chain Scientist. Así que, esto es una extensión del alcance para Lokad. El Supply Chain Scientist es, en realidad, el copiloto. Y en serio, cuando digo pilot, me refiero a un piloto automatizado en una aeronave. Y, por cierto, hoy en día, en las aeronaves, las maniobras más difíciles se realizan en autopiloto. Cuando tienes aeropuertos muy intimidantes, como el antiguo aeropuerto de Hong Kong, y uno nuevo que es mucho más sencillo, pero existe uno que está literalmente en medio de edificios altos, entonces el autopiloto para esas maniobras es obligatorio. Así que se hace, es completamente mecánico y la gente simplemente lo supervisa.

Así que aquí, el Supply Chain Scientist está diseñando las recetas numéricas y actúa como copiloto. Ellos deciden, realizan prácticamente la navegación para dirigir las cosas y luego elaboran el plan y la ruta para el piloto. Pero, fundamentalmente, el Supply Chain Scientist desempeña el papel de copiloto, definiendo las direcciones, pensando con antelación y asegurándose de que el piloto pueda operar de la manera más fluida posible. Aunque, en esencia, todos los ajustes de alta frecuencia los realiza el piloto, no el copiloto. Y luego, el cliente asumiría el papel de capitán.

Ya sabes, es un poco como en la vieja serie de televisión Star Trek, donde el capitán se sienta en la silla y da instrucciones de muy alto nivel a la tripulación. Así que, el cliente en este contexto da la estrategia y las directrices generales. Luego, es responsabilidad del Supply Chain Scientist implementar eso y el papel del piloto es simplemente ejecutar todos los micro-ajustes necesarios o todas las decisiones diarias que requiere la supply chain, y luego ejecutar la supply chain en sí.

Conor Doherty: Y esto es, nuevamente, solo para ser claro, ya que no lo discutimos, pero eso es además de todas las tareas cuantitativas automatizadas que ya se realizan. Se han estado haciendo durante años. Así que, si alguien está escuchando y pensando, “oh, bueno, esas son solo las tareas cualitativas”, estamos hablando de extremo a extremo. Sí, cuantitativo como la factoración de economic drivers, la generación de asignación, compras, fijación de precios; eso también está impulsado por IA y automatizado.

Así que el Supply Chain Scientist supervisa ambos tipos de consolas, tanto las cuantitativas como las cualitativas.

Joannes Vermorel: Exacto. Y la razón por la que Lokad finalmente comenzó a adoptar esta palabra clave de AI —que es un término paraguas— fue porque ahora estamos sumando, integrando, LLMs. Ya teníamos machine learning con differentiable programming y optimización estocástica, pero ahora estamos incorporando LLMs. Y así, es literalmente una herramienta muy completa.

El efecto es, literalmente, para los clientes, supply chains que pueden funcionar sin supervisión durante semanas. La gente se sorprende de lo largo que resulta, cuando tienes esos economic drivers, que en realidad puedes operar completamente sin supervisión. La belleza de ello es que no necesitas realizar ningún tipo de micro-ajuste. Por ejemplo, los ajustes al forecast son para la mayoría de nuestros clientes completamente inexistentes. Y la mayoría de los otros ajustes también se realizan de forma completamente automática, tales como la introducción de new products, la eliminación paulatina de productos antiguos, la incorporación de nuevos proveedores y la eliminación paulatina de proveedores no rentables.

Así que, todo eso forma parte del negocio habitual y, cuando las recetas están bien hechas, ya en el pasado no requerían tantas intervenciones. Pero con este AI Pilot que incluye LLMs, al añadir un nuevo proveedor a la mezcla, todas estas cosas pueden requerir aún menos intervención manual de lo que solían necesitar.

Conor Doherty: Está bien, Joannes, gracias. Llevamos unos 40 minutos. Hay preguntas a las que atender, así que nos dirigiremos a ellas ahora. Pero antes, como una especie de resumen o reflexión final, nuevamente en el contexto de la conversación mucho más amplia que tuvimos hace un mes y que tenemos hoy, ¿cuál es la conclusión tanto para el profesional de supply chain como para, digamos, los equipos ejecutivos que supervisan al profesional normal de supply chain? ¿Cuál es el llamado a la acción o el mensaje clave para ellos?

Joannes Vermorel: Creo que dentro de una década, esta visión de AI Pilots, quizá bajo un nombre diferente, será la norma. Tal vez será tan normal que la gente simplemente dirá supply chain y no AI Pilots para supply chain. Y será casi obvio que en supply chain tienes esos AI Pilots. Al igual que cuando dices que tienes una computadora, no dices “tengo una CPU, tengo memoria”, es algo dado que tienes una CPU en tu computadora, así que ni siquiera lo mencionas.

Mi opinión es que, dentro de una década, estas funciones estarán ampliamente automatizadas y Lokad, con esos AI Pilots, ofrece un paquete que lo hace todo con un Supply Chain Scientist. Para nuestros clientes, eso significa que la práctica de supply chain cambia en esencia. Significa que disponen de esos AI Pilots que pueden liberar mucho ancho de banda. Y ya estábamos liberando el ancho de banda para el proceso de toma de decisiones o los cálculos complejos. Pero ahora también estamos liberando el tiempo que se invertía en monitorear la lista de SKUs, la lista de proveedores, la lista de clientes, solo para mantener los datos maestros correctos, limpios y coherentes. Todo eso también desaparecerá y eliminará la necesidad de esas intervenciones manuales que, muy frecuentemente, ni siquiera eran realmente cuantitativas por naturaleza. Tenías que arreglar una etiqueta, corregir una entrada, eliminar un duplicado o algo así. Todo eso, nuevamente, Lokad se encargará de ello.

Así que, en resumen, es una mejora masiva en la productividad. Creo que con algunos clientes estamos logrando literalmente esta reducción del 90% en términos de personal para las tareas repetitivas. La realidad es que ahora tienes más tiempo y lo dedicas a hacer aquellas cosas que son mucho más difíciles de automatizar, y creo que eso añade más valor. Es decir, pensar cuidadosamente en la estrategia, dedicar mucho más tiempo a considerar las opciones, ¿qué deberías explorar en lugar de, de nuevo, perder tiempo en hojas de cálculo?

Así que dedica mucho tiempo a reflexionar intensamente sobre los problemas difíciles y luego habla con proveedores y clientes, y mantén conversaciones profundas y genuinas para que puedas organizar tu propia supply chain de manera que hagas a tus proveedores felices y, de esa forma, estén dispuestos a ofrecerte mejores precios, tendrás mejor calidad, mayor fiabilidad, etc. Si te organizas para adecuarte a las necesidades de tus proveedores, puede sonar, aunque sea un poco lo contrario, como “Oh, proveedores, soy el cliente, ellos tienen que adaptarse a mí.” Pero si puedes adaptarte mejor a tus proveedores, es un esfuerzo en equipo y puedes lograr mayor fiabilidad y mejores precios.

Y puedes hacer el mismo esfuerzo con tu cliente, ya que debe darse la misma colaboración. Y, de nuevo, se requiere una discusión inteligente, y esas son precisamente las cosas que, en estos momentos, van más allá de lo que esos LLMs pueden ofrecer. Así que creo que en Lokad podemos automatizar las tareas que nos gustan, esas minucias de bajo valor y tareas administrativas mundanas, y hacer que las personas se dediquen a lo de alto nivel, a lo semi-estratégico. Digo semi-estratégico porque hablarás con un cliente a la vez y luego elaborarás la estrategia, que consiste en resumir todo, crear una visión y luego apoyar al liderazgo de supply chain para que tengan una estrategia muy clara y bien fundamentada para su compañía.

Conor Doherty: De nuevo, solo para tomar dos ejemplos y conceptualizarlo, como las decisiones de bajo nivel, revisar una hoja de cálculo de Excel diciendo, “Oh, dice que el bloque de colores debe ser negro”, como si lo estuvieras autocorregiendo, es trivial, es mundano, no vale tu tiempo. “¿Debería abrir un warehouse en Hamburgo?” Estratégico.

Joannes Vermorel: Sí, es estratégico. Además, el problema es que hay tantas opciones. Podrías decir: un warehouse, ¿debería comprarlo, alquilarlo, qué tipo de contratos, cuál es el grado de mecanización, ¿necesito un contrato para el equipo de modo que pueda devolverlo, debería arrendar el equipo o no? Quiero decir, hay como cientos de preguntas y, muy frecuentemente, cuando las personas tienen que dedicar el 99% de su capacidad mental a las tareas administrativas, no les queda tiempo para esas grandes cuestiones.

Verás, si aplicara la Ley de Parkinson, la gente diría: he visto muchas empresas en las que, si calculara el total de minutos invertidos en algo como ABC classes, estaríamos hablando cada año de años-hombre invertidos en las ABC classes. Y cuando se trata de decidir sobre un nuevo warehouse, hablamos de semanas de tiempo. Pero ves el desequilibrio, donde colectivamente se invierten literalmente años de tiempo humano en algo que es completamente absurdo como las ABC classes. Y cuando se trata de una inversión de 50 millones de euros para abrir un warehouse, es literalmente semanas de tiempo y, de repente, se toma una decisión. Ves, debería ser al revés.

Conor Doherty: Bien, gracias por eso. Con esa nota, cambiaré a las preguntas de la audiencia. Muchas gracias. Siéntanse libres de enviarlas hasta que básicamente pare. Entonces, Joannes, esta es de Massimo. ¿Podrías explicar, por favor, cómo IT puede aprovechar los AI Pilots para reducir el atraso y por qué crees que se debería proponer este enfoque?

Joannes Vermorel: Los AI Pilots no se tratan de reducir el atraso de IT. Se trata de afrontar el hecho de que IT tiene años de atraso. Así que, nuestro plan en Lokad no es reducir el atraso de IT. Requiere repensar IT de la manera en que lo hizo Amazon. Eso sería otro episodio. Yo diría que busquen el memorando de 2002 de Jeff Bezos sobre las APIs en Amazon. En resumen, todos los departamentos de una empresa moderna necesitan toneladas de herramientas de software. Cada división —marketing, finanzas, contabilidad, supply chain, ventas— quiere toneladas de herramientas de software, y todo eso recae sobre IT. IT se está colapsando bajo ese peso.

Así que, mi punto es que en Lokad somos especialistas en supply chain. No vamos a encargarnos de todo lo relacionado con marketing, ventas, contabilidad y demás. Lo que decimos es que, con los LLMs, podemos liberar a IT de encargarse de Lokad. En resumen, pasamos de necesitar, digamos, de 10 a 20 días de trabajo de IT para poner en marcha la iniciativa de Supply Chain Quantitativa, construir la cadena de procesamiento, a solo unas pocas horas. Así que no estamos resolviendo el atraso. IT hace lo que IT hace. Ellos también pueden beneficiarse de los LLMs, pero, en su caso, las situaciones son mucho más diversas, mucho más difíciles.

Entonces, mi propuesta no es que los LLMs puedan realmente ayudar a TI a reducir sus atrasos. Es solo una forma para Lokad, en este caso específico, de decir: “Bueno, en lugar de añadir 20 días más al backlog, simplemente añadimos algo como cuatro horas y terminamos.” Así es como lidiamos con el backlog. Y, de manera más general, la solución a esos años de backlog es que cada división necesita internalizar la mayor parte de las cuestiones de software. Verás, los años de backlog se deben a que, en general, las empresas están exigiendo demasiado a TI. Deberían existir prácticas digitales en cada división – marketing, ventas, contabilidad, etc. No deberías pedirle a TI que resuelva todos esos problemas por ti. Deberías contar con expertos digitales en cada área para hacerlo. Y esa es exactamente la esencia de este memorando de 2002, si no me equivoco, de Jeff Bezos a su equipo. Es un memorando muy famoso. Puedes teclear “famous memo Bezos” porque, en esencia, él decía: “Tienen dos semanas para tener un plan que permita a cada división exponer todos sus datos, de modo que no tengamos este tipo de siloing y juegos de poder en la compañía, en Amazon.”

Y Bezos concluía: “Cada gerente que no tenga un plan sobre mi escritorio dentro de dos semanas, es despedido o algo así.”

Conor Doherty: Bien, muchas gracias. Este siguiente comentario, y es una pregunta que no formulé porque vi que se mencionaba en los comentarios, así que está planteado como un comentario pero tómalo como una pregunta. Esto es de Jesse. “Un Supply Chain Scientist más un LLM aún suena a copilot. Así que, de nuevo, delimita AI Pilot versus copilot.”

Joannes Vermorel: La razón por la que decimos que es un pilot es porque tenemos algunos clientes en los que, durante semanas, todas las decisiones se generan y luego se ejecutan sin supervisión. Y cuando digo sin supervisión, lo digo en serio. Durante los confinamientos de 2020, incluso tuvimos una empresa en la que, durante 14 meses, todos los empleados de oficina se quedaban literalmente en casa, sin trabajar, pagados por el estado porque este otorgaba subsidios en Europa. Varios estados ofrecían subsidios para, básicamente, quedarse en casa sin trabajar. Y así fue la situación. Entonces, tuvimos eso y cuando tienes una supply chain que opera prácticamente sin supervisión durante 14 meses, yo la llamo pilot, no copilot. Si no hay nadie que supervise los números generados por el sistema, realmente creo que es un pilot.

Pero en aquel entonces no estábamos utilizando un LLM. Y era una situación en la que los datos estaban limpios y no había una necesidad dramática de mejorar esta gestión de datos maestros. Y ese era un cliente que tenía una madurez muy alta en términos de integración EDI, etcétera. Así que, las cosas que se necesitaban antes y después eran muy, muy limitadas.

De todos modos, volviendo a la cuestión del copilot. La mayoría de los competidores de Lokad dicen que están haciendo un copilot. Y, de hecho, la forma en que lo hacen, y esto es algo completamente diferente, es que Lokad, el Supply Chain Scientist, está utilizando un lenguaje de programación. Así que, cuando usamos un LLM, es para generar, para ayudarnos a generar partes de un programa. Para eso lo usamos.

Entonces, se utiliza el LLM para generar, esencialmente, partes de programas que pueden ser los dialectos de SQL o algunas otras cosas. Y luego diseñamos el pilot y éste se ejecuta sin supervisión.

Nuestros competidores, especialmente aquellos que dicen que van a traer IA conversacional, interfaz conversacional, interfaz de usuario al mercado, hacen algo completamente diferente. Lo que hacen es, típicamente, generación aumentada por recuperación (RAG). Así que lo que hacen es componer un prompt. Y eso es, literalmente, lo que hacen todos nuestros competidores que afirman utilizar IA con LLM en el ámbito de la supply chain. Componen, digamos, una docena de prompts que se adaptan a varios scenarios. Luego, después del prompt, inyectan datos recuperados de la base de datos, ya sabes, que pueden ser estadísticas descriptivas básicas. Así que inyectarían unas pocas docenas de números, ventas promedio de la semana pasada, del mes pasado, del año pasado, o lo que sea, estadísticas básicas que se ajusten al escenario. Y luego añadirían la consulta extra del usuario y el LLM completará la respuesta.

Ya ves, esto es nuevamente: los LLMs se tratan simplemente de completar texto. Así que compones un texto y éste lo completa. Y en la generación aumentada por recuperación, la parte de recuperación es simplemente obtener algunos números de la base de datos y luego componer. Pero, en definitiva, ahora obtienes algo en lo que puedes hacer una pregunta. Pero la realidad es que, si no eres un ignorante, puedes leer los números directamente en la pantalla. No hay magia. Así que, fundamentalmente, el LLM solo puede responder preguntas que se pueden contestar fácilmente mediante un dashboard.

Así que sí, si realmente no estás familiarizado con la definición de cada número, puede aclararlo para ti. Pero también puedes tener, y ahí es donde Lokad lo hace, como una ficha técnica que simplemente te da la descripción en una línea adjunta a cada dashboard, para cada número presente en el dashboard. Y eso, efectivamente, cumple el mismo rol, sin necesidad de IA.

En resumen, soy muy, muy escéptico de esas IA conversacionales, esos copilots, porque esencialmente son trucos superpuestos sobre sistemas existentes que nunca han sido diseñados para ningún tipo de sistema de machine learning, ni siquiera para el machine learning clásico, y mucho menos para los LLMs.

Por eso digo que, hasta donde yo sé, todos nuestros competidores están haciendo copilots en los que, esencialmente, tienen algo que es, digamos, un chatbot que se encuentra sobre dashboards. Pero no realiza ninguna automatización. No te permite automatizar ningún tipo de AI Pilot. Es, sí, un truco superpuesto sobre un sistema heredado.

Conor Doherty: Bien, muchas gracias. Continuaré. Esto es de Kyle. “¿Puedes discutir la criticidad del análisis de procesos antes de instituir un modelo de IA?” Lo tomaré en el contexto de supply chain.

Joannes Vermorel: Por sorprendente que parezca, el análisis de procesos es muy importante. Pero no necesariamente de la manera en que la gente piensa. La realidad es que, especialmente en las supply chains, las empresas tuvieron cuatro o cinco décadas para inventar muchos procesos inventados. Y digo “inventados” intencionadamente. La supply chain es un juego de burocracia. Tiene un núcleo burocrático. El juego de la supply chain durante las últimas cinco décadas ha sido una forma de organizar la mano de obra, porque no puede haber una sola persona que se encargue de todos los SKUs, todos los almacenes, todas las ubicaciones, todos los productos. Por lo tanto, necesitas dividir y conquistar el problema, distribuyendo la carga de trabajo entre docenas, posiblemente cientos, de personas en empresas grandes, muy grandes.

Entonces, terminas teniendo una situación en la que el 90% de tus procesos simplemente refleja las complicaciones emergentes que surgen debido a que la carga de trabajo se distribuye entre muchas personas. Ya ves, son procesos accidentales, no procesos esenciales. Así que, diría que sí, necesitas hacer el análisis de procesos, pero ten cuidado: el 90% de los procesos existentes no aborda el problema fundamental al que se enfrenta tu supply chain, sino problemas accidentales creados por el hecho de que se requieren muchas personas para resolver ese 10% del problema que debe ser atendido.

En industrias como la de procesamiento químico, donde tienes muchos flujos y dependencias, es muy complicado. Por ejemplo, cuando se tienen reacciones químicas, se obtienen subproductos. Así que, cada vez que produces un compuesto, produces algo más. Ese algo más puede ser vendido o utilizado para otro proceso. Necesitas coordinar todo eso. Tienes montones de restricciones, procesos que operan en lotes y procesos que funcionan de manera continua. Es muy complicado.

Pero la realidad es que la mayoría de los procesos, en lugar de enfocarse en la fisicalidad del problema –es decir, en una industria de procesos, donde las reacciones químicas tienen entradas y salidas muy específicas y todo eso está muy, muy claramente definido y conocido–, en lugar de centrarse en la capa base de la realidad física de tu negocio, el análisis de procesos podría simplemente reconstruir procesos que desaparecerán cuando implementes el AI Pilot.

Lo interesante es que, cuando lo haces al estilo AI Pilot, ya no necesitas este enfoque de dividir y conquistar. Es un conjunto unificado de recetas numéricas que resuelven el problema de extremo a extremo. Así que todos esos problemas de coordinación que se resolvían con tantos procesos simplemente desaparecen.

Mi experiencia es que el 90% de esos procesos simplemente desaparecerán para cuando hayamos terminado. Por eso digo que es muy importante mantener un enfoque agudo en la capa física base de tu supply chain, en lugar de en los procesos inventados que existen solo para coordinar numerosos equipos. Esas cosas no serán actualizadas, serán reemplazadas por el AI Pilot.

Conor Doherty: Gracias. Y, de hecho, un ejemplo que mencionaste en esa respuesta sirve como una buena transición aquí. Entonces, de parte del espectador Durvesh, ¿tienes planes de hacer open source Envision para uso educativo o de pequeñas empresas? ¿Y se puede programar con reglas para beneficiar a negocios B2B, como el de productos químicos que requieren una extensa entrada manual?

Joannes Vermorel: Sí, tenemos planes de hacer open source Envision en algún momento. Pero primero déjame explicar por qué. En este mundo del software empresarial, contamos con documentación pública para Envision. La mayoría de mis colegas tienen lenguajes específicos de dominio (DSLs), pero no están documentados públicamente. Dassault Systèmes ha comprado otra compañía llamada Quintiq. En ese momento, venía con un DSL, pero no estaba documentado públicamente. Así que, literalmente, en el ámbito de la supply chain, hay otras empresas que tienen DSL y no son públicos. En Lokad, documentamos todo públicamente y contamos con un free sandbox environment para Envision. Incluso tenemos free workshops disponibles para que puedas enseñar o aprender Envision con ejercicios. Así que estamos haciendo mucho más.

Ahora, en lo que respecta a hacer open source un lenguaje, forma parte del plan, pero es demasiado pronto. ¿Por qué? Porque Envision aún está en rápida evolución. Verás, uno de los problemas que tienes al hacer open source un compilador es que el compilador es un programa de software que te permite compilar tu script en algo que se ejecuta. Tan pronto como haces open source tu compilador, significa que la gente va a operar código de Envision, en el caso de Lokad, en el entorno real. Y Lokad pierde la posibilidad de actualizar automáticamente esos scripts. La realidad es que, en la última década, Lokad ha modificado el lenguaje de programación Envision cientos de veces. Este lenguaje no es estable. Si miras mi libro, el libro de Supply Chain Quantitativa, que ahora tiene algo así como seis años, la sintaxis de Envision ha evolucionado dramáticamente. Puedes echar un vistazo a sintaxis vestigial que ya no existe en Envision.

Y entonces, ¿cómo lidiamos con este cambio constante de sintaxis? Bueno, cada semana en Lokad, tenemos lanzamientos cada martes y lo que aplicamos son reescrituras automáticas para todos los scripts de Envision que se operan en las plataformas de Lokad. Así que una de las propiedades clave de Envision es tener, diría, una afinidad muy alta con el análisis estático. Y el análisis estático es, por cierto, una rama del diseño y análisis de lenguajes. Cuando digo lenguaje, me refiero al lenguaje de computadoras, que te permite obtener propiedades de los programas sin ejecutarlos. Y, mediante el análisis estático, lo que podemos hacer es reescribir literalmente de forma automática un script existente desde la sintaxis antigua a la nueva. Y hacemos eso automáticamente los martes. Típicamente, cuando hacemos una actualización, durante unos días se aceptan tanto la sintaxis antigua como la nueva. Realizamos las reescrituras automáticas y, cuando vemos que la sintaxis antigua ya no existe, con un feature flag, confirmamos que solo existe la nueva sintaxis.

Y en Lokad, ya hemos desplegado más de 200 de esas reescrituras automáticas. Típicamente, lo hacemos como lanzamos cada martes, pero generalmente tenemos como dos reescrituras al mes y hemos estado haciendo eso durante una década. Así que, mientras este proceso continúe, en Lokad no podemos lanzar Envision como open source de manera realista. Vendrá a su debido tiempo, pero no quiero repetir el enorme error de Python. La actualización de Python 2 a Python 3 le tomó a la comunidad de Python una década y fue increíblemente dolorosa. Quiero decir, las empresas pasaron años en actualización, fue una pesadilla que duró una década. Eso fue realmente, realmente incorrecto. Incluso Microsoft, con la actualización de C# del framework .NET a .NET Core, demoró media década y fue un gran, gran dolor. Y ese, nuevamente, es el problema de que una vez que tienes un compilador que es open source en el entorno real, no controlas el código. Así que, si quieres introducir cambios en el lenguaje, necesitas colaborar con tu comunidad. Hace que el proceso sea súper lento, súper doloroso y, al final, nunca eliminas realmente todas las malas características de tu lenguaje.

Si miramos a Python, por ejemplo, la manera en que se introdujo la programación orientada a objetos, la sintaxis, ah, es torpe. Realmente se nota que Python no fue diseñado teniendo en mente la programación orientada a objetos. Fue una adición posterior a finales de los 90 y la sintaxis resulta algo pésima y ahora está ahí para siempre. Y, por cierto, todos los lenguajes tienen eso. En C#, tienes la palabra clave volatile que ya no sirve para nada. C++ está atascado para siempre con la herencia múltiple. Eso fue un error. Tener herencia múltiple fue una mala decisión de diseño que complica todo, etc. La única manera de poder evitar esos grandes errores –en Lokad cometimos muchos grandes errores en el diseño de Envision, pero los corregimos uno a uno– es que aún estamos en proceso, especialmente cuando surgen nuevos paradigmas. Por ejemplo, la programación diferenciable fue un gran nuevo paradigma y tuvimos que reingeniería el propio lenguaje para acomodar este paradigma.

Por cierto, existe una propuesta mega importante para Swift, propuesta por Apple, para hacer de la programación diferenciable un ciudadano de primera clase en Swift. Pero probablemente no vaya a suceder en el futuro cercano. Es como una revisión mayor, mayor. En este momento, el lenguaje que está más cerca de tener la programación diferenciable como ciudadano de primera clase sería Julia y, aun así, está lleno de soluciones improvisadas.

Conor Doherty: Gracias de nuevo. Aún quedan tres más por revisar. El siguiente es de Víctor. Esto trata ampliamente sobre IA. ¿Cómo aborda la IA los cuellos de botella aleatorios dado que opera sobre grandes conjuntos de datos para predecir escenarios plausibles o problemas recurrentes?

Joannes Vermorel: Seamos claros, cuando decimos IA, es una colección de técnicas. En Lokad, normalmente tenemos LLMs, programación diferenciable y optimización estocástica. La programación diferenciable es para el aprendizaje, la optimización estocástica sirve para optimizar bajo restricciones en presencia de incertidumbre, el modelo probabilístico que típicamente se ajusta con programación diferenciable, y los LLMs se utilizan para hacer este motor de plantillas universal y resistente al ruido.

Cuando abordas la supply chain con herramientas probabilísticas, la mayoría de las tareas a las que alude esta pregunta simplemente desaparecen. Esa es la belleza del forecast probabilístico, esos forecast no son más precisos, son simplemente mucho más resistentes al ruido ambiente de la supply chain. Cuando combinas el forecast probabilístico con optimización estocástica, eliminas en gran medida la necesidad de intervención manual. Y cuando digo en gran medida, me refiero a que, para la mayoría de los clientes, eso se elimina por completo. Y ahora nos quedan tareas que requieren revisar texto y manejar eso, y para eso están los LLMs. Y nuevamente, lo que describí es Lokad, tenemos esos AI Pilots que están realmente automatizados y, si hay alguna intervención manual, no es para hacer una entrada clerical en el sistema, sino para ingresar una revisión estratégica de la receta numérica que típicamente será una modificación profunda de la lógica misma para reflejar la estrategia revisada. No será, ya sabes, algo menor. Típicamente será algo fundamental que cambia la estructura misma de la lógica que se ha implementado.

Conor Doherty: Este es de Ahsan. ¿Podrías explicar cómo la IA, específicamente, aceleraría un pedido? ¿Sería capaz de ejecutar transacciones en el sistema ERP basándose en comandos verbales?

Joannes Vermorel: Los comandos verbales no son el enfoque adecuado para este problema. Si lo que deseas son entradas de datos más rápidas, la voz es un canal de muy baja capacidad. Escribes más rápido de lo que hablas, a menos que seas muy malo tecleando. Así que, este no es el tipo de ganancia que puedes obtener. Si tu UI está correctamente diseñada con un teclado, serás más rápido que con comando de voz. Lo sé muy bien porque hace 20 años trabajaba en AT&T Labs en la vanguardia de sistemas de reconocimiento de voz de grado producción. Había toneladas de aplicaciones en las que no funcionaba. El reconocimiento de voz funcionaba, pero la realidad es que tus manos en el teclado eran simplemente más rápidas. Las situaciones para la voz eran o manos sucias o manos ocupadas. De lo contrario, el teclado es simplemente más rápido.

Volviendo a la pregunta, primero quieres filtrar los pedidos. Aquí tenemos un proceso de toma de decisiones donde se debe decidir qué pedidos necesitan ser acelerados. Eso es clásico Lokad, es un proceso de toma de decisiones puro, cuantitativo. Necesitas decidir sí o no, si este pedido en curso justifica una solicitud para acelerar el proceso. Haríamos eso con programación diferenciable y optimización estocástica. Así es como llegamos a las decisiones correctas.

Una vez que tenemos eso, automáticamente obtenemos cada día las decisiones para los pedidos. No se trata de tener a alguien que dé órdenes verbales para eso. Será parte del conjunto de recetas numéricas con las que computaremos los pedidos optimizados. Con el tiempo, nos damos cuenta de que algunos pedidos se estaban excediendo o quedando cortos y solicitaremos posponer o acelerar respectivamente. La parte de los LLM es simplemente utilizar esta decisión cuantitativa, donde tienes una bandera binaria que dice “por favor, acélere”, para generar un correo electrónico con el contexto adecuado, enviarlo al proveedor con algo como “por favor confirme que puede hacerlo”, y luego el proveedor, con suerte, confirmará y dirá “sí”, “no”, “quizás puedo” o “esto es lo que puedo ofrecer”.

El LLM automatizará el chat con el proveedor. La IA no se trata de decidir acelerar el pedido. Esa es una decisión puramente cuantitativa que debe abordarse con herramientas cuantitativas, programación diferenciable y optimización estocástica. El LLM está ahí para la interacción con el proveedor, que frecuentemente utilizará un canal no estructurado como el correo electrónico.

Si estás pensando en comandos de voz, no funcionará. Es mucho demasiado lento. Tuve el privilegio de trabajar con los equipos que literalmente llevaron al mercado los primeros sistemas de reconocimiento de voz de grado producción hace 20 años. Pero, en definitiva, no vas a utilizar esas tecnologías de IA para eso. Los comandos de voz no tienen la capacidad necesaria para hacer lo que quieres hacer.

Conor Doherty: En una nota relacionada, cuando hablamos de optimización estocástica y programación diferenciable, contamos con extensos recursos en vídeo sobre estos temas. No los desglosamos porque son parte de una serie de tres partes (parte 1, parte 2 y parte 3) sobre programación diferenciable, pero no los estamos ignorando. Ya se han cubierto y dirijo amablemente a los espectadores que deseen aprender más sobre ello a revisarlos y luego unir estas piezas.

Última pregunta, y es de Isaac. Como cliente que actualmente está aprendiendo Envision, me interesa su capacidad de integración, específicamente con GitHub. ¿Podrías comentar el potencial de Envision para soportar integración con GitHub, particularmente para aplicaciones como explicar bloques de código en lenguaje natural o identificar cambios entre versiones? Por último, ¿hay algún plan para introducir un copilot de Envision en un futuro cercano?

Joannes Vermorel: La respuesta corta es sí, sí y sí. Los plazos varían mucho dependiendo de los componentes de los que estamos hablando. Con el uso de LLMs para hacer básicamente lo de un copilot, como el GitHub copilot pero que será el Lokad copilot en los códigos de Envision, ya estamos trabajando en ello. Lo más interesante es que, debido al hecho de que es un DSL que controlamos, tenemos control completo sobre los materiales de entrenamiento. Eso es muy genial porque significa que el día que logremos llevar este LLM a producción con éxito, cada vez que cambiemos la sintaxis, volveremos a ejecutar nuestro proceso de entrenamiento con la sintaxis actualizada y siempre tendremos un copilot que te ofrezca la sintaxis actualizada de Envision. A diferencia del GitHub copilot que te ofrece una sintaxis de Python, de C# o de Java.

Porque verás, de nuevo, Java existe desde hace 25 años, Python desde hace más de 30 años, C# desde hace 22 años o algo así. Así que, cada vez que le pides al compilador de GitHub que escriba código para ti, el problema es que te ofrece una versión semirreciente de esos lenguajes, pero no realmente la más reciente. Y a veces no deseas la versión más reciente porque tu entorno no está en sintonía con esas versiones súper recientes que aún no soportas.

Estamos trabajando en toda una serie de características súper naturales como comenta mi código, explica mi código, completa mi código. También estamos pensando en muchas acciones de código extendidas que son muy específicas para el tipo de flujos de trabajo que ocurren dentro de Lokad. Por ejemplo, estamos trabajando en poder automatizar la generación de dashboards de salud de datos. Esa es una tarea muy típica.

Los dashboards de salud de datos son esencialmente instrumentos que verifican que los datos que ingerimos son razonables. Y tenemos mucha experiencia y conocimiento sobre qué verificar, porque los problemas que encontrarás en los datos de los ERPs, suelen ser siempre los mismos. Cuando verificamos la corrección de los datos procedentes de un ERP, nosotros Supply Chain Scientists hemos cultivado, literalmente, nuestros propios métodos de entrenamiento para saber qué buscar y tenemos nuestras propias recetas, es decir, recetas humanas, sobre qué debo implementar, qué debo verificar, y podríamos automatizarlo en gran medida con los LLMs. Así que esto es algo que está en progreso en Lokad.

Estamos trabajando en un Lokad copilot. Para hacer que Envision sea más amigable con GitHub, ya hemos lanzado una extensión de Visual Studio code de código abierto. Ya puedes poner código de Envision en un repositorio git. Simplemente creas un archivo .nvn, haces commit y listo. Si deseas editar el código con un buen resaltado de sintaxis, necesitarías una extensión de Visual Studio code. Si buscas la extensión de Visual Studio code de Lokad para Envision, hay una que es completamente de código abierto y obtendrás resaltado de código.

En el futuro, planeamos exponer el código de Envision que se encuentra en una cuenta de Lokad como un repositorio git. La forma en que el código de Envision se almacena en una cuenta de Lokad es prácticamente la misma que en un repositorio git. Está versionado prácticamente de la misma manera. No está organizado exactamente de la misma forma que git; de nuevo, no voy a profundizar demasiado en las razones técnicas. Git es muy agnóstico al lenguaje. Si solo manejas un lenguaje en particular, puedes ser más inteligente y hacer todo tipo de cosas que no son posibles en el caso general. Pero, al final, el código de Envision está completamente versionado. Podríamos exponer un repositorio git que te permita exportar todo tu código de una cuenta de Lokad a un repositorio git y, tal vez, más tarde la otra forma para tener una sincronización bidireccional. Git es un sistema descentralizado en el que cada repositorio git es como el conjunto completo, tienes una copia completa y así puedes obtener cambios de un repositorio remoto pero enviar tus cambios a un repositorio remoto. Y, en algún momento, podríamos introducir, probablemente primero introduzcamos la exportación y luego la reimportación, pero eso tomará tiempo. Aún no hemos llegado a ese punto. Es parte de la hoja de ruta, pero no tenemos un cronograma para ello todavía.

Conor Doherty: Vale la pena señalar que algunas personas en los comentarios dijeron que estaban aprendiendo Envision. Producimos una serie de tutoriales que se realizan en colaboración con la University of Toronto y algunos otros que están en proceso. Hay recursos gratuitos y podemos brindar respuestas si la gente lo desea. Para cualquiera que quiera aprender, nuestros Supply Chain Scientists ponen mucho esfuerzo en esos talleres. Están disponibles gratuitamente en nuestro sitio web.

Joannes Vermorel: Para aquellos que no estén interesados en convertirse en Supply Chain Scientists por sí mismos, Lokad puede proporcionar al Supply Chain Scientist como parte de la oferta AI Pilot.

Conor Doherty: Esas son todas las preguntas, Joannes. Muchas gracias por tu tiempo y muchas gracias por ver. Espero que haya sido útil y nos vemos la próxima vez.