Machine Learning again

[tessob]

Наверное, Вы имеете в виду спектр алгоритмов, а не задач. Задач, как раз, много решить можно.

Нет, я имею ввиду именно задачи. Я просто не вижу этого значительного числа задач, которые можно было бы решать с помощью ML. Большая часть попыток имплементации алгоритмов ML к прикладным задачам бизнеса, из тех, что я видел/слышал, закончилась полным провалом. Градус недоверия к DS хайпу со стороны бизнеса, на мой взгляд, только растет.

Под ML я тут понимаю алгоритмы регрессии, классификации и кластеризации.

Насчёт оптимизации ... Во-первых, МЛ и есть оптимизация. Во-вторых, далеко не все задачи сводятся именно к выпуклой оптимизации. Пример из МЛ - глубокое обучение и нетворк. А уж если брать задачи из "жизни" ... недаром возникла, например, область генетических алгоритмов.

Как это ни странно, но очень широкий спектр реальных задач хорошо сводится к задаче линейного программирования и является вполне себе выпуклыми. Даже 7/12 землекопа часто не являются проблемой, если, например, ЛП используется для оценки качества целочисленной оптимизации. Что касается метаэвристик, то в моей практике они имеют очень широкое применение. Правда я предпочитаю алгоритмы Дориго (муравьиные алгоритмы). Мне удавалось добиваться с их помощью лучших результатов, чем с другими. Хотя тут выбор алгоритма - больше вкусовщина.

Я люблю использовать термин quantitative methods. Сюда можно и ряды поставить, и диффуры и другие.

Использую абсолютно аналогичный термин.

[Физик-Лирик]

Нет, я имею ввиду именно задачи. Я просто не вижу этого значительного числа задач, которые можно было бы решать с помощью ML. Большая часть попыток имплементации алгоритмов ML к прикладным задачам бизнеса, из тех, что я видел/слышал, закончилась полным провалом. Градус недоверия к DS хайпу со стороны бизнеса, на мой взгляд, только растет.
Под ML я тут понимаю алгоритмы регрессии, классификации и кластеризации.

Возможно, мы работаем в разных областях, но я наоборот придерживаясь мнения, что круг (бизнес) задач достаточно большой. Другое дело, что бизнес относится с недоверием в силу непонимания того, на что способны алгоритмы.
К какому типу алгоритмов Вы относите задачи эпидемиологии? Например, функции риска (хазардные функции)?
Или временные ряды? Ведь авторегрессионная модель - чистая линейная регрессия.

Как это ни странно, но очень широкий спектр реальных задач хорошо сводится к задаче линейного программирования и является вполне себе выпуклыми.

В основном, к линейном программированию сводятся "бюджетные" задачи эҡонометрики. И тогда берём симлекс и фигарим. Большинство же оптимизационных задач явно нелинейные. И даже невыпуклые. И многие даже плохообусловленные. Опять, зависит от области. Ещё более прикольные задачи оптимизации в гильбертовых пространствах, например, нахождения оптимальных функций. Они вообще могут быть сведены к решению диффуров в частных производных. В общем, всё зависит.

[tessob]

Возможно, мы работаем в разных областях, но я наоборот придерживаясь мнения, что круг (бизнес) задач достаточно большой. Другое дело, что бизнес относится с недоверием в силу непонимания того, на что способны алгоритмы.

Если вы из R&D, тогда в разных. Весь мой круг интересов сосредоточен в Operations. Соответственно, чаще сталкиваюсь со следующими задачами, куда пытаются "прикладывать" ML:

