AI Pilots en Supply Chain - Ep 159

00:00:00 Introducción a la entrevista
00:01:01 Impacto de la IA en los trabajos tradicionales
00:04:36 Automatización de la IA en la cadena de suministro
00:09:08 Necesidad de un sistema unificado en 2012
00:10:30 Reintroducción de decisiones en los sistemas
00:13:08 Evitando el problema de la alucinación en la IA
00:16:11 Impacto y retrasos debido a la acumulación de tareas de TI
00:20:04 Comparación de la configuración de Lokad y otros proveedores
00:23:06 Discusión sobre las alucinaciones y confabulaciones de LLM
00:30:38 Enfatizando el progreso sobre la perfección en la IA
00:33:00 Obtención de información faltante y ETA de pedidos
00:36:17 Tareas cuantitativas y LLMs en la cadena de suministro
00:38:28 Futuro de los AI Pilots en la cadena de suministro
00:41:18 Valor de las conversaciones y automatización de tareas de bajo valor
00:44:57 Aprovechando los AI Pilots para reducir la acumulación de tareas
00:49:00 AI Pilot vs copilot y escenario de bloqueo
00:53:36 Escepticismo hacia la IA conversacional y análisis de procesos
00:57:18 Comprender la realidad empresarial y la IA que reemplaza procesos
01:00:12 Desafíos de la divulgación de Envision
01:06:21 Enfoque de la IA hacia los cuellos de botella y la cadena de suministro
01:09:17 Ineficiencia de los comandos verbales y automatización de pedidos
01:14:12 Supply Chain Scientist como copiloto para AI Pilot
01:17:32 Verificación de la corrección de datos y automatización de verificaciones con LLMs
01:20:15 Hacer que Envision sea compatible con git
01:21:14 Recursos gratuitos para aprender Envision

Resumen

En un diálogo entre el CEO de Lokad, Joannes Vermorel, y el Jefe de Comunicación, Conor Doherty, discuten el impacto de la IA en la gestión de la cadena de suministro. Vermorel destaca los avances en IA y modelos de lenguaje grandes, que han revolucionado la automatización de tareas. Introduce los AI Pilots, una oferta de Lokad que automatiza la toma de decisiones y tareas administrativas, facilitado por el lenguaje de programación propietario de Lokad, Envision. Vermorel también habla sobre 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 la cadena de suministro, lo que llevará a mejoras significativas en la productividad. La conversación concluye con una sesión de preguntas y respuestas.

Resumen Extendido

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

Vermorel comenzó destacando el logro histórico de la IA generativa y los modelos de lenguaje grandes (LLMs) en 2023. Estos avances, explicó, han revolucionado la automatización de tareas que involucran texto, como leer correos electrónicos o categorizar quejas. El año 2023 fue especialmente significativo, ya que se produjo una reducción sustancial en el costo operativo de las técnicas de procesamiento de lenguaje natural para las empresas. Vermorel predijo que esto conduciría a la automatización de muchas funciones de soporte interno, con las operaciones de la cadena de suministro a la vanguardia.

Luego, Vermorel presentó los AI Pilots, una oferta de Lokad que automatiza el proceso de toma de decisiones y maneja tareas administrativas mundanas. Hizo hincapié en el enfoque único de Lokad, donde un Supply Chain Scientist puede asumir la responsabilidad total de una iniciativa. Esto es facilitado por el lenguaje de programación propietario de Lokad, Envision, dedicado a la optimización predictiva de las cadenas de suministro. Sin embargo, Vermorel admitió que Lokad había tenido dificultades anteriormente con la búsqueda de datos y el manejo de diversos dialectos de SQL.

La introducción de GPT-4, explicó Vermorel, ha sido un cambio de juego para Lokad, permitiendo a la empresa automatizar la composición de consultas SQL. Estas consultas pueden ser revisadas por un Supply Chain Scientist y probadas para garantizar la precisión. Este desarrollo, junto con una conexión segura de nube a nube, permite que el equipo de Supply Chain Scientists de Lokad persiga los datos de los clientes por su cuenta, reduciendo así los retrasos.

Vermorel también destacó el potencial de los LLM para automatizar muchas tareas relacionadas con los datos maestros, incluyendo la encuesta, el monitoreo y la mejora. Contrapuso el enfoque de Lokad con el de los competidores, afirmando que Lokad generalmente involucra a menos personas en una iniciativa, con cada persona teniendo competencia en todo el proceso. Esto, argumentó, es un contraste marcado con los competidores que a menudo involucran a muchas más personas en una iniciativa, incluyendo gerentes de proyectos, consultores, diseñadores de 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 los scripts generados por los LLM. Vermorel reconoció que los LLM a veces pueden producir resultados inexactos o “alucinados”, pero que generalmente son correctos en términos de dirección y pueden corregirse con algunas iteraciones a través de un ciclo de retroalimentación. Sugirió que aunque los LLM pueden cometer errores, aún pueden proporcionar mucho valor y su tasa de falsos positivos y falsos negativos se puede medir.

Vermorel explicó además la orquestación diaria entre el Supply Chain Scientist, el AI Pilot y el cliente. El AI Pilot, compuesto por el Supply Chain Scientist, maneja las operaciones diarias de la cadena de suministro, gestionando los detalles de la preparación de datos y las decisiones de orden de compra. En esta configuración, el cliente se asemeja al capitán, dando direcciones estratégicas generales.

En cuanto a las lecciones aprendidas para los profesionales de la cadena de suministro y los equipos ejecutivos, Vermorel predijo que en una década, los AI Pilots serán la norma en la Gestión de la Cadena de Suministro (SCM). Esto, según él, conducirá a una mejora masiva de la productividad, con una reducción potencial del 90% en la cantidad de personal para funciones anteriores. Animó a los profesionales de la cadena de suministro a dedicar más tiempo al pensamiento estratégico y a conversaciones en profundidad con proveedores y clientes.

La conversación concluyó con una sesión de preguntas y respuestas, donde Vermorel abordó preguntas sobre una variedad de temas, incluido el papel de los AI Pilots en la reducción de la acumulación de trabajo 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 abrir Envision como código abierto y cómo la IA aborda los cuellos de botella aleatorios. También confirmó que Lokad está trabajando en un copiloto de Lokad y planea hacer que Envision sea más compatible con GitHub.

Transcripción completa

Conor Doherty: Bienvenidos a Lokad en vivo. Mi nombre es Conor. Soy el Jefe de Comunicación aquí en Lokad. Y estoy acompañado en el estudio por el fundador de Lokad, Joannes Vermorel.

El tema de hoy es cómo la IA puede actuar como un piloto independiente para la toma de decisiones en la cadena de suministro. Siéntanse libres de enviar sus preguntas en cualquier momento en el chat de YouTube, y las responderemos en aproximadamente 30-35 minutos.

Y con eso, Joannes, los AI Pilots en la cadena de suministro me parece que esta conversación es una continuación de una que tuvimos, creo que hace unas cuatro semanas, donde hablamos sobre las implicaciones de la IA en el empleo y el futuro de los trabajos tradicionales versus la IA en la cadena de suministro.

