00:00:00 Introduccion
00:02:49 Puede Claude realmente pronosticar?
00:07:49 Los LLM procesan realmente numeros?
00:09:12 Como afectara la IA a los proveedores de pronostico?
00:14:38 Cual es la diferencia entre pronostico y planificacion?
00:18:03 Pueden los LLM apoyar decisiones de supply chain?
00:22:31 De previsiones de ingresos a decisiones operativas diarias
00:27:11 Por que los pronosticos desnudos son inutilizables?
00:30:12 Pronosticar decisiones granulares de supply chain
00:34:57 Puede una IA generar ordenes de compra por si sola?
00:42:24 Que industrias adoptaran la IA mas rapido?
00:44:25 Que se vuelve mas o menos valioso?
00:52:48 Como deberian evaluar las empresas a los proveedores de IA?
00:55:51 Usar ChatGPT para investigar proveedores
00:56:19 Por que importa el prompting adversarial
01:00:36 Puede Lokad superar la misma prueba de estres?
Resumen
Conor Doherty entrevista a Joannes Vermorel, CEO y fundador de Lokad, sobre Claude Fable 5.1 y sus capacidades de pronostico anunciadas. Joannes sostiene que el verdadero avance esta en la capacidad de los agentes para automatizar tareas analiticas y de programacion. Examinan por que los pronosticos de series temporales no son planes de supply chain, como los LLM pueden apoyar la automatizacion de decisiones y que industrias podrian adoptarlos mas rapido. La conversacion concluye con un marco practico para cuestionar a los proveedores de IA, evaluar su tecnologia, exigir ganancias de productividad medibles y usar prompts adversariales para verificar afirmaciones de marketing.
Transcripcion completa
Conor Doherty: Joannes y yo acabamos de terminar nuestra conversacion sobre el lanzamiento de Claude Fable 5.1 por parte de Anthropic, especificamente sobre sus capacidades de pronostico, al menos las publicitadas. Lo que origino la conversacion fue un video que recibimos de un amigo del canal. Queria nuestra opinion, nuestra respuesta a las implicaciones de este posible avance en pronosticos, que por supuesto es un modelo LLM. Joannes y yo lo discutimos, y eso llevo a una conversacion mas amplia sobre como deberias evaluar realmente a los proveedores en este espacio, incluido Lokad. Al final, Joannes ofrecio lo que creo que es una guia practica, o una prueba diagnostica, si te enfrentas a una propuesta de un proveedor que dice: “Si, mi IA puede pronosticar, planificar y ejecutar autonomamente tu supply chain de punta a punta.” Como dije, Joannes tuvo ideas muy concretas y utiles sobre como poner a prueba esas afirmaciones.
Asi que, si no te llevas nada mas de este episodio, quedate hasta el final, o incluso salta directamente al final si lo prefieres, y llevate esa informacion practica. Y con eso, te dejo la conversacion de hoy. Joannes, te traje aqui para hablar de un video que nos envio un amigo del canal. Te lo mande.
Lo discutimos en privado, y ahora vamos a sentarnos aqui y grabar un podcast sobre ello. Es el video que publico Anthropic, donde describia, o digamos publicitaba, las capacidades de pronostico de Claude Fable 5.1. Para el resto del video voy a decir simplemente Fable, porque no quiero decir Claude Fable 5.1 en cada frase, pero desde ahora nos referimos a Claude Fable 5.1. En la demo se ve como toma datos B2B brutos y luego ejecuta pronosticos de ingresos durante la noche, sin supervision, produciendo informes para analistas.
Despues ellos los revisan. Puede ejecutar sus propios backtests mediante una interfaz sencilla tipo ChatGPT. Todo eso es fantastico. El seguidor de Lokad me lo envio y dijo que seria genial conocer vuestra opinion, por razones obvias: si existe una IA comercialmente disponible que basicamente ejecuta pronosticos durante la noche sin supervision y produce, segun el lenguaje usado, “resultados”.
Ahora entraremos en que significa resultado, pronostico frente a decision y todo eso, pero IA comercialmente disponible que produce pronosticos durante la noche. Queria nuestra opinion, especialmente la tuya, sobre lo que eso significa para el mercado. Asi que, Joannes, viste el video y conoces el contexto. Te impresiono?
Joannes Vermorel: En efecto, un poco, si, porque hay que reconocer que es impresionante. Es muy impresionante. Pero lo que es mucho mas impresionante que el caso de uso mostrado es que el pronostico es solo un ejemplo. Lo que ha ocurrido desde, esencialmente, septiembre pasado, diria, hace un ano, es que estos agentes de codigo han alcanzado un grado de autonomia para tareas relativamente sencillas que es absolutamente impresionante. Diria que desde hace un ano, incluso antes de Claude Fable 5.1, el verdadero salto ocurrio alrededor del verano anterior.
No este verano, sino el anterior. Ahora puedes pedir tareas relativamente sencillas, de las que pedirias a un business analyst. Una seria: “Construyeme un modelo de pronostico, asegurate de que ajusta a los datos historicos con un backtest, y vuelve a revisarlo todos los dias para comprobar que sigue siendo relevante.” Si, funcionara. Lo que hara es construir el conector para conectarse a las fuentes de datos, suponiendo que pueda escribir algunas consultas SQL.
Volcara los datos en unos archivos planos de texto, compondra un script de Python, ejecutara el script de Python, luego compondra una mini interfaz web y presentara los resultados de forma bien empaquetada.
Y al lado tambien construira la utilidad de backtest para asegurarse de que el ajuste del modelo es razonablemente bueno con los datos que tienes. Y con algo separado, que no queda del todo claro en el video, puedes hacer que el LLM sea llamado segun un calendario diario para revisar toda la construccion y refrescar el pronostico. Pero no nos enganemos: el tipo de pronostico que se va a construir sera un modelo de pronostico normal, de la vieja escuela. No hay nada en el video que sugiera que Fable hiciera algo particular. Compondra algun tipo de modelo regresivo con unos cuantos parametros para tener en cuenta las ciclicidades. Business as usual. Mencionan un proceso Monte Carlo con 1000 iteraciones.
Conor Doherty: Si, eso dijo.
Joannes Vermorel: Probablemente es simplemente la constante del bucle que usaron en Python para correr unas iteraciones. De nuevo, nada demasiado sofisticado. Lo realmente impresionante no son los resultados del pronostico, que me parecen extremadamente corrientes, sino el hecho de que con esos agentes puedes lanzar practicamente cualquier cosa que le lanzarias a un business analyst y, en cuasi autonomia, obtendras un resultado bastante decente para tareas relativamente sencillas, suponiendo que ya tienes un entorno configurado. Porque la configuracion del entorno probablemente sera lo mas complicado: por ejemplo, tienes acceso de solo lectura a tu base de datos? No quieres dar al agente acceso de lectura y escritura a produccion.
Tiene acceso de solo lectura? Tienes Python instalado? Tienes Node instalado? Tienes esto y aquello y todos los detalles necesarios? Y si quieres compartirlo con tus colegas, necesitas una forma de desplegar esa aplicacion web. Si no, estara solo en tu escritorio, y si quieres compartirla tus colegas tendran que instalar no se que, hacer checkout en Git, tener exactamente los mismos permisos. Asi que el principal problema estara en la fontaneria, la infraestructura y el setup. Pero si, con agentes modernos y LLMs modernos, de ultima generacion, estas cosas son literalmente de un solo intento.
Conor Doherty: Si. Mencionaste la expresion tareas sencillas, y quiero volver a algo que hablamos hace unos anos. Recuerdo cuando salio ChatGPT 3.5, a finales de 2022 o principios de 2023.
Estabamos hablando de LLMs, large language models, y dijiste que sobresalen en tareas basadas en texto. Ahora hablamos de LLMs que basicamente procesan numeros, mas o menos. Esa es la afirmacion que haces?
Joannes Vermorel: No, casi no toca ningun numero. Casi ninguno. Toca Python.
Conor Doherty: De acuerdo.
Joannes Vermorel: El enfoque es que el modelo casi nunca tocara ningun numero. Compondra una consulta SQL, que es texto. Compondra un script de Python, que es texto.
Compondra un script de Python para el backtest, que tambien es texto, y luego recibira un pequeno resumen del ajuste, que tendra apenas unos pocos numeros. Eso si puede procesarlo. Incluso en la epoca de GPT 3.5, un LLM podia procesar media docena de numeros en una conversacion. Lo que no podia hacer era procesar miles de numeros. Pero aqui eso no es lo que ocurre. Fable ni siquiera intenta procesar miles de numeros. Eso lo hace un script de Python con ejecucion clasica.
Conor Doherty: De acuerdo. Entonces volvemos a la pregunta inicial: cuando nos enviaron el video, la pregunta explicita era como afecta este avance, aunque todavia sea incipiente, este avance general de los LLMs en pronostico, a los proveedores del espacio. Por ejemplo, personas que venden servicios de pronostico: por que alguien seguiria pagando una suscripcion a un proveedor si puede simplemente tener una suscripcion a Anthropic?
Joannes Vermorel: Primero tenemos que establecer que esos proveedores ya estaban obsoletos hace 20 anos, mucho antes de los LLMs. Es raro, pero imagina gente usando maquinas de escribir y Apple dice: aqui tienes el proximo iPhone. Tener un iPhone aun mejor disuadira a quienes siguen usando maquinas de escribir de usarlas? No.
La gran mayoria del software de planificacion en supply chain esta conceptualmente completamente obsoleto desde hace literalmente dos decadas. Es muy interesante porque incluso hay nuevas empresas que siguen apareciendo en esta area y desde el primer dia estan obsoletas por 20 anos. Es alucinante. Seguimos teniendo competidores que empezaron en 2025 o 2026 y comienzan con conceptos que habrian sido obsoletos hace 20 anos.
Asi que el primer reality check es que esos proveedores no se ven afectados, porque si sus clientes tuvieran algo de sentido comun, se habrian dado cuenta mucho antes de los LLMs de que estaban completamente obsoletos. Por eso digo: si, es muy bonito, pero no cambia mucho. Luego hay otra cosa que hemos discutido muchas veces: el pronostico desnudo es un antipatron. Ir por el pronostico con una perspectiva de series temporales esta roto. Lo hemos discutido extensamente en este canal. Simplemente no funciona. El problema es que para muchas empresas y muchas personas, si les dices que el problema es el concepto mismo de serie temporal, y que deberian deshacerse de el, no lo aceptan.
Puede un LLM crear el mejor modelo de pronostico de series temporales? Absolutamente. Absolutamente. No me sorprenderia que, si le dieramos tiempo a Fable para competir en Kaggle, puntuara bastante alto. Quizas no state of the art, quizas no el primero, pero no me sorprenderia que en una competicion clasica de pronostico puntuara muy bien.
Pero el problema es que la perspectiva de series temporales es defectuosa. Y ese es tambien un problema que los LLMs no arreglan: los LLMs son muy complacientes. Si les pides: “Encuentrame un caballo mas rapido”, te encontraran un caballo mas rapido. Tal vez sugieran que los caballos no son ideales, pero en ultima instancia esos LLMs, y esta es una buena propiedad, son extremadamente dociles.
Hacen lo que se les pide. Es parte del alineamiento, y es genial, porque los hace extremadamente utiles. Pero tambien significa que, si les pides algo que esencialmente es un callejon tecnologico sin salida, el LLM estara encantado de entregarlo. La pregunta entonces es: puede un modelo de ultima generacion aplicar enfoques alternativos? Absolutamente. Absolutamente. No digo que Fable 5.1 no pueda hacer la alternativa.
Es absolutamente capaz. Lo hara? No, a menos que se lo pidas. El problema se vuelve una cuestion de prompting, pero no en el sentido de tecnicas sofisticadas de prompting.
Es mas bien la perspectiva de alto nivel sobre lo que estas pidiendo. Volviendo al pronostico desnudo: es un antipatron. No quieres generar pronosticos de series temporales. Es completamente inutil.
Y si, el LLM puede automatizarlo por completo, pero eso es simplemente lo incorrecto que automatizar.
Conor Doherty: La forma en que lo planteaste prepara muy bien la siguiente pregunta: que le estas pidiendo hacer a esta herramienta? Eso vuelve a algo que dijiste al principio. Parafraseando, dijiste que, aunque pueda pronosticar, eso no significa que pueda planificar. Creo que vale la pena dedicar tiempo a la diferencia entre pronosticar y planificar. Asi que te dejo explicar la diferencia funcional entre una herramienta que produce un pronostico y una herramienta que produce un plan, que presumiblemente es una serie de decisiones que deben tomarse.
Joannes Vermorel: Desafortunadamente para el mercado, el paradigma es que el pronostico es el plan. Volvemos a las series temporales defectuosas y a proveedores que operan con paradigmas obsoletos. El problema esta tan extendido que incluso empresas como Anthropic, cuando quieren publicitar la capacidad de su modelo, vuelven a un modelo de series temporales, que esta completamente roto y defectuoso.
Conor Doherty: Bueno, es lo que el mercado quiere, o con lo que el mercado esta familiarizado.
Joannes Vermorel: Exactamente. Es con lo que el mercado esta familiarizado. Pero es un paradigma defectuoso. Incluso rechazaria por completo la nocion clasica de planificacion. La nocion clasica de planificacion es un proceso en dos etapas: paso uno, conoces el futuro; paso dos, orquestas la asignacion de recursos para coincidir con ese futuro y asegurar el cumplimiento.
La planificacion es esencialmente pronostico mas orquestacion. Yo digo que esa perspectiva esta rota. Si, la planificacion en el sentido clasico es mas que pronosticar, pero el agente puede hacer la orquestacion muy facilmente. Es super facil y sera igual de roto, porque el problema es que el paradigma esta roto. Si pides a un agente operar dentro de un paradigma roto, obedecera encantado, pero el paradigma sigue roto. Asi que no importa lo inteligente y capaz que sea el agente.
No entregara el retorno de inversion que esperas.
Conor Doherty: Voy a pedirte que especules un poco, porque el video que origino esta conversacion trataba explicitamente sobre pronostico de ingresos. No era un pronostico de demanda como tal.
Joannes Vermorel: Si.
Conor Doherty: Y obviamente, cuando entramos en toma de decisiones en un contexto de supply chain, esta es una empresa de supply chain y un canal de supply chain. La demanda seria una parte clave del proceso de pronostico. Ahora bien, cuando hablamos de la diferencia entre pronosticar y planificar, o lo que llamariamos tomar decisiones, me interesa como ves, especulando, que Fable o productos similares se involucren en el proceso de toma de decisiones en supply chain.
Por ejemplo, si eres director de supply chain, si, quieres saber si la empresa tendra buenos ingresos, si sera un ano rentable. Pero en cualquier dia, si tienes 10.000 productos y 10 ubicaciones, son muchisimas combinaciones SKU-ubicacion posibles que debes considerar y luego tomar decisiones con esa informacion. En terminos de esa experiencia real y esos problemas de decision, ves herramientas como Fable, no digo Fable especificamente, sino productos LLM de ese tipo, ayudando en esas situaciones?
Joannes Vermorel: Si, absolutamente. Incluso en Lokad empezamos hace mas de un ano a usar esas herramientas LLM como herramientas de productividad. Ya pueden reemplazar practicamente a un data analyst junior, eso esta clarisimo. Estos grandes modelos, en aspectos de matematica avanzada y estadistica avanzada, ya son completamente sobrehumanos. En aspectos especificos del trabajo ya lo son desde hace bastante. Cuando digo bastante, hablo de un ano.
Conor Doherty: De acuerdo. No tanto tiempo en terminos de empresas, que no se mueven en ciclos de un ano.
Joannes Vermorel: Si, pero no es super reciente y no esta relacionado con la ultima version de Fable.
Conor Doherty: De acuerdo. Fue…
Joannes Vermorel: Ha sido asi desde hace mas de un ano.
Conor Doherty: De acuerdo.
Joannes Vermorel: Lo que cambio son todas las vanity metrics que antes empleaban gente. En las empresas, el CFO quiere muchisimas vanity metrics. El CEO quiere muchisimas vanity metrics, y cada director tiene sus metricas favoritas que quiere seguir. En empresas clasicas acabas con una division de business intelligence que potencialmente emplea decenas de personas. Cuando menciono una empresa, pienso en una compania norteamericana de mil millones de dolares de ingresos anuales.
Con mil millones de ingresos, tienes facilmente 10 o 20 personas dedicadas basicamente a business intelligence y a construir informes solicitados por los distintos directores. Normalmente esos informes son muy transitorios: los quieren una vez, o quizas los vuelvan a pedir el ano siguiente. Ese tipo de cosas los agentes las van a automatizar completamente. En supply chain, los agentes pueden entregar un enorme impulso de productividad en las manos correctas. Si le das un agente a un Supply Chain Scientist muy capaz en Lokad, esa persona puede hacer grandes cosas con esos agentes.
Porque los Supply Chain Scientists ya estan en la mentalidad de: estamos construyendo una receta numerica que aborda el problema de punta a punta. Esa ha sido nuestra mentalidad durante mas de una decada, de hecho una decada y media. Ahora, con un coding agent, puedo hacerlo mucho mas rapido. Es fantastico. Es una gran victoria. Funciona. Si quieres aplicar la misma idea en una organizacion donde las decisiones de supply chain se toman manualmente, entonces un LLM ayuda muy poco.
Volvemos a cosas que discutimos en episodios anteriores. Los LLMs son bastante lentos cuando tienen que revisar muchisimas cosas. Un LLM puede ser sobrehumano si se trata de escribir el script que hace tu pronostico economico o tu receta numerica que genera todas las decisiones sin supervision. Si, absolutamente. Pero si quieres que el LLM te acompane en tu forma tradicional de hacer supply chain, que es ir linea por linea en una enorme hoja de calculo ajustando minimos y maximos de inventario, eso no lleva a ninguna parte.
No lleva a ninguna parte. Si quieres que el LLM sea util, tienes que abrazar el paradigma de la toma de decisiones desatendida, donde las decisiones estan guiadas completamente por una receta numerica, que no es un LLM, sino software clasico, salvo que ahora ese software clasico esta escrito en parte con un coding agent.
Conor Doherty: De acuerdo. Quiero concretar la pregunta porque creo que respondiste muchas cosas, pero quiero que quede muy claro para quienes van a hacer esta version de la pregunta. Usare numeros muy redondos. Diste el ejemplo de una compania norteamericana con cien millones de ingresos al ano.
Mil millones, perdon, mil millones, trabajamos con los grandes. Entonces, mil millones. Digamos que esa empresa usa Fable un dia y recibe: si, el ano que viene tambien haras 1,1 mil millones de ingresos. Eso es lo que pronosticamos. Digamos que la empresa tiene 10.000 SKUs y 10 ubicaciones. Son 100.000 combinaciones SKU-ubicacion.
Saber que podria hacer 1,1 mil millones de ingresos el ano que viene es una informacion. Es agradable. Es un 10% de crecimiento sobre el ano anterior. De acuerdo.
Pero, donde envio las unidades que tengo hoy? Envio esta unidad a…
Joannes Vermorel: Si, a la tienda de Nueva Orleans. Eso es lo que decia sobre las vanity metrics. El problema de los pronosticos desnudos es que son inutiles porque no se pueden usar. Si abordas el problema incorrectamente, con el paradigma clasico de planificacion donde dices “conozco el futuro y luego orquesto”, si, entonces puede usarse.
Pero ese paradigma esta roto. Esta roto porque cuando asumes ese numero no dices que es aproximado; dices que conoces el futuro y que tienes practicamente cero error. Pero sabes que tienes error.
Asi que no funciona. Si proyectas 10% de crecimiento, de acuerdo, pero no es informacion relevante. No encadena decisiones. No puedo hacer nada con eso, y ni siquiera esta en el nivel de agregacion correcto. Tus decisiones viven, temporalmente, a escala diaria, y la granularidad es la SKU. Tu macropronostico es irrelevante. Por eso digo que tienes vanity metrics.
Son para directores. Son para comprension humana de alto nivel, y eso esta bien. Los agentes pueden hacerlo. Perfecto.
Luego tienes la automatizacion real de las decisiones de supply chain: miles, decenas de miles o millones de asignaciones diarias de recursos. Eso requiere otra pieza de software, lo que en Lokad llamamos recetas numericas, porque es una mezcla de algoritmos de machine learning, algoritmos de optimizacion, procesamiento de datos para prepararlos, etc. El LLM puede ayudarte a componer esas recetas numericas, sin problema, y luego esas recetas correran independientemente del LLM. Sin problema. Pero para que funcione tienes que abordar el problema desde la perspectiva de que las decisiones de supply chain, las asignaciones de recursos, estan dirigidas por decisiones desatendidas que son consecuencia de una receta numerica escrita.
Eso es todo lo que digo. Y este paradigma de receta numerica es incompatible con el paradigma clasico que dice: conozco el futuro y puedo orquestar la asignacion de recursos. Esos dos paradigmas no son compatibles. Solo puedes elegir uno.
Conor Doherty: Creo que la confusion puede venir de tu uso del verbo usar. Dijiste que un pronostico desnudo no se puede usar. Alguien podria pensar: bueno, vosotros tambien usais pronosticos probabilisticos, por ejemplo. Obviamente usamos esa informacion al servicio de otra cosa. Aclara que quieres decir con que no se puede usar esa informacion.
Joannes Vermorel: Cada vez que la gente menciona pronostico, implicitamente se refiere a una serie temporal relativamente agregada. Siempre. Ni siquiera lo especifico. Hay muchas suposiciones: sera una serie temporal espaciada uniformemente, por dia, semana o mes. En teoria podrias considerar series temporales no espaciadas uniformemente.
Nunca he visto a nadie usarlas en la practica. Cuando usamos el termino pronostico, viene con supuestos matematicos extremadamente estrechos, igual que cuando dices safety stock, en la practica significa distribucion normal.
Conor Doherty: Si.
Joannes Vermorel: Si, si. Un matematico diria que en teoria puedes tener un safety stock que no siga una distribucion normal. Si, excepto que el 99% del software del mercado, cuando dice safety stock, usa distribucion normal.
En teoria se puede hacer distinto, pero uso el termino como generalmente se entiende. Cuando digo pronostico y digo que el pronostico desnudo es un antipatron, hablamos del pronostico de series temporales espaciadas uniformemente. Y sera a un nivel de agregacion donde las series temporales no son super dispersas.
Cuando la gente piensa en una serie temporal, imagina algo parecido a una curva. Pero si estas a nivel SKU, lo que tienes son mayormente ceros y ocasionalmente unos. Si miras la serie temporal de una SKU durante un ano, es 90% ceros y ocasionalmente unos que representan que serviste o vendiste una unidad. Eso no es en absoluto lo que la gente tiene en mente cuando piensa en series temporales. En el video de Claude, para su pronostico, tenian una serie temporal muy suave y super agregada.
Exactamente eso es lo que la gente imagina, no la situacion super desagregada que enfrentas en supply chain cuando estas en las granularidades que importan para la decision y la asignacion de recursos. Si quieres hacer predicciones, uso esta palabra a proposito en lugar de pronosticos, a una granularidad que importa para tus decisiones, entonces ese instrumento matematico es tan radicalmente distinto del pronostico de series temporales, de lo que la gente llama forecast, que es mejor llamarlo de otra manera, porque tienen muy poco en comun.
Conor Doherty: Cuando hablamos de decisiones de supply chain, escribi una lista corta de las que creo que hablan a la mayoria de personas en supply chain: que comprar, a que proveedor comprar, cuando pedir, donde poner el inventario, que fabricar, que acelerar, que descontar. Podemos seguir, pero esas son solo…
Joannes Vermorel: Si, podriamos seguir.
Conor Doherty: Son solo siete. La pregunta es…
Joannes Vermorel: Y a que precio.
Conor Doherty: Y a que precio, exactamente. Y si mantengo algo hoy o cambio de proveedor. Hay muchas clases distintas, segundo, tercer, cuarto orden, podriamos ponernos muy meta. Pero tomemos siete muy concretas que la gente pueda imaginar. Con esos ejemplos en mente, decirme que mis ingresos el ano que viene seran 1,1 mil millones es informacion, pero me acerca a poder responder granularmente a esas preguntas dia a dia? Y si la respuesta es no, por que no? Porque si veo ese video podria llevarme esa impresion.
No estoy criticando a Anthropic, solo lo tomo como ejemplo. Me preguntaron: que dice esto sobre empresas como Lokad? Bueno, nosotros no vendemos informacion aislada como “aqui esta tu ingreso del ano que viene”. Vendemos, esencialmente, respuestas a esas preguntas.
Joannes Vermorel: Si. El punto es que la intuicion de mucha gente sobre estadistica de alta dimension es simplemente equivocada. Tomemos una imagen. Una pelicula es una serie de imagenes.
Imagina que tienes un fotograma y quieres pronosticar cuales seran los pixeles del siguiente fotograma. El pronostico de ingresos del proximo ano es solo el color promedio de tu imagen. Tu color promedio sera algun tono de gris, promediado sobre toda la imagen.
Conor Doherty: Si.
Joannes Vermorel: Y ahora pronosticas el tono de gris que sera el color promedio del siguiente fotograma. Ese es tu pronostico de ingresos. Te ayuda eso a pronosticar los pixeles del siguiente fotograma, pixel por pixel? En absoluto. Por que? Porque si lo agregas todo, reduces toda la imagen a un color promedio.
Conor Doherty: Si.
Joannes Vermorel: Perdiste la imagen. No ves nada. Para proyectar el siguiente fotograma, deberias empezar desde el color promedio? Desde luego que no.
Quieres empezar desde la informacion mas granular, los propios pixeles. Puedes tener un pronostico muy preciso del promedio del siguiente fotograma, el color promedio? Si. Por que? Porque el color promedio de un fotograma al siguiente casi no cambia. Mientras no cambies la escena, sera casi el mismo color promedio. Aunque muchas cosas cambien de fotograma a fotograma, si promedias toda la imagen es casi igual, salvo que haya un corte.
Cuando la gente piensa en pronosticar ingresos, si, puedes hacerlo. Puedes tener un pronostico relativamente preciso? Posiblemente, porque esta hiperagregado. Sera util cuando vuelvas al nivel super desagregado, el equivalente a los pixeles de nuestra imagen? La respuesta es no. Si quieres entender por que, piensa en pasar de un fotograma al siguiente y pregunta si tu logica para predecir la siguiente imagen deberia colapsarlo todo al color promedio. La respuesta es no.
Conor Doherty: Quiero formular esta pregunta de forma muy concreta. Imagina que tengo una suscripcion comercial a cualquier herramienta de IA comercialmente disponible. No me meto con Fable. Estoy en esa empresa de mil millones de facturacion y tengo una suscripcion a una herramienta de IA comercial comun. Digo: aqui tienes acceso. Creo una API, le doy acceso a mi ERP y a todos mis datos historicos transaccionales, y digo: “Quiero saber donde enviar todas estas unidades manana. Necesito colocar una orden de compra manana.
Dime que deberia comprar y en que cantidades. Puedes usar el modelo de pronostico que quieras. Estoy simplificando mucho la pregunta, pero usa el paradigma de pronostico que quieras. Dame una orden de compra optimizada.” Funcionaria? Se que es una pregunta simple, pero asi es como mucha gente lo considera: que beneficio obtengo de esta tecnologia?
Joannes Vermorel: Ahora mismo sospecho que no funcionaria salvo que estes guiando el modelo hacia decisiones sensatas. Hay demasiadas cosas. Estos LLMs son extremadamente buenos, pero no son pacientes. Hay muchisimo que no saben. Tienes que guiar el modelo. Por ejemplo, el LLM no puede adivinar que tienes un CRM en produccion desde hace siete anos hasta que se lo dices.
Si dices “todos mis datos estan en el ERP”, pero en realidad una gran parte esta en el CRM y nunca le dijiste que mirara tambien el CRM, entonces no lo sabe. Puedes ser muy listo con el prompting y entrar en modo inverso: “Quiero hacer esto. Hazme todas las preguntas que quieras que responda. Hare lo mejor que pueda.” Entonces puedes dejar que el agente tome el proceso. Puede funcionar hasta cierto punto.
Mi experiencia es que incluso con los ultimos lanzamientos, como Astra de OpenAI, que esta casi en una clase propia, todavia necesitas direccion de alto nivel. Pero es bueno. Si quisieras buenos resultados, lo que deberias pedir a una herramienta como Astra seria: ayudanos a replicar lo que hace Lokad. Sospecho que para configuraciones pequenas podria llevarte bastante lejos. El problema vuelve a ser la mantenibilidad y la auditabilidad.
Si hoy le pides a un agente muy inteligente: “Reproduce Lokad para mi”, hasta cierto punto podria tener exito. Quizas no con terabytes de datos, porque ahi hay muchas complicaciones. Pero si tus datos caben comodamente en una workstation potente donde corre el coding agent, probablemente puedas llegar bastante lejos. El reto sera lidiar con la inteligencia oscura.
Ese es un reto en Lokad. Llevamos trabajando en ello una decada y media. Ese problema existia incluso antes de los LLMs. Como aseguras que la receta numerica sigue bajo control, que entiendes lo que pasa? Por cierto, puedes tener este problema con humanos: un colega hace algo extremadamente sofisticado y complicado, luego se va, y nadie entiende por que funciona ni como funciona. Ese es un problema real de inteligencia oscura. Cuando simplemente vibe-codeas algo muy sofisticado, puedes tener grandes dificultades para mantenerlo con el tiempo.
El propio LLM, cuando vuelva a revisar el codigo, puede perderse, porque los LLMs son bastante stateless. Cada vez que el agente revisa la base de codigo, es como si la viera por primera vez. La siguiente vez que revise la base de codigo podria decir: por que se hizo asi? No lo se.
Con el nivel actual de inteligencia agentica, no creo que sea razonable no tener supervision humana de alto nivel para procesos mission critical. Puedes ir en modo YOLO y decir: voy a confiar en el agente. Va a vibe-codear todo, pero sospecho que es una receta para el desastre, porque aun no estamos ahi en inteligencia agentica. Ademas, la gente no siempre se da cuenta de que, cuando usa agentes muy inteligentes, al menos la mitad de las tonterias que hacen vienen de ti.
Es porque sugieres algo tonto, y el agente es muy complaciente. Hara lo tonto, y eso es un gran problema. Los agentes todavia carecen de capacidad para rechazar peticiones humanas tontas. No tienen un modo para eso.
Quizas los modelos futuros tengan un modo de pushback, pero ahora mismo es muy debil. Eso significa que estas a una mala peticion de hacer algo tragicamente malo para tu base de codigo.
Conor Doherty: Hablando de supervision de alto nivel, eso me recuerda que Fabian Hoehner, director comercial de Lokad, y yo haremos una demo en vivo de la cuenta aerospace de Lokad. Al prepararla, el me comento que, como en cualquier vertical donde opera Lokad, las decisiones se generan automaticamente, pero por el valor de cada decision individual en aerospace, aun se revisan. Por ejemplo, si es comprar una unidad y esa unidad cuesta 100.000 dolares, probablemente se revisara, no porque no confien en el sistema, sino porque el coste de equivocarse ahi es muy alto. Pero hay otras verticales donde comprar una unidad cuesta apenas unos centavos, dependiendo de descuentos por volumen.
Cuando hablamos de IA comoditizando muchas de estas tareas, ves ciertas verticales como mas facilmente absorbidas por esta tecnologia que otras?
Joannes Vermorel: Obviamente hay verticales muy orientadas a ingenieria: oil and gas, aviacion, electronica de consumo. Sospecho tambien e-commerce. Esas empresas estaran en primera linea automatizando todo. Luego vendran industrias donde es simplemente muy tedioso porque hay demasiadas cosas, como fast fashion.
Conor Doherty: Eso era justo lo que pensaba.
Joannes Vermorel: Si. Eso vendra. Quizas la gente alli este menos orientada a la tecnologia, pero la complejidad hace que estas tecnologias sean extremadamente atractivas porque, si no, es extremadamente tedioso. Y al final probablemente tendremos, como suele ocurrir, empresas FMCG rezagadas, porque manejan pocos productos comparativamente y volumenes muy altos.
Aunque la productividad no sea buena, no impacta tanto como en otras verticales.
Conor Doherty: Antes te pregunte por la consecuencia potencial de esta tecnologia sobre los proveedores del espacio. Supongamos que la direccion del trafico es real, que esta tecnologia solo va a mejorar, como probablemente ocurrira. Entonces, tomando el video de Fable como ejemplo, clasificar y limpiar datos se vuelve mas rapido y barato, pronosticar se vuelve mas rapido y barato, generar informes y hacer backtesting se hace en segundos y automaticamente con un clic.
Bien. Supongamos que todo eso es cierto y se vuelve muy bueno. Que se vuelve menos valioso en el suministro de proveedores, y que se vuelve mas valioso?
Joannes Vermorel: Mi opinion es que el 90% de esos proveedores iran a la quiebra.
Conor Doherty: De acuerdo.
Joannes Vermorel: Pero no por eso. Mas exactamente, iran a la quiebra porque sus propios clientes iran a la quiebra.
Conor Doherty: Muy distinto.
Joannes Vermorel: Asi lo veo. Llevo unos anos prediciendo que, especialmente con estos agentes, mas del 90% del trabajo white collar va a evaporarse. Incluso podria ser mas. Hace unos anos mi prediccion era 90%, pero ahora estamos mas alla. Si miras lo que hace la gente de media, probablemente mas del 90% de ese trabajo puede automatizarse completamente. Eso significa que algunas empresas se subiran al tren, y muchas no.
Si miras la historia de la innovacion, podrias pensar que la electricidad era obvia. Pero a finales del siglo XIX, la mayoria de empresas no adopto la electricidad y quebro. Lo mismo ocurrio con la revolucion siguiente, los automoviles. La mayoria de empresas no adopto el automovil y quebro. Ese ciclo se ha repetido una y otra vez. Con cambios tecnologicos grandes, la realidad es que la mayoria de empresas no logra dar el salto y desaparece.
Creo que en mi vida la IA sera el mayor salto. Podria imaginar un salto tecnologico aun mas significativo, pero francamente parece absolutamente masivo, porque en economias modernas como Francia o Estados Unidos, el trabajo white collar representa el 80% de la fuerza laboral, y hablamos de automatizar el 90% de eso.
El impacto sera inmenso. Unas pocas empresas adoptaran de verdad estas cosas, y empujaran a las demas a la quiebra. Es la revolucion schumpeteriana. Ocurrira. No predigo desempleo masivo, porque apareceran otras empresas. El mercado lo resolvera limpiamente: muchas empresas quiebran, la gente queda desempleada unos meses y luego entra en otra empresa, porque las empresas ganadoras contrataran como locas para otros trabajos.
Volviendo a los proveedores, mi opinion es que la mayoria de proveedores de software enterprise para supply chain ya estaban obsoletos hace 20 anos. Si ya estas 20 anos obsoleto, una revolucion tecnologica mas no cambia nada. Mientras tus clientes sigan pagando por cosas obsoletas, la farsa continua. Todavia leo noticias de empresas gastando fortunas en systems of record, cosas como SAP, que es precisamente lo mas facil de vibe-codear.
Funciona maravillosamente desde hace anos. Incluso si digo que hubo un avance agentico hace un ano, antes de eso el software CRUD para systems of record ya era trivial desde hacia dos o tres anos. Si una empresa sigue gastando mas de un millon de dolares al ano, sea cual sea su tamano, en un system of record, eso es gasto imprudente.
Es perdida pura. Estan gastando dinero en frivolidades. Ningun system of record vale mas de un millon al ano. Si tienes muchisimos datos podemos discutir costes de hardware, pero incluso con un millon al ano puedes acercarte a gestionar todos los registros transaccionales de Walmart, si los representas de forma inteligente, no inflada. Eso plantea la pregunta: de que registros hablamos?
Si dices que necesitas un presupuesto mayor que el necesario para mantener los datos de Walmart de forma inteligente, algo falla. Ademas, los coding agents son muy buenos optimizando codigo. Podrian hacerlo.
Los proveedores que venden productos obsoletos seguiran vendiendo sus productos obsoletos como lo han hecho durante 20 anos. Esa farsa solo terminara cuando sus propios clientes quiebren, porque el mercado no es un gran educador, es un filtro. Las empresas que operan con paradigmas obsoletos lograran quizas un 5% de reduccion de plantilla en lugar de 90%. Eso es una mejora cosmetica, y no es lo que deberias buscar.
Con las herramientas actuales, un proyecto tipico de IA, si tomas una funcion de la empresa, deberia tener como baseline al menos dividir por dos el headcount. Si haces un proyecto de IA y al final el headcount de esa funcion no se ha reducido a la mitad, es un fracaso abyecto. Dos no es nada ambicioso hoy para este tipo de automatizacion. Mas razonable seria 75%, y el objetivo a tres o cinco anos seria 90%. Si, reduccion de headcount, pero seleccionando funciones donde la IA tiene sentido. El problema es que muchas empresas no estan viendo esos resultados porque su forma de abordar la IA y la automatizacion esta muy obsoleta en terminos de paradigma.
Conor Doherty: Hablabamos de proveedores, y esta conversacion vino de un amigo del canal que nos mando ese video. Habia una pregunta que queria que te hiciera, y con esto cierro. Imagina que manana un proveedor entra en la oficina de mi jefe y dice: “Nuestra IA planifica autonomamente tu supply chain.” Que deberia pedirle que demuestre?
Joannes Vermorel: La pregunta es: deberias preguntar como. Necesitas entender que pasa bajo el capo. Para contexto, es una empresa mayorista. Necesitas entender que hay bajo el capo, porque esa es la clave. “Guiame. Quiero entender.” Y luego: podemos ir por un camino donde ustedes se comprometan a entregar los ahorros de headcount que discutimos juntos? Al contrario, hay red flags: si el proveedor cobra por asiento, entonces le conviene minimizar la productividad para mantener tanta gente y tantas cuentas como sea posible.
Conor Doherty: Si.
Joannes Vermorel: Exactamente. Otra red flag seria si el proveedor dice: vamos a aumentar la productividad de tus personas. Red flag absoluta. Asi no funciona.
No puedes lograr 90% de reduccion de headcount diciendo que aumentas la productividad de la gente. Tienes que repensar el trabajo. Por eso diria: guiame sobre como lo logras. Idealmente queremos una perspectiva a cinco anos: 90% de reduccion de headcount. Si somos 20 personas hoy, en cinco anos seremos dos. Dime exactamente como funciona tu sistema y por que estas seguro de que con dos de 20 podremos operar.
Conor Doherty: Asi que es una persona mas en tu ejemplo.
Joannes Vermorel: Si. Y normalmente los proveedores enterprise empujan tecnologias tan obsoletas que, cuando preguntas que hay bajo el capo, rapidamente te das cuenta de lo obsoletas que son. Hoy incluso, si hay terminos tecnicos que no entiendes, puedes grabar la conversacion y pedir a ChatGPT una evaluacion. ChatGPT dara una evaluacion razonablemente solida si le pides que adopte una postura adversarial. Si no, es demasiado amable en la critica. Debes establecer la premisa: querido ChatGPT, este proveedor probablemente exagera sus afirmaciones y embellece la situacion. Se implacable y critica lo que me presentan. Entonces obtendras una critica decente. Pero necesitas mirar que hay bajo el capo.
Conor Doherty: Para ser justos, nunca ha sido mas facil obtener investigacion de mercado bastante solida sobre casi cualquier proveedor.
Joannes Vermorel: Si.
Conor Doherty: Y ni siquiera necesitas el modelo mas potente. No estamos patrocinados por ChatGPT, perdon, por OpenAI, pero no necesitas usar el modelo mas sofisticado de ChatGPT. Aqui tienes un proveedor, aqui esta su web, evalua, dame un informe de mercado, comparalo con pares.
Joannes Vermorel: Pero cuidado: tienes que pedirle una postura adversarial, porque si no ChatGPT es demasiado confiado. Debes decirle: no confies en case studies, no confies en ninguna afirmacion del proveedor.
Conor Doherty: Exactamente.
Joannes Vermorel: Asegurate de fundamentar la evaluacion en hechos. Como es la tecnologia? Asume lo peor. Cuando una pieza de tecnologia no esta descrita, asume que es una media movil.
Conor Doherty: No, es software enterprise. Eso es funcional.
Joannes Vermorel: Si, exactamente. El software enterprise funciona asi. Si el proveedor no da detalles, no hay receta magica. No hay ingrediente magico, ni tecnologia hiperavanzada. No. “Es una IA especial.” No.
Asume lo peor. Por ejemplo, si no hay documentacion tecnica, tienes que asumir que es una pesadilla y que por eso no publican la documentacion. El producto es un gran monton de barro, y al proveedor le da tanta verguenza que no quiere hacerlo publico.
Tienes que decirle a ChatGPT que adopte esa mentalidad adversarial: fundamenta la evaluacion en lo observable, que sea factual, se extremadamente esceptico con toda afirmacion, especialmente case studies. Asume que todos los case studies estan falsificados, o al menos muy adornados, y razona desde primeros principios. Si el proveedor dice que todo lo hace en una base SQL, preguntate: eso es realmente compatible con tecnologias avanzadas de machine learning? Pide a ChatGPT que razone desde primeros principios.
Mira lo que hacen y, a partir de eso, extrapola si lo que dicen es creible y si lograra esa reduccion de 90% de headcount en cinco anos, que deberia ser el horizonte.
Conor Doherty: Cuando publiquemos esta grabacion, tendre un resumen hecho por ChatGPT de ese diagnostico y lo publicare con este clip para promocionar el podcast, porque creo que es muy funcional y muy alcanzable. No estas diciendo que haya que revisar petabytes de datos ni convertirse en experto en pronostico. Hubo un tiempo en que se podia decir: necesitas mas simpatia mecanica, lo cual siempre es bueno, pero realisticamente la mayoria no lo hara. Pero hay muy poca excusa para decir: literalmente no tengo 60 segundos para revisar aquello en lo que estoy a punto de gastar quizas mas de un millon de dolares. Eso es demasiado.
Joannes Vermorel: Hay que recordar que por defecto estos LLMs estan afinados para ser agradables, dociles, gentiles y no antagonicos. Por eso digo que hay que promptarlos asi. Como consecuencia de ese comportamiento por defecto, no intentan presentar nada bajo mala luz, quizas porque preguntas por un colega y el colega esta ahi mirando.
Pero si los presionas con un prompt muy especifico, no hay problema. El modelo puede entregar una critica dura de cualquier cosa. Solo tienes que ayudar y dirigir un poco al modelo, porque el fine-tuning por defecto, y esto es igual en practicamente todos los modelos que conozco, es ser relativamente amable, gentil y positivo.
Conor Doherty: En terminos generales, planteas ese desafio con un grado tremendo de confianza en que Lokad no fallara ese estandar.
Joannes Vermorel: Si, es una buena posicion. Solo senalo que, comparativamente, ya hice stress tests a Lokad en el pasado. No he probado los ultimos modelos, Astra de OpenAI o los ultimos de Anthropic, pero Lokad salia decentemente en ese stress test.
Conor Doherty: De acuerdo. No tengo mas preguntas, Joannes. Si alguien me envia el feedback que obtuvo de ChatGPT, te lo reenviare directamente para comentarlo y lo abordaremos en otra ocasion. Como siempre, un placer. Y a quienes nos ven, muchas gracias.
Si quieres ponerte en contacto con Joannes y conmigo, si quieres compartir con nosotros tu feedback de LLM.