• IoT и прогнозирование отказов. На практике навешивать на оборудование датчики достаточно проблематично по целому ряду причин. Во-первых, нужно обучать инженеров как обслуживать все это. Во-вторых, нужно организовывать передачу данных, что довольно проблематично делать по воздуху, т.к. кругом, как правило, метал. Далее никто не гарантирует, что после этого в данных будет обнаружен сигнал. Более того, никто не гарантирует, что модель окажется переносимой и сможет работать на другом аналогичном оборудовании. Без переносимости такая модель скорее всего будет перекрывать по стоимости само оборудование, и иногда в разы. У среднего серийного производства от пары тысяч уникальных единиц оборудования, которое может не дублироваться. Соответственно под каждое нужно обучать свою модель. Про проблемы обучения модели я уже писал в какой-то другой теме.
• Прогнозирование спроса (запасов). На практике не всегда получается проводить даже "like-for-like" анализ. Многие позиции не живут в ассортименте более пары лет. Значительная часть может участвовать в различных акциях (скидки, подарки и т.п.). Продукция на время может замещаться акционной (+20%). Причем просто факт акции добавить в модель недостаточно, т.к. провальные акции тоже случаются (когда продажи падают во время акции). Еще бывает смена артикулов поставщика. Продукция отличающаяся только цветом может вестись как разные SKU.
• Ценообразование. В теории можно взять KNN, сказать, что К=4 и считать цену. На практике элементарно может получится, что равноудаленными окажутся 15-20 аналогичных позиций. Взять, например, какое-нибудь вино. В теории у него полно различных признаков (цвет, сорт, кислотность, медали, сульфаты, регион и т.п.). Только по факту никто это в своих ERP системах не ведет, т.к. трудоемко. В итоге вино за 100$ будет иметь идентичные признаки с вином за 5$.

Можно еще долго продолжать перечислять популярные кейсы и их проблемы. Если говорить про актуарные и скоринговые модели, то там ML применяли еще до хайпа и вполне успешно. Только доверие бизнеса к технологиям, на мой взгляд, подрывают факты, когда подобные проекты продают клиенту, а на выходе он получает облако и кучу бесполезных данных со странными отчетами.

К какому типу алгоритмов Вы относите задачи эпидемиологии? Например, функции риска (хазардные функции)? Или временные ряды? Ведь авторегрессионная модель - чистая линейная регрессия.

Временные ряды отношу скорее к ML. С остальным не сталкивался.

В основном, к линейном программированию сводятся "бюджетные" задачи эҡонометрики. И тогда берём симлекс и фигарим. Большинство же оптимизационных задач явно нелинейные. И даже невыпуклые. И многие даже плохообусловленные. Опять, зависит от области. Ещё более прикольные задачи оптимизации в гильбертовых пространствах, например, нахождения оптимальных функций. Они вообще могут быть сведены к решению диффуров в частных производных. В общем, всё зависит.

Иногда (в моей области) можно притвориться, что все линейное и фигарить симплекс-методом. Как-то в книжке по исследованию операций встретил хорошую фразу: "Исследование операций - это искусство давать плохие ответы в ситуации, когда все остальные ответы еще хуже."

[Физик-Лирик]

Вообще, ML и алгоритмы - это очень малая и самая простая часть DS.

Напрашивается естественный вопрос, а что есть самая большая и самая сложная часть ДС?
Я то как раз и считаю, что ДС - это именно МЛ и алгоритмы. Данные, их подготовка и обработка - это составная часть алгоритмов. Анализ данных, их понимание, анализ модели, её валидация - неотъемлемые части алгоритмов. Что же тогда осталось? Хранение данных и ЕТЛ - это не ДС, а дейта инжиниринг. Собственно чем раньше занимались сиквельщики, а теперь ещё и хадубщики.

[Физик-Лирик]

Если вы из R&D, тогда в разных. Весь мой круг интересов сосредоточен в Operations. Соответственно, чаще сталкиваюсь со следующими задачами, куда пытаются "прикладывать" ML:

Так и в R&D - тоже МЛ прикладывают. Хотя разные R&D бывают
Кстати, возвращаясь к МЛ, есть ещё рекомендации, типа маркет баскет.

[iDesperado]

Напрашивается естественный вопрос, а что есть самая большая и самая сложная часть ДС?
Я то как раз и считаю, что ДС - это именно МЛ и алгоритмы. Данные, их подготовка и обработка - это составная часть алгоритмов. Анализ данных, их понимание, анализ модели, её валидация - неотъемлемые части алгоритмов. Что же тогда осталось? Хранение данных и ЕТЛ - это не ДС, а дейта инжиниринг. Собственно чем раньше занимались сиквельщики, а теперь ещё и хадубщики.

со стороны программера это звучит и выглядит очень, очень странно. у нас точно так же каждый аналитик воротит свой анализ, свои очистки и валидации. в результате под каждое понятие создается 100500 интерпритаций с мизерными отличиями. дальше вся эта дребедень с мизерными отличиями (зачастую различия лишь в форматировании) идет в отчетные системы, KPI и модели.