Entonces, antes de entrar en los detalles de los AI Pilots, ¿podrías dar, para aquellos que no lo vieron, un resumen, simplemente un resumen ejecutivo, cuál es nuestra perspectiva sobre los trabajos tradicionales versus la IA en la cadena de suministro?

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

Ahora, en 2023, lo que llega al mercado es la IA generativa empaquetada para imágenes y, lo que es más importante, para texto. Y hay un producto que popularizó eso, es ChatGPT de OpenAI. ¿Qué significa eso? Significa muy específicamente, especialmente para esos modelos de lenguaje grandes, que tienes una máquina universal de plantillas resiliente al ruido.

Eso significa que todos los pasos de software empresarial, hablo en el contexto de los trabajadores de cuello blanco en entornos corporativos, significa que todos los pasos que no se podían automatizar en el pasado porque teníamos que lidiar con texto en cualquier forma, eso significa leer un correo electrónico, extraer una referencia o un precio de un correo electrónico o una cantidad o categorizar el tipo de queja o solicitud de un socio o cliente proveedor de un correo electrónico, identificar si una etiqueta de producto no tiene sentido, por ejemplo, si falta la descripción del producto, está bien, tenemos un problema, todas esas cosas en el pasado no se podían hacer fácilmente. Se podían hacer de otras formas, pero no se podían automatizar fácilmente.

Si volviéramos, digamos, cinco años atrás, la minería de texto ya era algo. Ya era posible tener 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 empaquetado que se logró con GPT-4, esencialmente a través de una API, significó que todos esos problemas de técnicas de procesamiento de lenguaje natural, tuvieron su costo operativo para las empresas reducido en un factor de 100, si no de 1,000. Lo que significa que no solo el costo, sino también el tiempo que lleva configurar la cosa.

Entonces, la conclusión, y esa es mi predicción, es que muchas funciones de soporte en las empresas que son funciones internas, que toman algunos datos y producen una salida para otras divisiones, serán automatizadas. La cadena de suministro está en primera línea porque no es exactamente una función orientada al cliente. Es una función muy interna, importante pero interna. Y por lo tanto, los casos en los que los modelos de lenguaje grandes eran el ladrillo que faltaba para automatizar en gran medida de principio a fin la gran mayoría de las operaciones mundanas en las cadenas de suministro.

Lokad ha estado automatizando el análisis cuantitativo y el proceso de toma de decisiones cuantitativas durante una década, pero hay muchas operaciones mundanas que ocurren antes y muchas operaciones mundanas que ocurren después, y esas son las que se pueden automatizar gracias a los modelos de lenguaje grandes, y de manera rápida y económica.

Conor Doherty: Bueno, gracias. Y ya tenemos un video en el que hablamos durante aproximadamente una hora y media sobre ese tema, así que no dedicaré más tiempo hoy a eso, pero eso sienta las bases para el resto de la conversación. Invito amablemente a cualquiera que quiera saber más sobre eso a revisar el video anterior. Ahora, hablando de eso, ¿cómo encajan los pilotos de IA en todo lo que acabas de decir? ¿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 un término general para englobar lo que tenían. Así que cuando digo pilotos de IA, es algo muy propio de Lokad. Es una evolución de nuestra oferta, probablemente la más grande que hemos tenido en años. ¿Y cuál es la diferencia? Bueno, la diferencia es que un piloto de IA es un software, lo que llamamos una serie de recetas numéricas, que no solo ejecuta el proceso de toma de decisiones, que es el aspecto cuantitativo puro de la cadena de suministro, es decir, determinar exactamente cuánto pedir, dónde asignar el stock, si hay que subir o bajar los precios, cómo programar exactamente la producción con todos los pasos, etc.

Eso es algo que ya estábamos haciendo, además de todo lo que viene antes y después en términos de tareas administrativas mundanas que son principalmente la gestión de datos maestros antes del 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, donde se desea enviar un correo electrónico a un proveedor para solicitar que se acelere algo o, por el contrario, que se posponga un pedido.

Y la esencia de esta oferta son obviamente los modelos de lenguaje grandes que Lokad no inventó, que hemos estado utilizando ampliamente durante 14 meses, un poco más que eso ahora. Y la idea clave en la forma en que Lokad opera es que debería haber un Supply Chain Scientist que pueda asumir la responsabilidad total de una iniciativa.

Para empresas muy grandes, es posible que tengamos varias personas trabajando en el caso, pero a diferencia de la mayoría de nuestros competidores, generalmente no están especializados. No es como si tomáramos un equipo de tres personas con el Sr. Base de Datos, el Sr. Algoritmos y el Sr. Experiencia de Usuario y UI. Esa no es en absoluto la forma en que Lokad opera. Un Supply Chain Scientist es capaz de hacer todo, desde el principio hasta el final.

Y esa es una de las razones por las que Lokad ha desarrollado su propia tecnología, su propio lenguaje de programación, un lenguaje de programación específico del dominio llamado Envision, dedicado a la optimización predictiva de las cadenas de suministro. Puede sonar muy extraño haber creado un lenguaje de programación personalizado, pero la idea principal es que, y esa fue una decisión que tomé en 2012, realmente necesitábamos algo que fuera unificado para que una persona pudiera hacer todo, de principio a fin.

Hasta hace unos años, eso implicaba obtener los datos de transacciones en bruto de los ERPs, CRMs, EDI y todos esos sistemas transaccionales, completarlos con una serie de hojas de cálculo para todos los datos estructurados que desafortunadamente forman parte de la TI en la sombra en lugar de la TI regular, y luego crear las recetas numéricas para la toma de decisiones. Y eso era responsabilidad del Supply Chain Scientist hacer todo eso, luego crear toda la instrumentación, incluidos los tableros de control 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 estábamos haciendo, además de todos los instrumentos para monitorear la calidad de las decisiones a lo largo del tiempo, además de la infraestructura para obtener 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 los receptores de los datos, no podíamos realmente buscar los datos. Y cuando digo buscar, el Supply Chain Scientist podía solicitar los datos, no estábamos pidiendo a las divisiones de TI de nuestros propios clientes que hicieran ninguna transformación sofisticada, simplemente se trataba de volcar las tablas, seleccionar todo de la tabla, ¡bam!, lo haces una vez al día y listo. Así que eran extracciones muy sencillas, pero aún así, eran las divisiones de TI de nuestros clientes las que lo hacían.

No se esperaba que los Supply Chain Scientists buscaran en el panorama aplicativo de nuestros clientes los datos que necesitaba la iniciativa. La razón de esto era muy simple, hay alrededor de 20 dialectos SQL, como Oracle SQL, Microsoft SQL Server T-SQL, MySQL, PostgreSQL, DB2 de IBM, etc. Así que hay alrededor de 20 dialectos SQL. Hasta hace unos años, un Supply Chain Scientist habría tenido grandes dificultades simplemente porque, incluso si lo que esta persona quería lograr era extremadamente 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 había un mensaje de error, nuevamente esta persona, aunque en general estuviera familiarizada con las bases de datos SQL, era un obstáculo enorme lidiar con dialectos de sistemas que no conocía.

En 2023, con ChatGPT, el problema está resuelto. ChatGPT, como asistente programador, no es naturalmente excelente para permitirte componer aplicaciones sofisticadas, pero cuando se trata de componer consultas SQL muy sencillas 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 que se te presenta, es bastante autoexplicativa.

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

