Интересное что-то – Telegram
Интересное что-то
517 subscribers
2.71K photos
252 videos
138 files
4.51K links
Материалы и мысли, понадерганные отовсюду
Блог: https://news.1rj.ru/str/asisakov_channel
Чат: https://news.1rj.ru/str/youknowds_chat
Download Telegram
#metric
Валера про статью с метриками в предсказании спроса
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
Forwarded from DevFM
В статье Анатомия GNU/Linux (хабр, 2020) просто и понятно описываются такие составляющие операционной системы, как
— загрузчик
— ядро
— начальный образ загрузки
— init
— командная оболочка
— графический сервер
— дисплейный менеджер
— окружение рабочего стола

И всякое разное другое. На картинке представлена схема взаимосвязи упомянутых в статье сущностей
Forwarded from Arseniy Trushin
Помогите, пожалуйста, разобрать кейс (Гугл, Цюрих, 2018). Задача на систем-дизайн.

* Есть файл в 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-хранилище - уменьшим назрузки с нашей базы, заплатив за использование другого хранилища. Добавьте что-нибудь по вкусу.
Это наброски ответа при наличии отсутствия интервьюера. Надеюсь, что решал ту задачу, которую вы подразумевали 🙂
Forwarded from Mike
Это характеристика нагрузки. Можно различать распределение запросов по времени в течение дня/недели/месяца, соотношение read:write запросов (или по типам запросов), геораспределенность запросов, роботы/пользователи, десктоп/мобильные. Присутствуют ли traffic spikes? Что-то забыл?

Без обратной связи можно долго гадать, согласен. Можете поделиться своим видением, сообществу, вероятно, будет полезно узнать, как может различаться ответ.
#ml #nlp
Матчинг похожих строк
#python
Паттерны проектирования
Шпаргалка по шаблонам проектирования

Описание 23-х шаблонов проектирования из книги "Design Patterns" от Банды четырех. Каждый пункт содержит короткое описание паттерна и UML-диаграмму.

Читать статью
#ml
Промпты для генеративных моделей
Forwarded from Chat Small Data Science for Russian Adventurers
Ну есть умного чего, например гайды https://www.inovex.de/de/blog/prompt-engineering-guide/

Проблема в том, что все эти наборы, рецепты и гайды не сравнивались «в бою». И вот тут соревнование бы подошло.
#algo
Визуализации алгоритмов
#systemdesign
Какой-то канал какого-то Михаила по System Design
Forwarded from Roman
Да, Михаил огонь на 146%. Курс его не видел но канал https://www.youtube.com/c/SystemDesignInterview/videos просто 10/10.
#ml #python
Интересная ссылочка для тех, кто хочет немного врубиться в Python
Forwarded from Start Career in DS
🐍 Python для анализа данных.
Я тут понял, что в канале не было материалов по изучению питона для новичков.
После ухода курсеры стало совсем печально (раньше часто ссылались на курс от Яндекса и МФТИ).

Перерыл кучу материалов, кажется, вот этот ресурс один из лучших: https://dfedorov.spb.ru/python3/
Тут и базовый Python, и азы библиотек для анализа данных. На скрине приведён скрин части лекций из него :)

А по чему вы изучали/изучаете Python?
#couses
Какой-то чувак собрал в одну табличку все бесплатные курсы для вкатывания в DS