[tessob]

Я работаю в электричестве. Работы непочатый край. Оптимизировать можно очень много, если улучшить элементарный прогноз потребления электроэнергии и газа на ближайший день. В настоящий момент ошибка прогноза 10-25%, работает линейная регрессия в Excel, переменные - температура и её производные, всё.

Я работал с аналогичной задачей несколько раз. Правда, каждый раз в генерации. Кстати тема очень хорошо изучена в СССР. Полно монографий и статей. Так что, оооочень рекомендую обратиться к сокральным знаниям исторической родины.

Если кратко, то у вас есть несколько явных циклов: дневной, недельный, годовой. Это покрывает суточные колебания, недельные, сезонность и праздники. Есть менее явные двухгодовой и четырехлетний. Последние два описывают всякие спортивные мероприятия и т.п. Для некоторых регионов России, в теплое время года значим погодный фактор. В плохую погоду потребление выше. Все эти циклы легко снимаются послойно простой AR моделью. Причем AR будет значительно лучше, чем ARMA, т.к. скользящее среднее будет сильно загрязнять модель. Далее, если вычесть полученную модель из исходных данных, то останется только шум и разовые фестивали. Шум - это следствие случайного процесса, лучшее, что вы сможете из него получить - это только дисперсия. Если дисперсия мала - хорошо. Если нет, то вы на это никак не повлияете.

Такая ситуация в большинстве электрических компаний сейчас в Австралии, однако, уже наступил кризис в индустрии. Начались black-outs, и цены на электричество выросли в выросли в 3 раза за последний год. Население бунтует. Политики забегали. Появляются новые мелкие retailers, которые строят бизне исключительно на data science: all-you-can-eat plans, дают торговать электричеством простым клиентам, а также virtual power plant системы.

У вас кризис скорее всего и обусловлен попыткой экономить. Просто генерация должна четко понимать сколько нужно выдать на следующий день, т.к. от этого зависит схема включения турбин и режимы их работы. Перепроизводство в любом случае должен кто-то оплачивать из своего кармана. Иначе будут отключения. Собственно, что вы и имеете. Единственный способ избегать перепроизводства - это заставить конечного потребителя приобретать ЭЭ по предоплате. Только мне кажется, что тогда этот потребитель придет на следующие выборы в плохом настроении. Мне кажется, что в данном случае вместо DS бума найдут крайнего, кто возьмет на себя потери от перепроизводства. Хотя это может подтолкнуть рынок аккумуляторов, чтоб можно было скупать излишки ЭЭ по низкой цене и использовать позже.

З.Ы. И ващще вы тут последняя индустрия на паровой тяге!

[tessob]

Кстати, возвращаясь к МЛ, есть ещё рекомендации, типа маркет баскет.

Да, целый один алгоритм (fp-growth).
Я согласен, что он хорошо должен работать в Amazon. Однако в магазине утюгов он уже работать так хорошо не будет, т.к. мало кто покупает утюги наборами. Его полезность очень сильно зависит от ассортимента. Однако, думаю, во всяких медиа-сервисах он должен хорошо себя показывать, т.к. их задача максимально долго удерживать внимание пользователя.

[Физик-Лирик]

Кстати, возвращаясь к МЛ, есть ещё рекомендации, типа маркет баскет.

Да, целый один алгоритм (fp-growth).

Ну почему один? Существуют разные типы сравнения, основанные на разных функциях расстояния. Также рекомендации на основе сравнения пользователей и товаров. Существуют модификации "корзин", не зависящих и зависящих от времени.
Опять возвращаясь к МЛ, ... аутлайеры. Очень популярная тема сейчас. Большое количество методов. Применение для очень многомерных пространств. Аутлайеры посредством супервайзд МЛ (типа одноклассовых методов, например, СВМ).
Выше Вы упомянули метод ближайшего соседа. Но ведь он может не сработать в многомерных пространствах в силу своей нелокальности. Что тогда?

[Физик-Лирик]