Eso realmente cambia el juego porque significa que de repente Lokad, que está capacitando a Supply Chain Scientists, puede encargarse de buscar los datos. Y sé que tenemos, a través de ChatGPT, las herramientas para no comprometernos demasiado diciendo que vamos a buscar los datos. Es un cambio de juego. 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 muy segura de nube a nube, y luego permitir que el equipo de Supply Chain Scientists busque sus propios datos.

¿Por qué eso marca tanta diferencia? Bueno, la realidad es que aunque Lokad solo necesite días de trabajo para una iniciativa determinada, estamos hablando de tal vez 10 a 20 días de trabajo para una iniciativa considerable para obtener las 20 a 50 tablas que necesitamos, simplemente volcando la tabla sin cruces, sin uniones, sin filtrados complicados, es muy sencillo. Sin embargo, el problema es que muchos de nuestros clientes tienen sus propias divisiones de TI que tienen grandes acumulaciones de trabajo. Quiero decir, literalmente años de acumulación y cuando tienes como tres años de acumulación, incluso si Lokad solo está pidiendo 10 días, son 10 días más tres años de acumulación, por lo que incluso si no estamos exactamente al final de la cola, si estamos en medio de la cola, esos 10 días de trabajo de TI pueden llevar cualquier cosa como un año en completarse y eso fue, diría yo, una frustración que teníamos, es que la mayoría de los retrasos que estábamos teniendo provenían de que TI no era incompetente o lento, es solo que tenían tanto acumulado que era muy difícil para ellos asignar esos 10 días.

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

La forma en que podemos hacer eso es típicamente monitoreando el rendimiento. Siempre que el rendimiento de la base de datos disminuye, significa que hay mucho en la base de datos y, por lo tanto, típicamente quieres aliviar la presión y retrasar tu propio proceso de recuperación de datos. Porque típicamente, en Lokad, necesitamos actualizar los datos diariamente, pero no es súper urgente. Quiero decir, de nuevo, depende. Hay algunas situaciones en las que tenemos horarios muy ajustados, pero con mucha frecuencia, en lo que respecta a las cadenas de suministro, si retrasamos la recuperación en 30 minutos solo porque hay un pico de actividad en esta base de datos en este momento, no es un problema.

El primer bloque de compromiso es buscar los datos nosotros mismos y así eliminar la causa número uno de retraso y acelerar enormemente las iniciativas. Nuevamente, esos retrasos se convirtieron con mucha frecuencia en la mayor parte del retraso de toda la iniciativa de Lokad para llegar a producción, simplemente esperando a que TI pudiera asignar esos días.

El segundo bloque de compromiso es la Mejora de los Datos Maestros. Y aquí, nuevamente, en el pasado, cuando te enfrentas a un catálogo donde hay, digamos, 100,000 descripciones de productos, algunos de ellos son basura, ya sabes, tal vez el 1%. Es mucho trabajo revisar esas 100,000 referencias, identificar las descripciones o etiquetas de productos incorrectas o a veces puede ser solo un punto de precio que es completamente inconsistente con la descripción. Si dice un tornillo y el punto de precio es de 20,000 dólares, probablemente no sea solo un tornillo, probablemente sea otra cosa, etc. Había muchas verificaciones básicas de sentido común que parecían obvias y simples, pero era muy difícil automatizar eso y frecuentemente no había otra alternativa que tener a una persona revisando las entradas en busca de cosas que fueran realmente malas.

Con un LLM, y potencialmente un LLM que también pueda procesar imágenes, puedes hacer muchas cosas cuando se trata de supervisar, monitorear y mejorar todo lo relacionado con los Datos Maestros. En el caso específico de Lokad, la parte de Datos Maestros que se necesita para pilotar las cadenas de suministro.

Conor Doherty: Bueno, hay mucho ahí, gracias. Tengo muchas preguntas sobre las 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 hacer una cantidad tremenda de trabajo. Trabajo que hasta este momento habría llevado mucho tiempo e involucrado a muchas personas. Ahora, en una configuración no estilo Lokad, ¿cuántas personas más estarían involucradas? ¿Cuántas más manos en la masa habría? Y luego puedes hablar sobre la eficiencia de ello, pero solo en términos de personal, ¿cuál es la diferencia entre los Supply Chain Scientists con LLM y, por ejemplo, S&OP?

Joannes Vermorel: Nuestros clientes suelen quedarse perplejos por el hecho de que incluso una gran iniciativa sea como 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. Entonces, en resumen, Lokad es típicamente el 1% de principio a fin. Si tenemos varias personas, nuevamente es para tener redundancia. Un día te enfocas en esta parte del proceso y yo hago esta otra parte del proceso, y al día siguiente cambiamos. No es que las personas no se especialicen, cada persona tiene competencia en todo el proceso. Hay algunas variaciones y algunas personas tienen alguna especialidad particular, pero aún así, en general, las personas realmente pueden sustituir a otras.

Nuestros competidores, es muy diferente. Incluso una pequeña iniciativa involucra literalmente media docena de personas. Tendrás al gerente de proyecto que solo está allí para coordinar a los demás, luego tienes al consultor, al diseñador de UX, al configurador, al administrador de base de datos, al especialista en redes y potencialmente a un programador, un ingeniero de software para las personalizaciones que no son nativas. Nuevamente, Lokad es una plataforma programática, la mayoría de nuestros competidores, sus plataformas no son programáticas. Entonces, cada vez que quieres tener algo que se comporte de manera programática, necesitas tener un ingeniero de software completo que literalmente implementará con un lenguaje de programación de propósito general como Java o Python las partes faltantes. Entonces, Lokad no es realmente así. Yo diría que nuestros competidores, en su mayoría, son una docena. Las iniciativas de S&OP pueden involucrar a varias docenas de personas, pero no necesariamente muchas habilidades diferentes, en su mayoría son personas diferentes de diferentes departamentos y con frecuencia no está muy impulsado por TI.

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

Conor Doherty: Gracias. Y volviendo a otro punto que mencionaste al principio cuando hablaste de los Supply Chain Scientists, diste el ejemplo de los diferentes dialectos de SQL y luego el Supply Chain Scientist que puede o no ser fluido en ese dialecto específico del cliente validaría o supervisaría los scripts que se generaron automáticamente porque los LLM a veces alucinan.

Bueno, en ese punto, los LLM alucinan muy a menudo. Ahora, nuevamente, está mejorando, pero puedes preguntarle a un LLM con un trozo de texto: “¿Puedes ver esta palabra oculta?” y dirá que sí, bueno, no está ahí. Sé que no está ahí, tú sabes que no está ahí. ¿Cómo puedes tener seguridad y control de calidad a gran escala cuando estás hablando de aprovechar los LLM de manera automatizada?

