00:18 Introducción
02:18 Antecedentes
12:08 ¿Por qué optimizar? 1/2 Pronóstico con Holt-Winters
17:32 ¿Por qué optimizar? 2/2 - Problema de enrutamiento de vehículos
20:49 La historia hasta ahora
22:21 Ciencias auxiliares (recapitulación)
23:45 Problemas y soluciones (recapitulación)
27:12 Optimización matemática
28:09 Convexidad
34:42 Estocasticidad
42:10 Multiobjetivo
46:01 Diseño del solucionador
50:46 Lecciones profundas (de aprendizaje)
01:10:35 Optimización matemática
01:10:58 “Verdadera” programación
01:12:40 Búsqueda local
01:19:10 Descenso de gradiente estocástico
01:26:09 Diferenciación automática
01:31:54 Programación diferencial (circa 2018)
01:35:36 Conclusión
01:37:44 Próxima clase y preguntas del público
Descripción
La optimización matemática es el proceso de minimizar una función matemática. Casi todas las técnicas modernas de aprendizaje estadístico, es decir, el pronóstico si adoptamos una perspectiva de cadena de suministro, se basan en la optimización matemática en su núcleo. Además, una vez que se establecen los pronósticos, identificar las decisiones más rentables también depende, en su núcleo, de la optimización matemática. Los problemas de la cadena de suministro suelen involucrar muchas variables. También suelen ser estocásticos por naturaleza. La optimización matemática es un pilar fundamental de la práctica moderna de la cadena de suministro.
Transcripción completa
Bienvenidos a esta serie de clases sobre cadena de suministro. Soy Joannes Vermorel y hoy presentaré “Optimización Matemática para la Cadena de Suministro”. La optimización matemática es la forma bien definida, formalizada y computacionalmente tratable de identificar la mejor solución para un problema dado. Todos los problemas de pronóstico se pueden ver como problemas de optimización matemática. Todas las situaciones de toma de decisiones en la cadena de suministro y fuera de ella también se pueden ver como problemas de optimización matemática. De hecho, la perspectiva de optimización matemática está tan arraigada en nuestra visión moderna del mundo que se ha vuelto muy difícil definir el verbo “optimizar” fuera de la pequeña caja que nos da el paradigma de optimización matemática.
Ahora bien, la literatura científica sobre optimización matemática es vasta, al igual que el ecosistema de software que ofrece herramientas para la optimización matemática. Desafortunadamente, la mayoría de ella tiene muy poco uso y relevancia en lo que respecta a la cadena de suministro. El objetivo de esta clase será doble: primero, queremos entender cómo abordar la optimización matemática para obtener algo que sea valioso y de utilidad práctica desde la perspectiva de la cadena de suministro. El segundo elemento será identificar, en este vasto panorama, algunos de los elementos más valiosos que se pueden encontrar.
La definición formal de optimización matemática es sencilla: se piensa en una función que típicamente se llamará la función de pérdida, y esta función será de valores reales, por lo que produce solo números. Lo que se desea es identificar la entrada (X0) que representa el mejor valor que minimiza la función de pérdida. Este es típicamente el paradigma de optimización matemática, y es engañosamente simple. Veremos que hay muchas cosas que se pueden decir sobre esta perspectiva general.
Creo que este campo, cuando pensamos en términos de optimización matemática aplicada, se desarrolló principalmente bajo el nombre de investigación operativa, que definimos de manera más específica como la investigación operativa clásica que se llevó a cabo desde la década de 1940 hasta finales de la década de 1970 en el siglo XX. La idea es que la investigación operativa clásica, en comparación con la optimización matemática, realmente se preocupaba por los problemas empresariales. La optimización matemática se preocupa por la forma general del problema de optimización, mucho menos por si el problema tiene algún tipo de importancia empresarial. Por el contrario, la investigación operativa clásica estaba haciendo principalmente optimización, pero no en cualquier tipo de problemas, sino en problemas que se identificaron como importantes para las empresas.
Curiosamente, pasamos de la investigación operativa a la optimización matemática de la misma manera en que pasamos del pronóstico, que surgió a principios del siglo XX como un campo preocupado por el pronóstico general de los niveles futuros de actividad económica, típicamente asociado con pronósticos de series de tiempo. Este dominio fue esencialmente reemplazado por el aprendizaje automático, que se preocupaba más ampliamente por hacer predicciones en un ámbito mucho más amplio de problemas. Podríamos decir que hemos tenido una transición similar de la investigación operativa a la optimización matemática como la que hubo del pronóstico al aprendizaje automático. Ahora, cuando dije que la era clásica de la investigación operativa llegó hasta finales de los años 70, tenía una fecha muy específica en mente. En febrero de 1979, Russell Ackoff publicó un impresionante artículo titulado “El futuro de la investigación operativa es pasado”. Para entender este artículo, que creo que es realmente un hito en la historia de la ciencia de la optimización, hay que entender que Russell Ackoff es uno de los padres fundadores de la investigación operativa.
Cuando publicó este artículo, ya no era un hombre joven; tenía 60 años. Ackoff nació en 1919 y había pasado prácticamente toda su carrera trabajando en investigación operativa. Cuando publicó su artículo, básicamente afirmó que la investigación operativa había fracasado. No solo no entregó resultados, sino que el interés en la industria estaba disminuyendo, por lo que había menos interés a fines de los años 90 que en el campo hace 20 años.
Lo interesante de entender es que la causa no es absolutamente el hecho de que las computadoras en ese momento fueran mucho más débiles que las que tenemos hoy en día. El problema no tiene nada que ver con la limitación en términos de potencia de procesamiento. Esto es a fines de los años 70; las computadoras son muy modestas en comparación con lo que tenemos hoy en día, pero aún pueden realizar millones de operaciones aritméticas en un tiempo razonable. El problema no está relacionado con la limitación de la potencia de procesamiento, especialmente en un momento en el que la potencia de procesamiento está progresando increíblemente rápido.
Por cierto, este artículo es una lectura fantástica. Realmente sugiero a la audiencia que le eche un vistazo; puedes encontrarlo fácilmente con tu motor de búsqueda favorito. Este artículo es muy accesible y está bien escrito. Aunque los problemas que Ackoff señala en este artículo todavía resuenan muy fuertemente cuatro décadas después, de muchas maneras, el artículo es muy visionario en muchos de los problemas que todavía aquejan a las cadenas de suministro actuales.
Entonces, ¿cuál es el problema entonces? El problema es que este paradigma, donde tomas una función y la optimizas, puedes demostrar que tu proceso de optimización identifica alguna solución buena o tal vez óptima. Sin embargo, ¿cómo demuestras que la función de pérdida que estás optimizando tiene algún interés para el negocio? El problema es que cuando digo que podemos optimizar un problema o una función determinada, ¿qué pasa si lo que estás optimizando es en realidad una fantasía? ¿Qué pasa si esto no tiene nada que ver con la realidad del negocio que estás tratando de optimizar?
Aquí radica la raíz del problema, y aquí radica la razón por la cual esos primeros intentos esencialmente fracasaron. Es porque resultó que cuando inventas algún tipo de expresión matemática que se supone que representa el interés del negocio, lo que obtienes es una fantasía matemática. Eso es literalmente lo que Russell Ackoff señala en este artículo, y él está en un punto de su carrera en el que ha estado jugando este juego durante mucho tiempo y reconoce que esencialmente no lleva a ninguna parte. En su artículo, comparte la opinión de que el campo ha fracasado y propone su diagnóstico, pero no tiene mucho que ofrecer en cuanto a soluciones. Es muy interesante porque uno de los padres fundadores, un investigador muy respetado y reconocido, dice que todo este campo de investigación es un callejón sin salida. Pasará el resto de su vida, que todavía es bastante largo, transitando completamente desde una perspectiva cuantitativa de optimización empresarial hacia una perspectiva cualitativa. Pasará las últimas tres décadas de su vida adoptando métodos cualitativos y aún producirá trabajos muy interesantes en la segunda parte de su vida después de este punto de inflexión.
Ahora, en lo que respecta a esta serie de conferencias, ¿qué hacemos porque los puntos que Russell Ackoff plantea sobre la investigación operativa siguen siendo muy válidos hoy en día? De hecho, ya he comenzado a abordar los mayores problemas que Ackoff señalaba, y en ese momento, él y sus colegas no tenían soluciones que ofrecer. Podían diagnosticar el problema, pero no tenían una solución. En esta serie de conferencias, las soluciones que propongo son de naturaleza metodológica, al igual que el hecho de que Ackoff señala que hay un problema metodológico profundo con esta perspectiva de investigación operativa.
Los métodos que propongo son esencialmente de dos tipos: por un lado, el personal de la cadena de suministro, y por otro lado, el método titulado optimización experimental que resulta ser realmente complementario a la optimización matemática. Además, a diferencia de la investigación operativa que afirma ser de interés o relevancia empresarial, la forma en que abordo el problema hoy no es a través del ángulo o las lentes de la investigación operativa. Estoy abordando el problema a través de las lentes de la optimización matemática, que posiciono como una ciencia auxiliar pura para la cadena de suministro. Digo que no hay nada intrínsecamente fundamental en la optimización matemática para la cadena de suministro; es solo de interés fundamental. Es solo un medio, no un fin. Ahí es donde difiere. El punto puede ser muy simple, pero tiene una gran importancia cuando se trata de lograr resultados de calidad de predicción con todo esto.
Ahora, ¿por qué queremos optimizar en primer lugar? La mayoría de los algoritmos de pronóstico tienen un problema de optimización matemática en su núcleo. En esta pantalla, lo que puedes ver es el algoritmo clásico de pronóstico de series de tiempo Holt-Winters multiplicativo. Este algoritmo es principalmente de interés histórico; no recomendaría a ninguna cadena de suministro actual que realmente aproveche este algoritmo específico. Pero por simplicidad, este es un método paramétrico muy simple y tan conciso que puedes ponerlo completamente en una pantalla. Ni siquiera es tan verboso.
Todas las variables que puedes ver en la pantalla son solo números simples; no hay vectores involucrados. Esencialmente, Y(t) es tu estimación; este es tu pronóstico de series de tiempo. Aquí en la pantalla, se pronosticará H períodos hacia adelante, por lo que H es como el horizonte. Y puedes pensar que estás trabajando en Y(t), que es esencialmente tu serie de tiempo. Puedes pensar en datos de ventas agregados semanalmente o datos de ventas agregados mensualmente. Este modelo tiene tres componentes: tiene Lt, que es el nivel (tienes un nivel por período), Bt, que es la tendencia, y St, que es un componente estacional. Cuando dices que quieres aprender el modelo Holt-Winters, tienes tres parámetros: alfa, beta y gamma. Estos tres parámetros son esencialmente solo números entre cero y uno. Entonces, tienes tres parámetros, todos números entre cero y uno, y cuando dices que quieres aplicar el algoritmo Holt-Winters, simplemente significa que identificarás los valores adecuados para esos tres parámetros, y eso es todo. La idea es que estos parámetros, alfa, beta y gamma, serán los mejores si minimizan el tipo de error que has especificado para tu pronóstico. En esta pantalla, puedes ver un error cuadrático medio, que es muy clásico.
El punto sobre la optimización matemática es idear un método para hacer esta identificación de los valores adecuados para alfa, beta y gamma. ¿Qué podemos hacer? Bueno, el método más fácil y simplista es algo como la búsqueda en cuadrícula. La búsqueda en cuadrícula diría que simplemente vamos a explorar todos los valores. Debido a que estos son números fraccionarios, hay un número infinito de valores, por lo que en realidad vamos a elegir una resolución, digamos pasos de 0.1, y avanzaremos en incrementos de 0.1. Dado que tenemos tres variables entre 0 y 1, avanzamos en incrementos de 0.1; eso son alrededor de 1,000 iteraciones para recorrer e identificar el mejor valor, considerando esta resolución.
Sin embargo, esta resolución es bastante débil. 0.1 te da una resolución del 10% en el tipo de escala que tienes para tus parámetros. Entonces, tal vez quieras ir por 0.01, que es mucho mejor; eso es una resolución del 1%. Sin embargo, si haces eso, el número de combinaciones realmente explota. Pasas de 1,000 combinaciones a un millón de combinaciones, y ves que ese es el problema con la búsqueda en cuadrícula: muy rápidamente, te encuentras con una barrera combinatoria y tienes un número enorme de opciones.
La optimización matemática se trata de idear algoritmos que te den más beneficios por tu inversión en recursos informáticos que deseas dedicar al problema. ¿Puedes obtener una solución mucho mejor que una simple búsqueda exhaustiva? La respuesta es sí, absolutamente.
Entonces, ¿qué podemos hacer en este caso para obtener una mejor solución invirtiendo menos recursos computacionales? Primero, podríamos usar algún tipo de gradiente. Toda la expresión para Holt-Winters es completamente diferenciable, excepto por una única división que es un caso especial muy pequeño y relativamente fácil de manejar. Entonces, toda esta expresión, incluida la función de pérdida, es completamente diferenciable. Podríamos usar un gradiente para guiar nuestra búsqueda; esa sería una aproximación.
Otra aproximación diría que en la práctica, en la cadena de suministro, tal vez tengas toneladas de series de tiempo. Entonces, en lugar de tratar cada serie de tiempo de forma independiente, lo que quieres hacer es una búsqueda en cuadrícula para las primeras 1,000 series de tiempo, e invertirás, y luego identificarás combinaciones para alfa, beta y gamma que sean buenas. Luego, para todas las demás series de tiempo, simplemente elegirás de esta lista corta de candidatos para identificar la mejor solución.
Ves, hay muchas ideas simples sobre cómo puedes hacer mucho mejor que simplemente optar por un enfoque de búsqueda en cuadrícula pura, y la esencia de la optimización matemática, y luego todo tipo de problemas de toma de decisiones también se pueden ver típicamente como problemas de optimización matemática.
Por ejemplo, el problema de enrutamiento de vehículos que puedes ver en la pantalla se puede ver como un problema de optimización matemática. Se trata de elegir la lista de puntos. No escribí la versión formal del problema porque es relativamente variable y no aporta mucha claridad. Pero si quieres pensarlo, simplemente puedes pensar: “Tengo puntos, puedo asignar una especie de pseudo-rango que es solo una puntuación a cada punto, y luego tengo un algoritmo que ordena todos los puntos por pseudo-rangos en orden ascendente, y esa es mi ruta”. El objetivo del algoritmo será identificar los valores de esos pseudo-rangos que te den las mejores rutas.
Ahora, con este problema, vemos que tenemos un problema donde de repente la búsqueda en cuadrícula ni siquiera es una opción. Tenemos docenas de puntos, y si probáramos todas las combinaciones, eso sería demasiado grande. Además, el gradiente no nos va a ayudar, al menos no es obvio cómo nos va a ayudar, porque el problema es muy discreto por naturaleza, y no hay algo que sea como un descenso de gradiente obvio para este tipo de problema.
Sin embargo, resulta que si queremos abordar este tipo de problema, hay heurísticas muy poderosas que se han identificado en la literatura. Por ejemplo, la heurística de dos-opt, publicada por Croes en 1958, te da una heurística muy sencilla. Comienzas con una ruta aleatoria, y en esta ruta, cada vez que la ruta se cruza a sí misma, aplicas una permutación para eliminar el cruce. Entonces, comienzas con una ruta aleatoria, y el primer cruce que observes, haces la permutación para eliminar el cruce, y luego repites el proceso con la heurística hasta que no queden cruces. Lo que obtendrás de esta heurística muy simple es en realidad una muy buena solución. Puede que no sea óptima en el verdadero sentido matemático, por lo que no es necesariamente la solución perfecta; sin embargo, es una muy buena solución, y puedes obtenerla con una cantidad relativamente mínima de recursos computacionales.
El problema con la heurística de dos-opt es que es una heurística muy específica para este problema en particular. Lo que realmente interesa para la optimización matemática es identificar métodos que funcionen en grandes clases de problemas en lugar de tener una heurística que solo funcione para una versión específica de un problema. Por lo tanto, queremos tener métodos muy generales.
Hasta ahora, en esta serie de conferencias: esta conferencia es parte de una serie de conferencias, y este capítulo en particular está dedicado a las ciencias auxiliares de la cadena de suministro. En el primer capítulo, presenté mis puntos de vista sobre la cadena de suministro tanto como campo de estudio como práctica. El segundo capítulo estuvo dedicado a la metodología y, en particular, presentamos una metodología que es de suma relevancia para la presente conferencia, que es la optimización experimental. Esa es la clave para abordar el problema muy válido identificado por Russell Ackoff hace décadas. El tercer capítulo está completamente dedicado al personal de la cadena de suministro. En esta conferencia, nos enfocamos en identificar el problema que estamos a punto de resolver, en lugar de mezclar la solución y el problema. En este cuarto capítulo, estamos investigando todas las ciencias auxiliares de la cadena de suministro. Hay una progresión desde el nivel más bajo en términos de hardware, subiendo al nivel de los algoritmos y luego a la optimización matemática. Estamos progresando en términos de niveles de abstracción a lo largo de esta serie.
Solo un breve resumen sobre las ciencias auxiliares: ofrecen una perspectiva sobre la propia cadena de suministro. La presente conferencia no trata sobre la cadena de suministro en sí, sino sobre una de las ciencias auxiliares de la cadena de suministro. Esta perspectiva marca una diferencia significativa con la perspectiva clásica de la investigación operativa, que se suponía que era un fin en sí misma, en contraposición a la optimización matemática, que es un medio para un fin pero no un fin en sí misma, al menos en lo que respecta a la cadena de suministro. La optimización matemática no se preocupa por los detalles comerciales, y la relación entre la optimización matemática y la cadena de suministro es similar a la relación entre la química y la medicina. Desde una perspectiva moderna, no tienes que ser un químico brillante para ser un médico brillante; sin embargo, un médico que afirme no saber nada de química parecería sospechoso.
La optimización matemática asume que el problema es conocido. No le importa la validez del problema, sino que se centra en aprovechar al máximo lo que se puede para un problema dado en términos de optimización. De alguna manera, es como un microscopio, muy poderoso pero con un enfoque increíblemente estrecho. El peligro, al volver a la discusión sobre el futuro de la investigación operativa, es que si apuntas tu microscopio en el lugar equivocado, podrías distraerte con desafíos intelectuales interesantes pero en última instancia irrelevantes.
Por eso es necesario utilizar la optimización matemática en conjunto con la optimización experimental. La optimización experimental, que vimos en la conferencia anterior, es el proceso mediante el cual puedes iterar con retroalimentación del mundo real hacia mejores versiones del problema en sí mismo. La optimización experimental es un proceso para mutar no la solución, sino el problema, de manera que de forma iterativa puedas converger hacia un buen problema. Este es el meollo del asunto y donde Russell Ackoff y sus colegas en ese momento no tenían una solución. Tenían las herramientas para optimizar un problema dado, pero no las herramientas para mutar el problema hasta que el problema fuera bueno. Si tomas un problema matemático tal como puedes escribirlo en tu torre de marfil, sin retroalimentación del mundo real, lo que obtienes es una fantasía. Tu punto de partida, cuando comienzas un proceso de optimización experimental, es solo una fantasía. Se necesita la retroalimentación del mundo real para que funcione. La idea es ir y venir entre la optimización matemática y la optimización experimental. En cada etapa de tu proceso de optimización experimental, utilizarás herramientas de optimización matemática. El objetivo es minimizar tanto los recursos computacionales como los esfuerzos de ingeniería, permitiendo que el proceso itere hacia la siguiente versión del problema.
En esta conferencia, primero refinaremos nuestra comprensión de la perspectiva de la optimización matemática. La definición formal es engañosamente simple, pero hay complejidades de las que debemos ser conscientes para lograr una relevancia práctica para los propósitos de la cadena de suministro. Luego exploraremos dos amplias clases de solucionadores que representan el estado del arte en la optimización matemática desde una perspectiva de la cadena de suministro.
Primero, hablemos de la convexidad y los primeros trabajos en la optimización matemática. La investigación operativa inicialmente se centró en funciones de pérdida convexas. Una función se dice que es convexa si cumple ciertas propiedades. De manera intuitiva, una función es convexa si, para cualquier par de puntos en la variedad definida por la función, la línea recta que conecta esos puntos siempre estará por encima de los valores tomados por la función entre esos puntos.
La convexidad es clave para permitir una verdadera optimización matemática, donde puedes demostrar resultados. De manera intuitiva, cuando tienes una función convexa, significa que para cualquier punto de la función (cualquier solución candidata), siempre puedes mirar alrededor y encontrar una dirección en la que puedas descender. No importa dónde comiences, siempre puedes descender y descender siempre es un movimiento bueno. El único punto donde no puedes descender más es esencialmente el punto óptimo. Estoy simplificando aquí; hay casos extremos donde tienes soluciones no únicas o ninguna solución en absoluto. Pero dejando de lado algunos casos extremos, el único punto donde no puedes optimizar más con una función convexa es el punto óptimo. De lo contrario, siempre puedes descender y descender es un movimiento bueno.
Se ha realizado una enorme cantidad de investigación sobre funciones convexas y han surgido varios paradigmas de programación a lo largo de los años. LP significa programación lineal y otros paradigmas incluyen programación cónica de segundo orden, programación geométrica (que trata con polinomios), programación semidefinida (que involucra matrices con eigenvalores positivos) y programación cónica geométrica. Estos marcos tienen en común que tratan con problemas convexos estructurados. Son convexos tanto en su función de pérdida como en las restricciones que limitan las soluciones elegibles.
Estos marcos han sido de gran interés, con una intensa literatura científica producida. Sin embargo, a pesar de sus nombres impresionantes, estos paradigmas tienen muy poca expresividad. Incluso problemas simples superan las capacidades de estos marcos. Por ejemplo, la optimización de los parámetros de Holt-Winters, un modelo básico de pronóstico de la década de 1960, ya supera lo que cualquiera de estos marcos puede hacer. De manera similar, el problema de enrutamiento de vehículos y el problema del viajante de comercio, ambos problemas simples, superan las capacidades de estos marcos.
Es por eso que decía al principio que ha habido una enorme cantidad de literatura, pero se utiliza muy poco. El único punto donde no se puede descender más es esencialmente el punto óptimo. Estoy simplificando aquí; hay casos extremos donde hay soluciones no únicas o ninguna solución en absoluto. Pero dejando de lado algunos casos extremos, el único punto donde no se puede optimizar más con una función convexa es el punto óptimo. De lo contrario, siempre se puede descender, y descender es una buena opción.
Se ha realizado una enorme cantidad de investigación sobre funciones convexas y han surgido varios paradigmas de programación a lo largo de los años. LP significa programación lineal y otros paradigmas incluyen programación cónica de segundo orden, programación geométrica (que trata con polinomios), programación semidefinida (que involucra matrices con eigenvalores positivos) y programación cónica geométrica. Estos marcos tienen en común que tratan con problemas convexos estructurados. Son convexos tanto en su función de pérdida como en las restricciones que limitan las soluciones elegibles.
Estos marcos han sido de gran interés, con una intensa literatura científica producida. Sin embargo, a pesar de sus nombres impresionantes, estos paradigmas tienen muy poca expresividad. Incluso problemas simples superan las capacidades de estos marcos. Por ejemplo, la optimización de los parámetros de Holt-Winters, un modelo básico de pronóstico de la década de 1960, ya supera lo que cualquiera de estos marcos puede hacer. De manera similar, el problema de enrutamiento de vehículos y el problema del viajante de comercio, ambos problemas simples, superan las capacidades de estos marcos.
Es por eso que decía al principio que ha habido una enorme cantidad de literatura, pero se utiliza muy poco. Una parte del problema fue un enfoque equivocado en los solucionadores de optimización matemática pura. Estos solucionadores son muy interesantes desde una perspectiva matemática porque se pueden producir pruebas matemáticas, pero solo se pueden usar con problemas de juguete o problemas completamente inventados. Una vez que estás en el mundo real, fallan, y ha habido muy poco progreso en estos campos en las últimas décadas. En lo que respecta a la cadena de suministro, casi nada, excepto algunos nichos, tiene relevancia para estos solucionadores.
Otro aspecto, que fue completamente desestimado e ignorado durante la era clásica de la investigación operativa, es la aleatoriedad. La aleatoriedad o estocasticidad es de vital importancia de dos maneras radicalmente diferentes. La primera forma en que debemos abordar la aleatoriedad es en el propio solucionador. Hoy en día, todos los solucionadores de vanguardia aprovechan ampliamente los procesos estocásticos internamente. Esto es muy interesante en contraposición a tener un proceso completamente determinista. Estoy hablando de los mecanismos internos del solucionador, el software que implementa las técnicas de optimización matemática.
La razón por la cual todos los solucionadores de vanguardia aprovechan ampliamente los procesos estocásticos tiene que ver con la forma en que existe el hardware informático moderno. La alternativa a la aleatoriedad al explorar soluciones es recordar lo que has hecho en el pasado, para no quedarte atrapado en el mismo bucle. Si tienes que recordar, consumirás memoria. El problema radica en el hecho de que necesitamos hacer muchas accesos a memoria. Una forma de introducir aleatoriedad es generalmente una forma de aliviar en gran medida la necesidad de acceso aleatorio a la memoria.
Al hacer que tu proceso sea estocástico, puedes evitar sondear tu propia base de datos de lo que has probado o no probado entre las posibles soluciones para el problema que deseas optimizar. Lo haces de manera un poco aleatoria, pero no completamente. Esto tiene una importancia clave en prácticamente todos los solucionadores modernos. Uno de los aspectos algo contraintuitivos de tener un proceso estocástico es que, aunque puedes tener un solucionador estocástico, la salida aún puede ser bastante determinista. Para entender esto, considera la analogía de una serie de tamices. Un tamiz es fundamentalmente un proceso estocástico físico, donde aplicas movimientos aleatorios y se lleva a cabo el proceso de tamizado. Aunque el proceso es completamente estocástico, el resultado es completamente determinista. Al final, obtienes un resultado completamente predecible del proceso de tamizado, aunque tu proceso fue fundamentalmente aleatorio. Esto es exactamente el tipo de cosa que sucede con los solucionadores estocásticos bien diseñados. Este es uno de los ingredientes clave de los solucionadores modernos.
Otro aspecto, que es ortogonal en cuanto a la aleatoriedad, es la naturaleza estocástica de los propios problemas. Esto estaba en su mayoría ausente en la era clásica de la investigación operativa: la idea de que tu función de pérdida es ruidosa y que cualquier medición que obtengas de ella tendrá cierto grado de ruido. Esto casi siempre es el caso en la cadena de suministro. ¿Por qué? La realidad es que en la cadena de suministro, cada vez que tomas una decisión, es porque anticipas algún tipo de eventos futuros. Si decides comprar algo, es porque anticipas que habrá una necesidad de ello más adelante en el futuro. El futuro no está escrito, por lo que puedes tener algunas ideas sobre el futuro, pero la idea nunca es perfecta. Si decides producir un producto ahora, es porque esperas que más adelante en el futuro haya demanda para este producto. La calidad de tu decisión, que es producir hoy, depende de condiciones futuras inciertas, y por lo tanto cualquier decisión que tomes en la cadena de suministro tendrá una función de pérdida que varía dependiendo de estas condiciones futuras que no se pueden controlar. El tipo de aleatoriedad debido a lidiar con eventos futuros es irreducible, y eso es de gran interés porque significa que estamos tratando fundamentalmente con problemas estocásticos.
Sin embargo, si volvemos a los solucionadores matemáticos clásicos, vemos que este aspecto está completamente ausente, lo cual es un gran problema. Significa que tenemos clases de solucionadores que ni siquiera pueden comprender el tipo de problemas a los que nos enfrentaremos, porque los problemas que serán de interés, donde queremos aplicar la optimización matemática, serán de naturaleza estocástica. Estoy hablando del ruido en la función de pérdida.
Existe una objeción de que si tienes un problema estocástico, siempre puedes transformarlo de nuevo en un problema determinista mediante muestreo. Si evalúas tu función de pérdida ruidosa 10,000 veces, puedes tener una función de pérdida aproximadamente determinista. Sin embargo, este enfoque es increíblemente ineficiente porque introduce una sobrecarga de 10,000 veces en tu proceso de optimización. La perspectiva de la optimización matemática se trata de obtener los mejores resultados para tus recursos computacionales limitados. No se trata de invertir una cantidad infinitamente grande de recursos computacionales para resolver el problema. Tenemos que lidiar con una cantidad finita de recursos computacionales, incluso si esta cantidad es bastante grande. Por lo tanto, al mirar los solucionadores más adelante, debemos tener en cuenta que es de interés primordial tener solucionadores que puedan comprender nativamente problemas estocásticos en lugar de recurrir al enfoque determinista.
Otro ángulo, que también es de interés primordial, es la optimización multiobjetivo. En la expresión ingenua del problema de optimización matemática, dije que la función de pérdida era esencialmente univaluada, por lo que teníamos un valor que queríamos minimizar. Pero ¿qué pasa si tenemos un vector de valores y lo que queremos hacer es encontrar la solución que da el punto más bajo según el orden lexicográfico de todos los vectores, como f1, f2, f3, etc.?
¿Por qué esto es incluso de interés desde una perspectiva de la cadena de suministro? La realidad es que si adoptas esta perspectiva multiobjetivo, puedes expresar todas tus restricciones como una única función de pérdida dedicada. Primero puedes tener una función que cuente las violaciones de tus restricciones. ¿Por qué tienes restricciones en la cadena de suministro? Bueno, tienes restricciones en todas partes. Por ejemplo, si realizas un pedido de compra, debes asegurarte de tener suficiente espacio en tu almacén para almacenar la mercancía cuando llegue. Entonces, tienes restricciones de espacio de almacenamiento, capacidad de producción y más. La idea es que, en lugar de tener un solucionador donde tengas que especificar las restricciones de forma especial, es más interesante tener un solucionador que pueda manejar la optimización multiobjetivo y donde puedas expresar las restricciones como uno de los objetivos. Solo cuentas el número de violaciones de restricciones y quieres minimizar eso, llevando este número de violaciones a cero.
La razón por la cual esta mentalidad es muy relevante para la cadena de suministro es porque los problemas de optimización que enfrentan las cadenas de suministro no son acertijos criptográficos. Estos no son problemas combinatorios súper ajustados donde o tienes una solución y es buena, o estás a solo un bit de la solución y no tienes nada. En la cadena de suministro, obtener lo que típicamente se llama una solución factible, una solución que satisface todas las restricciones, suele ser completamente trivial. Identificar una solución que satisfaga las restricciones no es una tarea difícil. Lo que es muy difícil es, entre todas las soluciones que satisfacen las restricciones, identificar la que es más rentable para el negocio. Aquí es donde se vuelve muy difícil. Encontrar una solución que no viole las restricciones es muy sencillo. Este no es el caso en otros campos, por ejemplo, en la optimización matemática para el diseño industrial, donde quieres colocar componentes dentro de un teléfono celular. Este es un problema increíblemente ajustado y combinatorio, y no puedes hacer trampa renunciando a una restricción y teniendo una pequeña protuberancia en tu teléfono celular. Es un problema increíblemente ajustado y combinatorio, y donde realmente necesitas tratar las restricciones como ciudadanos de primera clase. Esto no es necesario, creo, para la gran mayoría de los problemas de la cadena de suministro. Por lo tanto, nuevamente es de gran interés tener técnicas que puedan manejar la optimización multiobjetivo de forma nativa.
Ahora, vamos a discutir un poco más sobre el diseño del solucionador. Desde una perspectiva muy general sobre cómo queremos diseñar un software que produzca soluciones para una amplia clase de problemas, hay dos aspectos de diseño muy notables que me gustaría destacar. El primer aspecto a considerar es si vamos a operar desde una perspectiva de caja blanca o caja negra. La idea de una perspectiva de caja negra es que podemos procesar cualquier programa arbitrario, por lo que la función de pérdida puede ser cualquier programa arbitrario. No nos importa; tratamos eso como una caja negra completa. Lo único que queremos es un programa donde podamos evaluar el programa y obtener el valor de una solución tentativa. Por el contrario, un enfoque de caja blanca enfatiza el hecho de que la función de pérdida en sí misma tiene una estructura que podemos inspeccionar y aprovechar. Podemos ver dentro de la función de pérdida. Por cierto, cuando estaba discutiendo la convexidad unas diapositivas antes, todos esos modelos y solucionadores matemáticos puros eran realmente enfoques de caja blanca. Son el caso extremo de los enfoques de caja blanca, donde no solo puedes ver dentro del problema, sino que el problema tiene una estructura muy rígida, como la programación semidefinida, donde la forma es muy estrecha. Sin embargo, sin optar por algo tan rígido como un marco matemático, puedes, por ejemplo, decir que como parte de la caja blanca, tienes algo como el gradiente que te ayudará. Un gradiente de la función de pérdida es de gran interés porque de repente puedes saber en qué dirección quieres ir para descender, incluso si no tienes un problema convexo donde el simple descenso de gradiente garantiza un buen resultado. Como regla general, si puedes hacer de tu solucionador una caja blanca, tendrás un solucionador que es órdenes de magnitud más eficiente en comparación con un solucionador de caja negra.
Ahora, como segundo aspecto, tenemos solucionadores en línea versus solucionadores fuera de línea. El solucionador fuera de línea típicamente opera en lotes, por lo que un solucionador fuera de línea simplemente va a tomar el problema, ejecutarlo y tendrás que esperar hasta que se complete. En este momento, cuando el solucionador se completa, te da la mejor solución o algo que es la mejor solución identificada. Por el contrario, un solucionador en línea trabaja mucho más con un enfoque de mejor esfuerzo. Va a identificar una solución que sea aceptable y luego invertir recursos computacionales para iterar hacia soluciones cada vez mejores a medida que pasa el tiempo y a medida que inviertes más recursos computacionales. Lo que realmente es de gran interés es que cuando abordas un problema con un solucionador en línea, significa que prácticamente puedes pausar el proceso en cualquier momento y obtener una solución candidata temprana. Incluso puedes reanudar el proceso. Si volvemos a los solucionadores matemáticos, típicamente son solucionadores en lotes donde tienes que esperar hasta el final del proceso.
Desafortunadamente, operar en el mundo de la cadena de suministro puede ser un viaje muy accidentado, como se mencionó en una de las conferencias anteriores de esta serie. Habrá situaciones en las que normalmente puedes permitirte gastar, digamos, tres horas para ejecutar este proceso de optimización matemática. Pero a veces, puedes tener problemas informáticos, problemas del mundo real o una emergencia en tu cadena de suministro. En esos casos, será un salvavidas si lo que normalmente llevaba tres horas se puede interrumpir después de cinco minutos y proporcionar una respuesta, incluso una mala, en lugar de no tener respuesta en absoluto. Hay un dicho en el ejército que dice que el peor plan es no tener plan, por lo que es mejor tener un plan muy aproximado en lugar de no tener nada en absoluto. Esto es exactamente lo que te ofrece un solucionador en línea. Estos son los elementos de diseño clave que tendremos en cuenta en la siguiente discusión.
Ahora, para concluir esta primera sección de la conferencia sobre cómo abordar la optimización matemática, echemos un vistazo a las lecciones de deep learning. El deep learning ha sido una revolución completa para el campo del aprendizaje automático. Sin embargo, en su núcleo, el deep learning también tiene un problema de optimización matemática. Creo que el deep learning generó una revolución dentro de la optimización matemática misma y cambió por completo la forma en que vemos los problemas de optimización. El deep learning redefinió lo que consideramos como el estado del arte de la optimización matemática.
Hoy en día, los modelos de deep learning más grandes manejan más de un billón de parámetros, lo cual equivale a mil millones. Solo para ponerlo en perspectiva, la mayoría de los solucionadores matemáticos luchan incluso por manejar 1,000 variables y típicamente colapsan con solo unas decenas de miles de variables, sin importar cuánto hardware de cómputo les arrojes. En contraste, el deep learning tiene éxito, argumentablemente utilizando una gran cantidad de recursos computacionales, pero no obstante, es factible. Hay modelos de deep learning en producción que tienen más de un billón de parámetros, y todos esos parámetros están optimizados, lo que significa que tenemos procesos de optimización matemática que pueden escalar a un billón de parámetros. Esto es absolutamente impresionante y radicalmente diferente al rendimiento que vimos con las perspectivas de optimización clásicas.
Lo interesante es que incluso los problemas que son completamente deterministas, como jugar al Go o al ajedrez, que son no estadísticos, discretos y combinatorios, se han resuelto con mayor éxito con métodos que son completamente estocásticos y estadísticos. Esto es desconcertante porque jugar al Go o al ajedrez se puede ver como problemas de optimización discreta, sin embargo, se resuelven de manera más eficiente en la actualidad con métodos que son completamente estocásticos y estadísticos. Esto va en contra de la intuición que la comunidad científica tenía sobre estos problemas hace dos décadas.
Revisemos la comprensión que ha sido desbloqueada por el deep learning en relación con la optimización matemática. Lo primero es revisar por completo la maldición de la dimensionalidad. Creo que este concepto es en su mayoría defectuoso, y el deep learning está demostrando que este concepto no es la forma en que debes pensar siquiera en la dificultad de un problema de optimización. Resulta que cuando miras clases de problemas matemáticos, puedes demostrar matemáticamente que ciertos problemas son extremadamente difíciles de resolver perfectamente. Por ejemplo, si has oído hablar de problemas NP-hard, sabes que a medida que agregas dimensiones al problema, se vuelve exponencialmente más difícil de resolver. Cada dimensión adicional hace que el problema sea más difícil, y hay una barrera acumulativa. Puedes demostrar que ningún algoritmo puede esperar resolver el problema perfectamente con una cantidad limitada de recursos computacionales. Sin embargo, el deep learning mostró que esta perspectiva era en su mayoría defectuosa.
Primero, tenemos que diferenciar entre la complejidad representacional del problema y la complejidad intrínseca del problema. Permíteme aclarar estos dos términos con un ejemplo. Echemos un vistazo al ejemplo de pronóstico de series de tiempo dado inicialmente. Digamos que tenemos un historial de ventas, agregado diariamente durante tres años, por lo que tenemos un vector de tiempo agregado diariamente de aproximadamente 1,000 días. Esta es la representación del problema.
Ahora, ¿qué pasa si paso a una representación de series de tiempo por segundo? Este es el mismo historial de ventas, pero en lugar de representar mis datos de ventas en agregados diarios, voy a representar esta serie de tiempo, la misma serie de tiempo, en agregados por segundo. Eso significa que hay 86,400 segundos en cada día, por lo que voy a inflar el tamaño y la dimensión de mi representación del problema en 86,000.
Pero si comenzamos a pensar en la dimensión intrínseca, no es porque tengo un historial de ventas, y no es porque pase de una agregación por día a una agregación por segundo, que estoy aumentando la complejidad o la complejidad dimensional del problema en 1,000. Lo más probable es que si paso a ventas agregadas por segundo, la serie de tiempo sea increíblemente dispersa, por lo que en su mayoría serán ceros para prácticamente todos los compartimentos. No estoy aumentando la dimensionalidad interesante del problema en un factor de 100,000. El deep learning aclara que no es porque tienes una representación del problema con muchas dimensiones que el problema es fundamentalmente difícil.
Otro aspecto asociado con la dimensionalidad es que aunque se puede demostrar que ciertos problemas son NP-completos, por ejemplo, el problema del viajante de comercio (una versión simplificada del problema de enrutamiento de vehículos presentado al principio de esta conferencia), el viajante de comercio es técnicamente lo que se conoce como un problema NP-duro. Entonces, es un problema en el que si quieres encontrar la mejor solución en el caso general, va a ser exponencialmente costoso a medida que agregas puntos a tu mapa. Pero la realidad es que estos problemas son muy fáciles de resolver, como se ilustra con la heurística de dos-opt; puedes obtener excelentes soluciones con una cantidad mínima de recursos computacionales. Así que ten cuidado con las pruebas matemáticas que demuestran que algunos problemas son muy difíciles, pueden ser engañosas. No te dicen que si estás bien con tener una solución aproximada, la aproximación puede ser excelente, y a veces ni siquiera es una aproximación; vas a obtener la solución óptima. Simplemente no puedes demostrar que es óptima. Esto no dice nada sobre si puedes aproximar el problema, y con mucha frecuencia, esos problemas supuestamente plagados por la maldición de la dimensionalidad son fáciles de resolver porque sus dimensiones interesantes no son tan altas. El deep learning ha demostrado con éxito que muchos problemas que se pensaba que eran increíblemente difíciles no eran tan difíciles en primer lugar.
La segunda idea clave fue los mínimos locales. La mayoría de los investigadores que trabajan en optimización matemática e investigación operativa optaron por funciones convexas porque no había mínimos locales. Durante mucho tiempo, las personas que no trabajaban en funciones convexas estaban pensando en cómo evitar quedarse atrapadas en un mínimo local. La mayoría de los esfuerzos se dedicaron a trabajar en cosas como metaheurísticas. El deep learning ha proporcionado una comprensión renovada: no nos importan los mínimos locales. Esta comprensión proviene de trabajos recientes originados en la comunidad de deep learning.
Si tienes una dimensión muy alta, puedes demostrar que los mínimos locales desaparecen a medida que aumenta la dimensión del problema. Los mínimos locales son muy frecuentes en problemas de baja dimensionalidad, pero si aumentas la dimensión de los problemas a cientos o miles, estadísticamente hablando, los mínimos locales se vuelven increíblemente improbables. Hasta el punto en que, al mirar dimensiones muy grandes como millones, desaparecen por completo.
En lugar de pensar que una dimensión más alta es tu enemigo, como se asociaba con la maldición de la dimensionalidad, ¿qué pasa si puedes hacer exactamente lo contrario e inflar la dimensión del problema hasta que sea tan grande que sea trivial tener un descenso limpio sin mínimos locales en absoluto? Resulta que esto es exactamente lo que se está haciendo en la comunidad de deep learning y con modelos que tienen un billón de parámetros. Este enfoque te brinda una forma muy clara de avanzar en tu gradiente.
Esencialmente, la comunidad de deep learning demostró que era irrelevante tener una prueba sobre la calidad del descenso o la convergencia final. Lo que importa es la velocidad del descenso. Quieres iterar y descender rápidamente hacia una solución muy buena. Si puedes tener un proceso que descienda más rápido, en última instancia avanzarás más en términos de optimización. Estas ideas van en contra de la comprensión general de la optimización matemática, o lo que se entendía como comprensión principal hace dos décadas.
Hay otras lecciones que se pueden aprender del deep learning, ya que es un campo muy rico. Una de ellas es la simpatía por el hardware. El problema con los solucionadores matemáticos, como la programación cónica o la programación geométrica, es que se centran en la intuición matemática primero y no en el hardware de computación. Si diseñas un solucionador que fundamentalmente se opone a tu hardware de computación, sin importar cuán inteligente sea tu matemática, es probable que seas desesperadamente ineficiente debido a un mal uso del hardware computacional.
Una de las ideas clave de la comunidad de deep learning es que debes llevarte bien con el hardware de computación y diseñar un solucionador que lo abrace. Por eso comencé esta serie de conferencias sobre ciencias auxiliares para la cadena de suministro con computadoras modernas para la cadena de suministro. Es importante entender el hardware que tienes y cómo aprovecharlo al máximo. Esta simpatía por el hardware es cómo puedes lograr modelos con un billón de parámetros, aunque requiere un gran clúster de computadoras o una supercomputadora.
Otra lección del deep learning es el uso de funciones sustitutas. Tradicionalmente, los solucionadores matemáticos buscaban optimizar el problema tal como era, sin desviarse de él. Sin embargo, el deep learning mostró que a veces es mejor usar funciones sustitutas. Por ejemplo, con mucha frecuencia para las predicciones, los modelos de deep learning utilizan entropía cruzada como métrica de error en lugar de la media cuadrática. Prácticamente nadie en el mundo real está interesado en la entropía cruzada como métrica, ya que es bastante extraña.
Entonces, ¿por qué la gente usa entropía cruzada? Proporciona gradientes increíblemente pronunciados y, como mostró el deep learning, todo se trata de la velocidad del descenso. Si tienes gradientes muy pronunciados, puedes descender muy rápidamente. La gente podría objetar y decir: “Si quiero optimizar la media cuadrática, ¿por qué debería usar entropía cruzada? Ni siquiera es el mismo objetivo”. La realidad es que si optimizas la entropía cruzada, tendrás gradientes muy pronunciados y, al final, si evalúas tu solución en función de la media cuadrática, obtendrás una mejor solución según el criterio de la media cuadrática también, con mucha frecuencia, si no siempre. Solo estoy simplificando para explicarlo. La idea de las funciones sustitutas es que el problema real no es absoluto; es solo algo que usarás para controlar y evaluar la validez final de tu solución. No es necesariamente algo que usarás mientras el solucionador esté en progreso. Esto va completamente en contra de las ideas involucradas con los solucionadores matemáticos que eran populares durante las últimas dos décadas.
Por último, está la importancia de trabajar en paradigmas. Con la optimización matemática, hay implícitamente una división del trabajo involucrada en la organización de tu fuerza laboral de ingeniería. La división del trabajo implícita en los solucionadores matemáticos es que tendrás ingenieros matemáticos por un lado, que son responsables de diseñar el solucionador, e ingenieros de problemas por otro lado, cuya responsabilidad es expresar el problema de una forma adecuada para su procesamiento por los solucionadores matemáticos. Esta división del trabajo era prevalente y la idea era hacerla lo más simple posible para el ingeniero de problemas, para que solo tuviera que expresar el problema de la manera más minimalista y pura, dejando que el solucionador hiciera el trabajo.
El deep learning mostró que esta perspectiva era profundamente ineficiente. Esta división arbitraria del trabajo no era la mejor manera de abordar el problema en absoluto. Si haces eso, terminas con situaciones que son imposiblemente difíciles, es decir, que superan ampliamente el estado del arte para quienes son los ingenieros matemáticos que trabajan en el problema de optimización. Una forma mucho mejor es que los ingenieros de problemas hagan un esfuerzo adicional para reformular los problemas de manera que los hagan mucho más adecuados para la optimización por el optimizador matemático.
El deep learning se trata de un conjunto de recetas que te permiten enmarcar el problema sobre tu solucionador, para que obtengas el máximo provecho de tu optimizador. La mayoría de los desarrollos en la comunidad de deep learning se han centrado en crear estas recetas que son muy buenas para aprender mientras se juega bien dentro del paradigma de los solucionadores que tienen (por ejemplo, TensorFlow, PyTorch, MXNet). La conclusión es que realmente quieres colaborar con el ingeniero de problemas, o en términos de la cadena de suministro, el Supply Chain Scientist.
Ahora pasemos a la segunda y última sección de esta conferencia sobre los elementos más valiosos de la literatura. Echaremos un vistazo a dos amplias clases de solucionadores: búsqueda local y programación diferenciable.
Primero, permíteme detenerme nuevamente en el término “programación”. Esta palabra tiene una importancia crítica porque, desde una perspectiva de la cadena de suministro, realmente queremos poder expresar el problema que enfrentamos, o el problema que creemos que estamos enfrentando. No queremos una especie de versión de baja resolución del problema que simplemente se ajuste a alguna hipótesis matemática semi-absurda, como necesitar expresar tu problema en un cono o algo así. Lo que realmente nos interesa es tener acceso a un verdadero paradigma de programación.
Recuerda, esos solucionadores matemáticos como la programación lineal, la programación cónica de segundo orden y la programación geométrica, todos venían con una palabra clave de programación. Sin embargo, en las últimas décadas, lo que esperamos de un paradigma de programación ha evolucionado drásticamente. Hoy en día, queremos algo que te permita lidiar con programas casi arbitrarios, programas en los que tienes bucles, ramificaciones y posiblemente asignaciones de memoria, etc. Realmente quieres algo lo más cercano posible a un programa arbitrario, no alguna versión de juguete super limitada que tenga algunas propiedades matemáticas interesantes. En la cadena de suministro, es mejor estar aproximadamente correcto que estar exactamente equivocado.
Para lidiar con la optimización genérica, comencemos con la búsqueda local. La búsqueda local es una técnica de optimización matemática engañosamente simple. El pseudocódigo implica comenzar con una solución aleatoria, que representas como un conjunto de bits. Luego inicializas tu solución de manera aleatoria y comienzas a cambiar bits al azar para explorar el vecindario de la solución. Si, a través de esta exploración aleatoria, encuentras una solución que resulta ser mejor, esta se convierte en tu nueva solución de referencia.
Este enfoque sorprendentemente poderoso puede funcionar literalmente con cualquier programa, tratándolo como una caja negra, y también puede reiniciarse desde cualquier solución conocida. Hay muchas formas de mejorar este enfoque. Una forma es la computación diferencial, que no debe confundirse con la computación diferenciable. La computación diferencial es la idea de que si ejecutas tu programa en una solución dada y luego cambias un bit, puedes volver a ejecutar el mismo programa con una ejecución diferencial, sin tener que volver a ejecutar todo el programa. Obviamente, los resultados pueden variar y dependen mucho de la estructura del problema. Una forma de acelerar el proceso no es aprovechar algún tipo de información adicional sobre el programa de caja negra que operamos, sino simplemente poder acelerar el programa en sí, tratándolo principalmente como una caja negra, porque no volvemos a ejecutar todo el programa cada vez.
Hay otros enfoques para mejorar la búsqueda local. Puedes mejorar el tipo de movimientos que haces. La estrategia más básica se llama k-flips, donde cambias k bits con k siendo un número muy pequeño, algo así como un par de docenas. En lugar de simplemente cambiar bits, puedes permitir que el ingeniero del problema indique el tipo de mutaciones que se deben aplicar a la solución. Por ejemplo, puedes expresar que deseas aplicar algún tipo de permutación en tu problema. La idea es que estos movimientos inteligentes a menudo preservan la satisfacción de algunas restricciones en tu problema, lo que puede ayudar a que el proceso de búsqueda local converja más rápido.
Otra forma de mejorar la búsqueda local es no explorar completamente el espacio al azar. En lugar de cambiar bits al azar, puedes intentar aprender las direcciones correctas, identificando las áreas más prometedoras para los cambios. Algunos artículos recientes han demostrado que puedes agregar un módulo de aprendizaje profundo muy pequeño en la parte superior de la búsqueda local, actuando como un generador. Sin embargo, este enfoque puede ser complicado en términos de ingeniería, ya que debes asegurarte de que el costo adicional introducido por el proceso de aprendizaje automático genere un beneficio positivo en términos de recursos computacionales.
Hay otras heurísticas conocidas, y si deseas una visión sintética muy buena de lo que se necesita para implementar un motor de búsqueda local moderno, puedes leer el artículo “LocalSolver: A Black-Box Local-Search Solver for 0-1 Programs”. La empresa que opera LocalSolver también tiene un producto con el mismo nombre. En este artículo, ofrecen una perspectiva de ingeniería sobre lo que está sucediendo bajo el capó en su solucionador de calidad de producción. Utilizan el enfoque de multi-start y recocido simulado para obtener mejores resultados.
Una advertencia que agregaría sobre la búsqueda local es que no se maneja muy bien o de manera nativa con problemas estocásticos. Con problemas estocásticos, no es tan fácil como simplemente decir “tengo una mejor solución” y decidir de inmediato que se convierte en la mejor solución. Es más complicado que eso y necesitas hacer un esfuerzo adicional antes de pasar a la solución evaluada como la nueva mejor.
Ahora, avancemos hacia la segunda clase de solucionadores que discutiremos hoy, que es la programación diferenciable. Pero primero, para comprender la programación diferenciable, debemos comprender el descenso de gradiente estocástico. El descenso de gradiente estocástico es una técnica de optimización iterativa basada en gradientes. Surgió como una serie de técnicas pioneras a principios de la década de 1950, lo que lo convierte en casi 70 años de antigüedad. Permaneció bastante nicho durante casi seis décadas, y tuvimos que esperar el avance del aprendizaje profundo para comprender el verdadero potencial y poder del descenso de gradiente estocástico.
El descenso de gradiente estocástico asume que la función de pérdida se puede descomponer aditivamente en una serie de componentes. En la ecuación, Q(W) representa la función de pérdida, que se descompone en una serie de funciones parciales, Qi. Esto es relevante porque la mayoría de los problemas de aprendizaje se pueden ver como tener que aprender una predicción basada en una serie de ejemplos. La idea es que puedes descomponer tu función de pérdida como el error promedio cometido en todo el conjunto de datos, con un error local para cada punto de datos. Muchos problemas de la cadena de suministro también se pueden descomponer aditivamente de esta manera. Por ejemplo, puedes descomponer tu red de cadena de suministro en una serie de rendimientos para cada SKU individual, con una función de pérdida adjunta a cada SKU. La verdadera función de pérdida que deseas optimizar es la total.
Cuando tienes esta descomposición en su lugar, que es muy natural para problemas de aprendizaje, puedes iterar con el proceso de descenso de gradiente estocástico (SGD). El vector de parámetros W puede ser una serie muy grande, ya que los modelos de aprendizaje profundo más grandes tienen billones de parámetros. La idea es que en cada paso del proceso, actualizas tus parámetros aplicando una pequeña cantidad de gradiente. Eta es la tasa de aprendizaje, un número pequeño típicamente entre 0 y 1, a menudo alrededor de 0.01. Nabla de Q es el gradiente para una función de pérdida parcial Qi. Sorprendentemente, este proceso funciona bien.
Se dice que el SGD es estocástico porque eliges aleatoriamente tu próximo elemento i, saltando a través de tu conjunto de datos y aplicando un pequeño bit de gradiente a tus parámetros en cada paso. Esta es la esencia del descenso de gradiente estocástico.
Permaneció relativamente nicho y en gran medida ignorado por la comunidad en general durante casi seis décadas, porque es bastante sorprendente que el descenso de gradiente estocástico funcione en absoluto. Funciona porque proporciona un excelente equilibrio entre el ruido en la función de pérdida y el costo computacional de acceder a la función de pérdida en sí. En lugar de tener una función de pérdida que debe evaluarse en todo el conjunto de datos, con el descenso de gradiente estocástico, podemos tomar un punto de datos a la vez y aún aplicar un poco de gradiente. Esta medición va a ser muy fragmentaria y ruidosa, pero este ruido está bien porque es muy rápido. Puedes realizar órdenes de magnitud más optimizaciones pequeñas y ruidosas en comparación con el procesamiento de todo el conjunto de datos.
Sorprendentemente, el ruido introducido ayuda al descenso del gradiente. Uno de los problemas en espacios de alta dimensión es que los mínimos locales se vuelven relativamente inexistentes. Sin embargo, aún puedes enfrentar grandes áreas de mesetas donde el gradiente es muy pequeño y el descenso del gradiente no tiene una dirección para elegir para el descenso. El ruido te proporciona gradientes más pronunciados y ruidosos que ayudan con el descenso.
Lo que también es interesante con el descenso de gradiente es que es un proceso estocástico, pero puede manejar problemas estocásticos de forma gratuita. Si Qi es una función estocástica con ruido y da un resultado aleatorio que varía cada vez que lo evalúas, ni siquiera necesitas cambiar una sola línea del algoritmo. El descenso de gradiente estocástico es de gran interés porque te brinda algo que está completamente alineado con el paradigma que es relevante para los propósitos de la cadena de suministro.
La segunda pregunta es: ¿de dónde viene el gradiente? Tenemos un programa y simplemente tomamos el gradiente de la función de pérdida parcial, pero ¿de dónde viene este gradiente? ¿Cómo obtienes un gradiente para un programa arbitrario? Resulta que hay una técnica muy elegante y minimalista descubierta hace mucho tiempo llamada diferenciación automática.
La diferenciación automática surgió en la década de 1960 y se fue perfeccionando con el tiempo. Hay dos tipos: el modo directo, descubierto en 1964, y el modo inverso, descubierto en 1980. La diferenciación automática se puede ver como un truco de compilación. La idea es que tienes un programa para compilar y, con la diferenciación automática, tienes tu programa que representa la función de pérdida. Puedes volver a compilar este programa para obtener un segundo programa, y la salida del segundo programa no es la función de pérdida, sino los gradientes de todos los parámetros involucrados en el cálculo de la función de pérdida.
Además, la diferenciación automática te brinda un segundo programa con una complejidad de cálculo básicamente idéntica a la de tu programa inicial. Esto significa que no solo tienes una forma de crear un segundo programa que calcula los gradientes, sino que también el segundo programa tiene las mismas características de cálculo en términos de rendimiento que el primer programa. Es un factor constante de inflación en términos de costo de cálculo. Sin embargo, la realidad es que el segundo programa obtenido no tiene exactamente las mismas características de memoria que el programa inicial. Aunque los detalles técnicos van más allá del alcance de esta presentación, podemos discutir eso durante las preguntas. Esencialmente, el segundo programa, llamado el reverso, requerirá más memoria y, en algunas situaciones patológicas, puede requerir mucha más memoria que el programa inicial. Recuerda que más memoria crea problemas con el rendimiento de cálculo, ya que no se puede asumir un acceso uniforme a la memoria.
Para ilustrar un poco cómo se ve la diferenciación automática, como mencioné, hay dos modos: directo e inverso. Desde una perspectiva de aprendizaje o de optimización de la cadena de suministro, el único modo de interés para nosotros es el modo inverso. Lo que puedes ver en la pantalla es una función de pérdida F, completamente inventada. Puedes ver la traza directa, una secuencia de operaciones aritméticas o elementales que se llevan a cabo para calcular tu función para dos valores de entrada dados, X1 y X2. Esto te da todos los pasos elementales realizados para calcular el valor final.
La idea es que para cada paso elemental, y la mayoría de ellos son solo operaciones aritméticas básicas como multiplicación o suma, el modo inverso es un programa que ejecuta los mismos pasos pero en orden inverso. En lugar de tener los valores directos, tendrás los adjuntos. Para cada operación aritmética, tendrás su contraparte inversa. La transición de la operación directa a la contraparte es muy sencilla.
Incluso si parece complicado, tienes una ejecución directa y una ejecución inversa, donde tu ejecución inversa no es más que una transformación elemental aplicada a cada operación individual. Al final de la ejecución inversa, obtienes los gradientes. La diferenciación automática puede parecer complicada, pero no lo es. El primer prototipo que implementamos tenía menos de 100 líneas de código, por lo que es muy sencillo y básicamente un truco de transpilación económico.
Ahora bien, esto es interesante porque tenemos el descenso de gradiente estocástico, que es un mecanismo de optimización increíblemente poderoso. Es increíblemente escalable, en línea, en pizarra y funciona de forma nativa con problemas estocásticos. El único problema que quedaba era cómo obtener el gradiente, y con la diferenciación automática, tenemos el gradiente por un costo fijo o un factor constante, para prácticamente cualquier programa arbitrario. Lo que obtenemos al final es la programación diferenciable.
Curiosamente, la programación diferenciable es una combinación del descenso de gradiente estocástico y la diferenciación automática. Aunque estas dos técnicas, el descenso de gradiente estocástico y la diferenciación automática, tienen décadas de antigüedad, la programación diferenciable solo se hizo prominente a principios de 2018 cuando Yann LeCun, el Jefe de IA en Facebook, comenzó a comunicar sobre este concepto. LeCun no inventó este concepto, pero fue fundamental para popularizarlo.
Por ejemplo, la comunidad de deep learning inicialmente utilizaba la retropropagación en lugar de la diferenciación automática. Para aquellos familiarizados con las redes neuronales, la retropropagación es un proceso complejo que es órdenes de magnitud más complicado de implementar que la diferenciación automática. La diferenciación automática es superior en todos los aspectos. Con esta idea, la comunidad de deep learning refinó su visión de lo que constituye el aprendizaje en el deep learning. El deep learning combinó la optimización matemática con diversas técnicas de aprendizaje, y la programación diferenciable surgió como un concepto limpio que aislaba las partes no relacionadas con el aprendizaje del deep learning.
Las técnicas modernas de deep learning, como el modelo transformer, asumen un entorno de programación diferenciable que opera por debajo. Esto permite a los investigadores centrarse en los aspectos de aprendizaje que se construyen encima. La programación diferenciable, aunque es fundamental para el deep learning, también es muy relevante para la optimización de la cadena de suministro y para apoyar los procesos de aprendizaje de la cadena de suministro, como el pronóstico estadístico.
Al igual que con el deep learning, hay dos partes en el problema: la programación diferenciable como capa base y las técnicas de optimización o aprendizaje por encima de eso. La comunidad de deep learning busca identificar arquitecturas que funcionen bien con la programación diferenciable, como los transformers. De manera similar, se deben identificar las arquitecturas que funcionen bien para fines de optimización. Esto es lo que se ha hecho para aprender a jugar al Go o al ajedrez en entornos altamente combinatorios. Discutiremos técnicas que funcionan bien para la optimización específica de la cadena de suministro en conferencias posteriores.
Pero ahora, es hora de concluir. Una parte importante de la literatura de la cadena de suministro e incluso la mayoría de sus implementaciones de software están bastante confundidas cuando se trata de la optimización matemática. Este aspecto generalmente ni siquiera se identifica correctamente como tal, y como resultado, los profesionales, investigadores e incluso ingenieros de software que trabajan para empresas de software empresarial a menudo se mezclan en sus recetas numéricas de manera bastante caótica cuando se trata de la optimización matemática. Tienen un gran problema, ya que un componente no se ha identificado como de naturaleza de optimización matemática y porque ni siquiera son conscientes de lo que está disponible en la literatura, a menudo recurren a búsquedas en cuadrícula rudimentarias o heurísticas apresuradas que producen un rendimiento errático e inconsistente. Como conclusión de esta conferencia, a partir de ahora, cada vez que te encuentres con un método numérico de la cadena de suministro o un software de la cadena de suministro que afirme ofrecer cualquier tipo de función analítica, debes preguntarte qué está sucediendo en términos de optimización matemática y qué se está haciendo al respecto. Si te das cuenta de que los proveedores no ofrecen una visión clara sobre esta perspectiva, lo más probable es que estés en el lado izquierdo de la ilustración, y este no es el lugar en el que quieres estar.
Ahora, echemos un vistazo a las preguntas.
Pregunta: ¿Es la transición hacia los métodos computacionales una habilidad previa en operaciones, y los roles operativos se volverán obsoletos, o viceversa?
Primero, permítanme aclarar algunas cosas. Creo que es un error depositar estas preocupaciones en el CIO. La gente espera demasiado de sus CIOs. Como Director de Información, ya tienes que lidiar con la capa base de tu infraestructura de software, como recursos computacionales, sistemas transaccionales de bajo nivel, integridad de la red y ciberseguridad. No se espera que el CIO entienda lo que se necesita para hacer algo de valor para tu cadena de suministro.
El problema es que en muchas empresas, las personas son tan desesperadamente ignorantes en todo lo relacionado con la computación que el CIO se convierte en la persona a la que acudir para todo. La realidad es que el CIO debería ocuparse de la capa base de la infraestructura, y luego depende de cada especialista abordar sus necesidades específicas con los recursos computacionales y las herramientas de software disponibles para ellos.
En cuanto a los roles operativos que se vuelven obsoletos, si tu función es revisar manualmente hojas de cálculo de Excel todo el día, entonces sí, es muy probable que tu función se vuelva obsoleta. Este ha sido un problema conocido desde 1979, cuando Russell Ackoff publicó su artículo. El problema es que las personas sabían que este método de tomar decisiones no era el futuro, pero siguió siendo el status quo durante mucho tiempo. La clave del problema es que las empresas necesitan comprender el proceso experimental. Creo que habrá una transición en la que las empresas comiencen a adquirir nuevamente estas habilidades. Muchas grandes empresas norteamericanas después de la Segunda Guerra Mundial tenían algún conocimiento de investigación de operaciones entre sus ejecutivos. Era un tema nuevo y candente, y los consejos de administración de las grandes empresas sabían cosas sobre investigación de operaciones. Como señala Russell Ackoff, debido a la falta de resultados, estas ideas fueron relegadas al último escalón de la empresa hasta que fueron externalizadas por completo, ya que en su mayoría eran irrelevantes y no ofrecían resultados tangibles. Creo que la investigación de operaciones solo volverá si las personas aprenden las lecciones de por qué la era clásica de la investigación de operaciones no entregó resultados. El CIO solo tendrá una contribución modesta en esta tarea; en su mayoría es una cuestión de repensar el valor agregado de las personas dentro de la empresa.
Quieres tener una contribución capitalista, y eso vuelve a una de mis conferencias anteriores sobre la entrega orientada al producto en el sentido de productos de software para cadenas de suministro. La clave es: ¿qué tipo de valor agregado capitalista entregas a tu empresa? Si la respuesta es ninguno, es posible que no formes parte de lo que tu empresa debería ser y será en el futuro.
Pregunta: ¿Qué hay de usar el solucionador de Excel para minimizar el valor MRMSC y encontrar el valor óptimo para alfa, beta y gamma?
Creo que esta pregunta es relevante para el caso de Holt-Winters, donde realmente puedes encontrar una solución con búsqueda en cuadrícula. Sin embargo, ¿qué está sucediendo en este solucionador de Excel? ¿Es un descenso de gradiente u otra cosa? Si te refieres al solucionador lineal de Excel, no es un problema lineal, por lo que Excel no puede hacer nada por ti en ese caso. Si tienes otros solucionadores en Excel o complementos, sí, pueden funcionar, pero esta es una perspectiva muy anticuada. No abarca una visión más estocástica; el tipo de pronóstico que obtienes es un pronóstico no probabilístico, que es un enfoque desactualizado.
No estoy diciendo que no se pueda usar Excel, pero la pregunta es, ¿qué tipo de capacidades de programación se están desbloqueando en Excel? ¿Puedes hacer descenso de gradiente estocástico en Excel? Probablemente, si agregas algún complemento dedicado. Excel te permite conectar cualquier programa arbitrario encima de él. ¿Podrías potencialmente hacer programación diferenciable en Excel? Sí. ¿Es una buena idea hacerlo en Excel? No. Para entender por qué, tienes que volver al concepto de entrega de software orientada al producto, que detalla qué está saliendo mal con Excel. Se reduce al modelo de programación y si realmente puedes mantener tu trabajo a lo largo del tiempo con un esfuerzo en equipo.
Pregunta: Los problemas de optimización suelen estar sesgados hacia la ruta de vehículos o el pronóstico. ¿Por qué no considerar también la optimización de toda la cadena de suministro? ¿No reduciría eso los costos en comparación con mirar áreas aisladas?
Estoy completamente de acuerdo. La maldición de la optimización de la cadena de suministro es que cuando realizas una optimización local en un subproblema, lo más probable es que desplaces el problema, no lo resuelvas para toda la cadena de suministro. Estoy completamente de acuerdo, y tan pronto como comienzas a analizar un problema más complejo, estás lidiando con un problema híbrido, por ejemplo, un problema de enrutamiento de vehículos combinado con una estrategia de reabastecimiento. El problema es que necesitas un solucionador muy genérico para abordar esto porque no quieres estar restringido. Si tienes un solucionador muy genérico, necesitas tener mecanismos muy genéricos en lugar de depender de heurísticas inteligentes como el two-opt, que solo funciona bien para el enrutamiento de vehículos y no para algo que es una combinación de reabastecimiento y enrutamiento de vehículos al mismo tiempo.
Para pasar a esta perspectiva holística, no debes tener miedo de la maldición de la dimensionalidad. Hace veinte años, la gente decía que estos problemas ya eran extremadamente difíciles y NP-completos, como el problema del viajante, y quieres resolver un problema aún más difícil entrelazándolo con otro problema. La respuesta es sí; quieres poder hacer eso, y por eso es esencial tener un solucionador que te permita lidiar con programas arbitrarios porque tu solución puede ser la consolidación de muchos problemas entrelazados e intercalados.
De hecho, la idea de resolver estos problemas de forma aislada es mucho más débil en comparación con resolver todo. Es mejor estar aproximadamente correcto que exactamente equivocado. Es mucho mejor tener un solucionador muy débil que aborde toda la cadena de suministro como un sistema, como un bloque, en lugar de tener optimizaciones locales avanzadas que solo crean problemas en otros lugares a medida que microoptimizas localmente. La verdadera optimización del sistema no es necesariamente la mejor optimización para cada parte, por lo que es natural que si optimizas en interés de toda la empresa y su cadena de suministro, no será óptimo a nivel local porque tienes en cuenta los otros aspectos de la empresa y su cadena de suministro.
Pregunta: Después de realizar un ejercicio de optimización, ¿cuándo deberíamos revisar el escenario considerando que pueden aparecer nuevas restricciones en cualquier momento? La respuesta es que debes revisar la optimización con frecuencia. Este es el papel del Supply Chain Scientist que he presentado en la segunda conferencia de esta serie. El Supply Chain Scientist revisará la optimización tantas veces como sea necesario. Si surge una nueva restricción, como un barco gigantesco bloqueando el Canal de Suez, fue inesperado, pero debes lidiar con esta disrupción en tu cadena de suministro. No tienes otra opción que abordar estos problemas; de lo contrario, el sistema que has implementado generará resultados sin sentido porque operará bajo condiciones falsas. Incluso si no tienes una emergencia con la que lidiar, aún quieres invertir tu tiempo en pensar en el ángulo más probable de generar el mayor retorno para la empresa. Esto es fundamentalmente investigación y desarrollo. Tienes el sistema en su lugar, opera y solo estás tratando de identificar áreas donde puedes mejorar el sistema. Se convierte en un proceso de investigación aplicada que es altamente capitalista e irregular. Como Supply Chain Scientist, hay días en los que pasas todo el día probando métodos numéricos, ninguno de los cuales ofrece mejores resultados que los que ya tienes. En algunos días, haces un pequeño ajuste y tienes mucha suerte, ahorrando millones a la empresa. Es un proceso irregular, pero en promedio, el resultado puede ser enorme.
Pregunta: ¿Cuáles serían los casos de uso para problemas de optimización que no sean programación lineal, programación entera, programación mixta y en el caso de Weber y costo de bienes?
Yo invertiría la pregunta: ¿dónde ves que la programación lineal tenga relevancia en algún problema de la cadena de suministro? Prácticamente no hay ningún problema de la cadena de suministro que sea lineal. Mi objeción es que estos marcos son muy simplistas y ni siquiera pueden abordar problemas sencillos. Como dije, estos marcos matemáticos, como la programación lineal, ni siquiera pueden abordar un problema sencillo como la optimización de invierno duro para un modelo de pronóstico paramétrico antiguo y de baja dimensionalidad. Ni siquiera pueden resolver el problema del viajante o prácticamente cualquier otra cosa.
La programación entera o la programación entera mixta es solo un término genérico para indicar que algunas de las variables van a ser enteras, pero eso no cambia el hecho de que estos marcos de programación son simplemente marcos matemáticos sencillos que están lejos de tener la expresividad necesaria para abordar problemas de la cadena de suministro.
Cuando preguntas sobre los casos de uso de problemas de optimización, te invito a que veas todas mis conferencias sobre personajes de la cadena de suministro. Ya tenemos una serie de personajes de la cadena de suministro y estoy enumerando literalmente toneladas de problemas que se pueden abordar mediante la optimización matemática. En las conferencias sobre los personajes de la cadena de suministro, tenemos a París, Miami, Ámsterdam y una serie mundial, y vendrán más. Tenemos muchos problemas que deben abordarse y merecerían abordarse desde una perspectiva adecuada de optimización matemática. Sin embargo, verás que para cada uno de esos problemas no podrás enmarcarlos dentro de las restricciones superestrictas y en su mayoría extrañas que surgen de estos marcos matemáticos. Nuevamente, esos marcos matemáticos se centran principalmente en la convexidad, y esta no es la perspectiva correcta para la cadena de suministro. La mayoría de los puntos con los que tratamos no son convexos. Pero está bien, no es porque no sean convexos que sean imposiblemente difíciles. Verás, es solo que no podrás tener una prueba matemática al final del día. Pero a tu jefe o a tu empresa, les importa el beneficio, no si tienes una prueba matemática para respaldar la decisión. Les importa el hecho de que puedas tomar la decisión correcta en términos de producción, reabastecimiento, precios, surtidos y demás, no que tengas una prueba matemática adjunta a esas decisiones.
Pregunta: ¿Cuánto tiempo se debe almacenar los datos del algoritmo de aprendizaje para ayudar en el aprendizaje?
Bueno, yo diría que, considerando que el almacenamiento de datos hoy en día es increíblemente barato, ¿por qué no conservarlo para siempre? El almacenamiento de datos es tan económico; por ejemplo, ve a un supermercado y verás que el precio de un disco duro de un terabyte es de alrededor de 60 o algo así. Así que es increíblemente barato.
Ahora, obviamente, hay una preocupación separada de que si tienes datos personales en tus datos, entonces los datos que conservas se convierten en una responsabilidad. Pero desde una perspectiva de cadena de suministro, si asumimos que has eliminado todos los datos personales primero, porque normalmente no necesitas tener datos personales en primer lugar. No necesitas conservar números de tarjetas de crédito o los nombres de tus clientes. Solo necesitas tener identificadores de clientes y cosas por el estilo. Si simplemente eliminas todos los datos personales de tus datos, diría, ¿por cuánto tiempo? Bueno, consérvalos para siempre.
Uno de los puntos en la cadena de suministro es que tienes datos limitados. No es como los problemas de deep learning como el reconocimiento de imágenes, donde puedes procesar todas las imágenes en la web y tener acceso a bases de datos casi infinitas para analizar. En la cadena de suministro, tus datos siempre son limitados. De hecho, si quieres pronosticar la demanda futura, hay muy pocas industrias donde mirar más de una década en el pasado sea realmente relevante, estadísticamente hablando, para pronosticar la demanda del próximo trimestre. Pero aún así, diría que siempre es más fácil truncar los datos si los necesitas en lugar de darte cuenta de que has descartado datos y ahora faltan. Así que mi sugerencia es conservar todo, eliminar los datos personales y al final de tu tubería de extracción de datos, verás si es mejor filtrar los datos muy antiguos. Puede ser que sí o puede ser que no; depende de la industria en la que estés operando. Por ejemplo, en la industria aeroespacial, cuando tienes piezas y aviones con una vida útil operativa de cuatro décadas, tener datos en tu sistema de los últimos cuatro décadas es relevante.
Pregunta: ¿Es la programación multiobjetivo una función de dos o más objetivos, como la suma o la minimización de múltiples funciones en una meta?
Hay múltiples variantes de cómo quieres abordar los objetivos múltiples. No se trata de tener una función que sea una suma porque, si tienes la suma, entonces es solo una cuestión de descomposición y estructura de la función de pérdida. No, se trata realmente de tener un vector. Y de hecho, hay múltiples variantes de programación multiobjetivo. La variante más interesante es aquella en la que quieres ir por un orden lexicográfico. En lo que respecta a la cadena de suministro, la minimización, cuando quieres decir que tomas la media o el máximo de las muchas funciones, puede ser de interés, pero no estoy muy seguro. Creo que el enfoque multiobjetivo, donde realmente puedes introducir restricciones y tratar las restricciones como parte de tu optimización regular, es muy interesante para fines de cadena de suministro. Las otras variantes también podrían ser interesantes, pero no estoy tan seguro. No estoy diciendo que no lo sean; solo digo que no estoy seguro.
Pregunta: ¿Cómo decidirías cuándo usar una solución aproximada en lugar de la solución optimizada?
Quiero decir, no estoy muy seguro de entender la pregunta. La idea es que, si hay una lección que aprender del deep learning, es que no hay una solución óptima. Todo es una aproximación hasta cierto punto. Incluso cuando dices que tienes números, en las computadoras, los números no vienen con precisión infinita; vienen con precisión finita. Y esta precisión finita puede volver en tu contra en algunas circunstancias. Entonces la respuesta es que siempre es aproximado. Diría que la lección más importante es que es una ilusión pensar que hay una solución perfecta. No existe tal cosa como una solución perfecta y óptima. Todas las soluciones que tienes son aproximaciones, y algunas de ellas son, diría yo, un poco más o menos aproximadas. Entonces, no estoy muy seguro del sentido de tu pregunta, pero desde la perspectiva de la optimización matemática, significa que tienes una función de pérdida para evaluar la calidad, y al final del día, si tienes dos soluciones competidoras, tienes tu función de pérdida para evaluar cuál es la mejor. Así es como funciona.
Pregunta: ¿Por qué se dividió la serie de tiempo, en términos de datos históricos, por 86,400 en primer lugar?
No se dividió. Fue un ejemplo. Solo quería resaltar y llevar la situación a un estado absurdo donde ves, cuando usas un algoritmo clásico de pronóstico de series de tiempo, adoptas lo que se conoce como una serie de tiempo equiespaciada. Hay muchas formas de representar series de tiempo, y la forma más típica de representar la serie de tiempo es la variante equiespaciada de la serie de tiempo, donde se realiza una agregación en intervalos de igual longitud. Eso es típicamente lo que obtienes con la agregación diaria o la agregación semanal. Tienes intervalos que tienen la misma longitud, y tu serie tiene una estructura similar a un vector.
Pero lo que estoy señalando es que es arbitrario en gran medida. Puedes decidir representar los datos como datos diarios, pero podrías decidir representar los datos por segundo. ¿Tendría sentido representar los datos por segundo? La respuesta es sí; depende del tipo de problemas. Por ejemplo, si eres un proveedor de electricidad y quieres gestionar una red, entonces debes gestionar la energía en cada segundo para que tengas exactamente el equilibrio entre la oferta de electricidad en tu red y el consumo de energía. Y este equilibrio se ajusta realmente por segundo. Entonces, puede haber situaciones en las que tenga sentido representar los datos por segundo. Para la venta en tu tienda local, puede que no tenga sentido. Lo que quería señalar con esos 86,400, por cierto, es simplemente 24 horas multiplicado por 60 minutos multiplicado por 60 segundos, y quería aclarar el hecho de que siempre tienes una representación de tus datos, y no debes confundir la representación de tus datos que viene con una cierta dimensionalidad con la dimensión intrínseca de tus datos, que puede tener una dimensión completamente diferente. La representación es, en gran medida, completamente inventada y arbitraria. Te da un indicador numérico, como tener tres años de datos, para que tengas un vector de dimensión mil. Pero este mil es algo que se inventa en gran medida porque se basa en la decisión de agregar datos diariamente. Si eligieras cualquier otro período alternativo, obtendrías una dimensión diferente. Ese es el punto que quería hacer, y eso es lo que el deep learning realmente hizo bien: tener otras cosas donde no te dejes engañar por elecciones arbitrarias de representación de los datos. Quieres ser un poco indiferente a la representación.
Pregunta: Al introducir el pronóstico probabilístico, pasamos a una función de costo y restricciones que son probabilísticas en su naturaleza. ¿Qué implicaciones tiene esto en el proceso de encontrar una solución?
Bueno, tiene una restricción muy básica y fundamental. Si tienes un solucionador que no puede procesar problemas, y nuevamente, recuerda que siempre puedes volver de un problema estocástico a un problema determinista simplemente promediando tus resultados sobre un número muy grande de muestras, entonces estás en problemas en términos de costos computacionales. Significa que tendrás que gastar aproximadamente 10,000 veces más potencia de procesamiento para llegar a una solución satisfactoria en comparación con una solución alternativa. La implicación es que realmente quieres asegurarte de que tus herramientas de optimización matemática, la infraestructura que tienes, sean capaces de manejar nativamente problemas estocásticos. Eso es exactamente lo que obtienes con la programación diferenciable, no tanto con la búsqueda local, pero también puedes mejorar o revisar la búsqueda local para que funcione de manera más fluida en ese tipo de situaciones.
Fundamentalmente, cuando optas por el pronóstico probabilístico, no solo desafía la forma en que ves el futuro; también desafía profundamente el tipo de herramientas e instrumentación con las que tienes que trabajar con esos pronósticos. Ese es exactamente el tipo de herramientas que Lokad ha estado desarrollando durante la última década. La razón es que necesitamos tener herramientas que puedan funcionar bien con el tipo de problemas estocásticos que inevitablemente surgen en la cadena de suministro porque prácticamente todos los problemas en las cadenas de suministro tienen un componente de incertidumbre y, por lo tanto, todos están lidiando con un problema estocástico en cierta medida.
Excelente. Entonces, la próxima conferencia será el mismo día de la semana, un miércoles. Habrá algunas vacaciones entre ahora y entonces. La próxima conferencia será el 22 de septiembre y espero verlos a todos. Esta vez estaremos discutiendo el aprendizaje automático para la cadena de suministro. Nos vemos entonces.
Referencias
- El futuro de la investigación operativa es pasado, Russell L. Ackoff, febrero de 1979
- LocalSolver 1.x: un solucionador de búsqueda local de caja negra para programación 0-1, Thierry Benoist, Bertrand Estellon, Frédéric Gardi, Romain Megel, Karim Nouioua, septiembre de 2011
- Diferenciación automática en el aprendizaje automático: una encuesta, Atilim Gunes Baydin, Barak A. Pearlmutter, Alexey Andreyevich Radul, Jeffrey Mark Siskind, última revisión en febrero de 2018