Если кратко, то у вас есть несколько явных циклов: дневной, недельный, годовой. Это покрывает суточные колебания, недельные, сезонность и праздники. Есть менее явные двухгодовой и четырехлетний. Последние два описывают всякие спортивные мероприятия и т.п. Для некоторых регионов России, в теплое время года значим погодный фактор. В плохую погоду потребление выше. Все эти циклы легко снимаются послойно простой AR моделью. Причем AR будет значительно лучше, чем ARMA, т.к. скользящее среднее будет сильно загрязнять модель. Далее, если вычесть полученную модель из исходных данных, то останется только шум и разовые фестивали. Шум - это следствие случайного процесса, лучшее, что вы сможете из него получить - это только дисперсия. Если дисперсия мала - хорошо. Если нет, то вы на это никак не повлияете.

Скорее SARIMA. Можно попробовать ЕТС (экспоненциальное сглаживание). Кстати, для моделирования временных процессов временные ряды могут быть не лучшим выбором.

[tessob]

Ну почему один? Существуют разные типы сравнения, основанные на разных функциях расстояния. Также рекомендации на основе сравнения пользователей и товаров. Существуют модификации "корзин", не зависящих и зависящих от времени.

Не поделитесь ссылками? Это не совсем моя тематика, но с удовольствием почитаю.

Выше Вы упомянули метод ближайшего соседа. Но ведь он может не сработать в многомерных пространствах в силу своей нелокальности. Что тогда?

Я его упомянул в контексте задачи ценообразования. Там у него несколько огромных плюсов:

1. Его легко объяснить, т.к. мы всегда можем вытащить те товары, которые приняли участие в скоринге.
2. Можно легко ограничить аутлаеров. Так как если мы "неожиданно" включили в ассортимент очень дорогой товар, можно настроить модель таким образом, чтобы она отдавала решение человеку, а не назначала слишком низкую цену.
3. Аутлаеры влияют на модель, даже если их не очень много.

[tessob]

Скорее SARIMA. Можно попробовать ЕТС (экспоненциальное сглаживание). Кстати, для моделирования временных процессов временные ряды могут быть не лучшим выбором.

Сложные модели не дают значимого прироста качества. Имея априорные знания о циклах их уже достаточно просто можно вытащить слой за слоем. Тут больший эффект может дать знание о начале и конце рабочего дня, времени проводимом в пробках, среднем возрасте популяции. Еще форма суточных графиков может отличаться между городами и регионами. Умение включить в выборку "правильные" данные имеет значительно больший вес, чем выбор алгоритма.

[Физик-Лирик]

Не поделитесь ссылками? Это не совсем моя тематика, но с удовольствием почитаю.

Например, первая книга по Махауту, который в действии (хотя, может она и последняя ). Очень неплохо описаны методы.
Аутлайеры - это целая область. Согласен, много где используется.
Ваш последний пост - хорошая иллюстрация по поводу "самой малой и самой простой части ДС". Собственно, это и есть настоящий ДС.

со стороны программера это звучит и выглядит очень, очень странно. у нас точно так же каждый аналитик воротит свой анализ, свои очистки и валидации. в результате под каждое понятие создается 100500 интерпритаций с мизерными отличиями. дальше вся эта дребедень с мизерными отличиями (зачастую различия лишь в форматировании) идет в отчетные системы, KPI и модели.

Увы, такое тоже бывает.

[Физик-Лирик]

Совершенно верно, правильные данные важнее алгоритма.

И то и другое важно.

Общий вопрос. Есть ли какие вести с полей, где урожай пожирает злобный товарищ по имени bias? Что-нибудь новенькое в теории есть?

[Flash-04]

Кстати Амазоне стал предлагать сервис распознавания изображений. Rekognit.

[tessob]

Вторая причина, почему такая высокая ошибка, - мы (это я про всю индустрию сейчас говорю) не знаем точно потребление электричества в предыдущую единицу времени.

Честно говоря я тогда не очень понимаю, что именно вы пытаетесь спрогнозировать и для какой цели. Просто, с моей колокольни, электрическая генерация - это очень высокоинертная система. Любое управляющее воздействие будет идти с огромным лагом (часы). Смысл оперативного прогнозирования?

Флешмоб сварщиков предсказать все равно не получится, если они собираются не каждый вторник. Все остальное у вас достаточно хорошо объясняется историческими данными. У вас же основные потребители: крупные предприятия, городская инфраструктура и домохозяйства.