Joannes Vermorel: Las alucinaciones, o confabulaciones como prefiero llamarlas, realmente ocurren cuando usas el LLM como una base de conocimiento de todo. Si estás usando los LLM como una base de conocimiento de todo, entonces sucede. Si pides documentos médicos y dices: “Dame una lista de documentos sobre esta patología”, te dará algo que es direccionalmente correcto. Los autores existen con frecuencia, han publicado, tienen cosas que estaban en esta área, han publicado documentos que estaban más o menos en la misma línea pero no del todo. Eso es nuevamente, 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 vendrían con algo que es medianamente plausible con nombres correctos de colegas o investigadores, títulos semi-correctos, ese tipo de cosas. Entonces, esa es una situación donde obtienes confabulaciones, pero estás suplicando por ello. Quiero decir, estás pidiendo que los LLM 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 de SQL, lo intentas y obtienes algo, esto será aproximadamente correcto. Si preguntas, “Quiero leer una tabla”, va a hacer un “select star from table” esto y aquello. No te va a dar, cuando le pides, digamos con GPT-4, que lea una tabla, no te va a dar “drop table”. Puede darte una sintaxis que es ligeramente inadecuada, por lo que pruebas tu consulta de SQL y obtienes un mensaje de error y haces un pequeño ajuste y funciona. Pero como ves, sigue siendo direccionalmente correcto. Si pides leer la base de datos, no va a producir un comando que elimine una tabla o modifique las tasas de permiso de la base de datos.

Lo mismo ocurre cuando pides conocimiento inventado. Por ejemplo, si preguntas: “Ok, tengo un compresor industrial de 20 kilovatios de potencia, ¿cuál es el punto de precio de eso?” Si le preguntas a GPT, probablemente dirá algo como $10,000. Es solo una estimación. 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.

Entonces, la conclusión es que las confabulaciones no ocurren al azar. Hay tareas realmente específicas donde ocurren con mucha más frecuencia. Así que diría que cuando lo estás suplicando, cuando estás usando el LLM como una base de datos de todo, entonces es mejor verificarlo. Puede ser extremadamente útil, te da, por ejemplo, para los dialectos de SQL, te dará una pista sobre el tipo de palabras clave que debes usar, cómo se ve la sintaxis, y puede cometer un pequeño error, omitir una coma o algo así, pero con unas pocas iteraciones, lo lograrás. Especialmente porque una vez que tienes la consulta de SQL, puedes probarla en la base de datos, verás la salida y validarás, por lo que tienes un bucle de retroalimentación instantáneo para validar eso.

Si quieres detectar, digamos, etiquetas de productos extrañas, etiquetas de productos que parecen sospechosas como esta descripción de producto que falta, esa es tu etiqueta de producto, está obviamente mal. Pero puedes tener todo tipo de errores. Por ejemplo, puedes tener una etiqueta de producto que dice “tournevis cruciforme” está en francés y el problema es que está solo en francés, es un destornillador con cabeza Phillips, creo. Y nuevamente, puedes pedir cosas pero en algún momento, no es perfecto, es una decisión subjetiva. Un humano cometería el mismo error, por lo que no puedes esperar que el LLM sea un oráculo definitivo que pueda responder cada pregunta correctamente. En algún momento, si estás haciendo 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 al igual que 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 con mucha frecuencia, obtienes algo que es bastante bueno, algo que te brinda mucho valor incluso si aún comete algunos errores.

Conor Doherty: Progreso, no perfección.

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

Conor Doherty: También está el valor del tiempo que no se gastó haciendo eso manualmente y que podrías haber hecho algo más que genere o agregue valor. Entonces, nuevamente, hay impulsores directos e indirectos de valor.

Joannes Vermorel: Además, la realidad es que cuando haces una tarea súper repetitiva durante una hora, puedes tener un cierto nivel de calidad. Cuando haces eso durante 100 horas, en la hora 67, quiero decir, típicamente, los humanos no son motores de rendimiento constantes. Después de unas pocas horas, la concentración disminuiría y, por lo tanto, la cantidad de falsos positivos, falsos negativos probablemente se dispararía, incluso con un empleado bastante diligente.

Conor Doherty: Gracias. Y quiero tener en cuenta el hecho de que en realidad tenemos algunas preguntas de la audiencia que abordan cosas que iba a preguntar, así que omitiré algunas cosas, pero se abordarán en las preguntas de la audiencia. Pero un pensamiento final aquí, cuando hablas de los Supply Chain Scientists, el AI Pilot, y volveremos a eso más adelante en las preguntas, pero el Supply Chain Scientist, un AI Pilot y el cliente, ¿cómo funciona realmente esa orquestación en el día a día? ¿El cliente tiene acceso, interactúan con el LLM?

Joannes Vermorel: Típicamente, lo vemos como todas las recetas numéricas compuestas por los Supply Chain Scientists son el AI Pilot. Esto es lo que pilotea la cadena de suministro a diario. Es sin supervisión y genera las decisiones. Ahora, con LLMs, maneja los detalles de la preparación de datos y las decisiones de PO también. Por ejemplo, la predecisión sería pedir a los proveedores sus MQS. Necesitas obtener esta información, está faltante o no está actualizada, necesitas cambiar eso. LLMs puede ayudarte a obtener eso. La post-decisión sería enviar un correo electrónico para solicitar una ETA, tiempo estimado de llegada, para los pedidos si no tienes un EDI en su lugar o si no tienes un puente, o pedir que se acelere un pedido o se posponga. Ese es el tipo de detalles que vienen después, donde Lokad puede generar la decisión de solicitar que se acelere un pedido, pero no hacer los detalles que eran simplemente componer un correo electrónico y enviarlo.

Todo eso es prácticamente el AI Pilot y esa es la gran receta numérica que realiza el proceso de principio a fin. Todo eso es implementado por el Supply Chain Scientist. Entonces, esta es una extensión del alcance para Lokad. El Supply Chain Scientist es el copiloto en realidad. Y realmente piensa en ello como cuando digo piloto, realmente me refiero a un piloto automático en una aeronave. Y por cierto, en la actualidad, las maniobras más difíciles de las aeronaves se realizan con el piloto automático. Cuando tienes aeropuertos muy aterradores como el antiguo aeropuerto de Hong Kong, con uno nuevo que es mucho más fácil, pero tienen uno que está literalmente en medio de edificios altos, entonces el piloto automático para esas maniobras es obligatorio. Entonces se hace, es la máquina todo el camino, las personas solo supervisan.

Entonces, aquí, el Supply Chain Scientist está diseñando las recetas numéricas y son el copiloto. Deciden, hacen prácticamente la navegación para dirigir las cosas y luego diseñan el plan y el plan de curso para el piloto. Pero fundamentalmente, el Supply Chain Scientist desempeña el papel de copiloto, pensando en las direcciones, pensando en el futuro y asegurándose de que el piloto pueda operar de la manera más fluida posible. Pero fundamentalmente, todos los ajustes de alta frecuencia, es el piloto, no el copiloto. Y luego el cliente sería el papel del capitán.

Sabes, un poco como en la antigua serie de televisión, Star Trek, donde el capitán está sentado en la silla y dando instrucciones de alto nivel a la tripulación. Entonces, el cliente en esta configuración está dando la estrategia y dando las direcciones generales. Luego, es el papel del Supply Chain Scientist implementar eso y el papel del piloto es simplemente ejecutar todos los microajustes que se necesitan o todas las decisiones diarias que se necesitan para la cadena de suministro y luego ejecutar la cadena de suministro en sí.

