Forwarded from Время Валеры
В рамках написания книги по Мл систем дизайну и главы про метрики, прочитал статью Evaluating predictive count data distributions in retail sales forecasting
Статья от Академика, но неплохая, более менее понятная, а как вы знаете, любая статья которую я могу понять - хорошая
В статье разбирается следующая проблема. Прогноз спроса - вещь важная, которую решают многие люди и организации. При этом решают они эту проблему зачастую используя неподходящие метрики/функции потерь. Потому как во первых очень часто природа прогнозируемых данных дискретна - если мы прогнозируем продажи товаров (SKU) они кратны единице учета, нельзя продать 1.5 шампуня. Во вторых спрос вещь прерывистая, продажи определенного товара легко могут упасть в ноль
Если агрегировать данные и прогнозировать что-то продающееся в больших объемах, то тогда конечно можно использовать методы, подходящие для непрерывных данных, но как только мы хотим идти глубже, начинаются проблемы при использовании классических методов
В чем проблемы ?
1. Абсолютные ошибки, MAE оптимизирует - медиану, а тот же wMAPE это по факту MAE разделенное на среднее и даже MASE(mean absolute scaled error) почти тоже самое.
Выбор между средним и медианой не самая большая проблема если распределение симметрично, но это не так в случае дискретных распределений с возможностью падением в ноль
Кроме того оптимизация медианы приводит к смещению, что легко доказать
As an example, assume that f = Pois(λ) for λ < log 2 ≈ 0.693. In this case, the median of f is 0, whereas its expectation is λ. The EMAD-optimal point forecast is 0, regardless of whether λ = 0.01, λ = 0.1 or λ = 0.5. Thus, an EMAD-optimal point forecast will be biased downward. Similarly, if log 2 < λ < λ0 , where λ0 ≈ 1.678 satisfies λ0 e−λ0 + e−λ0 = 12 , then the E MAD-optimal point forecast will be 1, which is biased upward for log2 < λ < 1 and downwardfor1<λ<λ0.
2. Ошибки в процентах тоже не подходят. MAPE не определена в нуле, а symmetric MAPE на самом деле не симметричный, кроме того smape ломается если и предикт и факт равны нулю
3. Квадратичные ошибки - чувствительны к выбросам, но хотя бы могут быть несмещенными (плюс пара интересных заметок про GMAE и GRMSE)
4. Относительные ошибки - Prominent variations are the median relative absolute error (MdRAE) and the geometric mean relative absolute error (GMRAE). Часты они сравнивают абсолютные ошибки - смотри п.1, если сравнивать с бенчмарками, то те могут выдавать ноль и снова неопределенность в нуле
5. Ранжирующие ошибки - Mean Squared Rank и Mean Absolute Rank, пытаются оценить насколько хорошо прогноз оценивает средний спрос на возрастающем отрезке времени. Интересный подход, но недостаток в том, что больший вес задается ближайшему будущему. В принципе может быть именно это и нужно, но хотелось бы уметь задавать веса
6. Scaled Errors - признаны в статье самым многообещающим подходом. sMSE - усредненный квадрат ошибки. (MSE где предикт получается регрессией факта на предикт с изначальной модели). Хотя все еще могу быть чувствительны к перепрогнозу
Все конечно здорово, но есть еще одна проблема, это все точечные оценки, а хочется уметь оценивать распределение. Потому что нам нужно знать не среднее, а вероятность какого-то события, то есть распределение. Можно конечно идти в оценку определенных квантилей, но что если нам нужно много разных квантилей? Делать много моделей/оценок или все же научиться оценивать распределение?
Здесь мы подходим к тому, что-же предложили пацаны
Возникает вопрос, стоит ли это разбирать?
#ArticleReview
Статья от Академика, но неплохая, более менее понятная, а как вы знаете, любая статья которую я могу понять - хорошая
В статье разбирается следующая проблема. Прогноз спроса - вещь важная, которую решают многие люди и организации. При этом решают они эту проблему зачастую используя неподходящие метрики/функции потерь. Потому как во первых очень часто природа прогнозируемых данных дискретна - если мы прогнозируем продажи товаров (SKU) они кратны единице учета, нельзя продать 1.5 шампуня. Во вторых спрос вещь прерывистая, продажи определенного товара легко могут упасть в ноль
Если агрегировать данные и прогнозировать что-то продающееся в больших объемах, то тогда конечно можно использовать методы, подходящие для непрерывных данных, но как только мы хотим идти глубже, начинаются проблемы при использовании классических методов
В чем проблемы ?
1. Абсолютные ошибки, MAE оптимизирует - медиану, а тот же wMAPE это по факту MAE разделенное на среднее и даже MASE(mean absolute scaled error) почти тоже самое.
Выбор между средним и медианой не самая большая проблема если распределение симметрично, но это не так в случае дискретных распределений с возможностью падением в ноль
Кроме того оптимизация медианы приводит к смещению, что легко доказать
3. Квадратичные ошибки - чувствительны к выбросам, но хотя бы могут быть несмещенными (плюс пара интересных заметок про GMAE и GRMSE)
4. Относительные ошибки - Prominent variations are the median relative absolute error (MdRAE) and the geometric mean relative absolute error (GMRAE). Часты они сравнивают абсолютные ошибки - смотри п.1, если сравнивать с бенчмарками, то те могут выдавать ноль и снова неопределенность в нуле
5. Ранжирующие ошибки - Mean Squared Rank и Mean Absolute Rank, пытаются оценить насколько хорошо прогноз оценивает средний спрос на возрастающем отрезке времени. Интересный подход, но недостаток в том, что больший вес задается ближайшему будущему. В принципе может быть именно это и нужно, но хотелось бы уметь задавать веса
6. Scaled Errors - признаны в статье самым многообещающим подходом. sMSE - усредненный квадрат ошибки. (MSE где предикт получается регрессией факта на предикт с изначальной модели). Хотя все еще могу быть чувствительны к перепрогнозу
Все конечно здорово, но есть еще одна проблема, это все точечные оценки, а хочется уметь оценивать распределение. Потому что нам нужно знать не среднее, а вероятность какого-то события, то есть распределение. Можно конечно идти в оценку определенных квантилей, но что если нам нужно много разных квантилей? Делать много моделей/оценок или все же научиться оценивать распределение?
Здесь мы подходим к тому, что-же предложили пацаны
Возникает вопрос, стоит ли это разбирать?
#ArticleReview
Forwarded from DevFM
В статье Анатомия GNU/Linux (хабр, 2020) просто и понятно описываются такие составляющие операционной системы, как
— загрузчик
— ядро
— начальный образ загрузки
— init
— командная оболочка
— графический сервер
— дисплейный менеджер
— окружение рабочего стола
И всякое разное другое. На картинке представлена схема взаимосвязи упомянутых в статье сущностей
— загрузчик
— ядро
— начальный образ загрузки
— init
— командная оболочка
— графический сервер
— дисплейный менеджер
— окружение рабочего стола
И всякое разное другое. На картинке представлена схема взаимосвязи упомянутых в статье сущностей
Forwarded from Arseniy Trushin
Помогите, пожалуйста, разобрать кейс (Гугл, Цюрих, 2018). Задача на систем-дизайн.
* Есть файл в 4Гб - полная карта. Есть программа, которой можно скормить этот файл, ширину, долготу и язык. Программа за 5 минут сгенерирует локализованную вырезку из карты. Раз в месяц 4Гб файл обновляется. Как сделать систему, доставляющую локализованные "вырезки" на мобильные устройства?
Мне интересен вариант ответа на этот систем-дизайн вопрос "по полной программе":
* Какие вопросы нужно было бы задать интервьюру, если он задал эту задачу?
* Какие оценки "на обратной стороне конверта" нужно здесь делать?
* Как выглядит вся система?
* Какие компромиссы можно здесь обсуждать? Какие варианты можно рассматривать?
У меня есть ещё несколько такого рода задач с разных интервью, которые хотелось бы "по косточкам" разобрать.
* Есть файл в 4Гб - полная карта. Есть программа, которой можно скормить этот файл, ширину, долготу и язык. Программа за 5 минут сгенерирует локализованную вырезку из карты. Раз в месяц 4Гб файл обновляется. Как сделать систему, доставляющую локализованные "вырезки" на мобильные устройства?
Мне интересен вариант ответа на этот систем-дизайн вопрос "по полной программе":
* Какие вопросы нужно было бы задать интервьюру, если он задал эту задачу?
* Какие оценки "на обратной стороне конверта" нужно здесь делать?
* Как выглядит вся система?
* Какие компромиссы можно здесь обсуждать? Какие варианты можно рассматривать?
У меня есть ещё несколько такого рода задач с разных интервью, которые хотелось бы "по косточкам" разобрать.
Forwarded from Mike
Привет, сколько пользователей и какой профиль нагрузки, где находятся пользователи? Какие требования по отказоустойчивости? Какой размер ответа? Есть ли ограничения? Сколько ресурсов потребляет программа? Может ли она падать? Какие SLO на время ответа и availability? Необходимо ли масштабироваться?
Можно различные расчеты произвести. Например, допустим у нас 10М запросов в день. Одна машина, обрабатывающая запрос, сможет сделать 12*24 (около 300) запросов в сутки, получим количество машин = 10M / 300. Допустим, запрос потребляет полностью одно ядро процессора, тогда средняя машина может выполнить *4 запроса одновременно. Тут добавляем требования отказоустойчивости и размещаем машины в разных датацентрах. Упоминаем какой-нибудь autoscaling, чтобы уменьшить стоимость (профиль нагрузки нам поможет определиться).
В самом простом виде будет такая схема - балансировщик над веб-серверами, которые реализуют такой API: создать запрос на вырезку из карты, прочитать состояние запроса (готов/процент готовности), забрать результат. База данных, которая хранит информацию о запросе (можно хранить kv id-запроса->информация о запросе+результат, зачем что-то сложнее да и масштабироваться проще). Подумать, сколько информации нужно нам хранить и необходимо ли шардировать данные. Очередь задач + обработчики, которые используют карту-4Gb + бинарник. Схема будет примерно такой: пользователь посылает запрос на веб-сервер, который добавляет запись в базу+задачу в очередь сообщений. Воркеры вычитывают очередь, делают работу и размещают данные в базу (обновляют прогресс, если можно или позволяют ресурсы). Клиенты вычитывают информацию (скорее всего polling раз в k секунд). Нотификацию можно приделать, но смысла особого не вижу (клиентам и так придётся ждать 5 минут).
Забыл, тут можно уточнить про кеширование - можно ли результаты запросов использовать повторно (скорее всего, нет)?
Файл в 4Gb хранить прямо на машинах, при изменении раскатывать его физически любым способом, и при обработке поднимать его в память, конечно.
Компромиссов можно много придумать. Хотим нотификации о прогрессе - добавим пуши, улучшим user exp, но усложним систему (железо, поддержка и т.д.) Если результаты тяжелые - давайте хранить результат в отдельном blob-хранилище - уменьшим назрузки с нашей базы, заплатив за использование другого хранилища. Добавьте что-нибудь по вкусу.
Это наброски ответа при наличии отсутствия интервьюера. Надеюсь, что решал ту задачу, которую вы подразумевали 🙂
Можно различные расчеты произвести. Например, допустим у нас 10М запросов в день. Одна машина, обрабатывающая запрос, сможет сделать 12*24 (около 300) запросов в сутки, получим количество машин = 10M / 300. Допустим, запрос потребляет полностью одно ядро процессора, тогда средняя машина может выполнить *4 запроса одновременно. Тут добавляем требования отказоустойчивости и размещаем машины в разных датацентрах. Упоминаем какой-нибудь autoscaling, чтобы уменьшить стоимость (профиль нагрузки нам поможет определиться).
В самом простом виде будет такая схема - балансировщик над веб-серверами, которые реализуют такой API: создать запрос на вырезку из карты, прочитать состояние запроса (готов/процент готовности), забрать результат. База данных, которая хранит информацию о запросе (можно хранить kv id-запроса->информация о запросе+результат, зачем что-то сложнее да и масштабироваться проще). Подумать, сколько информации нужно нам хранить и необходимо ли шардировать данные. Очередь задач + обработчики, которые используют карту-4Gb + бинарник. Схема будет примерно такой: пользователь посылает запрос на веб-сервер, который добавляет запись в базу+задачу в очередь сообщений. Воркеры вычитывают очередь, делают работу и размещают данные в базу (обновляют прогресс, если можно или позволяют ресурсы). Клиенты вычитывают информацию (скорее всего polling раз в k секунд). Нотификацию можно приделать, но смысла особого не вижу (клиентам и так придётся ждать 5 минут).
Забыл, тут можно уточнить про кеширование - можно ли результаты запросов использовать повторно (скорее всего, нет)?
Файл в 4Gb хранить прямо на машинах, при изменении раскатывать его физически любым способом, и при обработке поднимать его в память, конечно.
Компромиссов можно много придумать. Хотим нотификации о прогрессе - добавим пуши, улучшим user exp, но усложним систему (железо, поддержка и т.д.) Если результаты тяжелые - давайте хранить результат в отдельном blob-хранилище - уменьшим назрузки с нашей базы, заплатив за использование другого хранилища. Добавьте что-нибудь по вкусу.
Это наброски ответа при наличии отсутствия интервьюера. Надеюсь, что решал ту задачу, которую вы подразумевали 🙂
Forwarded from Mike
Это характеристика нагрузки. Можно различать распределение запросов по времени в течение дня/недели/месяца, соотношение read:write запросов (или по типам запросов), геораспределенность запросов, роботы/пользователи, десктоп/мобильные. Присутствуют ли traffic spikes? Что-то забыл?
Без обратной связи можно долго гадать, согласен. Можете поделиться своим видением, сообществу, вероятно, будет полезно узнать, как может различаться ответ.
Без обратной связи можно долго гадать, согласен. Можете поделиться своим видением, сообществу, вероятно, будет полезно узнать, как может различаться ответ.
Forwarded from Pattern Guru. Шаблоны проектирования. Архитектура ПО
Шпаргалка по шаблонам проектирования
Описание 23-х шаблонов проектирования из книги "Design Patterns" от Банды четырех. Каждый пункт содержит короткое описание паттерна и UML-диаграмму.
Читать статью
Описание 23-х шаблонов проектирования из книги "Design Patterns" от Банды четырех. Каждый пункт содержит короткое описание паттерна и UML-диаграмму.
Читать статью
Forwarded from Chat Small Data Science for Russian Adventurers
Ну есть умного чего, например гайды https://www.inovex.de/de/blog/prompt-engineering-guide/
Проблема в том, что все эти наборы, рецепты и гайды не сравнивались «в бою». И вот тут соревнование бы подошло.
Проблема в том, что все эти наборы, рецепты и гайды не сравнивались «в бою». И вот тут соревнование бы подошло.
inovex GmbH
Prompt Engineering and Zero-Shot/Few-Shot Learning [Guide] - inovex GmbH
This blog post gives you an overview of prompt engineering, the definition of zero-shot and few-shot learning, and provides a practical guide.
Forwarded from ДНСЙ 🫀
Полезные тулы для визуализации алгоритмов ☺️
https://www.toptal.com/developers/sorting-algorithms
https://visualgo.net/en
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
https://algorithm-visualizer.org/
https://www.toptal.com/developers/sorting-algorithms
https://visualgo.net/en
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
https://algorithm-visualizer.org/
Toptal
Sorting Algorithms Animations
Animation, code, analysis, and discussion of 8 sorting algorithms on 4 initial conditions.
Forwarded from Roman
Да, Михаил огонь на 146%. Курс его не видел но канал https://www.youtube.com/c/SystemDesignInterview/videos просто 10/10.
Forwarded from Start Career in DS
🐍 Python для анализа данных.
Я тут понял, что в канале не было материалов по изучению питона для новичков.
После ухода курсеры стало совсем печально (раньше часто ссылались на курс от Яндекса и МФТИ).
Перерыл кучу материалов, кажется, вот этот ресурс один из лучших: https://dfedorov.spb.ru/python3/
Тут и базовый Python, и азы библиотек для анализа данных. На скрине приведён скрин части лекций из него :)
А по чему вы изучали/изучаете Python?
Я тут понял, что в канале не было материалов по изучению питона для новичков.
После ухода курсеры стало совсем печально (раньше часто ссылались на курс от Яндекса и МФТИ).
Перерыл кучу материалов, кажется, вот этот ресурс один из лучших: https://dfedorov.spb.ru/python3/
Тут и базовый Python, и азы библиотек для анализа данных. На скрине приведён скрин части лекций из него :)
А по чему вы изучали/изучаете Python?
#couses
Какой-то чувак собрал в одну табличку все бесплатные курсы для вкатывания в DS
Какой-то чувак собрал в одну табличку все бесплатные курсы для вкатывания в DS