[tessob]

У нас не только retail utility, но ещё и электростанции. Если мы знаем, сколько наши клиенты потребляют электричества, мы можем соответственно делать dynamic hedging, т.е. on/off генераторы в реальном времени.

Вам просто нужно подойти к энергетикам на станции и попросить данные по разнице мощностей. Вы в реальном времени увидите сколько они генерируют и сколько потребляется в сети. Кроме того у них есть SCADA-системы, с которых вы можете собирать эти данные удаленно, если у вас несколько станций. Более того, вы можете вытаскивать из SCADA ваш dynamic hedging, т.к. энергетики в течении дня динамически хеджат режимы работы турбин (схема чуть сложнее, чем вкл/выкл генератора).

Что касается самой задачи, то она, мягко говоря, странная. Ее можно сформулировать немного проще. Предположим, что есть ассиметричная монетка, где орел выпадает с вероятностью 0.7 (решка 0.3). Вы играете в игру с единственным оппонентом и называете сторону, которая выпадет следующей. Если вы выигрываете, то получаете 1$, если проигрываете, то платите его. Нужно просто ставить на орла. Вы же пытаетесь строить модель случайного процесса, основывая свой выбор на предыдущих значениях. Это только математическая сторона. С практической стороны к сети подключены не только ваши станции, и они тоже делают dynamic hedging. По-хорошему, еще у вас на рынке должен быть регулятор, который разделяет мощности между станциями. Просто станции работают далеко не на 100% своей мощности, т.к. как конкуренция.

Я уверен, что скоро бум DS в Австралийской энергетике сойдет на нет.

[blanko27]

Вам просто нужно подойти к энергетикам на станции и попросить данные по разнице мощностей.

Шурик, вы комсомолец? Это же не наш метод!

[RedPanda]

3-4 часа в день - это афигеть как много. Я занимаюсь 1-2 час в день, в выходные 2-3 часа в день. Заканчиваю седьмой год, за это время прошла 2 года бакалавра, плюс два года мастера в статистике, параллельно научилась программировать. Фултайм работу и семью никто не отменял.

А кем же вы изначально работали, если все образование получили уже работая и программировать не умели?

[tessob]

Вы не поняли мою проблему, может быть я плохо объясняю. Мне не надо ходить на станции, у меня есть все данные по генераторам в реальном времени, включая scada и dispatch, это как бы public knowledge. Чего у меня нет, это данных по потреблению каждым клиентом в реальном времени, и я уверена, что если бы эти данные были доступны, решились бы многие проблемы на уровне страны. Не все, но многие.

Я правда не понимаю как знания об объеме потребления каждым отдельным клиентом могут улучшить существующую модель управления режимами работы турбин. Объем потребления конечных потребителей будет всегда меньше величины генерации на случайную величину с большой дисперсией. Просто на практике наблюдается большой "падеж" электронов. Далеко не всем из них суждено благополучно добраться до потребителя. Часть рассеется в воздухе, часть сгинет в трансформаторах...

Более того, если такие потери являются случайной величиной, а сама задача является попыткой оптимизировать функцию от объема потребления и случайной величины, то результатом такой функции тоже будет случайная величина. Можно заменить случайную величину потерь мат ожиданием, но при большой дисперсии это будет уже "оптимизация средней по больнице".

Вот, что-то внутри меня негодуэ от осознания всего этого...

[Think_Different]

вы, скорее всего, не понимаете что такое dynamic hedging. dynamic hedging это не оптимизационная задача. it's a replication problem.

[tessob]

it's a replication problem.

Впервые встречаю этот термин. А Google, собака, отправляет меня генетику учить...

[Think_Different]

https://en.wikipedia.org/wiki/Replicating_portfolio

http://www.efrag.org/Assets/Download?as ... eSupport=1

Думаю будет проще если Королева вам на пальцах объяснит суть задачи

[tessob]

Думаю будет проще если Королева вам на пальцах объяснит суть задачи

Как я понял, это про commodity (приобретение топлива). Мне казалось, что мы говорили про генерацию (сжигание топлива).
Да, думаю нужно подождать Королеву.

[Deckel]

Хорошая статья по теме http://www.kdnuggets.com/2017/03/6-busi ... icorn.html