Conor Doherty: Y esto también, nuevamente, para ser claro porque no hablamos de ello, pero eso es además de todas las tareas cuantitativas automatizadas que ya se realizan. Se han realizado durante años. Entonces, en caso de que alguien esté escuchando y pensando: “Oh, bueno, eso son solo tareas cualitativas”, estamos hablando de principio a fin. Sí, cuantitativo, como el factor de impulsores económicos, generación de asignación, compras, precios, eso también está impulsado por IA y ya está automatizado.

Entonces, el Supply Chain Scientist supervisa ambos tipos de consolas, cuantitativas y cualitativas.

Joannes Vermorel: Exactamente. Y la razón por la cual Lokad comenzó a adoptar esta palabra clave de IA finalmente, que es un término general, fue porque ahora estamos agregando, lanzando al conjunto, LLMs. Ya teníamos aprendizaje automático con programación diferenciable y optimización estocástica, pero ahora estamos agregando LLMs encima. Y así es literalmente un conjunto de herramientas muy completo.

El efecto es literalmente para los clientes, cadenas de suministro que pueden funcionar sin supervisión durante semanas. La gente se sorprende de cuánto tiempo se puede operar sin supervisión cuando se tienen esos impulsores económicos. Lo bueno es que no necesitas hacer ningún tipo de microajuste. Por ejemplo, los ajustes al pronóstico no existen para la mayoría de nuestros clientes. Y la mayoría de los otros ajustes también se realizan completamente automáticamente, como la introducción de nuevos productos, la eliminación de productos antiguos, la introducción de nuevos proveedores y la eliminación de proveedores que no cumplen.

Entonces, todo eso es algo normal en el negocio y cuando las recetas se hacen correctamente, ya no requieren tantas intervenciones. Pero con este Piloto de IA que incluye LLMs, agregar un nuevo proveedor al conjunto, todas estas cosas pueden requerir incluso menos intervención manual de lo que solían requerir.

Conor Doherty: De acuerdo, Joannes, gracias. Hemos estado hablando durante unos 40 minutos. Hay preguntas a las que debemos responder, así que ahora nos dirigiremos hacia eso. Pero antes de hacerlo, como resumen o pensamiento final, nuevamente en el contexto de la conversación mucho más amplia que tuvimos hace un mes y ahora que estamos teniendo hoy, ¿cuál es la conclusión para el profesional de la cadena de suministro y digamos los equipos ejecutivos que supervisan al profesional de la cadena de suministro promedio? ¿Cuál es la llamada a la acción o el mensaje para ellos?

Joannes Vermorel: Creo que dentro de una década, esta visión de los Pilotos de IA, tal vez con un nombre diferente, será la norma. Tal vez sea la norma y la gente simplemente dirá cadena de suministro y no Pilotos de IA para la cadena de suministro. Y será obvio que la cadena de suministro tiene esos Pilotos de IA. Al igual que cuando dices una computadora, no dices que tienes una CPU, tienes memoria, se da por sentado que tienes una CPU en tu computadora, por lo que ni siquiera mencionas eso.

Mi opinión es que dentro de aproximadamente una década, estas funciones estarán ampliamente automatizadas y Lokad, con esos Pilotos de IA, ofrecerá un paquete que simplemente lo hace con un Supply Chain Scientist. Para nuestros clientes, esto significa que la práctica de la cadena de suministro cambia en su naturaleza. Significa que tienen esos Pilotos de IA que pueden liberar mucha capacidad. Y ya estábamos liberando la capacidad para el proceso de toma de decisiones o el cálculo complejo. Pero ahora también estamos liberando el tiempo que se dedicaba a monitorear la lista de SKUs, la lista de proveedores, la lista de clientes, solo para mantener los datos maestros correctos, limpios y saludables. Todo eso también desaparece y elimina la necesidad de tener esas intervenciones manuales que muy a menudo ni siquiera eran realmente cuantitativas en su naturaleza. Tenías que corregir una etiqueta, corregir una entrada, eliminar un duplicado o algo así. Todo eso, nuevamente, Lokad se encargará de eso.

Entonces, la conclusión es que es una mejora de productividad masiva. Creo que con algunos clientes estamos logrando literalmente una reducción del 90% en términos de personal para las tareas repetitivas. La realidad es que ahora tienes más tiempo y realmente haces lo que es mucho más difícil de automatizar y creo que eso agrega más valor. Lo cual es realmente pensar cuidadosamente en la estrategia, dedicar mucho más tiempo a pensar en las opciones, qué deberías explorar en lugar de perder tu tiempo en hojas de cálculo.

Así que dedica mucho tiempo a pensar detenidamente en los problemas difíciles y luego habla con los proveedores y los clientes y ten una conversación genuina y profunda para que puedas organizar tu propia cadena de suministro para satisfacer las necesidades de tus proveedores y así estarán dispuestos a darte mejores precios, tendrás mejor calidad, mejor confiabilidad, etc. Si te organizas para satisfacer las necesidades de tus proveedores, puede sonar un poco lo contrario, “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 tener más confiabilidad y mejores precios.

Y puedes hacer el mismo esfuerzo con tus clientes porque también debe haber una colaboración similar. Y nuevamente, requiere mucha discusión inteligente y esas son las cosas que van más allá de lo que esos LLM pueden ofrecer en la actualidad. Así que creo que Lokad puede automatizar las tareas que nos gustan, las tareas de bajo valor y tareas administrativas mundanas, y hacer que las personas realicen tareas semiestratégicas de alto nivel. Digo semiestratégicas porque hablarás con un cliente a la vez y luego harás la estrategia que es resumir todo eso, crear una visión y luego apoyar al liderazgo de la cadena de suministro para que tengan una estrategia muy clara y bien fundamentada para su empresa.

Conor Doherty: Entonces, nuevamente, solo para tomar dos ejemplos para conceptualizar eso, las decisiones de bajo nivel, revisar una hoja de cálculo de Excel y decir: “Oh, dice bloque en colores, debe ser negro”, corregir eso automáticamente, eso es trivial, mundano, no vale la pena tu tiempo. “¿Debería abrir un almacén en Hamburgo?” Estratégico.

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

Ves, si aplicara la Ley de Parkinson, la gente diría, he visto muchas empresas donde si calculara la suma total de minutos invertidos en algo como clases ABC, estaríamos hablando de años de trabajo invertidos en clases ABC cada año. Y cuando se trata de decidir por un nuevo almacén, estamos hablando de semanas de tiempo. Pero ves el desequilibrio donde las personas gastan colectivamente años de tiempo humano en algo completamente absurdo como las clases ABC. Y cuando se trata de una inversión de 50 millones de euros para abrir un almacén, son literalmente semanas de tiempo y luego ¡zas!, se toma una decisión. Ves, debería ser al revés.

Conor Doherty: Muy bien, gracias por eso. En ese sentido, pasaré a las preguntas de la audiencia. Muchas gracias. Siéntanse libres de enviarlas hasta que básicamente pare. Entonces, Joannes, esto es de Massimo. ¿Podrías elaborar por favor sobre cómo IT puede aprovechar los pilotos de IA para reducir el atraso y por qué crees que se debería proponer este enfoque?

