00:28 Introducción
00:43 Robert A. Heinlein
03:03 La historia hasta ahora
06:52 Una selección de paradigmas
08:20 Análisis estático
18:26 Programación con arrays
28:08 Miscibilidad de hardware
35:38 Programación probabilística
40:53 Programación diferenciable
55:12 Versionado de código+datos
01:00:01 Programación segura
01:05:37 En conclusión, las herramientas también importan en Supply Chain
01:06:40 Próxima conferencia y preguntas de la audiencia
Descripción
Si bien la teoría de supply chain dominante lucha por prevalecer en las empresas en general, una herramienta; a saber, Microsoft Excel, ha disfrutado de un considerable éxito operativo. Reimplementar las recetas numéricas de la teoría de supply chain dominante a través de hojas de cálculo es trivial, sin embargo, esto no fue lo que ocurrió en la práctica a pesar del conocimiento de la teoría. Demostramos que las hojas de cálculo triunfaron al adoptar paradigmas de programación que resultaron superiores para ofrecer resultados de supply chain.
Transcripción completa
Hola a todos, bienvenidos a esta serie de conferencias sobre supply chain. Soy Joannes Vermorel, y hoy presentaré mi cuarta conferencia: Paradigmas de programación para Supply Chain.
Así que cuando me preguntan, “Señor Vermorel, ¿cuáles cree que son las áreas de mayor interés en términos de conocimiento de supply chain?” una de mis respuestas principales suele ser los paradigmas de programación. Y luego, no tan frecuentemente, pero lo suficiente, la reacción de la persona con la que hablo es, “¿Paradigmas de programación, señor Vermorel? ¿De qué diablos está hablando? ¿Cómo es que tiene relación, siquiera remotamente, con la tarea en cuestión?” Y ese tipo de reacciones, obviamente, no son muy frecuentes, pero cuando ocurren, invariablemente me recuerdan a esta cita completamente increíble de Robert A. Heinlein, quien es considerado el decano de los escritores de ciencia ficción.
Heinlein tiene una cita fantástica sobre el hombre competente, que resalta la importancia de la competencia en diversos campos, especialmente en supply chain donde tenemos problemas complejos en nuestras manos. Estos problemas son casi tan desafiantes como la vida misma, y creo que realmente vale la pena invertir tiempo en explorar la idea de los paradigmas de programación, ya que podrían aportar mucho valor a tu supply chain.
Hasta ahora, en la primera conferencia, hemos visto que los problemas de supply chain son complejos. Cualquiera que hable de soluciones óptimas se está perdiendo el punto; no existe nada siquiera remotamente cercano a la optimalidad. En la segunda conferencia, esbocé el Supply Chain Quantitativa, una visión con cinco requisitos clave para la grandeza en la gestión de supply chain. Estos requisitos no son suficientes por sí solos, pero no se pueden omitir si se quiere alcanzar la grandeza.
En la tercera conferencia, discutí la entrega de productos de software en el contexto de la optimización de supply chain. Defendí la proposición de que la optimización de supply chain requiere que un producto de software sea abordado adecuadamente de manera capitalista, pero no se puede encontrar tal producto en el estante. Hay demasiada diversidad, y los desafíos a los que nos enfrentamos van mucho más allá de las tecnologías que tenemos en la actualidad. Por lo tanto, por necesidad, será algo completamente hecho a la medida. Así, si se trata de un producto de software que va a ser hecho a la medida para la empresa o la supply chain en cuestión, surge la cuestión de cuáles son las herramientas adecuadas para realmente entregar este producto. Esto me lleva al tema de hoy: la herramienta adecuada comienza con los paradigmas de programación correctos, porque vamos a tener que programar este producto de una manera u otra.
Hasta ahora, requerimos capacidades programáticas para abordar el lado de la optimización del problema, sin confundirse con el lado de la gestión. Lo que hemos visto, que fue el tema de mi conferencia anterior, es que Microsoft Excel ha sido el ganador hasta ahora. Desde empresas muy pequeñas hasta empresas muy grandes, es ubicuo, se utiliza en todas partes. Incluso en empresas que han invertido millones de dólares en sistemas súper inteligentes, Excel sigue reinando, ¿y por qué? Porque posee las propiedades de programación adecuadas. Es muy expresivo, ágil, accesible y mantenible. Sin embargo, Excel no es el producto final. Estoy firmemente convencido de que podemos hacer mucho más, pero necesitamos tener las herramientas, la mentalidad, las ideas y los paradigmas de programación correctos.
Los paradigmas de programación pueden parecer excesivamente oscuros para la audiencia, pero en realidad es un campo de estudio que ha sido investigado intensivamente durante las últimas cinco décadas. Se ha realizado una cantidad inmensa de trabajo en este campo de estudio. No es ampliamente conocido para una audiencia más amplia, pero existen bibliotecas enteras llenas de trabajos de alta calidad realizados por muchas personas. Así que hoy, voy a presentar una serie de siete paradigmas que Lokad ha adoptado. No inventamos ninguna de estas ideas; las tomamos de personas que las inventaron antes que nosotros. Todos estos paradigmas han sido implementados en el producto de software de Lokad, y después de casi una década de ejecutar Lokad en producción, aprovechando estos paradigmas, creo que han sido absolutamente críticos para nuestro éxito operativo hasta ahora.
Procedamos a lo largo de esta lista comenzando con el análisis estático. El problema aquí es la complejidad. ¿Cómo se enfrenta a la complejidad en supply chain? Se enfrentará a sistemas empresariales que tienen cientos de tablas, cada una con docenas de campos. Si está considerando un problema tan simple como el reabastecimiento de existencias en un almacén, tiene tantas cosas a tener en cuenta. Puede tener MOQs, escalas de precios, forecast de demanda, forecast de lead times, y todo tipo de devoluciones. Puede haber limitaciones de espacio en estantes, límites de capacidad de recepción y fechas de caducidad que hacen obsoletos algunos de sus lotes. Entonces, acaba con toneladas de cosas a considerar. En supply chain, la idea de “moverse rápido y romper cosas” simplemente no es la mentalidad correcta. Si inadvertidamente ordena mercadería por valor de un millón de dólares que no necesita en absoluto, esto es un error muy costoso. No puede tener un programa de software dirigiendo su supply chain, tomando decisiones rutinarias, y cuando hay un error, cuesta millones. Necesitamos tener algo con un grado muy alto de corrección por diseño. No queremos descubrir los errores en producción. Esto es muy diferente de su software promedio, donde un fallo no es gran cosa.
En lo que respecta a la optimización de supply chain, este no es su problema habitual. Si acaba de pasar un pedido masivo e incorrecto a un proveedor, no puede simplemente llamarlo una semana después para decir, “Oh, fue mi error, no, olvídelo, nunca lo pedimos.” Esos errores van a costar mucho dinero. Se le llama análisis estático porque se trata de analizar un programa sin ejecutarlo. La idea es que tiene un programa escrito con sentencias, palabras clave y todo, y sin siquiera ejecutar este programa, ¿puede ya decir si el programa presenta problemas que casi ciertamente impactarían negativamente su producción, especialmente la producción de supply chain? La respuesta es sí. Estas técnicas existen, y están implementadas y son sumamente valiosas.
Para dar un ejemplo, pueden ver una captura de pantalla de Envision en la pantalla. Envision es un lenguaje de programación específico de dominio que ha sido desarrollado durante casi una década por Lokad y está dedicado a la optimización predictiva de supply chain. Lo que están viendo es una captura de pantalla del editor de código de Envision, una aplicación web que pueden usar en línea para editar código. La sintaxis está fuertemente influenciada por Python. En esta pequeña captura de pantalla, con solo cuatro líneas, estoy ilustrando la idea de que si están escribiendo una gran cantidad de lógica para el reabastecimiento de inventario en un almacén, e introducen algunas variables económicas, como escalas de precios, mediante un análisis lógico del programa, pueden ver que esas escalas de precios no tienen ninguna relación con los resultados finales que retorna el programa, que son las cantidades a reabastecer. Aquí, tienen un problema obvio. Han introducido una variable importante, escalas de precios, y esas escalas de precios lógicamente no tienen influencia en los resultados finales. Así que aquí, nos enfrentamos a un problema que se puede detectar mediante análisis estático. Es un problema evidente porque si introducimos variables en el código que no tienen ningún impacto en el resultado del programa, entonces no cumplen ningún propósito. En este caso, nos enfrentamos a dos opciones: o bien esas variables son realmente código muerto, y el programa no debería compilar (se debería eliminar ese código muerto para reducir la complejidad y no acumular complejidad accidental), o fue un error genuino y existe una variable económica importante que debería haber sido incorporada en su cálculo, pero se pasó por alto debido a la distracción u otra razón.
El análisis estático es absolutamente fundamental para lograr cualquier grado de corrección por diseño. Se trata de arreglar las cosas en tiempo de compilación cuando se escribe el código, incluso antes de tocar los datos. Si surgen problemas cuando se ejecuta, lo más probable es que sus problemas ocurran solo durante la noche, cuando el lote nocturno impulsa el reabastecimiento del almacén. Es probable que el programa se ejecute a horas extrañas cuando nadie lo atiende, por lo que no se desea que algo falle mientras no hay nadie observando el programa. Debería fallar en el momento en que la gente esté realmente escribiendo el código.
El análisis estático tiene muchos propósitos. Por ejemplo, en Lokad, utilizamos el análisis estático para la edición WYSIWYG de dashboards. WYSIWYG significa “lo que ves es lo que obtienes.” Imagina que estás construyendo un dashboard para reportes, con gráficos de líneas, gráficos de barras, tablas, colores y varios efectos de estilo. Quieres poder hacer eso de manera visual, en lugar de ajustar el estilo de tu dashboard a través del código, ya que es muy engorroso. Todas las configuraciones que has implementado se volverán a inyectar en el propio código, y eso se hace mediante análisis estático.
Otro aspecto en Lokad, que puede no ser de tanta importancia para el supply chain en general pero ciertamente crítico para emprender el proyecto, fue lidiar con un lenguaje de programación llamado Envision que estamos desarrollando. Sabíamos desde el primer día, hace casi una década, que se cometerían errores. No contábamos con una bola de cristal para tener la visión perfecta desde el primer día. La pregunta era, ¿cómo podemos asegurarnos de poder corregir esos errores de diseño en el mismo lenguaje de programación de la manera más conveniente posible? Aquí, Python fue una advertencia para mí.
Python, que no es un lenguaje nuevo, se lanzó por primera vez en 1991, hace casi 30 años. La migración de Python 2 a Python 3 tomó a toda la comunidad casi una década, y fue un proceso de pesadilla, muy doloroso para las empresas involucradas en esta migración. Mi percepción fue que el lenguaje en sí no tenía suficientes construcciones. No fue diseñado de manera que se pudieran migrar programas de una versión del lenguaje de programación a otra. De hecho, era extremadamente difícil hacerlo de manera completamente automatizada, y eso se debe a que Python no ha sido desarrollado pensando en el análisis estático. Cuando se tiene un lenguaje de programación para supply chain, realmente se desea uno que tenga una calidad excelente en términos de análisis estático, porque sus programas serán de larga duración. Los supply chains no tienen el lujo de decir, “Espere tres meses; simplemente estamos reescribiendo el código. Espérenos; la caballería viene. Simplemente no va a estar funcionando durante un par de meses.” Es literalmente como arreglar un tren mientras el tren está corriendo a toda velocidad sobre las vías, y quieres arreglar el motor mientras el tren está funcionando. Así es como se ve arreglar cosas de supply chain que están realmente en producción. No se tiene el lujo de simplemente pausar el sistema; nunca se pausa.
El segundo paradigma es la programación con arrays. Queremos tener la complejidad bajo control, ya que ese es un gran tema recurrente en supply chain. Queremos tener una lógica en la que no existan ciertas clases de errores de programación. Por ejemplo, cada vez que se crean bucles o ramas escritos explícitamente por los programadores, se expone a clases enteras de problemas muy difíciles. Se vuelve extremadamente difícil cuando las personas pueden simplemente escribir bucles arbitrarios para tener garantías sobre la duración del cálculo. Aunque pueda parecer un problema de nicho, no es exactamente así en la optimización de supply chain.
En la práctica, supongamos que tienes una cadena minorista. A medianoche, habrán consolidado por completo todas las ventas de toda la red, y los datos serán consolidados y pasados a algún tipo de sistema para optimización. Este sistema tendrá exactamente una ventana de 60 minutos para hacer el forecast, la optimización de inventario y las decisiones de reubicación para cada tienda de la red. Una vez hecho, los resultados se transmitirán al sistema de gestión de almacenes para que puedan comenzar a preparar todos los envíos. Los camiones se cargarán, tal vez a las 5:00 AM, y para las 9:00 AM, las tiendas abrirán con la mercancía ya recibida y colocada en los estantes.
Sin embargo, tienes un tiempo muy estricto, y si tu cálculo se sale de esta ventana de 60 minutos, estarás poniendo en riesgo toda la ejecución de supply chain. No quieres algo en lo que simplemente descubras en producción cuánto tiempo toman las cosas. Si tienes bucles donde las personas pueden decidir cuántas iteraciones van a tener, es muy difícil tener alguna prueba de la duración de tu cálculo. Ten en cuenta que estamos hablando de optimización de supply chain. No tienes el lujo de hacer revisión por pares y verificar todo dos veces. A veces, debido a la pandemia, algunos países están cerrando mientras otros reabren de forma bastante errática, generalmente con un aviso de 24 horas. Necesitas reaccionar rápidamente.
Así que, la programación con arrays es la idea de que puedes operar directamente sobre arrays. Si observamos el fragmento de código que tenemos aquí, este es código de Envision, el DSL de Lokad. Para entender lo que está sucediendo, tienes que entender que cuando escribo “orders.amounts”, lo que aparece es una variable y “orders” es en realidad una tabla en el sentido de una tabla relacional, como en una tabla en tu base de datos. Por ejemplo, aquí en la primera línea, “amounts” sería una columna en la tabla. En la línea uno, lo que estoy haciendo es decir literalmente que para cada línea de la tabla orders, simplemente voy a tomar “quantity”, que es una columna, y multiplicarla por “price”, y luego obtengo una tercera columna que se genera de forma dinámica, que es “amount”.
Por cierto, el término moderno para la programación con arrays hoy en día también se conoce como programación de data frames. El campo de estudio es bastante antiguo; se remonta a tres o cuatro décadas, tal vez incluso cuatro o cinco. Se ha conocido como programación con arrays, incluso si hoy en día la gente generalmente está más familiarizada con la idea de data frames. En la línea dos, lo que estamos haciendo es un filtro, al igual que en SQL. Estamos filtrando las fechas, y resulta que la tabla orders tiene una fecha. Se va a filtrar, y digo “date that is greater than today minus 365”, así que son días. Conservamos los datos del año pasado, y luego escribimos “products.soldLastYear = SUM(orders.amount)”.
Ahora, lo interesante es que tenemos lo que llamamos un natural join entre products y orders. ¿Por qué? Porque cada línea de pedido está asociada con un product y únicamente un product, y un product está asociado con cero o más líneas de pedido. En esta configuración, puedes decir directamente, “quiero calcular algo a nivel de product que sea simplemente una suma de lo que ocurre a nivel de orders”, y eso es exactamente lo que se está haciendo en la línea nueve. Puede que notes que la sintaxis es muy básica; no tienes muchos accidentes o tecnicismos. Sostendría que este código está casi completamente desprovisto de accidentes cuando se trata de programación de data frames. Luego, en las líneas 10, 11 y 12, simplemente estamos mostrando una tabla en nuestro dashboard, lo cual se puede hacer de manera muy conveniente: “LIST(PRODUCTS)”, y luego “TO(products)”.
Hay muchas ventajas de la programación con arrays para supply chains. Primero, elimina clases enteras de problemas. No vas a tener errores de desajuste de índices en tus arrays. Será mucho más fácil paralelizar e incluso distribuir el cálculo. Eso es muy interesante porque significa que puedes escribir un programa y hacer que se ejecute no en una sola máquina local, sino directamente en una flota de máquinas que viven en la nube, y por cierto, esto es exactamente lo que se está haciendo en Lokad. Esta paralelización automática es de altísimo interés.
Verás, la forma en que funciona es que cuando haces optimización de supply chain, tus patrones típicos de consumo en términos de hardware computacional son muy intermitentes. Si retrocedo al ejemplo que estaba dando sobre la ventana de 60 minutos para las redes de retail durante la reposición en tienda, significa que hay una hora al día en la que necesitas potencia de cómputo para realizar todos tus cálculos, pero el resto del tiempo, las otras 23 horas, no la necesitas. Así que lo que quieres es un programa que, cuando estés a punto de ejecutarlo, se distribuya en muchas máquinas y luego, una vez que termine, simplemente libere todas esas máquinas para que otros cálculos puedan realizarse. La alternativa sería tener muchas máquinas que estás rentando y pagando durante todo el día pero solo usándolas el 5% del tiempo, lo cual es muy ineficiente.
Esta idea de que puedes distribuir rápidamente y de manera predecible en muchas máquinas, y luego ceder la potencia de procesamiento, requiere la computación en la nube en un entorno multiinquilino y una serie de otras cosas adicionales que está implementando Lokad. Pero, ante todo, necesita la cooperación del propio lenguaje de programación. Es algo que simplemente no es factible con un lenguaje de programación genérico como Python, porque el lenguaje en sí no se presta a este tipo de enfoque tan inteligente y pertinente. Esto es más que simples trucos; es literalmente dividir los costos de hardware de TI por 20, acelerar masivamente la ejecución y eliminar clases enteras de posibles errores en tu supply chain. Esto cambia las reglas del juego.
La programación con arrays ya existe en muchos aspectos, como en NumPy y pandas en Python, que son tan populares para el segmento de data scientist de la audiencia. Pero la pregunta que tengo para ti es, si es tan importante y útil, ¿por qué estas cosas no son ciudadanos de primera clase del propio lenguaje? Si lo único que haces es canalizar a través de NumPy, entonces NumPy debería ser un ciudadano de primera clase. Diría que se puede llegar incluso más allá que NumPy. NumPy trata solo de la programación con arrays en una máquina, pero ¿por qué no hacer programación con arrays en una flota de máquinas? Es mucho más poderoso y mucho más adecuado cuando tienes una nube con capacidad de hardware accesible.
Entonces, ¿cuál va a ser el cuello de botella en la optimización de supply chain? Existe este dicho de Goldratt que afirma, “Cualquier mejora realizada junto al cuello de botella en un supply chain es una ilusión,” y estoy totalmente de acuerdo con esta afirmación. Realísticamente, cuando queremos hacer optimización de supply chain, el cuello de botella serán las personas, y más específicamente, los Supply Chain Scientist que, desafortunadamente para Lokad y mis clientes, no crecen en los árboles.
El cuello de botella son los Supply Chain Scientist, las personas que pueden elaborar las recetas numéricas que tienen en cuenta todas las estrategias de la empresa, los comportamientos adversos de los competidores, y que convierten toda esta inteligencia en algo mecánico que puede ejecutarse a escala. La tragedia de la manera ingenua de hacer data science, cuando comencé mi doctorado, que por cierto nunca terminé, era que podía ver que todos en el laboratorio literalmente estaban haciendo data science. La mayoría de las personas escribían código para algún tipo de modelo avanzado de machine learning, presionaban enter y luego empezaban a esperar. Si tienes un conjunto de datos grande, digamos de 5-10 gigabytes, no va a ser en tiempo real. Así, el laboratorio entero estaba lleno de personas que escribían unas pocas líneas, presionaban enter, y luego se iban a tomar una taza de café o a leer algo en línea. Por lo tanto, la productividad era sumamente baja.
Cuando creé mi propia empresa, tenía en mente que no quería terminar pagando a un ejército de personas súper inteligentes que pasan la mayor parte de su día tomando café, esperando a que sus programas se completen para poder obtener resultados y seguir adelante. En teoría, podrían paralelizar muchas cosas a la vez y realizar experimentos, pero en la práctica, nunca he visto realmente eso. Intelectualmente, cuando estás comprometido en encontrar una solución para un problema, quieres probar tu hipótesis, y necesitas el resultado para poder continuar. Es muy difícil realizar múltiples tareas en asuntos altamente técnicos y perseguir múltiples líneas intelectuales al mismo tiempo.
Sin embargo, había un lado positivo. Los data scientists, y ahora los Supply Chain Scientist en Lokad, no terminan escribiendo mil líneas de código y luego diciendo “please run.” Usualmente añaden dos líneas a un script que ya tiene mil líneas, y luego solicitan que se ejecute el script. Este script se está ejecutando contra exactamente los mismos datos que acaban de procesar hace unos minutos. Es casi exactamente la misma lógica, salvo por esas dos líneas. Entonces, ¿cómo puedes procesar terabytes de datos en segundos en lugar de varios minutos? La respuesta es: si en la ejecución anterior del script has registrado todos los pasos intermedios del cálculo y los has almacenado (típicamente en discos de estado sólido o SSDs), que son muy baratos, rápidos y convenientes.
La próxima vez que ejecutes tu programa, el sistema notará que es casi el mismo script. Va a hacer una comparación (diff) y verá que, en términos del grafo de cómputo, es casi idéntico, salvo por algunos detalles. En cuanto a los datos, suele ser 100% idéntico. A veces hay algunos cambios, pero casi nada. El sistema diagnosticará automáticamente que solo tienes unas pocas cosas que necesitas calcular, para que puedas obtener los resultados en segundos. Esto puede aumentar de manera dramática la productividad de tu Supply Chain Scientist. Puedes pasar de personas que presionan enter y esperan 20 minutos por el resultado a algo en lo que presionan enter y, 5 o 10 segundos después, tienen el resultado y pueden continuar.
Estoy hablando de algo que puede parecer muy oscuro, pero en la práctica, estamos hablando de algo que tiene un impacto de 10 veces en la productividad. Esto es enorme. Entonces, lo que estamos haciendo aquí es utilizar un truco ingenioso que Lokad no inventó. Estamos sustituyendo un recurso de cómputo bruto, que es el compute, por otro, que es la memoria y el almacenamiento. Tenemos los recursos fundamentales de cómputo: compute, memoria (ya sea volátil o persistente) y ancho de banda. Estos son los recursos fundamentales por los que pagas cuando adquieres recursos en una plataforma de computación en la nube. En realidad, puedes sustituir un recurso por otro, y el objetivo es obtener el mayor rendimiento por tu dinero.
Cuando la gente dice que deberías estar utilizando in-memory computing, yo diría que eso es una tontería. Si dices in-memory computing, significa que estás poniendo un énfasis de diseño en un recurso en lugar de en todos los demás. Pero no, hay compensaciones, y lo interesante es que puedes tener un lenguaje de programación y un entorno que haga que estas compensaciones y perspectivas sean más fáciles de implementar. En un lenguaje de programación de propósito general regular, es posible hacer eso, pero tienes que hacerlo manualmente. Esto significa que la persona que lo hace tiene que ser un ingeniero de software profesional. Un Supply Chain Scientist no va a realizar estas operaciones a bajo nivel con los recursos fundamentales de cómputo de tu plataforma. Esto tiene que estar diseñado a nivel del lenguaje de programación en sí mismo.
Ahora, hablemos de programación probabilística. En la segunda conferencia donde introduje la visión para la Supply Chain Quantitativa, mi primer requisito fue que necesitamos observar todos los futuros posibles. La respuesta técnica a este requisito es probabilistic forecasting. Quieres tratar con futuros en los que tienes probabilidades. Todos los futuros son posibles, pero no son todos igualmente probables. Necesitas tener un álgebra en la que puedas hacer cálculos con incertidumbre. Una de mis grandes críticas a Excel es que es sumamente difícil representar la incertidumbre en una hoja de cálculo, sin importar si es Excel o alguna versión más moderna basada en la nube.
En este pequeño fragmento, estoy ilustrando el álgebra de variables aleatorias, que es una característica nativa de Envision. En la línea uno, estoy generando una distribución de Poisson que es discreta, con una media de 2, y la asigno a la variable X. Luego, hago lo mismo para otra distribución de Poisson, Y. Después, calculo Z como la multiplicación de X por Y. Esta operación, la multiplicación de variables aleatorias, puede parecer muy extraña. ¿Por qué necesitas incluso este tipo de cosas desde una perspectiva de supply chain? Permíteme darte un ejemplo.
Supongamos que estás en el mercado de repuestos automotrices y vendes pastillas de freno. La gente no compra pastillas de freno por unidad; compran dos o cuatro. Entonces, la pregunta es, si quieres hacer un forecast, quizás desees forecast las probabilidades de que los clientes se presenten para comprar un cierto tipo de pastillas de freno. Esa va a ser tu primera variable aleatoria que te da la probabilidad de observar cero unidades de demanda, una unidad de demanda, dos, tres, cuatro, etc. para las pastillas de freno. Luego tendrás otra distribución de probabilidad que representa si la gente va a comprar dos o cuatro pastillas de freno. Tal vez sea 50-50, o tal vez sea 10 por ciento comprando dos y 90 por ciento comprando cuatro. La cuestión es que tienes estos dos ángulos, y si quieres conocer el consumo total real de pastillas de freno, quieres multiplicar la probabilidad de que un cliente se presente para comprar estas pastillas y luego la distribución de probabilidad de comprar dos o cuatro. Así, necesitas hacer esta multiplicación de estas dos cantidades inciertas.
Aquí, estoy asumiendo que las dos variables aleatorias son independientes. Por cierto, esta multiplicación de variables aleatorias se conoce en matemáticas como una convolución discreta. Puedes ver en la captura de pantalla el dashboard generado por Envision. En las primeras tres líneas, estoy realizando este cálculo de álgebra aleatoria, y luego en las líneas cuatro, cinco y seis, estoy mostrando esas cosas en la página web, en el dashboard generado por el script. Estoy trazando A1, B2, por ejemplo, tal como en una cuadrícula de Excel. Los dashboards de Lokad están organizados de manera similar a las cuadrículas de Excel, con posiciones que tienen las columnas B, C, etc., y filas 1, 2, 3, 4, 5.
Puedes ver que la convolución discreta, Z, tiene este patrón muy extraño y con picos pronunciados que, en realidad, se encuentra muy comúnmente en supply chains cuando la gente puede comprar packs, lotes o múltiples unidades. En este tipo de situación, generalmente es mejor descomponer las fuentes de los eventos multiplicativos asociados con el lote o el pack. Necesitas tener un lenguaje de programación que tenga estas capacidades disponibles al alcance de tu mano, como ciudadanos de primera clase. De eso se trata exactamente la programación probabilística, y así es como la implementamos en Envision.
Ahora, discutamos sobre programación diferenciable. Debo poner una advertencia aquí: no espero que la audiencia entienda realmente lo que está pasando, y me disculpo por ello. No es que te falte inteligencia; es solo que este tema merece una serie completa de conferencias. De hecho, si miras el plan de las próximas conferencias, hay toda una serie dedicada a la programación diferenciable. Voy a ir súper rápido, y va a ser bastante críptico, así que me disculpo de antemano.
Procedamos con el problema de supply chain de interés aquí, que es la canibalización y sustitución. Estos problemas son muy interesantes, y probablemente son donde el time series forecast, que es ubicuo, falla de la manera más brutal. ¿Por qué? Porque frecuentemente, tenemos clientes o prospectos que se acercan y me preguntan si podemos hacer, por ejemplo, forecast a 13 semanas para ciertos artículos como mochilas. Diría que sí, podemos, pero obviamente, si tomas una mochila y quieres forecast la demanda para este producto, depende masivamente de lo que estés haciendo con tus otras mochilas. Si solo tienes una mochila, entonces tal vez vayas a concentrar toda la demanda de mochilas en este único producto. Si introduces 10 variantes diferentes, obviamente habrá toneladas de canibalización. No vas a multiplicar el monto total de ventas por un factor de 10 solo porque has multiplicado el número de referencias por 10. Entonces, obviamente, se está produciendo canibalización y sustitución. Estos fenómenos son prevalentes en las supply chains.
¿Cómo analizas la canibalización o sustitución? La forma en que lo hacemos en Lokad, y no pretendo que sea la única manera, pero ciertamente es una forma que funciona, es típicamente observando el grafo que conecta a clientes y productos. ¿Por qué es eso? Porque la canibalización ocurre cuando los productos compiten entre sí por los mismos clientes. La canibalización es literalmente el reflejo de que tienes un cliente con una necesidad, pero con preferencias, y va a elegir un producto entre el conjunto de productos que se ajustan a su afinidad, escogiendo solo uno. Esa es la esencia de la canibalización.
Si quieres analizar eso, necesitas analizar no la serie temporal de las ventas, porque no capturas esa información en primer lugar. Quieres analizar el grafo que conecta las transacciones históricas entre clientes y productos. Resulta que en la mayoría de los negocios, estos datos están fácilmente disponibles. Para ecommerce, eso es un hecho. Por cada unidad que vendes, conoces al cliente. En B2B, es lo mismo. Incluso en B2C en el comercio minorista, la mayoría de las veces, las cadenas minoristas hoy en día tienen programas de loyalty en los que conocen un porcentaje de dos dígitos de los clientes que se presentan con sus tarjetas, así que sabes quién compra qué. No para el 100% del tráfico, pero no necesitas eso. Si tienes el 10% o más de tus transacciones históricas donde conoces el par cliente-producto, es suficiente para este tipo de análisis.
En este fragmento relativamente pequeño, voy a detallar un análisis de afinidad entre clientes y productos. Ese es literalmente el paso fundamental que necesitas para realizar cualquier tipo de análisis de canibalización. Echemos un vistazo a lo que está sucediendo en este código.
Desde las líneas uno a cinco, esto es muy mundano; simplemente estoy leyendo un archivo plano que contiene un historial de transacciones. Solo estoy leyendo un archivo CSV que tiene cuatro columnas: fecha, producto, cliente y cantidad. Algo muy básico. Ni siquiera uso todas esas columnas, sino solo para hacer el ejemplo un poco más concreto. En el historial de transacciones, asumo que los clientes son conocidos para todas esas transacciones. Así que, es muy mundano; simplemente estoy leyendo datos de una tabla.
Luego, en las líneas siete y ocho, simplemente estoy creando la tabla para productos y la tabla para clientes. En una configuración de producción real, normalmente no crearía esas tablas; las leería de otros archivos planos en otro lugar. Quería mantener el ejemplo súper simple, así que simplemente estoy extrayendo una tabla de productos de los productos que observé en el historial de transacciones, y hago lo mismo para los clientes. Verás, es solo un truco para mantenerlo súper simple.
Ahora, las líneas 10, 11 y 12 involucran espacios latinos, y esto se va a volver un poco más oscuro. Primero, en la línea 10, estoy creando una tabla con 64 líneas. La tabla no contiene nada; está definida únicamente por el hecho de que tiene 64 líneas, y eso es todo. Así que, esto es como un marcador de posición, una tabla trivial con muchas líneas y sin columnas. No es tan útil solo así. Luego, “P” es básicamente un producto cartesiano, una operación matemática con todos los pares. Es una tabla en la que tienes una línea por cada línea en los productos y cada línea en la tabla “L”. Entonces, esta tabla “P” tiene 64 líneas más que la tabla de productos, y estoy haciendo lo mismo para los clientes. Simplemente estoy inflando esas tablas a través de esta dimensión extra, que es esta tabla “L”.
Esto será mi soporte para mis espacios latinos, que es exactamente lo que voy a aprender. Lo que quiero aprender es, para cada producto, un espacio latino que será un vector de 64 valores, y para cada cliente, un espacio latino de 64 valores también. Si quiero conocer la afinidad entre un cliente y un producto, solo quiero poder hacer el producto punto entre los dos. El producto punto es simplemente la multiplicación término a término de todos los elementos de esos dos vectores, y luego se suma. Puede sonar muy técnico, pero es solo multiplicación término a término más suma – ese es el producto punto.
Estos espacios latinos son solo una jerga elegante para crear un espacio con parámetros que son algo inventados, que es lo que quiero aprender. Toda la magia de la programación diferenciable ocurre en solo cinco líneas, desde la línea 14 hasta la 18. Tengo una palabra clave, “autodiff”, y “transactions”, que indica que esta es una tabla de interés, una tabla de observaciones. Voy a procesar esta tabla línea por línea para realizar mi proceso de aprendizaje. En este bloque, estoy declarando un conjunto de parámetros. Los parámetros son las cosas que quieres aprender, como números, pero aún no conoces los valores. Esas cosas se van a inicializar aleatoriamente, con números aleatorios.
Introduzco “X”, “X*” y “Y”. No voy a profundizar en lo que exactamente hace “X*”; tal vez en las preguntas. Estoy devolviendo una expresión que es mi función de pérdida, y esa es la suma. La idea del collaborative filtering o la descomposición de matrices es simplemente que quieres aprender espacios latinos que se ajusten a todos tus enlaces en tu grafo bipartito. Sé que es un poco técnico, pero lo que estamos haciendo es literalmente muy simple, en términos de supply chain. Estamos aprendiendo la afinidad entre productos y clientes.
Sé que probablemente parezca súper opaco, pero quédate conmigo, y habrá más conferencias en las que te daré una introducción más reflexiva al respecto. Todo se hace en cinco líneas, y eso es completamente notable. Cuando digo cinco líneas, no estoy haciendo trampa al decir: “Mira, son solo cinco líneas, pero en realidad estoy llamando a una biblioteca de terceros de complejidad gigantesca donde estoy ocultando toda la inteligencia.” No, no, no. Aquí, en este ejemplo, literalmente no hay magia de machine learning aparte de las dos palabras clave “autodiff” y “params”. “Autodiff” se usa para definir un bloque donde tendrá lugar la programación diferenciable, y por cierto, este es un bloque donde puedo programar cualquier cosa, así que literalmente, puedo inyectar nuestro programa. Luego, tengo “params” para declarar mis problemas, y eso es todo. Así que, ya ves, no hay magia opaca en marcha; no hay una biblioteca de un millón de líneas en el fondo haciendo todo el trabajo por ti. Todo lo que necesitas saber está literalmente en esta pantalla, y esa es la diferencia entre un paradigma de programación y una biblioteca. El paradigma de programación te da acceso a capacidades aparentemente increíblemente sofisticadas, como realizar análisis de canibalización con solo unas pocas líneas de código, sin recurrir a bibliotecas de terceros masivas que envuelven la complejidad. Transciende el problema, haciéndolo mucho más simple, para que puedas tener algo que parece súper complicado resuelto en solo unas pocas líneas.
Ahora, unas palabras sobre cómo funciona la programación diferenciable. Hay dos ideas principales. Una es la diferenciación automática. Para aquellos de ustedes que han tenido el lujo de una formación en ingeniería, han visto dos formas de calcular derivadas. Existe la derivada simbólica, por ejemplo, si tienes x al cuadrado, calculas la derivada respecto a x, y te da 2x. Esa es la derivada simbólica. Luego tienes la derivada numérica, así que si tienes una función f(x) que deseas diferenciar, será f’(x) ≈ (f(x + ε) - f(x))/ε. Esa es la derivación numérica. Ninguna de las dos es adecuada para lo que intentamos hacer aquí. La derivación simbólica tiene problemas de complejidad, ya que tu derivada podría ser un programa mucho más complejo que el programa original. La derivación numérica es numéricamente inestable, por lo que tendrás muchos problemas con la estabilidad numérica.
La diferenciación automática es una idea fantástica que data de los años 70 y fue redescubierta por el mundo en general en la última década. Es la idea de que puedes calcular la derivada de un programa informático arbitrario, lo cual es asombroso. Aún más asombroso, el programa que es la derivada tiene la misma complejidad computacional que el programa original, lo cual es impresionante. La programación diferenciable es simplemente una combinación de diferenciación automática y parámetros que deseas aprender.
Entonces, ¿cómo aprendes? Cuando tienes la derivación, significa que puedes propagar los gradientes, y con el descenso por gradiente estocástico, puedes hacer pequeños ajustes a los valores de los parámetros. Ajustando esos parámetros, de manera incremental, a lo largo de muchas iteraciones de descenso por gradiente estocástico, convergerás a parámetros que tengan sentido y logren lo que deseas aprender u optimizar.
La programación diferenciable puede utilizarse para problemas de aprendizaje, como el que estoy ilustrando, donde quiero aprender la afinidad entre mis clientes y mis productos. También puede utilizarse para problemas de optimización numérica, como optimizar cosas bajo restricciones, y es muy escalable como paradigma. Como puedes ver, este aspecto se ha convertido en un ciudadano de primera clase en Envision. Por cierto, todavía hay algunas cosas que están en progreso en términos de sintaxis de Envision, así que no esperes exactamente esas cosas aún; aún estamos refinando algunos aspectos. Pero la esencia está ahí. No voy a discutir los detalles mínimos de las pocas cosas que aún están evolucionando.
Ahora pasemos a otro problema relevante para la preparación de la producción de tu configuración. Típicamente, en la optimización de la supply chain te enfrentas a Heisenbugs. ¿Qué es un Heisenbug? Es un tipo de error frustrante en el que se realiza una optimización y se producen resultados basura. Por ejemplo, tuviste un cálculo por lotes para el reabastecimiento de inventario durante la noche, y en la mañana descubres que algunos de esos resultados eran un sinsentido, causando errores costosos. No quieres que el problema vuelva a suceder, así que vuelves a ejecutar tu proceso. Sin embargo, cuando vuelves a ejecutar el proceso, el problema ha desaparecido. No puedes reproducir la falla, y el Heisenbug no se manifiesta.
Puede sonar como un caso límite extraño, pero en los primeros años de Lokad, nos enfrentamos a estos problemas de forma repetida. He visto muchas iniciativas de supply chain, especialmente del tipo data science, fracasar debido a Heisenbugs no resueltos. Tenían errores ocurriendo en producción, intentaron reproducir los problemas localmente pero no pudieron, por lo que los problemas nunca se solucionaron. Después de un par de meses en modo pánico, el proyecto entero generalmente se cerraba en silencio, y la gente volvía a usar hojas de cálculo de Excel.
Si quieres lograr una replicabilidad completa de tu lógica, necesitas versionar el código y los datos. La mayoría de las personas en la audiencia que son ingenieros de software o data scientists pueden estar familiarizados con la idea de versionar el código. Sin embargo, también quieres versionar todos los datos para que, cuando tu programa se ejecute, sepas exactamente qué versión del código y de los datos se está utilizando. Puede que no puedas replicar el problema al día siguiente porque los datos han cambiado debido a nuevas transacciones u otros factores, por lo que las condiciones que desencadenaron el error en primer lugar ya no están presentes.
Quieres asegurarte de que tu entorno de programación pueda replicar exactamente la lógica y los datos tal como estaban en producción en un momento específico. Esto requiere la versionación completa de todo. Nuevamente, el lenguaje de programación y el stack de programación tienen que cooperar para hacer esto posible. Es alcanzable sin que el paradigma de programación sea un ciudadano de primera clase en tu stack, pero entonces el Supply Chain Scientist debe ser sumamente cuidadoso con todas las cosas que hace y la forma en que programa. De lo contrario, no podrá replicar sus resultados. Esto pone una presión inmensa sobre los hombros de los Supply Chain Scientists, quienes ya están bajo una presión significativa por la propia supply chain. No quieres que estos profesionales tengan que lidiar con una complejidad accidental, como no poder replicar sus propios resultados. En Lokad, llamamos a esto una “time machine” donde puedes replicar todo en cualquier punto del pasado.
Cuidado, no se trata solo de replicar lo que sucedió anoche. A veces, descubres un error mucho tiempo después. Por ejemplo, si realizas una orden de compra con un proveedor que tiene un tiempo de entrega de tres meses, puede que descubras tres meses después que la orden era un sinsentido. Necesitas retroceder tres meses en el tiempo hasta el punto donde generaste esta orden de compra falsa para averiguar cuál fue el problema. No se trata de versionar solo las últimas horas de trabajo; literalmente se trata de tener un historial completo del último año de ejecución.
Otra preocupación es el aumento del ransomware y los ciberataques en las supply chains. Estos ataques son enormemente disruptivos y pueden ser muy costosos. Al implementar soluciones impulsadas por software, necesitas considerar si estás haciendo que tu empresa y tu supply chain sean más vulnerables a ciberataques y riesgos. Desde esta perspectiva, Excel y Python no son ideales. Estos componentes son programables, lo que significa que pueden tener numerosas vulnerabilidades de seguridad.
Si tienes un equipo de data scientists o supply chain scientists que se ocupan de problemas de supply chain, no pueden permitirse el cuidadoso e iterativo proceso de revisión por pares del código que es común en la industria del software. Si una tarifa cambia de la noche a la mañana o un almacén se inunda, necesitas una respuesta rápida. No puedes pasar semanas produciendo especificaciones de código, revisiones y demás. El problema es que estás dando capacidades de programación a personas que, por defecto, tienen el potencial de causar daño a la empresa de manera accidental. Puede ser incluso peor si hay un empleado pícaro de forma intencionada, pero dejando eso de lado, sigues teniendo el problema de que alguien exponga accidentalmente una parte interna de los sistemas informáticos. Recuerda, los sistemas de optimización de supply chain, por definición, tienen acceso a una gran cantidad de datos a lo largo de toda la empresa. Estos datos no son solo un activo, sino también un pasivo.
Lo que quieres es un paradigma de programación que promueva una programación segura. Quieres un lenguaje de programación en el que existan clases enteras de cosas que no se pueden hacer. Por ejemplo, ¿por qué deberías tener un lenguaje de programación que pueda hacer llamadas al sistema para propósitos de optimización de supply chain? Python puede hacer llamadas al sistema, y Excel también. Pero, ¿por qué querrías un sistema programable con tales capacidades en primer lugar? Es como comprar una pistola para dispararte en el pie.
Quieres algo en lo que clases enteras o características estén ausentes porque no las necesitas para la optimización de supply chain. Si estas características están presentes, se convierten en un pasivo masivo. Si introduces capacidades programables sin las herramientas que obligan a una programación segura por diseño, aumentas el riesgo de ciberataques y ransomware, empeorando la situación.
Por supuesto, siempre es posible compensar duplicando el tamaño del equipo de ciberseguridad, pero eso es muy costoso y no es ideal al enfrentar situaciones urgentes de supply chain. Necesitas actuar de manera rápida y segura, sin el tiempo para los procesos, revisiones y aprobaciones habituales. También deseas una programación segura que elimine problemas mundanos como excepciones de referencia nula, errores de falta de memoria, bucles off-by-one y efectos secundarios.
En conclusión, las herramientas importan. Existe un refrán: “No lleves una espada a un tiroteo.” Necesitas las herramientas y paradigmas de programación adecuados, no solo los que aprendiste en la universidad. Necesitas algo profesional y de nivel de producción para satisfacer las necesidades de tu supply chain. Aunque quizás puedas lograr algunos resultados con herramientas de baja calidad, no serán grandiosos. Un músico fantástico puede hacer música solo con una cuchara, pero con un instrumento adecuado, puede hacerlo mucho mejor.
Ahora, procedamos con las preguntas. Tengan en cuenta que hay un retraso de alrededor de 20 segundos, por lo que existe cierta latencia en la transmisión entre el vídeo que están viendo y yo leyendo sus preguntas.
Pregunta: ¿Qué hay de la programación dinámica en términos de investigación de operaciones?
La programación dinámica, a pesar del nombre, no es un paradigma de programación. Es más una técnica algorítmica. La idea es que si quieres realizar una tarea algorítmica o resolver cierto problema, repetirás la misma suboperación con mucha frecuencia. La programación dinámica es un caso específico del compromiso espacio-tiempo que mencioné anteriormente, donde inviertes un poco más en memoria para ahorrar tiempo en el cómputo. Fue una de las primeras técnicas algorítmicas, que se remonta a los años 60 y 70. Es buena, pero el nombre es algo desafortunado porque no hay nada realmente dinámico en ella, y no se trata realmente de programación. Es más sobre la concepción de los algoritmos. Así que, para mí, a pesar del nombre, no califica como un paradigma de programación; es más una técnica algorítmica específica.
Pregunta: Johannes, ¿podrías por favor proporcionar algunos libros de referencia que todo buen ingeniero de supply chain debería tener? Lamentablemente, soy nuevo en el área, y mi enfoque actual es data science y system engineering.
Tengo una opinión muy mixta sobre la literatura existente. En mi primera conferencia, presenté dos libros que considero el pináculo de los estudios académicos sobre supply chain. Si quieres leer dos libros, puedes leer esos libros. Sin embargo, tengo un problema constante con los libros que he leído hasta ahora. Básicamente, hay personas que presentan colecciones de recetas numéricas de juguete para supply chains idealizadas, y creo que estos libros no abordan el supply chain desde el ángulo adecuado, y pierden completamente el punto de que se trata de un problema complejo. Existe un extenso cuerpo de literatura muy técnica, con ecuaciones, algoritmos, teoremas y demostraciones, pero creo que pierde totalmente el objetivo.
Luego, tienes otro estilo de libros de gestión de supply chain, que son más del estilo consultor. Puedes reconocer fácilmente estos libros porque usan analogías deportivas cada dos páginas. Estos libros tienen todo tipo de diagramas simplistas, como variantes 2x2 del análisis SWOT (Strengths, Weaknesses, Opportunities, Threats), que considero formas de razonamiento de baja calidad. El problema con estos libros es que tienden a entender mejor que el supply chain es una empresa complicada. Entienden mucho mejor que es un juego jugado por personas, donde pueden suceder todo tipo de cosas bizarras, y se puede ser inteligente en cuanto a enfoques. Les reconozco el mérito por ello. El problema con esos libros, típicamente escritos por consultores o profesores de escuelas de gestión, es que no son muy accionables. El mensaje se reduce a “sé un mejor líder”, “sé más inteligente”, “ten más energía,” y para mí, esto no es accionable. No te da elementos que puedas convertir en algo de alto valor, como sí puede hacerlo el software.
Así que, vuelvo a la primera conferencia: lee los dos libros si quieres, pero no estoy seguro de que sea tiempo bien empleado. Es bueno saber lo que la gente ha escrito. En el lado consultor de la literatura, mi favorito es probablemente el trabajo de Katana, que no listé en la primera conferencia. No todo es malo; algunas personas tienen más talento, aunque sean más “consultant-ish”. Puedes revisar el trabajo de Katana; tiene un libro sobre dynamic supply chains. Incluiré el libro en las referencias.
Pregunta: ¿Cómo utilizas la paralelización al abordar decisiones de cannibalización o de assortment, donde el problema no se puede paralelizar fácilmente?
¿Por qué no se puede paralelizar fácilmente? El stochastic gradient descent es bastante trivial de paralelizar. Tienes pasos de stochastic gradient que pueden tomarse en órdenes aleatorios, y puedes tener múltiples pasos al mismo tiempo. Así que, creo que cualquier cosa impulsada por stochastic gradient descent es bastante trivial de paralelizar.
Al tratar con la cannibalización, lo más difícil es abordar otro tipo de paralelización, que es determinar qué viene primero. Si coloco este producto primero, luego hago un forecast, pero luego tomo otro producto, se modifica el panorama. La respuesta es que quieres tener una forma de abordar el panorama en su totalidad de manera frontal. No dices, “Primero, introduzco este producto y hago el forecast; luego introduzco otro producto y rehago el forecast, modificando el primero.” Simplemente lo haces de manera frontal, todo eso a la vez, simultáneamente. Necesitas más paradigmas de programación. Los paradigmas de programación que he introducido hoy pueden servir mucho para ello.
En lo que respecta a las decisiones de assortment, este tipo de problemas no presenta mayores dificultades para la paralelización. Lo mismo se aplica si tienes una red minorista mundial, y quieres optimizar el assortment para todas tus tiendas. Puedes tener cálculos que ocurran en todas las tiendas en paralelo. No quieres hacerlo en secuencia, donde optimizas el assortment de una tienda y luego pasas a la siguiente. Esa es la forma incorrecta de hacerlo, pero puedes optimizar la red en paralelo, propagar toda la información y luego repetir. Existen todo tipo de técnicas, y las herramientas pueden ayudarte enormemente a hacerlo de maneras mucho más sencillas.
Pregunta: ¿Estás utilizando un enfoque de base de datos gráfica?
No, no en el sentido técnico y canónico. Existen muchas bases de datos gráficas en el mercado que son de gran interés. Lo que estamos usando internamente en Lokad es una integración vertical completa a través de una pila de compilador monolítica y unificada para eliminar completamente todos los elementos tradicionales que encontrarías en una pila clásica. Así es como logramos un muy buen rendimiento, en términos de rendimiento de cómputo, muy cerca del metal. No porque seamos codificadores sorprendemente inteligentes, sino simplemente porque hemos eliminado prácticamente todas las capas que tradicionalmente existen. Lokad no utiliza literalmente ninguna base de datos. Tenemos un compilador que se encarga de todo, hasta la organización de las estructuras de datos para la persistencia. Es un poco raro, pero es mucho más eficiente hacerlo de esta manera, y de esta forma, se integra mucho mejor con el hecho de que compilas un script para una flota de máquinas en la cloud. Tu plataforma objetivo, en términos de hardware, no es una sola máquina; es una flota de máquinas.
Pregunta: ¿Cuál es tu opinión sobre Power BI, que también ejecuta códigos Python y algoritmos relacionados como gradient descent, greedy, etc.?
El problema que tengo con cualquier cosa relacionada con business intelligence, Power BI siendo uno de ellos, es que tiene un paradigma que considero inadecuado para supply chain. Ves todos los problemas como un hipercubo, donde tienes dimensiones que solo se cortan y segmentan. En el fondo, tienes un problema de expresividad, que es muy limitante. Cuando terminas usando Power BI con Python en medio, necesitas Python porque la expresividad relacionada con el hipercubo es muy pobre. Para recuperar expresividad, añades Python en medio. Sin embargo, recuerda lo que dije en la pregunta anterior sobre esas capas: la maldición del moderno enterprise software es que tienes demasiadas capas. Cada capa que añades va a introducir ineficiencias y errores. Si usas Power BI más Python, vas a terminar con demasiadas capas. Así que, tienes Power BI que se asienta sobre otros sistemas, lo que significa que ya tienes múltiples sistemas antes de Power BI. Luego tienes Power BI encima, y sobre Power BI, tienes Python. ¿Pero está Python actuando por sí solo? No, lo más probable es que vayas a usar librerías de Python, como Pandas o NumPy. Así, tienes capas en Python que se acumularán y terminas con docenas de capas. Puedes tener errores en cualquiera de esas capas, por lo que la situación será bastante desastrosa.
No soy partidario de aquellas soluciones en las que terminas teniendo una cantidad masiva de stacks. Existe una broma que en C++ siempre puedes resolver cualquier problema añadiendo una capa más de indirección, incluso el problema de tener demasiadas capas de indirección. Obviamente, esto es algo absurdo como afirmación, pero discrepo profundamente del enfoque en el que las personas tienen un producto con un diseño central inadecuado, y en lugar de abordar el problema de manera frontal, terminan añadiendo cosas encima mientras los cimientos están inestables. Esta no es la manera de hacerlo, y vas a tener una pobre productividad, batallas constantes con errores que nunca vas a resolver, y luego, en términos de mantenibilidad, es simplemente una receta para una pesadilla.
Pregunta: ¿Cómo se pueden integrar los resultados de un análisis de filtrado colaborativo en el algoritmo de demand prediction para cada producto, como por ejemplo las mochilas?
Lo siento, pero abordaré este tema en la próxima conferencia. La respuesta corta es que no quieres integrar eso en un algoritmo de predicción existente. Quieres tener algo que esté mucho más integrado de forma nativa. No haces eso y luego vuelves a tus viejas formas de hacer forecasting; en su lugar, simplemente descartas la antigua forma de hacer el forecast y haces algo radicalmente diferente que lo aproveche. Pero lo discutiré en una conferencia posterior. Sería demasiado para hoy.
Supongo que esto es todo por esta conferencia. Muchas gracias a todos por asistir. La próxima conferencia será el miércoles 6 de enero, a la misma hora y el mismo día de la semana. Me tomaré unas vacaciones de Navidad, así que les deseo a todos una feliz Navidad y un próspero Año Nuevo. Continuaremos nuestra serie de conferencias el próximo año. Muchas gracias.
