00:28 Введение
00:43 Роберт А. Хайнлайн
03:03 До сих пор
06:52 Выбор парадигм
08:20 Статический анализ
18:26 Программирование с использованием массивов
28:08 Совместимость с аппаратным обеспечением
35:38 Вероятностное программирование
40:53 Дифференцируемое программирование
55:12 Версионирование кода+данных
01:00:01 Безопасное программирование
01:05:37 В заключение, инструменты также важны в цепочке поставок
01:06:40 Предстоящая лекция и вопросы аудитории
Описание
В то время как основная теория цепочки поставок борется за преобладание в компаниях в целом, одно средство, а именно Microsoft Excel, имело значительный операционный успех. Повторная реализация численных методов основной теории цепочки поставок с помощью электронных таблиц тривиальна, однако на практике это не произошло, несмотря на осведомленность о теории. Мы демонстрируем, что электронные таблицы победили, приняв программные парадигмы, которые оказались превосходными в достижении результатов цепочки поставок.
Полный текст
Привет всем, добро пожаловать на эту серию лекций по цепочке поставок. Я Йоанн Верморель, и сегодня я представлю свою четвертую лекцию: Программные парадигмы для цепочки поставок.
Когда меня спрашивают: “Мистер Верморель, какие области наиболее интересны для вас в плане знаний о цепочке поставок?”, одним из моих главных ответов обычно являются программные парадигмы. И затем, не слишком часто, но достаточно часто, реакция человека, с которым я разговариваю, звучит так: “Программные парадигмы, мистер Верморель? О чем вы вообще говорите? Как это вообще имеет отношение к текущей задаче?” И такие реакции, очевидно, не так часты, но когда они происходят, они всегда напоминают мне об этой абсолютно невероятной цитате Роберта А. Хайнлайна, который считается деканом писателей научной фантастики.
У Хайнлайна есть фантастическая цитата о компетентном человеке, которая подчеркивает важность компетентности в различных областях, особенно в сфере цепей поставок, где у нас есть сложные проблемы. Эти проблемы почти так же сложны, как сама жизнь, и я считаю, что исследование идеи программных парадигм действительно стоит вашего времени, так как это может принести много ценности вашей цепи поставок.
До сих пор, в первой лекции, мы видели, что проблемы цепей поставок являются сложными. Тот, кто говорит о оптимальных решениях, не понимает сути; здесь нет ничего, что было бы даже отдаленно близко к оптимальности. Во второй лекции я описал Количественную оптимизацию цепи поставок, видение с пятью ключевыми требованиями для достижения великолепия в управлении цепью поставок. Эти требования сами по себе недостаточны, но их нельзя обойти, если вы хотите достичь великолепия.
В третьей лекции я обсудил доставку программного обеспечения в контексте оптимизации цепи поставок. Я отстаивал предложение о том, что оптимизация цепи поставок требует правильного подхода к программному продукту в капиталистическом стиле, но такого продукта нельзя найти на полке. Слишком много разнообразия, и стоящие перед нами вызовы выходят далеко за рамки существующих технологий. Поэтому это будет нечто полностью индивидуальное. Таким образом, если это программный продукт, который будет разработан индивидуально для компании или интересующей цепи поставок, возникает вопрос о том, какие инструменты нужны для его доставки. Это приводит меня к теме сегодняшней лекции: правильный инструмент начинается с правильных программных парадигм, потому что нам придется программировать этот продукт каким-то образом.
До сих пор нам требуются программные возможности для работы с оптимизацией проблемы, не путать с управлением. Как мы видели, что было темой моей предыдущей лекции, победителем до сих пор является Microsoft Excel. От очень маленьких компаний до очень больших компаний, он повсеместно используется. Даже в компаниях, которые вложили миллионы долларов в супер-умные системы, Excel все равно правит, и почему? Потому что у него есть правильные программные свойства. Он очень выразителен, гибок, доступен и поддерживаем. Однако Excel - это не конечная цель. Я твердо верю, что мы можем сделать гораздо больше, но нам нужны правильные инструменты, подход, понимание и программные парадигмы.
Программные парадигмы могут показаться аудитории чрезмерно сложными, но это на самом деле область исследований, которая активно изучается в течение последних пяти десятилетий. В этой области было проделано огромное количество работы. Это не широко известно широкой аудитории, но существуют целые библиотеки, наполненные высококачественными работами, выполненными многими людьми. Поэтому сегодня я собираюсь представить серию из семи парадигм, которые приняла компания Lokad. Мы не изобрели ни одну из этих идей; мы взяли их у людей, которые изобрели их до нас. Все эти парадигмы были реализованы в программном продукте Lokad, и после почти десятилетия работы Lokad в производстве, используя эти парадигмы, я считаю, что они были абсолютно критическими для нашего операционного успеха до сих пор.
Давайте продолжим этот список с помощью статического анализа. Проблема здесь заключается в сложности. Как вы справляетесь с сложностью в цепочке поставок? Вы столкнетесь с предприятий, в которых есть сотни таблиц, каждая из которых содержит десятки полей. Если вы рассматриваете проблему, такую простую, как пополнение запасов на складе, вам нужно учесть множество вещей. У вас могут быть минимальные объемы заказа, скидки на цены, прогнозы спроса, прогнозы сроков поставки и все виды возвратов. У вас могут быть ограничения по месту на полках, ограничения по приему товара и сроки годности, из-за которых некоторые партии становятся устаревшими. Таким образом, у вас возникает множество вещей, которые нужно учесть. В цепочке поставок идея “двигаться быстро и ломать вещи” просто не является правильным подходом. Если вы случайно заказываете товар на миллион долларов, который вам совсем не нужен, это очень дорогая ошибка. Вы не можете позволить программному обеспечению управлять вашей цепочкой поставок, принимать рутинные решения, и когда возникает ошибка, это стоит миллионы. Нам нужно иметь что-то с очень высокой степенью правильности по конструкции. Мы не хотим обнаруживать ошибки в производстве. Это совершенно отличается от вашего обычного программного обеспечения, где сбой не является большой проблемой.
Когда дело доходит до оптимизации цепочки поставок, это не ваша обычная проблема. Если вы только что передали поставщику массовый неправильный заказ, вы не можете просто позвонить им через неделю и сказать: “О, моя ошибка, нет, забудьте об этом, мы никогда не заказывали это”. Такие ошибки будут стоить много денег. Статический анализ называется так потому, что он заключается в анализе программы без ее запуска. Идея заключается в том, что у вас есть программа, написанная с помощью операторов, ключевых слов и всего остального, и даже не запуская эту программу, можно ли уже сказать, если программа имеет проблемы, которые почти наверняка негативно повлияют на ваше производство, особенно на производство в цепочке поставок? Ответ - да. Такие техники существуют, они реализованы и чрезвычайно ценны.
Просто чтобы дать пример, вы можете увидеть скриншот Envision на экране. Envision - это язык программирования, специально разработанный для предсказательной оптимизации цепочки поставок, который Локад разрабатывал почти десять лет. То, что вы видите, - это скриншот редактора кода Envision, веб-приложения, которое вы можете использовать онлайн для редактирования кода. Синтаксис сильно повлиян на Python. На этом маленьком скриншоте, всего с четырьмя строками, я иллюстрирую идею, что если вы пишете большой логический блок для пополнения запасов на складе и вводите некоторые экономические переменные, такие как скидки на цены, через логический анализ программы вы можете увидеть, что эти скидки на цены не имеют никакого отношения к конечным результатам, которые возвращает программа, а именно к количеству, которое нужно пополнить. Здесь у вас есть очевидная проблема. Вы ввели важную переменную - скидки на цены, и эти скидки на цены логически не влияют на конечные результаты. Итак, у нас есть проблема, которую можно обнаружить с помощью статического анализа. Это очевидная проблема, потому что если мы вводим переменные в код, которые не имеют никакого влияния на вывод программы, то они совершенно бесполезны. В этом случае у нас есть два варианта: либо эти переменные на самом деле являются мертвым кодом, и программа не должна компилироваться (вам просто нужно избавиться от этого мертвого кода, чтобы уменьшить сложность и не накапливать случайную сложность), либо это была настоящая ошибка, и в вашем расчете должна была быть важная экономическая переменная, но вы упустили мяч из-за отвлечения или по какой-то другой причине.
Статический анализ абсолютно необходим для достижения любой степени правильности по конструкции. Речь идет о исправлении проблем на этапе компиляции при написании кода, еще до того, как вы коснетесь данных. Если проблемы возникают при выполнении, вероятно, что они произойдут только ночью, когда у вас есть ночной пакет, управляющий пополнением склада. Программа, скорее всего, будет запускаться в необычные часы, когда перед ней никого нет, поэтому вы не хотите, чтобы что-то сломалось, когда перед программой никого нет. Она должна сломаться в тот момент, когда люди на самом деле пишут код.
Статический анализ имеет множество целей. Например, в Lokad мы используем статический анализ для WYSIWYG-редактирования панелей управления. WYSIWYG означает “то, что вы видите, то и получаете”. Представьте, что вы создаете панель управления для отчетности с линейными графиками, столбчатыми диаграммами, таблицами, цветами и различными стилистическими эффектами. Вы хотите иметь возможность делать это визуально, а не настраивать стиль панели управления через код, так как это очень неудобно. Все настройки, которые вы реализовали, будут внедрены в сам код, и это делается с помощью статического анализа.
Еще одной аспект в Lokad, который может быть не так важен для всей цепочки поставок, но определенно критичен для выполнения проекта, было работа с языком программирования, называемым Envision, который мы разрабатываем. Мы знали с первого дня, почти десять лет назад, что будут допущены ошибки. У нас не было хрустального шара, чтобы сразу иметь идеальное видение с первого дня. Вопрос был в том, как мы можем убедиться, что мы можем исправить эти проектные ошибки в самом языке программирования максимально удобным способом? Здесь Python был для меня предостережением.
Python, который не является новым языком, был выпущен впервые в 1991 году, почти 30 лет назад. Миграция с Python 2 на Python 3 заняла всем сообществу почти десять лет, и это был кошмарный процесс, очень болезненный для компаний, участвовавших в этой миграции. Мое восприятие заключалось в том, что сам язык не имел достаточно конструкций. Он не был разработан таким образом, чтобы можно было переносить программы с одной версии языка программирования на другую версию. Фактически, это было чрезвычайно сложно сделать полностью автоматическим образом, и это потому, что Python не был разработан с учетом статического анализа. Когда у вас есть язык программирования для цепочки поставок, вы действительно хотите иметь такой язык, который обладает отличным качеством статического анализа, потому что ваши программы будут долгоживущими. Цепочки поставок не имеют возможности сказать: “Подождите три месяца, мы просто переписываем код. Подождите нас, кавалерия идет. Просто не будет работать пару месяцев”. Это буквально похоже на то, как ремонтируют поезд, когда поезд движется по рельсам со скоростью, и вы хотите починить двигатель, пока поезд работает. Вот как выглядит исправление проблем цепочки поставок, которые фактически находятся в производстве. У вас нет возможности просто остановить систему; она никогда не останавливается.
Вторая парадигма - это массивное программирование. Мы хотим иметь контроль над сложностью, так как это большая повторяющаяся тема в цепочках поставок. Мы хотим иметь логику, где у нас нет определенных классов программных ошибок. Например, когда у вас есть циклы или ветвления, написанные явно программистами, вы подвергаете себя целым классам очень сложных проблем. Это становится чрезвычайно сложным, когда люди могут просто писать произвольные циклы, чтобы иметь гарантии о длительности вычисления. Хотя это может показаться узкоспециализированной проблемой, это не совсем так в оптимизации цепочки поставок.
На практике, предположим, у вас есть розничная сеть. В полночь они полностью сконсолидируют все продажи из всей сети, и данные будут сконсолидированы и переданы в некоторую систему для оптимизации. У этой системы будет ровно 60-минутное окно для прогнозирования, оптимизации запасов и принятия решений о перераспределении для каждого отдельного магазина сети. После этого результаты будут переданы в систему управления складом, чтобы они могли начать подготовку всех отгрузок. Грузовики будут загружены, возможно, в 5:00 утра, и к 9:00 утра магазины откроются с уже полученным и выставленным на полки товаром.
Однако у вас есть очень строгое время, и если ваш расчет выходит за пределы этого 60-минутного окна, вы ставите под угрозу всю исполнение цепочки поставок. Вы не хотите, чтобы вы обнаружили в производстве, сколько времени занимаются вещи. Если у вас есть циклы, где люди могут решить, сколько итераций они будут иметь, очень сложно иметь какое-либо доказательство длительности вашего расчета. Имейте в виду, что речь идет об оптимизации цепочки поставок. У вас нет возможности провести рецензию и дважды проверить все. Иногда из-за пандемии некоторые страны закрываются, в то время как другие открываются довольно хаотично, обычно за 24 часа. Вам нужно быстро реагировать.
Итак, программирование массивов - это идея того, что вы можете работать непосредственно с массивами. Если мы посмотрим на фрагмент кода, который у нас здесь, это код Envision, DSL Lokad. Чтобы понять, что происходит, вам нужно понять, что когда я пишу “orders.amounts”, то это переменная, а “orders” на самом деле является таблицей в смысле реляционной таблицы, как в таблице вашей базы данных. Например, здесь, в первой строке, “amounts” будет столбцом в таблице. В первой строке я буквально говорю, что для каждой строки таблицы orders я просто возьму “quantity”, который является столбцом, и умножу его на “price”, а затем я получу третий столбец, который динамически генерируется, и это “amount”.
Кстати, современный термин для программирования массивов сегодня также известен как программирование с использованием фреймов данных. Область исследования довольно древняя; она уходит на три или четыре десятилетия, может быть даже на четыре или пять. Она была известна как программирование массивов, даже если сейчас люди обычно более знакомы с идеей фреймов данных. Во второй строке мы делаем фильтр, как SQL. Мы фильтруем даты, и случается так, что у таблицы orders есть дата. Она будет отфильтрована, и я говорю “дата, которая больше сегодня минус 365”, то есть дней. Мы сохраняем данные с прошлого года, а затем мы пишем “products.soldLastYear = SUM(orders.amount)”.
Теперь интересно то, что у нас есть то, что мы называем естественным объединением между продуктами и заказами. Почему? Потому что каждая строка заказа связана с одним и только одним продуктом, и один продукт связан с нулем или более строками заказа. В этой конфигурации вы можете прямо сказать: “Я хочу вычислить что-то на уровне продукта, что является просто суммой того, что происходит на уровне заказов”, и это именно то, что делается в строке девять. Вы можете заметить, что синтаксис очень простой; у вас нет множества случайностей или технических деталей. Я утверждаю, что этот код почти полностью лишен любых случайностей, когда речь идет о программировании с использованием фреймов данных. Затем, в строках 10, 11 и 12, мы просто помещаем таблицу на нашем панели управления, что можно сделать очень удобно: “LIST(PRODUCTS)”, а затем “TO(products)”.
Программирование массивов имеет множество преимуществ для цепей поставок. Во-первых, оно устраняет целые классы проблем. У вас не будет ошибок на единицу в ваших массивах. Будет намного проще параллелизировать и даже распределить вычисления. Это очень интересно, потому что это означает, что вы можете написать программу и выполнить ее не на одной локальной машине, а непосредственно на флоте машин, которые находятся в облаке, и, кстати, именно это делается в Lokad. Эта автоматическая параллелизация представляет собой очень интересный аспект.
Вы видите, что это работает так: когда вы выполняете оптимизацию цепи поставок, типичные потребительские паттерны в терминах вычислительного оборудования являются супер прерывистыми. Если я вернусь к примеру, который я приводил о 60-минутном окне для розничных сетей во время пополнения магазина, это означает, что есть один час в день, когда вам нужна вычислительная мощность для выполнения всех ваших расчетов, но в остальное время, в другие 23 часа, вам это не нужно. Поэтому вам нужна программа, которая, когда вы собираетесь ее запустить, будет распределена на множество машин, а затем, как только она закончится, она просто освободит все эти машины, чтобы могли произойти другие вычисления. Альтернативой было бы иметь много машин, которые вы арендуете и платите за них весь день, но используете их только 5% времени, что очень неэффективно.
Эта идея, что вы можете быстро и предсказуемо распределить вычислительную мощность на множество машин, а затем освободить ее, требует облака в многопользовательской среде и ряда других вещей, которые делает Lokad. Но прежде всего это требует сотрудничества самого языка программирования. Это неосуществимо с общим языком программирования, таким как Python, потому что сам язык не предназначен для такого умного и актуального подхода. Это больше, чем просто трюки; это буквально деление ваших затрат на аппаратное обеспечение IT на 20, массовое ускорение выполнения и устранение целых классов потенциальных ошибок в вашей цепи поставок. Это изменяет игру.
Программирование с использованием массивов уже существует во многих аспектах, таких как NumPy и pandas в Python, которые настолько популярны среди аудитории специалистов по обработке данных. Но вопрос, который у меня к вам возникает, заключается в том, если это настолько важно и полезно, почему эти вещи не являются важными элементами самого языка? Если все, что вы делаете, - это работа с помощью NumPy, то NumPy должен быть важным элементом языка. Я бы сказал, что можно сделать даже лучше, чем NumPy. NumPy - это просто программирование с использованием массивов на одной машине, но почему бы не выполнять программирование с использованием массивов на целом парке машин? Это намного мощнее и более подходящее, когда у вас есть облачная платформа с доступными вычислительными ресурсами.
Итак, что будет являться узким местом в оптимизации цепи поставок? Есть такое высказывание Голдратта, которое гласит: “Любое улучшение, внесенное помимо узкого места в цепи поставок, является иллюзией”, и я очень согласен с этим утверждением. По реалистичным причинам, когда мы хотим провести оптимизацию цепи поставок, узким местом будут люди, а точнее, ученые по цепям поставок, которые, к сожалению для Lokad и моих клиентов, не растут на деревьях.
Узким местом являются ученые по цепям поставок, люди, которые могут создавать числовые алгоритмы, учитывающие все стратегии компании, враждебное поведение конкурентов и превращающие всю эту информацию в механизм, который можно масштабировать. Трагедия наивного подхода к анализу данных, когда я начинал свою докторскую программу, которую, кстати, я никогда не закончил, заключалась в том, что я видел, что все в лаборатории буквально занимаются анализом данных. Большинство людей писали код для какой-то сложной модели машинного обучения, нажимали Enter и начинали ждать. Если у вас есть большой набор данных, скажем, 5-10 гигабайт, это не будет работать в режиме реального времени. Таким образом, весь лабораторный зал был заполнен людьми, которые писали несколько строк кода, нажимали Enter и уходили за чашкой кофе или чтением чего-то онлайн. Таким образом, производительность была чрезвычайно низкой.
Когда я создавал свою собственную компанию, у меня была мысль, что я не хочу платить армии очень умных людей, которые проводят большую часть своего дня, попивая кофе и ждут, когда их программы завершатся, чтобы получить результаты и продолжить работу. В теории они могли бы параллельно выполнять много задач и запускать эксперименты, но на практике я такого никогда не видел. Интеллектуально, когда вы занимаетесь поиском решения проблемы, вы хотите проверить свою гипотезу и вам нужен результат, чтобы продолжить работу. Очень сложно одновременно заниматься высокотехническими вещами и преследовать несколько интеллектуальных направлений одновременно.
Однако была светлая сторона. Ученые по данным и теперь ученые по цепям поставок в Lokad не пишут тысячи строк кода и не говорят “пожалуйста, запустите”. Они обычно добавляют две строки в скрипт, который состоит из тысячи строк, и затем просят запустить этот скрипт. Этот скрипт выполняется на основе тех же данных, которые они только что использовали несколько минут назад. Это практически та же самая логика, за исключением этих двух строк. Так как можно обрабатывать терабайты данных за секунды вместо нескольких минут? Ответ заключается в том, что если во время предыдущего выполнения скрипта вы записали все промежуточные шаги вычисления и сохранили их на накопителе (обычно твердотельные накопители или SSD, которые очень дешевы, быстры и удобны в использовании).
В следующий раз, когда вы запустите свою программу, система заметит, что это почти тот же самый скрипт. Она выполнит сравнение и увидит, что в терминах вычислительного графа он почти идентичен, за исключением нескольких битов. В отношении данных он обычно полностью идентичен на 100%. Иногда есть некоторые изменения, но почти ничего. Система автоматически диагностирует, что вам нужно вычислить только несколько вещей, поэтому вы можете получить результаты за секунды. Это может значительно повысить производительность вашего ученого по цепям поставок. Вы можете перейти от людей, которые нажимают Enter и ждут 20 минут для получения результата, к ситуации, когда они нажимают Enter, а через 5 или 10 секунд у них уже есть результат и они могут продолжить работу.
Я говорю о чем-то, что может показаться очень сложным, но на практике это имеет в 10 раз больший эффект на производительность. Это огромно. Так что то, что мы делаем здесь, это использование умного трюка, который Lokad не изобрел. Мы заменяем один вычислительный ресурс, а именно вычисления, на другой, а именно память и хранение. У нас есть основные вычислительные ресурсы: вычисления, память (либо волатильная, либо постоянная) и пропускная способность. Это основные ресурсы, за которые вы платите, когда покупаете ресурсы на облачной вычислительной платформе. Вы можете фактически заменить один ресурс другим, и цель состоит в том, чтобы получить максимальную отдачу от своих денег.
Когда люди говорят, что вам следует использовать вычисления в памяти, я бы сказал, что это глупость. Если вы говорите о вычислениях в памяти, это означает, что вы делаете упор на один ресурс по сравнению со всеми остальными. Но нет, есть компромиссы, и интересно то, что вы можете иметь язык программирования и среду, которые делают эти компромиссы и перспективы легче внедрять. В обычном языке общего назначения это возможно, но нужно делать это вручную. Это означает, что человек, который это делает, должен быть профессиональным программным инженером. Ученый по цепям поставок не будет выполнять эти низкоуровневые операции с основными вычислительными ресурсами вашей платформы. Это должно быть разработано на уровне самого языка программирования.
Теперь давайте поговорим о вероятностном программировании. Во второй лекции, где я представил видение количественной цепи поставок, мое первое требование заключалось в том, что нам нужно рассмотреть все возможные будущие события. Технический ответ на это требование - вероятностное прогнозирование. Вы хотите иметь дело с будущими событиями, где есть вероятности. Все будущие события возможны, но они не все одинаково вероятны. Вам нужна алгебра, в которой можно выполнять вычисления с неопределенностью. Одно из моих больших критических замечаний по поводу Excel заключается в том, что в нем чрезвычайно сложно представить неопределенность в электронной таблице, независимо от того, является ли она Excel или любой другой более современной облачной версией. В электронной таблице очень сложно представить неопределенность, потому что вам нужно что-то лучше, чем числа.
В этом небольшом фрагменте я иллюстрирую алгебру случайных величин, которая является встроенной функцией Envision. В первой строке я генерирую дискретное распределение Пуассона с средним значением 2 и помещаю его в переменную X. Затем я делаю то же самое для другого распределения Пуассона, Y. Затем я вычисляю Z как произведение X на Y. Эта операция, умножение случайных величин, может показаться очень странной. Зачем вам вообще нужно такое изучение с точки зрения цепи поставок? Позвольте мне привести вам пример.
Допустим, вы занимаетесь продажей тормозных колодок в автомобильной отрасли. Люди не покупают тормозные колодки поштучно; они покупают их либо по две, либо по четыре. Итак, вопрос в том, если вы хотите сделать прогноз, вам может понадобиться прогнозировать вероятности того, что клиенты действительно придут купить определенный тип тормозных колодок. Это будет ваша первая случайная величина, которая дает вам вероятность наблюдения нулевого количества спроса, одного, двух, трех, четырех и т. д. для тормозных колодок. Затем у вас будет еще одно распределение вероятностей, которое представляет, будут ли люди покупать две или четыре тормозные колодки. Может быть, это будет 50 на 50, или может быть, это будет 10 процентов покупающих две и 90 процентов покупающих четыре. Важно то, что у вас есть эти два аспекта, и если вы хотите знать фактическое общее потребление тормозных колодок, вам нужно умножить вероятность того, что клиент придет за этими тормозными колодками, а затем распределение вероятностей покупки двух или четырех. Таким образом, вам нужно иметь это умножение этих двух неопределенных величин.
Здесь я предполагаю, что две случайные величины независимы. Кстати, это умножение случайных величин известно в математике как дискретная свертка. На скриншоте вы можете увидеть панель управления, сгенерированную Envision. В первых трех строках я выполняю этот расчет случайной алгебры, а затем в строках четыре, пять и шесть я отображаю эти вещи на веб-странице, в панели управления, сгенерированной сценарием. Я рисую, например, A1, B2, точно так же, как в таблице Excel. Панели управления Lokad организованы аналогично таблицам Excel, с позициями, имеющими столбцы B, C и т. д., и строками 1, 2, 3, 4, 5.
Вы можете видеть, что дискретная свертка, Z, имеет очень странный, супер-шипастый узор, который на самом деле очень часто встречается в цепях поставок, когда люди могут покупать пакеты, партии или множества. В такой ситуации обычно лучше разложить источники мультипликативных событий, связанных с партией или пакетом. Вам нужно иметь язык программирования, который имеет эти возможности под рукой, как граждане первого класса. Вот в чем именно суть вероятностного программирования, и вот как мы его реализовали в Envision.
Теперь давайте поговорим о дифференцируемом программировании. Я должен сделать здесь оговорку: я не ожидаю, что аудитория действительно поймет, что происходит, и прошу прощения за это. Это не значит, что у вас недостаточно интеллекта; просто этой теме требуется целая серия лекций. Фактически, если вы посмотрите на план предстоящих лекций, там есть целая серия, посвященная дифференцируемому программированию. Я собираюсь идти очень быстро, и это будет довольно загадочно, поэтому заранее прошу прощения.
Продолжим с проблемой цепи поставок, которая здесь представляет интерес, а именно каннибализация и замещение. Эти проблемы очень интересны и, вероятно, именно здесь прогнозирование временных рядов, которое является повсеместным, терпит наиболее жесткое поражение. Почему? Потому что часто у нас есть клиенты или потенциальные клиенты, которые обращаются ко мне и спрашивают, можем ли мы делать, например, прогнозы на 13 недель вперед для определенных товаров, таких как рюкзаки. Я бы сказал, да, мы можем, но очевидно, если мы возьмем один рюкзак и захотим спрогнозировать спрос на этот товар, это в значительной степени зависит от того, что вы делаете со своими другими рюкзаками. Если у вас есть всего один рюкзак, то, возможно, вы сосредоточите весь спрос на рюкзаки на этом одном товаре. Если вы вводите 10 разных вариантов, очевидно, будет много каннибализации. Вы не увеличите общее количество продаж в 10 раз только потому, что увеличили количество ссылок в 10 раз. Таким образом, очевидно, происходит каннибализация и замещение. Эти явления распространены в цепях поставок.
Как анализировать каннибализацию или замещение? То, как мы это делаем в Lokad, и я не претендую на то, что это единственный способ, но это, безусловно, работающий способ, заключается в том, чтобы обратить внимание на граф, который связывает клиентов и продукты. Почему так? Потому что каннибализация происходит, когда продукты конкурируют сами с собой за одних и тех же клиентов. Каннибализация - это буквально отражение того, что у вас есть клиент с потребностью, но у него есть предпочтения, и он выберет один продукт из набора продуктов, соответствующих его предпочтениям, и выберет только один. Вот суть каннибализации.
Если вы хотите проанализировать это, вам нужно анализировать не временные ряды продаж, потому что вы изначально не улавливаете эту информацию. Вы хотите проанализировать граф, который связывает исторические транзакции между клиентами и продуктами. Оказывается, что в большинстве бизнесов эти данные легко доступны. Для электронной коммерции это данность. Каждую единицу, которую вы продаете, вы знаете клиента. В B2B то же самое. Даже в B2C в рознице, большую часть времени розничные сети сегодня имеют программы лояльности, где они знают двузначный процент клиентов, которые приходят со своими картами, поэтому вы знаете, кто покупает что. Не для 100% трафика, но вам это не нужно. Если у вас есть 10% и более от ваших исторических транзакций, где вы знаете пару клиентов и продуктов, это достаточно хорошо для такого рода анализа.
В этом относительно небольшом фрагменте я подробно рассмотрю анализ аффинности между клиентами и продуктами. Это буквально первоначальный шаг, который вам нужно предпринять для анализа каннибализации. Давайте посмотрим, что происходит в этом коде.
Со строк с первой по пятую это очень обыденно; я просто считываю плоский файл, содержащий историю транзакций. Я просто считываю CSV-файл, в котором четыре столбца: дата, продукт, клиент и количество. Что-то очень простое. Я даже не использую все эти столбцы, но просто чтобы пример был более конкретным. В истории транзакций я предполагаю, что клиенты известны для всех этих транзакций. Так что это очень обыденно; я просто считываю данные из таблицы.
Затем, на строках седьмой и восьмой, я просто создаю таблицу для продуктов и таблицу для клиентов. В реальной производственной среде я обычно не создаю эти таблицы; я считываю эти таблицы из других плоских файлов в другом месте. Я хотел сделать пример максимально простым, поэтому я просто извлекаю таблицу продуктов из продуктов, которые я наблюдал в истории транзакций, и делаю то же самое для клиентов. Видите, это просто трюк, чтобы сделать все максимально простым.
Теперь, строки 10, 11 и 12 связаны с латинскими пространствами, и это становится немного запутанным. Сначала, на строке 10, я создаю таблицу с 64 строками. В таблице ничего нет; она определяется только тем, что имеет 64 строки, и все. Так что это как заполнитель, тривиальная таблица с множеством строк и без столбцов. Она не очень полезна просто так. Затем “P” - это в основном декартово произведение, математическая операция со всеми парами. Это таблица, в которой у вас есть одна строка для каждой строки в продуктах и каждой строке в таблице “L”. Таким образом, эта таблица “P” имеет на 64 строки больше, чем таблица продуктов, и я делаю то же самое для клиентов. Я просто увеличиваю эти таблицы через эту дополнительную размерность, которая представлена таблицей “L”.
Это будет моя поддержка для моих латинских пространств, которые я собираюсь изучить. Я хочу узнать, для каждого продукта латинское пространство, которое будет вектором из 64 значений, и для каждого клиента - латинское пространство из 64 значений. Если я хочу узнать взаимосвязь между клиентом и продуктом, я просто хочу иметь возможность выполнить скалярное произведение между ними. Скалярное произведение - это просто поэлементное умножение всех членов этих двух векторов, а затем сумма. Это может звучать очень технически, но это просто поэлементное умножение плюс сумма - это скалярное произведение.
Эти латинские пространства - это просто модные жаргонные выражения для создания пространства с параметрами, которые немного выдуманы, где я просто хочу научиться. Вся магия дифференцируемого программирования происходит всего за пять строк, с 14 по 18. У меня есть одно ключевое слово, “autodiff”, и “transactions”, которое говорит, что это таблица интереса, таблица наблюдений. Я собираюсь обрабатывать эту таблицу построчно для выполнения процесса обучения. В этом блоке я объявляю набор параметров. Параметры - это вещи, которые вы хотите изучить, как числа, но вы просто не знаете их значений еще. Эти вещи будут инициализированы случайным образом, с помощью случайных чисел.
Я ввожу “X”, “X*” и “Y”. Я не буду углубляться в то, что именно делает “X*”, может быть, вопросы. Я возвращаю выражение, которое является функцией потерь, и это сумма. Идея коллаборативной фильтрации или матричного разложения заключается в том, что вы хотите изучить латинские пространства, которые соответствуют всем вашим ребрам в вашем двудольном графе. Я знаю, что это немного технический термин, но то, что мы делаем, буквально очень просто с точки зрения цепочки поставок. Мы изучаем взаимосвязь между продуктами и клиентами.
Я знаю, что это, вероятно, кажется супер непрозрачным, но оставайтесь со мной, и будет еще лекции, где я дам вам более продуманное введение в это. Весь этот процесс выполняется всего за пять строк, и это совершенно замечательно. Когда я говорю пять строк, я не обманываю, говоря: “Смотрите, это всего лишь пять строк, но на самом деле я вызываю стороннюю библиотеку гигантской сложности, где я скрываю всю интеллектуальность”. Нет, нет, нет. Здесь, в этом примере, кроме двух ключевых слов “autodiff” и “params”, буквально нет магии машинного обучения. “Autodiff” используется для определения блока, в котором будет происходить дифференцируемое программирование, и, кстати, это блок, в котором я могу программировать все, так что буквально я могу внедрить нашу программу. Затем у меня есть “params” для объявления моих проблем, и это все. Итак, вы видите, здесь нет непрозрачной магии; нет библиотеки в миллион строк, которая делает всю работу за вас. Все, что вам нужно знать, буквально на этом экране, и вот в чем разница между программной парадигмой и библиотекой. Программная парадигма дает вам доступ к кажущимся невероятно сложным возможностям, таким как анализ каннибализации всего несколькими строками кода, без использования массовых сторонних библиотек, которые оборачивают сложность. Она превосходит проблему, делая ее намного проще, так что вы можете решить что-то, что кажется супер сложным, всего несколькими строками.
Теперь несколько слов о том, как работает дифференцируемое программирование. Есть два понятия. Одно из них - автоматическое дифференцирование. Для тех из вас, кто имел роскошь инженерного обучения, вы видели два способа вычисления производных. Существует символьная производная, например, если у вас есть x в квадрате, вы берете производную по x, и это дает вам 2x. Это символьная производная. Затем у вас есть численная производная, поэтому если у вас есть функция f(x), которую вы хотите дифференцировать, это будет f’(x) ≈ (f(x + ε) - f(x))/ε. Это численное дифференцирование. Оба не подходят для того, что мы пытаемся сделать здесь. Символьное дифференцирование имеет проблемы сложности, так как ваша производная может быть программой, которая намного сложнее исходной программы. Численное дифференцирование численно неустойчиво, поэтому у вас будет много проблем с численной стабильностью.
Автоматическое дифференцирование - это фантастическая идея, возникшая в 70-х годах и вновь открытая миром в последнее десятилетие. Это идея, что вы можете вычислить производную произвольной компьютерной программы, что поразительно. Еще более поразительно то, что программа, являющаяся производной, имеет ту же вычислительную сложность, что и исходная программа, что потрясающе. Дифференцируемое программирование - это просто комбинация автоматического дифференцирования и параметров, которые вы хотите изучить.
Как же вы учитесь? Когда у вас есть производная, это означает, что вы можете поднимать градиенты, и с помощью стохастического градиентного спуска вы можете вносить небольшие корректировки в значения параметров. Изменяя эти параметры, вы постепенно, через множество итераций стохастического градиентного спуска, сходитесь к параметрам, которые имеют смысл и достигают того, что вы хотите изучить или оптимизировать.
Дифференцируемое программирование может использоваться для решения задач обучения, подобной той, которую я иллюстрирую, где я хочу изучить взаимосвязь между моими клиентами и моими продуктами. Оно также может использоваться для численных оптимизационных задач, таких как оптимизация вещей при наличии ограничений, и оно очень масштабируемо как парадигма. Как вы можете видеть, этот аспект был сделан важным элементом в Envision. Кстати, еще есть несколько вещей, которые находятся в процессе разработки в терминах синтаксиса Envision, так что не ожидайте точно таких вещей пока; мы все еще уточняем несколько аспектов. Но суть в том, что она есть. Я не собираюсь обсуждать мелкие детали нескольких вещей, которые все еще развиваются.
Теперь перейдем к другой проблеме, связанной с готовностью вашей настройки к производству. Обычно в оптимизации цепочки поставок вы сталкиваетесь с так называемыми Heisenbugs. Что такое Heisenbug? Это раздражающий вид ошибки, при котором оптимизация происходит и приводит к некорректным результатам. Например, вы проводили пакетный расчет для пополнения запасов товаров на складе ночью, а утром обнаружили, что некоторые из этих результатов были бессмысленными, что привело к дорогостоящим ошибкам. Вы не хотите, чтобы эта проблема повторилась, поэтому вы повторно запускаете процесс. Однако, когда вы повторно запускаете процесс, проблема исчезает. Вы не можете воспроизвести проблему, и Heisenbug не проявляется.
Это может показаться странным крайним случаем, но в первые годы работы Lokad мы сталкивались с этими проблемами постоянно. Я видел множество инициатив в области управления цепочкой поставок, особенно в области науки о данных, которые потерпели неудачу из-за неразрешенных Heisenbugs. Они сталкивались с ошибками в производстве, пытались воспроизвести проблемы локально, но не могли этого сделать, поэтому проблемы так и оставались нерешенными. Через несколько месяцев в режиме паники весь проект обычно тихо закрывался, и люди возвращались к использованию электронных таблиц Excel.
Если вы хотите достичь полной воспроизводимости вашей логики, вам необходимо версионировать код и данные. Большинство людей в аудитории, которые являются программистами или учеными в области данных, могут быть знакомы с идеей версионирования кода. Однако вы также хотите версионировать все данные, чтобы, когда ваша программа выполняется, вы точно знали, какая версия кода и данных используется. Возможно, вы не сможете воспроизвести проблему на следующий день, потому что данные изменились из-за новых транзакций или других факторов, поэтому условия, вызывающие ошибку в первую очередь, больше не существуют.
Вы хотите убедиться, что ваша среда программирования может точно воспроизвести логику и данные такими, какими они были в производстве в определенный момент времени. Это требует полного версионирования всего. Опять же, язык программирования и стек программирования должны сотрудничать, чтобы это стало возможным. Это можно достичь без того, чтобы программная парадигма была гражданином первого класса вашего стека, но тогда ученому в области управления цепочкой поставок придется быть чрезвычайно осторожным во всех своих действиях и способе программирования. В противном случае он не сможет воспроизвести свои результаты. Это создает огромное давление на плечи ученых в области управления цепочкой поставок, которые уже находятся под значительным давлением со стороны самой цепочки поставок. Вы не хотите, чтобы эти профессионалы сталкивались с ненужной сложностью, такой как невозможность воспроизвести свои собственные результаты. В Lokad мы называем это “машиной времени”, где вы можете воспроизвести все в любой момент прошлого.
Осторожно, здесь не только речь идет о воспроизведении того, что произошло прошлой ночью. Иногда вы обнаруживаете ошибку через длительное время. Например, если вы размещаете заказ у поставщика с сроком поставки в три месяца, вы можете обнаружить через три месяца, что заказ был бессмысленным. Вам нужно вернуться на три месяца назад к моменту, когда вы сгенерировали этот фиктивный заказ, чтобы выяснить, в чем была проблема. Здесь речь не только о версионировании последних нескольких часов работы; это буквально о наличии полной истории последнего года выполнения.
Еще одна проблема - это рост программного обеспечения-вымогателя и кибератак на цепочки поставок. Эти атаки могут причинить огромный ущерб и быть очень дорогостоящими. При реализации программно-ориентированных решений вам необходимо учитывать, делаете ли вы свою компанию и цепочку поставок более уязвимыми для кибератак и рисков. С этой точки зрения Excel и Python не являются идеальными. Эти компоненты являются программными, что означает, что они могут иметь множество уязвимостей безопасности.
Если у вас есть команда ученых в области данных или ученых в области управления цепочкой поставок, которые занимаются проблемами цепочки поставок, они не могут позволить себе тщательный итеративный процесс рецензирования кода, который обычен в программной индустрии. Если тариф меняется за ночь или склад затопляется, вам нужен быстрый ответ. Вы не можете тратить недели на создание спецификаций кода, рецензий и т. д. Проблема заключается в том, что вы предоставляете возможности программирования людям, которые по умолчанию могут причинить вред компании случайно. Это может быть еще хуже, если есть намеренный злонамеренный сотрудник, но даже несмотря на это, у вас все равно есть проблема с тем, что кто-то случайно раскрывает внутреннюю часть ИТ-системы. Помните, что системы оптимизации цепочки поставок, по определению, имеют доступ к большому объему данных по всей компании. Эти данные являются не только активом, но и обязательством.
То, что вам нужно, это программная парадигма, которая способствует безопасному программированию. Вам нужен язык программирования, в котором есть целые классы вещей, которые вы не можете делать. Например, зачем вам язык программирования, который может выполнять системные вызовы для оптимизации цепочки поставок? Python может выполнять системные вызовы, также как и Excel. Но зачем вам программируемая система с такими возможностями вообще? Это похоже на покупку пистолета, чтобы застрелить себе ногу.
Вам нужно что-то, где отсутствуют целые классы или функции, потому что вам они не нужны для оптимизации цепочки поставок. Если эти функции присутствуют, они становятся огромной уязвимостью. Если вы вводите программные возможности без инструментов, которые обеспечивают безопасное программирование по дизайну, вы увеличиваете риск кибератак и вымогательства, делая ситуацию еще хуже.
Конечно, всегда можно компенсировать увеличением размера команды кибербезопасности, но это очень дорого и не идеально в случае срочных ситуаций в цепочке поставок. Вам нужно действовать быстро и безопасно, без времени на обычные процессы, обзоры и утверждения. Вы также хотите безопасного программирования, которое устраняет мелкие проблемы, такие как исключения нулевой ссылки, ошибки нехватки памяти, циклы с смещением на единицу и побочные эффекты.
В заключение, важны инструменты. Есть поговорка: “Не берите меч на пистолетный бой”. Вам нужны правильные инструменты и программные парадигмы, а не только те, которые вы изучили в университете. Вам нужно что-то профессиональное и готовое к производству, чтобы удовлетворить потребности вашей цепочки поставок. Хотя вы можете достичь некоторых результатов с неполноценными инструментами, это не будет великолепно. Фантастический музыкант может создавать музыку просто ложкой, но с правильным инструментом он может сделать гораздо лучше.
Теперь перейдем к вопросам. Обратите внимание, что есть задержка около 20 секунд, поэтому есть некоторая задержка в потоке между видео, которое вы видите, и моим чтением ваших вопросов.
Вопрос: Что насчет динамического программирования с точки зрения операционного исследования?
Динамическое программирование, несмотря на название, не является программной парадигмой. Это скорее алгоритмическая техника. Идея заключается в том, что если вы хотите выполнить алгоритмическую задачу или решить определенную проблему, вы будете часто повторять одну и ту же подоперацию. Динамическое программирование является конкретным случаем компромисса между пространством и временем, о котором я упоминал ранее, где вы вкладываете немного больше памяти, чтобы сэкономить время на вычислениях. Это была одна из первых алгоритмических техник, которая появилась в 60-х и 70-х годах. Это хорошая техника, но название немного неудачное, потому что в ней нет ничего действительно динамичного, и это не совсем о программировании. Это скорее о концепции алгоритмов. Так что, по моему мнению, несмотря на название, оно не квалифицируется как программная парадигма; это скорее конкретная алгоритмическая техника.
Вопрос: Джоханнес, не могли бы вы дать некоторые рекомендуемые книги, которые должен иметь каждый хороший инженер цепочки поставок? К сожалению, я новичок в этой области, и мое текущее внимание сосредоточено на науке о данных и системном инжиниринге.
У меня очень смешанное мнение о существующей литературе. В своей первой лекции я представил две книги, которые, по моему мнению, являются вершиной академических исследований в области цепочки поставок. Если вы хотите прочитать две книги, вы можете прочитать эти книги. Однако у меня постоянная проблема с книгами, которые я прочитал до сих пор. По сути, есть люди, которые представляют коллекции игрушечных численных рецептов для идеализированных цепочек поставок, и я считаю, что эти книги не подходят к проблеме цепочки поставок с правильной стороны, и они полностью упускают то, что это сложная проблема. Есть обширное количество литературы, которая очень технична, с уравнениями, алгоритмами, теоремами и доказательствами, но я считаю, что она совершенно не понимает суть проблемы.
Затем у вас есть еще один стиль книг по управлению цепями поставок, которые больше похожи на консультационные. Вы легко узнаете эти книги, потому что они используют спортивные аналогии каждые две страницы. В этих книгах есть все виды упрощенных диаграмм, таких как 2x2 варианты диаграмм SWOT (Strengths, Weaknesses, Opportunities, Threats), которые я считаю низкокачественными способами рассуждения. Проблема этих книг в том, что они обычно лучше понимают, что управление цепями поставок - это сложное дело. Они гораздо лучше понимают, что это игра, в которой происходят самые разные странные вещи, и вы можете быть умными в терминах подходов. Я признаю им это. Проблема с этими книгами, обычно написанными консультантами или профессорами школ управления, заключается в том, что они не очень действенны. Суть сводится к “будьте лучшим лидером”, “будьте умнее”, “имейте больше энергии”, и для меня это не действенно. Он не дает вам элементы, которые вы можете превратить в нечто очень ценное, как это может сделать программное обеспечение.
Итак, я возвращаюсь к первой лекции: прочитайте две книги, если хотите, но я не уверен, что это будет время, проведенное с пользой. Хорошо знать, что люди написали. В отношении консультационной литературы мой фаворит, вероятно, это работа Катаны, которую я не упомянул в первой лекции. Не все плохо; у некоторых людей есть больше таланта, даже если они больше похожи на консультантов. Вы можете ознакомиться с работой Катаны; у него есть книга о динамических цепях поставок. Я добавлю эту книгу в список литературы.
Вопрос: Как вы используете параллелизацию при работе с каннибализацией или принятии решений о ассортименте, когда проблему не так легко параллелизовать?
Почему это не так легко параллелизовать? Стохастический градиентный спуск довольно прост в параллелизации. У вас есть стохастические градиентные шаги, которые можно выполнять в случайном порядке, и вы можете выполнять несколько шагов одновременно. Так что я считаю, что все, что основано на стохастическом градиентном спуске, довольно просто параллелизовать.
При работе с каннибализацией более сложно справиться с другим видом параллелизации, а именно с тем, что делать в первую очередь. Если я помещаю этот продукт первым, затем делаю прогноз, но затем беру другой продукт, это изменяет ситуацию. Ответ заключается в том, что вы хотите иметь способ решить всю ситуацию фронтально. Вы не говорите: “Сначала я представляю этот продукт и делаю прогноз; я представляю другой продукт, а затем повторно делаю прогноз, изменяя первый”. Вы просто делаете это фронтально, все эти вещи одновременно, одновременно. Вам нужны более продвинутые программные парадигмы. Программные парадигмы, которые я представил сегодня, могут долго помочь в этом.
Когда дело доходит до принятия решений о ассортименте, такие проблемы не представляют больших трудностей для параллелизации. То же самое относится, если у вас есть мировая розничная сеть, и вы хотите оптимизировать ассортимент для всех ваших магазинов. Вы можете выполнять вычисления параллельно для всех магазинов. Вы не хотите делать это последовательно, где вы оптимизируете ассортимент для одного магазина, а затем переходите к следующему магазину. Это неправильный способ сделать это, но вы можете оптимизировать сеть параллельно, распространять всю информацию, а затем повторять. Есть все виды техник, и инструментарий может значительно помочь вам сделать это гораздо проще.
Вопрос: Вы используете подход графовой базы данных?
Нет, не в техническом, каноническом смысле. На рынке есть много графовых баз данных, которые представляют большой интерес. То, что мы используем внутри Lokad, - это полная вертикальная интеграция через унифицированный, монолитный компиляторный стек, чтобы полностью устранить все традиционные элементы, которые вы найдете в классическом стеке. Именно так мы достигаем очень хорошей производительности в терминах вычислительной производительности, очень близкой к металлу. Не потому, что мы фантастически умные программисты, а просто потому, что мы удалили практически все слои, которые традиционно существуют. Lokad вообще не использует базу данных. У нас есть компилятор, который заботится обо всем, вплоть до организации структур данных для сохранения. Это немного странно, но это намного эффективнее делать так, и таким образом вы гораздо лучше соответствуете тому факту, что вы компилируете скрипт на флот машин в облаке. Ваша целевая платформа в терминах аппаратного обеспечения - это не одна машина, а флот машин.
Вопрос: Каково ваше мнение о Power BI, который также выполняет коды Python и связанные алгоритмы, такие как градиентный спуск, жадный и т. д.?
Проблема, которую я имею с чем-либо, связанным с бизнес-аналитикой, включая Power BI, заключается в том, что у него есть парадигма, которую я считаю неадекватной для цепочки поставок. Вы видите все проблемы как гиперкуб, где у вас есть измерения, которые вы только нарезаете и нарезаете. В основе у вас есть проблема экспрессивности, которая очень ограничена. Когда вы используете Power BI с Python посередине, вам нужен Python, потому что экспрессивность, связанная с гиперкубом, очень низкая. Чтобы вернуть экспрессивность, вы добавляете Python посередине. Однако помните то, что я сказал в предыдущем вопросе о тех слоях: проклятие современного предприятия заключается в том, что у вас слишком много слоев. Каждый отдельный слой, который вы добавляете, будет вводить неэффективности и ошибки. Если вы используете Power BI плюс Python, у вас будет слишком много слоев. Итак, у вас есть Power BI, который находится поверх других систем, что означает, что у вас уже есть несколько систем перед Power BI. Затем у вас есть Power BI сверху, и над Power BI у вас есть Python. Но действует ли Python сам по себе? Нет, вероятно, вы будете использовать библиотеки Python, такие как Pandas или NumPy. Итак, у вас есть слои в Python, которые будут накапливаться, и вы получите десятки слоев. В любом из этих слоев могут быть ошибки, поэтому ситуация будет довольно кошмарной.
Я не верю в такие решения, где вы просто получаете огромное количество стеков. Есть такая шутка, что в C++ вы всегда можете решить любую проблему, добавив еще один уровень косвенности, включая проблему слишком многих уровней косвенности. Очевидно, это немного бессмысленное утверждение, но я глубоко не согласен с подходом, когда у людей есть продукт с неадекватным основным дизайном, и вместо того, чтобы решать проблему фронтально, они начинают добавлять вещи сверху, в то время как основы шаткие. Это не тот путь, и у вас будет низкая производительность, непрекращающиеся битвы с ошибками, которые вы никогда не решите, а затем, в плане поддержки, это просто рецепт для кошмара.
Вопрос: Как результаты анализа коллаборативной фильтрации могут быть встроены в алгоритм прогнозирования спроса для каждого продукта, например, рюкзаков?
Извините, но я расскажу об этой теме на следующей лекции. Краткий ответ заключается в том, что вы не хотите вставлять это в существующий алгоритм прогнозирования. Вам нужно иметь что-то, что намного более интегрировано. Вы не делаете это, а затем возвращаетесь к старым способам прогнозирования; вместо этого вы просто отбрасываете старый способ прогнозирования и делаете что-то радикально отличное, что использует это. Но я обсуду это на следующей лекции. Сегодня это будет слишком много.
Думаю, это все для этой лекции. Большое спасибо всем за участие. Следующая лекция состоится в среду, 6 января, в то же время, в тот же день недели. Я собираюсь взять небольшой отпуск на Рождество, поэтому желаю всем счастливого Рождества и счастливого Нового года. Мы продолжим нашу серию лекций в следующем году. Большое спасибо всем.