Joannes Vermorel: Los pilotos de IA no se tratan de reducir los atrasos de IT. Se trata de lidiar con el hecho de que IT tiene años de atraso. Entonces, 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. Diría que busquen el memorando de Jeff Bezos de 2002 sobre las APIs en Amazon. La conclusión es que todos los departamentos en una empresa moderna necesitan toneladas de cosas de software. Cada división - marketing, finanzas, contabilidad, cadena de suministro, ventas - todos quieren toneladas de herramientas de software y todo eso recae sobre los hombros de IT. IT se está colapsando bajo eso.

Entonces, mi punto es que en Lokad, somos especialistas en cadena de suministro. No vamos a abordar todas las cosas de marketing, ventas, contabilidad y demás. Lo que decimos es que con LLMs, podemos liberar a IT de ocuparse de Lokad. La conclusión es que 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 el pipeline, a solo unas pocas horas. Entonces, no estamos resolviendo el atraso. IT hace lo que IT hace. También pueden beneficiarse de LLMs, pero en su caso, las situaciones son mucho más diversas, mucho más difíciles.

Entonces, mi propuesta no es que LLMs realmente puedan ayudar a IT a reducir sus atrasos. Es solo una forma para Lokad, en este caso específico, de decir: “Bueno, en lugar de agregar 20 días más al atraso, solo agregamos aproximadamente cuatro horas y listo”. Así es como enfrentamos el atraso. Y luego, de manera más general, la solución a esos años de atraso es que cada división internice la mayor parte de las cosas de software. Verás, los años de atraso se deben a que las empresas en general exigen demasiado a IT. Debería haber prácticas digitales en cada división: marketing, ventas, contabilidad y demás. No deberías pedirle a IT que resuelva todos esos problemas por ti. Deberías tener expertos digitales en cada área para hacer eso. Y eso es exactamente la esencia de este memorando de 2002, si no confundo, de Jeff Bezos a su equipo. Es un memorando muy famoso. Puedes buscar “famous memo Bezos” porque él decía, en esencia: “Tienen dos semanas para tener un plan para que cada división pueda exponer todos sus datos para que no tengamos este tipo de aislamiento y juegos de poder en la empresa, en Amazon”.

Y Bezos concluía: “Cada gerente que no tenga un plan en mi escritorio en dos semanas será despedido o algo así”.

Conor Doherty: Bueno, gracias. Este próximo comentario, y es una pregunta que no hice porque vi que se mencionaba en los comentarios, así que está formulado como un comentario pero tómalo como una pregunta. Esto es de Jesse. “Un Supply Chain Scientist más un LLM todavía suena como un copiloto. Entonces, nuevamente, delinea el piloto de IA versus el copiloto”.

Joannes Vermorel: La razón por la que decimos que es un piloto es porque tenemos algunos clientes donde durante semanas, todas las decisiones se generan y luego se ejecutan sin supervisión. Y cuando digo sin supervisión, realmente lo digo en serio. Durante los confinamientos de 2020, incluso tuvimos una empresa donde durante 14 meses, todos los trabajadores de cuello blanco literalmente se quedaban en casa, sin trabajar, pagados por el estado porque el estado estaba dando subsidios en Europa. Varios estados estaban dando subsidios para básicamente quedarse en casa y no trabajar. Y esa era la situación. Entonces, teníamos eso y cuando tienes una cadena de suministro que opera prácticamente sin supervisión durante 14 meses, lo llamo un piloto, no un copiloto. Si no hay nadie supervisando los números generados por el sistema, realmente creo que es un piloto.

Pero en ese entonces no estábamos usando un LLM. Y fue 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 y demás. Entonces, las cosas que se necesitaban antes y después eran muy, muy limitadas.

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

Entonces, LLM se utiliza para generar básicamente partes de programas que pueden ser los dialectos SQL, entre otras cosas. Y luego diseñamos el piloto y luego el piloto se ejecuta sin supervisión.

Nuestros competidores, especialmente aquellos que dicen que van a llevar la inteligencia artificial conversacional, la interfaz de usuario conversacional, al mercado, hacen algo completamente diferente. Lo que hacen es típicamente generación aumentada por recuperación (RAG, por sus siglas en inglés). Entonces, lo que hacen es componer una indicación. Ellos, literalmente, todos nuestros competidores que dicen que hacen IA con LLM en el espacio de la cadena de suministro, componen, digamos, una docena de indicaciones que se ajustan a varios escenarios. Luego, después de la indicación, inyectan datos recuperados de la base de datos, ya sabes, que pueden ser estadísticas descriptivas básicas. Inyectarían unas pocas docenas de números, ventas promedio durante la última semana, el último mes, el último año, o lo que sea, ya sabes, estadísticas básicas que se ajusten al escenario. Y luego agregarían la consulta adicional del usuario y luego el LLM completaría la respuesta.

Ves, entonces esto es nuevamente, los LLMs se tratan solo de completar texto. Entonces compones un texto y lo completa. Y la generación aumentada por recuperación, la parte de recuperación es solo recuperar algunos números de la base de datos y luego componer. Pero la conclusión es que, bueno, ahora tienes algo donde puedes hacer una pregunta. Pero la realidad es que si no estás perdido, puedes leer los números directamente de la pantalla. No hay magia. Entonces, el LLM solo ve los números como tú los ves en tu informe. Fundamentalmente, solo puede responder preguntas que se responden fácilmente con un panel de control.

Entonces sí, si no estás realmente familiarizado con la definición de cada número, puede aclararlo para ti. Pero también puedes tener, ahí es donde Lokad lo hace, como una hoja de trucos que simplemente te brinda la descripción de una línea adjunta a cada panel de control, para cada número que está presente en el panel de control. Y eso hará efectivamente el mismo papel, sin intervención de la IA.

Entonces, en resumen, soy muy, muy escéptico acerca de esos asistentes de IA conversacionales, esos copilotos, porque básicamente son trucos que se superponen a sistemas existentes que nunca han sido diseñados para ningún tipo de sistema de aprendizaje automático, ni siquiera el clásico tipo de aprendizaje automático, y mucho menos los LLMs.

Es por eso que digo, según mi conocimiento, todos nuestros competidores están haciendo copilotos donde esencialmente tienen algo que es, digamos, un chatbot que está sobre los paneles de control. Pero no hace ninguna automatización. No te permite automatizar ningún tipo de pilotos de IA. Es, sí, un truco sobre un sistema heredado.

Conor Doherty: Bueno, gracias. Seguiré adelante. Esto es de Kyle. “¿Puede hablar sobre la importancia del análisis de procesos antes de implementar un modelo de IA?” Lo tomaré en el contexto de la cadena de suministro.

Joannes Vermorel: Por sorprendente que parezca, el análisis de procesos es muy importante. Pero no necesariamente de la forma en que la gente piensa. La realidad es que, especialmente en las cadenas de suministro, las empresas han tenido cuatro o cinco décadas para inventar muchos procesos inventados. Y digo “inventados” a propósito. La cadena de suministro es un juego de burocracia. Viene con un núcleo burocrático. El juego de la cadena de suministro durante los últimos cinco décadas ha sido una forma de organizar el trabajo porque no puedes tener una persona que se ocupe de todos los SKU, todos los almacenes, todas las ubicaciones, todos los productos. Entonces, necesitas dividir y conquistar el problema, distribuyendo la carga de trabajo entre docenas, posiblemente cientos de personas para empresas grandes, muy grandes.

