00:00:00 Introducción a la entrevista
00:01:00 El camino de Rinat en Lokad y los desafíos de supply chain
00:03:59 La evolución de Lokad y perspectivas sobre simulación
00:07:07 Complejidades de simulación y decisiones basadas en agentes
00:09:15 Introducción a los LLMs y optimizaciones de simulación
00:11:18 El impacto de ChatGPT y las categorías de modelos
00:14:14 Los LLMs como herramientas cognitivas en las empresas
00:17:10 LLMs mejorando las interacciones con clientes y listados
00:20:30 El rol limitado de los LLMs en los cálculos de supply chain
00:23:07 LLMs mejorando la comunicación en supply chains
00:27:49 El rol de ChatGPT en el análisis de datos y en insights
00:32:39 El procesamiento de texto de los LLMs y los desafíos de datos cuantitativos
00:38:37 Refinando la búsqueda empresarial y cerrando insights de IA
Resumen
En un diálogo reciente, Conor Doherty de Lokad conversó con Joannes Vermorel y Rinat Abdullin acerca del impacto de la IA generativa en supply chains. Vermorel, CEO de Lokad, y Abdullin, consultor técnico, discutieron la evolución desde el time series forecast hasta el aprovechamiento de Grandes Modelos de Lenguaje (LLMs) como ChatGPT. Exploraron el potencial de los LLMs para automatizar tareas, mejorar la productividad y asistir en el análisis de datos sin desplazar empleos. Aunque Vermorel se mostró cauteloso respecto a los LLMs en la planificación, ambos reconocieron su utilidad para componer soluciones. La entrevista subrayó el rol transformador de la IA en la gestión de supply chain y la importancia de integrar los LLMs con herramientas especializadas.
Resumen Extendido
En una entrevista reciente, Conor Doherty, el Jefe de Comunicaciones en Lokad, sostuvo una discusión que invita a la reflexión con Joannes Vermorel, CEO y fundador de Lokad, y Rinat Abdullin, consultor técnico en Trustbit y ex CTO de Lokad. La conversación se centró en el creciente campo de la IA generativa y sus implicaciones para la gestión de supply chain.
Rinat Abdullin, al rememorar su etapa en Lokad, relató los primeros desafíos que enfrentó la empresa, particularmente en alinear la tecnología con las necesidades del cliente y en hacer que los complejos datos de supply chain fueran comprensibles y confiables. Joannes Vermorel confirmó que los orígenes de Lokad estaban en el time series forecasting, un elemento crítico en la optimización de supply chain.
A medida que avanzaba el diálogo, Abdullin profundizó en la evolución de la tecnología de Lokad, destacando la tensión entre la explicabilidad y el rendimiento de los modelos de machine learning. Compartió sus experiencias en el uso de simulaciones para desmitificar sistemas complejos, lo que allanó el camino para métodos computacionales más optimizados.
La conversación se desplazó entonces hacia los LLMs, con Vermorel señalando su reciente auge en popularidad. Abdullin compartió sus primeras experiencias con modelos de lenguaje y su evolución hacia herramientas amigables para el usuario como ChatGPT. Enfatizó el potencial transformador de los LLMs, comparándolos con un departamento personal de asistentes capaces de realizar una variedad de tareas, desde redactar documentos hasta automatizar la búsqueda de información dentro de grandes silos.
Abdullin abordó las preocupaciones sobre que los LLMs reemplacen empleos, afirmando que potencian la eficiencia de los empleados en lugar de sustituirlos. Citó ejemplos donde la productividad aumentó de diez a cien veces. También señaló que, aunque los supply chains han sido lentos en adoptar los LLMs, los departamentos de marketing han sido rápidos en utilizarlos para las interacciones con clientes y la reducción de costos.
Joannes Vermorel amplió sobre el potencial de los LLMs para automatizar comunicaciones abiertas con los socios de supply chain, ahorrar tiempo en correos electrónicos rutinarios y permitir concentrarse en tareas más complejas. Elogió a los LLMs por su fineza lingüística al ajustar el tono de las comunicaciones, una tarea que puede consumir mucho tiempo para los humanos.
Abdullin destacó las avanzadas capacidades de análisis de datos de ChatGPT, que facultan a los tomadores de decisiones empresariales para analizar datos complejos sin necesidad de habilidades de programación. Sin embargo, Joannes Vermorel mantuvo su escepticismo respecto a la IA generativa en la planificación de supply chain, enfatizando que los LLMs son más adecuados para generar análisis y reportes desechables.
Rinat Abdullin sugirió que los LLMs podrían utilizarse junto con herramientas especializadas para obtener mejores resultados, particularmente en la intersección de dominios numéricos, textuales y de código. Joannes Vermorel coincidió, aclarando que los LLMs son más adecuados para componer programas que resuelvan problemas en lugar de resolverlos directamente.
Para concluir, Rinat Abdullin animó a las empresas a adoptar los LLMs, ya que pueden aportar un valor significativo cuando se combinan con herramientas especializadas. Conor Doherty finalizó la entrevista agradeciendo a Joannes y a Rinat por sus aportes al dinámico campo de la IA generativa y su papel en la configuración del futuro de la gestión de supply chain.
Transcripción Completa
Conor Doherty: Bienvenido de nuevo a Lokad TV. El progreso realizado en la IA generativa en los últimos 12 meses es una hazaña extraordinaria de progreso tecnológico. Los LLMs, o grandes modelos de lenguaje, han pasado de ser un nicho a ser mainstream en menos de un año. Aquí, para explicar la importancia, particularmente en un contexto de supply chain, se encuentra el primer CTO de Lokad, Rinat Abdullin. Rinat, bienvenido a Lokad.
Rinat Abdullin: Es un placer y un honor estar de vuelta. Estuve en Lokad cuando apenas comenzaba, en una pequeña y diminuta sala, creo, en la universidad. Y de todas las empresas con las que he trabajado desde entonces, incluyendo siete startups, Lokad fue el lugar más desafiante y gratificante de mi vida.
Conor Doherty: No tienes que decir nada directamente sobre Joannes, pero cuando afirmas que fue lo más desafiante, ¿qué fue exactamente lo que hizo a Lokad tan desafiante? Y luego, en contraste, ¿la dificultad de proyectos futuros?
Rinat Abdullin: Éramos una startup en aquel entonces, y fue una combinación interesante de tratar de encontrar una correspondencia entre las tecnologías y lo que el cliente quería y realmente necesitaba. Equilibrar este triángulo siempre fue un desafío porque las tecnologías en ese entonces eran incipientes. Fuimos uno de los primeros grandes clientes de Azure, comenzando a construir una biblioteca escalable para procesar muchas series de tiempo de los clientes. No había soporte; todo tenía que construirse desde cero, y ese camino tomó muchos años. Continuó con la creación de un DSL hecho a la medida para empoderar a los expertos en Lokad, y aún sigue en marcha. Esa es una parte del triángulo. La segunda parte era que los clientes querían mejores números; querían que su negocio funcionara de manera predecible sin dinero congelado en el inventario. Al mismo tiempo, querían que estos números fueran comprendidos porque si proporcionas a los clientes unos números que salen de una caja negra mágica, los ejecutivos podrían decir, “Sí, funciona”, pero los expertos en supply chain en los locales warehouses dirán, “No entiendo estos números. No confío en las fórmulas, y mi instinto, basado en 10-20 años de experiencia, va a decir que no, no va a funcionar, así que lo voy a ignorar.” Y, obviamente, no se puede despedir a todos.
Joannes Vermorel: Escuchando a Rinat, ¿antes trabajábamos con series de tiempo, es así?
Rinat Abdullin: Sí, Lokad fue literalmente fundada como un servicio de time series forecasting, así que sé una o dos cosas sobre series de tiempo, incluso si años después nos desviamos de ese camino. Hemos estado trabajando con series de tiempo, y es un bloque de construcción muy básico. La tensión que mencioné sobre la explicabilidad también fue algo que finalmente se abordó, pero más de una década después de la fundación de Lokad. Tuvimos que adoptar differentiable programming para que finalmente tuviéramos modelos que eran de machine learning pero explicables. Llegó muy tarde. Durante años, tuvimos la opción de elegir entre modelos crude que eran de caja blanca pero no muy buenos, o modelos de machine learning que eran mejores pero cajas negras, creando toneladas de problemas operativos. A veces, no eran naturalmente mejores según todas las dimensiones del problema. Fue una lucha inmensa, y el recorrido de Lokad ha sido casi una década de batallas cuesta arriba. Rinat afrontó la primera mitad de una década de batallas cuesta arriba, y luego hubo otras personas que continuaron luchando por las demás. Ha sido una muy larga serie de problemas masivos que abordar.
Conor Doherty: Gracias, Rinat. Volviendo a ti, cuando intentamos explicar lo que hace Lokad, es a través de una serie de artículos muy largos, conferencias, discusiones como esta. Pero cuando tratas de explicar el machine learning de caja blanca en este contexto, ¿cómo lo abordas?
Rinat Abdullin: Uno de los enfoques que funcionó bastante bien cuando ayudé a organizar un hackathon para una compañía logística internacional fue a través de simulaciones. Cuando hablas de logística internacional, hay muchas variables en juego. Tienes carga que debe ser transportada entre múltiples ubicaciones utilizando varios modos de transporte. Tienes empresas de camiones y otras compañías compitiendo en el mercado abierto para las entregas de carga desde la ubicación A hasta la ubicación B. Luego, tienes rutas de entrega reales como carreteras, redes ferroviarias, tal vez la última milla de entrega en algún lugar. A medida que los camiones transportan la carga entre esas ubicaciones, se generan retrasos, atascos, y la carga podría llegar a un almacén fuera del horario laboral, o el área de descarga del almacén podría estar llena.
Queríamos modelar toda esta complejidad de una manera que resultara accesible para estudiantes o nuevos empleados en la empresa. Lo que hicimos fue bastante brutal. Es quizás muy similar a cómo investigadores antiguos intentaban modelar el número pi lanzando una moneda a través de una simulación. Así que construimos un mapa virtual de Europa con carreteras principales, y en este mapa virtual, las carreteras tenían longitudes, el tiempo pasaba, los camiones iban y venían, y las empresas de camiones podían decidir qué carga recolectar y si la entregarían a tiempo. Ese fue el punto de entrada para los participantes del hackathon, porque podían programar agentes que tomarían decisiones como, “Soy el camionero A, y voy a recoger esta carga desde la ubicación A hasta la ubicación B.” Pero había un truco: cuando un camión transporta carga de una ubicación a otra, al igual que en el mundo real, cuesta dinero. Para ganar dinero, se deben pagar impuestos, pagar combustible y asegurarse de que el conductor descanse.
Debido a que es una simulación, no necesitas fórmulas complejas; estás forzando la realidad de manera cruda. Simplemente ejecutas, como si fuese un script por lotes, para NPCs o para un juego de manera secuencial, y puedes tener muchas reglas explicables en una hoja de papel. Este mundo era tan comprensible para las personas que, de hecho, creamos dos niveles de dificultad. En el primer nivel, las empresas simplemente conducían camiones tratando de ganar la mayor cantidad de dinero. En el segundo nivel, los precios de la gasolina subieron un poco, las empresas tuvieron que compensar por las emisiones de CO2, y los camioneros podían fatigarse. Si el camionero conducía por más de 12 o 14 horas, entonces existía una probabilidad creciente de un accidente. Cuando hay un accidente, el camionero entra en descanso, y esa máquina no hace nada, desperdiciando esencialmente el tiempo. Construimos este entorno, los participantes pudieron programar sus agentes, y al ejecutar una simulación de eventos discretos a una velocidad acelerada, esencialmente obtienes meses de tiempo virtual que transcurren en segundos de tiempo real.
Pudimos generar rápidamente muchas simulaciones y decir: “Equipo, las decisiones que sus agentes estaban tomando en este mundo virtual, esta era la distribución de lead time, esta era la distribución de precios, estos eran los márgenes, y este era el número de accidentes que tenían sus agentes.” Ese es esencialmente el enfoque que normalmente sigo cuando necesito explicar un entorno complejo. Primero se comienza con la simulación porque es similar a un juego, es fácil explicar las reglas, no tienes que hacer programación diferencial. Pero cuando ejecutas esta simulación, es esencialmente un análisis de Monte Carlo que sigue las dependencias en sistemas complejos. Esto significa que, por ejemplo, en algunos casos, no obtienes una distribución simple en el exterior, sino que, debido a la interferencia entre múltiples elementos del sistema, se generan patrones de interferencia en las distribuciones externas. Parece una caja negra, pero la gente puede entender las reglas, cambiarlas, y luego, por ejemplo, si una empresa finalmente comprende cómo funciona este entorno y le gustan los números que se obtienen de forma lenta porque la simulación aún toma tiempo, existe una forma de optimizar el cómputo, diciendo, “Bueno, estos son los números que estamos obteniendo de la simulación, y cambiemos a la programación diferencial directamente con las probabilidades para obtener los mismos números, pero de forma más rápida.” Es simplemente una optimización de rendimiento. Así es como normalmente lo abordaría.
Joannes Vermorel: Lo que es muy interesante es que durante el último año, una nueva clase de herramientas, LLMs, se han vuelto disponibles, y eso es muy interesante porque es literalmente una clase entera de tecnologías que han existido durante aproximadamente media década, pero eran muy especializadas y solo los expertos podían comprender realmente su potencial porque, en ese momento, se trataba principalmente de potencial. Tal vez, Rinat, ¿cómo ves que cambia la situación al introducir esta clase de herramientas de LLMs? ¿Cómo lo comparas? Tuvimos varias clases de herramientas para aprendizaje automático para empresas, como clasificación, regresión, simulaciones de Monte Carlo. Eran clases de herramientas que se podían combinar, y ahora tenemos otra clase de herramientas completamente diferente, los LLMs. Quizás para la audiencia que no esté familiarizada con los LLMs, aparte de ChatGPT, ¿cómo lo asimilas en un contexto de enterprise software, flujos de trabajo empresariales? ¿Cuál es tu visión general al respecto?
Rinat: He estado en contacto con modelos de lenguaje desde 2015, antes de que apareciera el chatbot y lo hiciera popular. Tienes razón en que eran realmente de nicho. Se utilizaban en traductores de idiomas, reconocimiento de voz y modelos de lenguaje que corrigen errores ortográficos o ayudan a encontrar texto en grandes corpus. Cuando surgió ChatGPT, su popularidad se disparó. Una de las razones es que fueron entrenados para ser útiles y obedientes a las personas.
Y es que a veces resultan tan irritantes, porque cuando quieres obtener resultados del modelo y este empieza a disculparse, diciendo “I’m sorry” repetidamente, puede ser frustrante. En mi forma de ver, básicamente separo los modelos a gran escala en dos categorías. Una categoría de modelos trabaja principalmente con números, es decir, hablamos de regresiones, Monte Carlo, redes neuronales. La otra clase de modelos, que son los grandes modelos de lenguaje, sí, trabajan con números, pero en apariencia trabajan con texto, con grandes textos no estructurados, y de ahí proviene su utilidad principal.
Estos modelos permiten que una máquina o automatización se conecte directamente con las interacciones humanas. Por ejemplo, con regresiones o series de tiempo, necesitas conectar el modelo en algún punto intermedio de los procesos digitales empresariales. Hay una base de datos de un lado, un motor de forecast en el medio y, quizá, una base de datos, un CRM o un ERP en el otro. En el mejor de los casos, obtienes un informe, pero siguen siendo números. Con los LLMs, te conectas directamente en el centro del proceso empresarial, en medio de los flujos de trabajo humanos.
Esto crea tantas posibilidades, especialmente porque no se requiere mucho esfuerzo para implementar algo que hace una década era completamente imposible o costoso. Por ejemplo, personalmente, cuando trabajo con LLMs, empiezo a sentir que tengo mi propio departamento privado de asistentes. Son políglotas, son full-stack, quizá a veces ingenuos, pero también son inteligentes, y nunca se quejarán. Por ejemplo, pedirles que muevan un botón en un diseño o que reescriban una carta a un magistrado en Alemania es muy útil, muy obediente, a veces tonto, pero pueden hacer cosas grandiosas.
En las aplicaciones empresariales de adopción de LLM que he visto, se trata principalmente de lo que llaman digitalización empresarial. Ayuda a las compañías a automatizar flujos de trabajo que giran en torno a encontrar texto en un gran corpus. Por ejemplo, una empresa tiene muchos datos, posee sus bases de conocimiento, pero estas bases son, esencialmente, compartimentos aislados. Pueden ser RFCs, cuestionarios o una Wikipedia que nadie realmente mantiene actualizada, y la gente necesita realizar alguna actividad que a veces requiere encontrar información en lugares oscuros. Esto exige tiempo, esfuerzo y, sobre todo, energía cognitiva.
Lo que los LLMs pueden hacer es realizar un trabajo preparatorio. Pueden redactar artículos, pueden investigar los datos privados de una empresa, diciendo, “Bueno, estás compilando esta respuesta para la empresa, así que, basado en los flujos de trabajo de tu compañía y en las indicaciones codificadas, este es mi borrador.” Para cada elemento de esta lista de verificación de respuestas, pueden mostrar de dónde obtuvieron la información. Así, la persona ya no tiene que hacer el trabajo rutinario y puede dedicarse a tareas intelectualmente más demandantes, como comprobar si el modelo acertó algo. Esto permite escalar la eficiencia de una empresa de manera masiva.
Cuando salió ChatGPT, la gente tenía mucho miedo de que los LLMs y la IA les quitaran sus empleos, pero no lo hacen. Créeme, he estado ayudando a clientes a crear productos impulsados por LLMs y aprendizaje automático durante bastante tiempo, y se necesita mucho esfuerzo para producir algo que pueda reemplazar a un humano. Es casi imposible. Pero lo que los LLMs pueden hacer es hacer que los empleados existentes sean más eficientes, a veces hasta 10 o 100 veces más eficientes. Estos son casos excepcionales. Simplemente hacen a la gente más eficiente, pero nunca pueden reemplazar a las personas. Siempre tiene que haber personas involucradas.
Conor: Si puedo profundizar en ese punto, ya que, repito, el contexto de la discusión es la IA generativa y los LLMs en el contexto de supply chain. Por lo que acabas de decir, Rinat, parece que los LLMs serán potenciadores de productividad en general. Pero, ¿ves algún caso de uso específico dentro de supply chain, o es simplemente, como dijiste, “Tengo un equipo de políglotas, necesito traducir este RFP a 10 idiomas”?
Rinat: En mi experiencia, las supply chains son algo lentas para adoptar los LLMs en el núcleo del proceso. Los LLMs más bien empiezan a incorporarse desde la periferia. Un caso común es que los departamentos de marketing suelen ser los primeros en adoptar. Cuando una empresa tiene, por ejemplo, interacción directa con los usuarios, el punto de contacto entre la empresa y los clientes es donde he visto la mayor adopción. Por ejemplo, existen marketplaces que venden productos a sus clientes, y quieren hacer que esta interacción sea más agradable y, quizá, reducir el costo de interactuar con ellos.
Ya es bastante factible construir sistemas que rastreen automáticamente los catálogos de productos uno por uno, de forma incansable y sin descanso, 24/7, y detecten, “Ok, este es un producto, pero fue ingresado incorrectamente por el proveedor de la supply chain.” ¿Por qué? Porque he rastreado internet, encontré las especificaciones de este producto, que son similares, también hallé la descripción en PDF del productor, y, según mi criterio, como que la mitad de internet tiene este número correcto y tú lo tienes mal. Estas son las referencias. Por favor, decide si es necesario corregirlo automáticamente. “Oh, querido gerente, vi que corregiste la descripción de este producto, esta propiedad del producto. ¿Quieres que regenere la descripción para tener el número actualizado, no solo el número, sino también el texto?” Y de paso, creé tres descripciones de producto para que elijas la que tenga sentido. También elaboré un texto de marketing SEO, actualicé las palabras clave en tu motor de publicación, y además creé un anuncio para Twitter y otro para LinkedIn.
Otra conexión entre los clientes y los minoristas que se integran a la supply chain es la lista de productos en los marketplaces. Imagina que eres un proveedor que tiene que trabajar con muchos marketplaces, y tu catálogo cuenta con 10,000 artículos con pequeñas variaciones, como repuestos de autos o piezas de aviones. Quieres automatizar este proceso, especialmente si tu propio inventario cambia rápidamente. Es bastante factible, y ya lo he visto implementado. Por ejemplo, recibes un par de imágenes del producto, especialmente si se trata de productos reutilizados, particularmente en moda; funciona muy bien. Las pasas por reconocimiento de imágenes, que da los mejores resultados cuando está entrenado en moda y estilo. Obtienes los textos, las descripciones, organizas los recuadros, redimensionas las imágenes automáticamente y, de ello, generas una descripción para las personas.
Y luego, llega una de las partes más agradables. También creas una descripción oculta aumentada por LLM que se utiliza para la búsqueda semántica. ¿Qué significa esto? Entonces, cuando un cliente de una plataforma de moda intenta encontrar una prenda, no siempre buscará, por ejemplo, una camisa de estilo boho con dragones, talla M y que cueste menos de $10. Buscará: “Hey, voy a una fiesta esta noche y mis amigos estarán allí, ¿qué puedo ponerme que complemente mis shorts?” Si tienes descripciones de productos y explicaciones semánticas que los LLMs extrajeron del producto, y las buscas, pero no el texto completo—porque quién sabe cómo escribe la gente lo de boho—sino que usas una búsqueda basada en embeddings, que es esencialmente una búsqueda vectorial, es decir, una búsqueda basada en el significado del texto y no en la redacción exacta, entonces obtienes resultados que, a simple vista, parecen mágicos porque el modelo de alguna manera empieza a sugerir lo que realmente pretendías preguntar, y no lo que dijiste.
Conor: Gracias, Rinat. Joannes, ¿tus ideas? Quiero decir, cuando observo las supply chains, diría que funcionan casi a partes iguales. La mitad de las personas utiliza hojas de cálculo, y la otra mitad se ocupa de comunicaciones mundanas con socios, proveedores, clientes, etc. Las hojas de cálculo tratan, en realidad, de automatizar la decisión de cantidad; eso es lo que Lokad ha estado haciendo durante una década. La segunda parte, en su mayoría, no estaba automatizada porque, hasta la llegada de los LLMs, no existía una tecnología real que ofreciera una respuesta plausible a eso.
Joannes: Es decir, que lo que requiere comunicación, ya fuera porque se trataba de un flujo de trabajo muy ajustado y por ello podía automatizarse —por ejemplo, mediante EDI para transmitir una orden—, se convierte en un problema no textual una vez que hay un puente que transmite la orden. Pero eso no es exactamente lo que se quiere decir cuando se afirma que la gente pasa la mitad del tiempo en hojas de cálculo y la otra mitad gestionando socios, clientes, transportistas, proveedores. Es más bien, “¿Podrías agilizar este pedido y, en caso afirmativo, a qué precio?” Es más difuso y abierto.
Hay que tomar este caso límite y redactar un correo al respecto, aclarando cuál es la intención, lo que está en juego, y eso lleva media hora. Luego repites con una situación distinta, un problema diferente, y produces otro correo. Terminas con un departamento de compras donde cada persona, durante ocho horas de trabajo, dedica cuatro horas a la hoja de cálculo y cuatro horas a escribir 20 correos a 20 socios. Aquí veo un enorme potencial de mejora. Lokad ya está automatizando literalmente la primera parte, pero con los LLM hay un enorme potencial para automatizar en gran medida —aunque no completamente— la segunda parte. Esencialmente, permitir que las personas, diría yo, puedan contar con apoyo para componer automáticamente comunicaciones que serán recibidas por sus socios. El LLM se ha utilizado para proporcionar una versión razonablemente contextualizada de la declaración del problema y de lo que esperamos del socio.
Si la declaración del problema tiene límites bien definidos, entonces dispones de EDI; simplemente se convierte en parte de un flujo de trabajo completamente mecanizado. Pero estoy hablando del resto, de las cosas que no están del todo alineadas, como cuando pediste 1,000 unidades y te entregaron 1,050. No vas a rechazar el pedido porque entregaron 50 unidades de más. Te agrada este proveedor, así que aceptarás y validarás el pedido, lo recibirás y pagarás por 1,050 unidades en lugar de 1,000. Pero quieres comunicarle de forma cortés a tu proveedor que preferirías que se adhiera al acuerdo original, que era enviar 1,000 unidades y no 1,050. Hay cierto matiz en el que no quieres interrumpir el flujo de trabajo; es casi correcto, pero aún así quieres dejar claro que no está bien entregar siempre un 5% más para que el proveedor pueda cobrarse un poco más.
Este es el tipo de cosas en las que los LLMs realmente destacan, ese tipo de comunicación sutil en la que necesitas transmitir un mensaje. Llevaría tiempo equilibrar la redacción para que no resulte demasiado agresiva, pero que el socio entienda que tienes una fuerte preferencia de que se adhiera estrictamente a la cantidad inicial acordada. Es el tipo de cuestión en la que alguien puede agonizar durante una hora redactando medio correo, y es precisamente este tipo de asunto en el que, con los LLM modernos, lo que se requiere no es una inteligencia superdotada. La inteligencia que poseen esos LLMs es lingüística, y si lo que quieres es ajustar el tono, casi poseen capacidades sobrehumanas. No son necesariamente súper inteligentes en el sentido de captar el panorama general o de acertar en la dirección, pero si deseas obtener el mismo texto con una tonalidad un poco más oscura —como, quiero el mismo texto, pero ligeramente más agresivo, o un poco más suave o más solidario—, son extraordinariamente buenos en eso.
Te tomaría quizá 20 minutos hacerlo para media página, y un LLM puede hacer eso literalmente en segundos. Es precisamente el tipo de tarea donde se puede conseguir un aumento masivo de productividad en esos toques sutiles a los que la gente dedica horas. Si llevamos esto un poco más allá, imagina una empresa que diariamente tiene miles de comunicaciones de este tipo sobre casos límite. Esa es una nueva capacidad que aportan los LLMs. Para los dueños de negocio, para los stakeholders que necesitan obtener el panorama general, se requiere esfuerzo, pero ahora contamos con LLMs que son muy buenos escaneando enormes cantidades de textos no estructurados y detectando patrones. Imagina que un LLM puede leer cientos de informes, correos electrónicos o intercambios sobre no enviar un 5% extra y, al final del día, proporcionar un resumen sucinto a los ejecutivos diciendo: “Hey, parece que tenemos un patrón repetitivo en el que cada vez más proveedores, en la última semana, están intentando enviarnos más stock.”
Como sabes, ChatGPT tiene una capacidad asombrosa llamada advanced data analytics, y esto es literalmente como tener un departamento de analistas de datos a tu disposición. No son expertos en supply chain, por lo que aún necesitarás a Lokad para eso, pero lo que puedes hacer es hacerles preguntas sencillas como, “Aquí está mi archivo de base de datos, aquí está mi archivo Excel, haz un análisis para mí y detecta las tendencias.” Esa es la parte sorprendente, que es posible mayormente en línea. No puedes ejecutarlo localmente ni vía API, pero ChatGPT formulará teorías, escribirá código, lo ejecutará, tal vez encontrará errores, los corregirá, imprimirá los resultados e incluso creará un gráfico para ti. Todo el proceso, desde el momento en que envías una hoja de cálculo Excel y una pregunta hasta llegar al gráfico final, está completamente automatizado. Se autocorrige, se autorepara, y obtienes buenos resultados. Esto brinda a los responsables de la toma de decisiones empresariales la capacidad de analizar datos por sí mismos, incluso cuando estos se almacenan en sistemas complejos, y de visualizarlos sin necesidad de saber Python, JavaScript, C o SQL. Creo que es realmente empoderador, abre nuevas oportunidades de negocio y genera nuevo valor empresarial.
Conor: Hace aproximadamente seis meses, tuvimos una discusión sobre IA generativa y su rol en supply chain, y en general éramos algo escépticos. Cuando escuchas lo que se ha descrito sobre los avances en solo los últimos seis meses, ¿todavía tienes la misma perspectiva, o te has suavizado un poco?
Joannes: Mi posición se mantiene profundamente escéptica en ciertos aspectos. Mi escepticismo fue esencialmente una reacción a la mayoría de los competidores de Lokad que dicen, “Simplemente vamos a aplicar ChatGPT directamente a terabytes de datos de transacciones, y funcionará.” Mi opinión es que no, no lo creo. Todavía soy muy escéptico porque literalmente no es así. Si dices que lo que puedes hacer es listar un par de tablas con esquemas, o que la herramienta auto-examine el esquema de la base de datos para calcular análisis desechables como el tamaño medio de la cesta, esa es una propuesta completamente diferente. En el pasado, esto tenía que pasar por el equipo de business intelligence. Estoy hablando de cosas básicas como cuál es el tamaño medio de la cesta, cuánto tiempo en promedio retenemos a los clientes, cuántas unidades hemos vendido en Alemania —preguntas muy básicas. En las grandes empresas, usualmente cuentas con docenas de personas en las divisiones de BI produciendo informes desechables todo el día. Para este tipo de cosas, creo que los LLMs realmente pueden ayudar, pero eso no es en absoluto lo que nuestros competidores están proponiendo. Ellos dicen, “Tienes estos modelos, les das tu base de datos de terabytes, les das acceso a Twitter e Instagram, y tienes tu planificación, tu decisión, todo, y es completamente automatizado.” Yo digo no, ni siquiera cerca. Estamos en un mundo de fantasía.
Rinat: Respecto a tu respuesta a ese desafío, tengo dos ideas para compartir. Primero, sobre el proceso de utilizar los LLMs para procesar grandes cantidades de datos, he estado trabajando con varios LLMs durante bastante tiempo. Una de las primeras preguntas que suelen hacer los clientes es si pueden ejecutar algo como ChatGPT localmente en sus instalaciones. Para responder a eso, es necesario realizar pruebas comparativas de los LLMs en diferentes configuraciones y calcular los costos. Los LLMs son bastante caros. Ejecutar un megabyte de texto a través de los LLMs para predicción, podría costar un par de Euros, dependiendo del modelo. Si deseas ejecutarlo localmente en los mejores modelos disponibles, podría costarte €10 o tal vez €20.
Y eso es lo que hace GPT-3.5; es muy barato. Pero el punto es, ni siquiera es posible procesar terabytes o petabytes de datos a través de los LLMs. En segundo lugar, los LLMs son terribles con los números. Si alguien le pide a un LLM que realice cálculos matemáticos o que enumere números primos, eso es un mal uso. Los LLMs son modelos lingüísticos; tienen una gran base de conocimientos y son muy inteligentes, aunque aún tienen limitaciones. No le pides a un LLM un problema matemático; en cambio, le pides que formule el problema, y luego el cálculo se pasa a un kernel de Python especializado o algo que hará mucho mejor la operación que desperdiciar la operación en un LLM.
Las cosas más interesantes ocurren en el punto de encuentro entre diferentes dominios. Por ejemplo, tenemos el vasto dominio numérico por un lado, el texto o casos marginales suaves y difusos por el otro, y el código como la tercera parte. El código no es números, no es texto, es estructurado pero verificable, y los LLMs son excepcionalmente buenos para lidiar con él. Esto crea nuevos casos que podrían ser aplicables para la supply chain, empujando la aplicabilidad de soluciones como Lokad aún más lejos.
Por ejemplo, un caso en el que he estado aplicando LLMs para analizar grandes cantidades de texto fuera de las capacidades de los LLMs es formulando el problema al LLM. Por ejemplo, encontrar texto en cientos de gigabytes de informes anuales en todo el mundo o ayudar a resolver un problema numérico sin hacer el cálculo real. Se te ocurre una teoría de cómo abordarlo porque eres inteligente, conoces el contexto, y estos son los controles que te doy.
Cuando hablo de buscar a través de una enorme base de datos, le pido al LLM en una sintaxis específica que elabore búsquedas de embedding en las que trabajaré, que genere una lista de stop keywords, o una lista blanca de palabras clave que potencien. Luego, otro sistema dedicado a eso y que es muy bueno procesando a gran escala tomará esta solicitud bien formulada del LLM y la ejecutará. Ahí es de donde proviene lo mejor, porque los LLMs son capaces de refinar las búsquedas.
Regresas al LLM y dices, “Este era mi problema original, esto es lo que pensaste sobre él, esta es la consulta que generaste, y estos son los resultados basura que devolviste. Por favor, ajústalo y adáptalo.” Debido a que trabajar con LLMs es prácticamente gratis, iteras quizás diez veces, tal vez haces una cadena de pensamiento, tal vez un árbol de pensamiento, con buenas decisiones y malas decisiones, y luego mejora. Lo mismo es aplicable a los dominios numéricos. Por ejemplo, los gerentes de supply chain quieren idear cómo balancear mejor sus inventarios. En teoría, pueden decir, “Aquí hay una pequeña simulación de mi entorno, que quizás sea lo suficientemente buena, y así es como puedes ajustarla. Ahora, por favor, realiza una resolución de restricciones difusa y trata de generar ideas que me puedan ayudar a balancear mejor mis inventarios.”
Esta es la posibilidad que se abre cuando comienzas a unir múltiples dominios: numérico, código y texto, y utilizas las mejores herramientas disponibles para cada dominio juntas.
Conor: Gracias, Rinat. Joannes, ¿cuáles son tus pensamientos al respecto?
Joannes: Solo para aclarar para la audiencia, lo interesante es que para muchos problemas, la forma en que quieres abordarlo con un LLM es decir, “Por favor, compón un programa que resuelva el problema.” No dirás, “Quiero que resuelvas el problema.” Dirás, “Compón un programa, y luego aprenderé del programa.” Existen trucos adicionales, como proporcionarle al LLM un compilador para verificar si el programa compila o una herramienta que te permita ejecutar el programa un poco para comprobar que la salida tenga sentido.
No se trata de que el LLM resuelva el problema directamente; es algo mediado. El LLM produce un programa, luego utiliza otra cosa que sigue siendo salida textual, porque si usas un compilador, éste intentará compilar el programa. Si no funciona, proporciona un mensaje de error. A los LLMs les encanta procesar mensajes de error y arreglar los problemas asociados. Estamos muy inmersos en el reino del texto.
Para la supply chain, la mayoría de las situaciones serán mediadas. Queremos que el LLM componga el programa que resolverá lo que estamos tratando de hacer. Por ejemplo, con el problema inicial de encontrar la facturación en Bélgica del año pasado para clientes por encima de 1 millón de EUR, el LLM no tomará los datos de la base de datos para hacerlo. Compondrá una consulta SQL que será ejecutada por tu propia base de datos. De nuevo, mediación.
¿Qué significa eso para el software empresarial? ¿Tienes, como parte de tu entorno de software empresarial, plataformas que soporten la ejecución de tu supply chain, al menos la capa de decisión, con capacidad programática? El LLM no tomará los datos de transacciones en bruto para producir la salida; tomará la declaración del problema, producirá un programa, y es muy versátil en el tipo de programa que puede generar. Pero luego, algo en tu entorno debe ejecutar el programa. ¿Qué tipo de entorno de programación puedes proporcionar al LLM?
La mayoría de los softwares empresariales clásicos no proporcionan ningún entorno en absoluto. Solo tienen una base de datos con un lenguaje que puedes usar, pero la única forma de interactuar con, digamos, un gran ERP que se supone debería permitirte optimizar tu inventario, es configurando manualmente los niveles mínimos y máximos de stock levels o los parámetros de safety stock producto por producto. El LLM puede decirte la receta que necesitas aplicar, pero si deseas aplicarla, tendrás que pasar por la configuración manual del ERP. Si el ERP proporciona una API, puede componer un programa que te permita hacerlo a escala a través de la API, pero sigue siendo muy torpe en comparación con tener una solución programática nativa. Aún estará mediada a través del framework.
Requiere algunos cambios profundos e introduce la programabilidad de la solución como un ciudadano de primera clase. Sin ánimo de autopromoción, Lokad tiene una plataforma programática. No lo hicimos para los LLMs; fue más una cuestión de suerte, pero lo hicimos hace 10 años para tener esta mentalidad programática como el núcleo de la plataforma y como un ciudadano de primera clase. Eso fue una casualidad, no una visión futurista sobre lo que sucedería dentro de una década con los LLMs.
Conor: Gracias, Joannes. Tengo en cuenta el tiempo de todos, así que, como es costumbre, Rinat, te devuelvo la palabra para una reflexión final. ¿Hay algo que quieras decir a todos los que nos están viendo?
Rinat: Hubo un par de burbujas en la historia pasada, como la burbuja dot-com y la burbuja financiera. Los LLMs e IA también podrían ser una burbuja, o no. Incluso mi madre sabe sobre ChatGPT y cómo usarlo, lo cual es interesante. Animo a todos a no temer a nuestros señores máquinas porque Skynet no funcionará tan fácilmente. Como alguien que intenta estabilizar estas cosas en producción, requiere mucho esfuerzo, y no funciona de forma confiable fácilmente. Así que, primero, no tengan miedo de los LLMs, y segundo, simplemente acéptenlos. La combinación de LLMs, humanos y empresas puede crear mucho más valor, especialmente cuando se complementa con herramientas especializadas como el forecast de Lokad que se integra muy bien en el entorno.
Conor: Gracias, Rinat. Joannes, muchas gracias por tu tiempo. Rinat, muchas gracias por acompañarnos de nuevo. Y muchas gracias a todos por vernos. Nos vemos la próxima vez.