Entonces, terminas teniendo una situación en la que el 90% de tus procesos simplemente reflejan las complicaciones emergentes que tienes debido al hecho de que la carga de trabajo se distribuye entre muchas personas. Entonces, ves, son procesos accidentales, no procesos esenciales. Entonces, diría que sí, necesitas hacer el análisis de procesos, pero ten cuidado, el 90% de los procesos existentes no están abordando el problema fundamental al que se enfrenta tu cadena de suministro, sino problemas accidentales creados por el hecho de que necesitas muchas personas para resolver el 10% del problema que debe abordarse.

En industrias como el procesamiento químico, donde tienes muchos flujos y dependencias, es muy complicado. Por ejemplo, cuando tienes reacciones químicas, vas a tener subproductos. Entonces, cada vez que produces un compuesto, produces algo más. Este algo más se puede vender o usar para otro proceso. Necesitas coordinar todo eso. Tienes toneladas de restricciones, tienes procesos que operan a través de lotes y procesos que operan de forma continua. Es muy complicado.

Pero la realidad es que la mayoría de los procesos, en lugar de centrarse en la fisicalidad del problema, el hecho de que digamos, en una industria de procesos, tienes reacciones químicas que 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 ingeniar procesos que desaparecerán cuando configures el piloto de IA.

Lo interesante es que cuando lo haces al estilo del piloto de IA, ya no necesitas este enfoque de dividir y conquistar. Es un conjunto unificado de recetas numéricas que resuelven el problema de principio a fin. Entonces, todos esos problemas de coordinación que se resolvieron mediante tantos procesos simplemente desaparecen.

Mi experiencia es que el 90% de esos procesos simplemente desaparecerán cuando terminemos. Es por eso que digo que es muy importante mantener un enfoque claro en la capa física base de tu cadena de suministro, en lugar de los procesos inventados que solo están ahí para coordinar numerosos equipos. Esas cosas no se van a mejorar, serán reemplazadas por el piloto de IA.

Conor Doherty: Gracias. Y de hecho, un ejemplo que mencionaste en esa respuesta proporciona una buena transición aquí. Entonces, de un espectador llamado Durvesh, ¿tienen planes de hacer de Envision de código abierto para uso educativo o de pequeñas empresas? ¿Y se puede programar con reglas para beneficiar a las empresas B2B como las químicas que requieren una entrada manual extensa?

Joannes Vermorel: Sí, tenemos planes de hacer de Envision de código abierto en algún momento. Pero primero permítanme explicar por qué. En este mundo del software empresarial, tenemos documentación pública para Envision. La mayoría de mis colegas tienen lenguajes específicos de dominio (DSL), pero no están documentados públicamente. Dassault Systèmes ha comprado otra empresa llamada Quintiq. En ese momento, viene con un DSL, pero no está documentado públicamente. Entonces, literalmente, en el espacio de la cadena de suministro, hay otras empresas que tienen DSL y no son públicos. En Lokad, documentamos todo públicamente y tenemos un entorno de sandbox gratuito para Envision. Incluso tenemos talleres gratuitos disponibles para que puedas enseñar o aprender Envision con ejercicios. Así que estamos haciendo mucho más.

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

Entonces, ¿cómo lidiamos con este cambio constante de sintaxis? Bueno, todas las semanas en Lokad, tenemos lanzamientos semanales los martes y lo que aplicamos son reescrituras automatizadas para todos los scripts de Envision que se operan en las plataformas de Lokad. Por lo tanto, una de las propiedades clave de Envision es tener una alta afinidad 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 a lenguaje de computadora, que te permite tener propiedades de programas sin ejecutarlos. Y a través del análisis estático, lo que podemos hacer es reescribir automáticamente un script existente desde la sintaxis antigua a la nueva sintaxis. Y hacemos eso automáticamente los martes. Y típicamente, cuando hacemos una actualización, durante unos días, aceptamos tanto la sintaxis antigua como la nueva. Hacemos las reescrituras automáticas y luego cuando vemos que la sintaxis antigua ya no existe, con una bandera de características, bloqueamos el hecho de que solo existe la nueva sintaxis.

Y en Lokad, ya hemos implementado más de 200 de esas reescrituras automatizadas. Normalmente, lo hacemos como una versión cada martes, pero típicamente tenemos alrededor de dos reescrituras al mes y hemos estado haciendo esto durante una década. Entonces, mientras este proceso esté en marcha, Lokad no puede lanzar Envision como código abierto de manera realista. Llegará en su debido tiempo, pero no quiero repetir el error masivo de Python. La actualización de Python 2 a Python 3 llevó a la comunidad de Python una década y fue increíblemente doloroso. Quiero decir, las empresas pasaron años actualizando, fue una pesadilla que duró una década. Así que eso fue realmente, realmente incorrecto. Incluso Microsoft, con la actualización de C# del framework .NET a .NET Core, tomó media década y eso fue un gran dolor. Entonces, ese es nuevamente el problema de una vez que tienes un compilador que es de código abierto en la naturaleza, no controlas el código. Entonces, si quieres hacer cambios en el lenguaje, necesitas colaborar con tu comunidad. Esto hace que el proceso sea súper lento, súper doloroso y al final, nunca eliminas realmente todas las características malas de tu lenguaje.

Si miramos a Python, la forma en que se introdujo la programación orientada a objetos en Python, la sintaxis, ah, es torpe. Realmente puedes sentir que Python no fue diseñado teniendo en cuenta la programación orientada a objetos. Fue una adición posterior a finales de los 90 y la sintaxis es un poco mala 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á atrapado 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 forma de poder evitar esos grandes errores, Lokad, cometimos muchos grandes errores en el diseño de Envision, pero los corregimos después de uno y todavía estamos en el proceso, especialmente cuando tenemos nuevos paradigmas que llegan. Por ejemplo, la programación diferenciable fue un gran nuevo paradigma y tuvimos que rediseñar el propio lenguaje para adaptarse a este paradigma.

Por cierto, hay 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 sucederá pronto. Es como una revisión importante, importante. En este momento, el lenguaje que está más cerca de tener la programación diferenciable como un ciudadano de primera clase sería Julia e incluso allí, hay mucho parche.

Conor Doherty: Gracias de nuevo. Aún quedan tres más por responder. El siguiente es de Victor. Esto se refiere ampliamente a la IA. ¿Cómo aborda la IA los cuellos de botella aleatorios dado que opera en grandes conjuntos de datos para predecir escenarios plausibles o problemas recurrentes?

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

Cuando abordas la cadena de suministro con herramientas probabilísticas, la mayoría de las tareas que se mencionan en esta pregunta simplemente desaparecen. Esa es la belleza del pronóstico probabilístico, esos pronósticos no son más precisos, simplemente son mucho más resistentes al ruido ambiental de la cadena de suministro. Cuando combinas el pronóstico probabilístico con la 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, se elimina por completo. Y ahora nos quedan tareas que requieren revisar el texto y lidiar con eso, y eso es LLMs. Y nuevamente, lo que describí es Lokad, tenemos esos Pilotos de IA que son realmente automatizados y si hay una intervención manual, no es para hacer una entrada administrativa en el sistema, es 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 va a ser algo menor. Típicamente será algo fundamental y cambiará 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? ¿Podría ejecutar transacciones en el sistema ERP basándose en comandos verbales?

Joannes Vermorel: Los comandos verbales no son el enfoque correcto para este problema. Si lo que quieres es una entrada de datos más rápida, la voz es un canal de baja capacidad. Escribir es más rápido que hablar, a menos que seas muy malo escribiendo. Por lo tanto, este no es el tipo de ganancia que puedes obtener. Si tu interfaz de usuario está diseñada correctamente con un teclado, serás más rápido que con comandos de voz. Sé esto muy bien porque hace 20 años trabajaba en AT&T Labs en la vanguardia de los sistemas de reconocimiento de voz de calidad de producción. Había toneladas de aplicaciones donde 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 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 quieres decidir qué pedidos deben acelerarse. Eso es lo clásico de Lokad, es un proceso de toma de decisiones puro y cuantitativo. Necesitas decidir sí o no, si este pedido en curso justifica una solicitud para acelerar el proceso. Lo haríamos con programación diferenciable, optimización estocástica. Así es como llegamos a las decisiones correctas.

Una vez que tenemos eso, automáticamente tenemos todos los días las decisiones para los pedidos. No se trata de tener a alguien que dé órdenes verbales para eso. Va a ser parte del conjunto de recetas numéricas que vamos a calcular los pedidos optimizados. A medida que pasa el tiempo, nos damos cuenta de que algunos pedidos se excedieron o no alcanzaron y solicitaremos posponer o acelerar respectivamente. La parte del LLM se trata simplemente de usar esta decisión cuantitativa, donde tienes una bandera binaria que dice “por favor acelera”, para generar un correo electrónico con un contexto adecuado, enviarlo al proveedor con algo como “por favor confirma que puedes hacerlo”, y luego el proveedor va a confirmar, con suerte, y decir “sí”, “no”, “tal vez pueda” 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, optimización estocástica. El LLM está ahí para la interacción con el proveedor, que frecuentemente va a utilizar un canal no estructurado como el correo electrónico.

Si estás pensando en comandos de voz, no va a funcionar. Es demasiado lento. He tenido el privilegio de trabajar con los equipos que literalmente lanzaron al mercado los primeros sistemas de reconocimiento de voz de calidad de producción hace 20 años. Pero la conclusión es que no vas a usar esas tecnologías de IA para eso. Los comandos de voz no tienen el ancho de banda para hacer lo que quieres hacer.

Conor Doherty: En relación a esto, cuando hablamos de optimización estocástica y programación diferenciable, tenemos extensos recursos en video sobre esos temas. No los estamos desarrollando porque son 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 amablemente dirijo a los espectadores que deseen aprender más sobre eso a revisar esos videos y luego unir todas las piezas.

Última pregunta, y es de Isaac. Como cliente que actualmente está aprendiendo Envision, me interesa sus capacidades de integración, específicamente con GitHub. ¿Podría hablar sobre el potencial de Envision para admitir la integración con GitHub, especialmente 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 copiloto 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 estemos hablando. En cuanto al uso de LLM para hacer básicamente un copiloto, como el copiloto de GitHub pero que será el copiloto de Lokad en los códigos de Envision, ya estamos trabajando en eso. Lo interesante es que, debido al hecho de que es un DSL donde tenemos control completo sobre los materiales de entrenamiento. Eso es muy bueno 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 copiloto que te brinde la sintaxis actualizada de Envision. A diferencia del copiloto de GitHub que te brinda una sintaxis de Python, una sintaxis de C#, una sintaxis de Java.

Porque verás, nuevamente, Java ha existido durante 25 años, Python ha existido durante más de 30 años, C# ha existido durante 22 años o algo así. Así que cuando le pides al compilador de GitHub que escriba código por ti, el problema es que te da una versión semi-reciente de esos lenguajes, pero no realmente super reciente. Y a veces no quieres la versión reciente porque tu entorno no está alineado con esas versiones super recientes que aún no admites.

Estamos trabajando en una serie completa de características sobrenaturales como comentar mi código, explicar mi código, completar mi código. También estamos pensando en muchas acciones de código extendidas que son muy específicas de los flujos de trabajo que ocurren dentro de Lokad. Por ejemplo, estamos trabajando en poder automatizar la generación de paneles de control de salud de datos. Esa es una tarea muy típica.

Los paneles de control de salud de datos son básicamente instrumentos que verifican que los datos que ingresamos sean coherentes. Y tenemos muchos trucos y conocimientos sobre qué verificar porque los problemas que encontrarás en los datos de los ERPs son más o menos siempre los mismos. Cuando verificamos la corrección de los datos provenientes de un ERP, los Supply Chain Scientists hemos cultivado, literalmente, nuestros propios métodos de entrenamiento para saber qué buscar y tenemos nuestras propias recetas, quiero decir recetas humanas, de qué debo implementar, qué debo verificar, y podríamos automatizar en gran medida eso con los LLMs. Así que esto es algo que está en progreso en Lokad.

Estamos trabajando en un copiloto de Lokad. Para hacer que Envision sea más amigable con GitHub, ya hemos lanzado una extensión de código Visual Studio de código abierto. Ya puedes poner código Envision en un repositorio git. Solo tienes que crear un archivo .nvn y hacer un commit y listo. Si quieres editar el código con un buen coloreado de código, 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 el coloreado de código.

En el futuro, planeamos exponer el código Envision que se encuentra en una cuenta de Lokad como un repositorio git. La forma en que se almacena el código Envision en una cuenta de Lokad es prácticamente la misma que un repositorio git. Está versionado de manera muy similar. No está organizado exactamente de la misma manera que git, nuevamente no voy a entrar demasiado en las razones técnicas. Git es muy agnóstico con respecto al lenguaje. Si solo estás lidiando con un lenguaje en particular, puedes ser más inteligente y hacer todo tipo de cosas que no son posibles en el caso general. Pero la conclusión es que el código Envision está completamente versionado. Podríamos exponer un repositorio git que te permita exportar todo tu código desde una cuenta de Lokad a un repositorio git y tal vez más adelante hacerlo en sentido contrario para tener una sincronización bidireccional. Git es un sistema descentralizado donde cada repositorio git es como todo el sistema, 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 introducir la exportación y luego introducir la reimportación, pero eso llevará tiempo. Aún no estamos allí. Es parte de la hoja de ruta, pero aún no tenemos un cronograma para eso.

Conor Doherty: Vale la pena señalar que algunas personas en los comentarios dijeron que estaban aprendiendo Envision. Producimos una serie de tutoriales en colaboración con la Universidad de Toronto y otros que están en proceso. Hay recursos gratuitos y podemos proporcionar respuestas si las personas lo desean. Para aquellos que quieran aprender, nuestros Supply Chain Scientists dedican mucho esfuerzo a esos talleres. Están disponibles de forma gratuita en nuestro sitio web.

Joannes Vermorel: Para aquellos que no estén interesados en convertirse en Supply Chain Scientists ellos mismos, Lokad puede proporcionar el 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.