#ml #statistics
Интересная книга с Байесовским подходом в анализе данных

https://www.stat.columbia.edu/~gelman/book/BDA3.pdf

​​#statistics

Weighted Z-test для мета-анализа результатов экспериментов.

Мне попался на глаза пост от ebay про z-test для мета-анализа (спасибо коллегам). Так что сегодня поговорим про этот метод.

Итак. Предположим, что у нас есть несколько запусков одного теста (например, волны коммуникации со схожей механикой, либо повторный запуск какого-либо эксперимента).

У нас есть N тестов (например, N t-тестов для средних), для каждого из которых есть свое p-value, свое значение статистики и свой доверительный интервал. Мы думаем, что объединение разрозненных источников информации даст нам преимущество и позволить уточнить наши выводы, увеличив мощность полученного комбинированного теста.

Для one-sided теста у нас может использоваться Fishers method. Но в случае two-sided теста нам нужен другой способ. И тут на сцену выходит Z-test.

Мы можем скомбинировать наши p-values в комбинированный p-value, используя Z-статистики из каждого эксперимента и веса, которые получаются из выражения w_i = 1 / SE_i, где SE_i - это standart error для i-го эксперимента (формула построения доверительного интервала комбинированного эксперимента есть в исходном посте по ссылке в начале).

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

Какие тут плюсы и минусы?

Плюсы:
- Тест может комбинировать отдельные результаты тестов с разными размерами выборки;
- Полученная комбинация имеет большую мощность, чем каждый отдельный тест

Минусы:
- Тест предполагает нормальность распределения (не забываем о Z-статистике при его расчете);
- Тест чувствителен к весам. Соответственно, есть возможность того, что какой-то тест попросту перевесит все остальные;
- Комбинированный тест может быть сложнее к пониманию и реализации, чем единичный обычный проведенный тест

Идемпо… что? Улучшаем API

Когда писал пост про работу с HTTP, обнаружил непростительную оплошность. Мы ни разу не рассказывали о такой супер важной штуке, как идемпотентность API.

Начало статьи Стажёр Вася и его истории об идемпотентности API очень метко характеризует этот термин:
Звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.

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

Автор на примере приложения Такси и всего одной кнопки "Заказать такси" рассказывает о множестве подвохов, которые поджидают разработчика.

Из-за затупа с базой пользователь дважды нажал кнопку Заказать и приехало две машины.
Что ж, на фронте начали блокировать кнопку Заказать, пока не придет ответ с сервера.

Оказалось, этого не достаточно. Из-за проблем с сетью по таймауту возникла ошибка и клиентское приложение разблокировало кнопку Заказать. Но кто бы мог подумать... проблема проблемой, но до сервера запрос дошёл и даже выполнился. По итогу имеем снова две машины. Эту проблему поправили уже на беке, добавив пару if.

Проблема решена, можно заканчивать статью. А потом тарам-пам-пам... классика. Менеджер изменил бизнес требования и старое решение уже не подходит.

Тут-то автор и подходит к сути статьи. Ключ идемпотентности, что за зверь такой, как он поможет решить обозначенную проблему. Но не всё так просто, поэтому далее в статье раскрываются ещё несколько тонких моментов.

Когда я первый раз прочитал эту статью в далёком 19 году, то был в искреннем восторге, насколько доступно и на понятных примерах можно раскрыть тему. А классический пример с заказчиком: от "нам это не нужно абсолютно точно" до "срооооочно нужна эта фича" — просто вишенка на торте.
#skills

Зелёные потоки в Python

Переключение между потоками — процесс очень затратный по времени, как мы уже разбирали. Для решения этой проблемы были придуманы зелёные потоки (green threads, они же coroutines или корутины), у которых вместо честного переключения потоков операционной системой реализуется виртуальное переключение потоков в пользовательском пространстве. Для IO-bound задач, где бутылочным горлышком являются медленные операции ввода-вывода, в том числе сетевого, зелёные потоки являются спасением. Для CPU-bound задач, где надо много физически вычислять на процессоре и нет простоев зелёные потоки не нужны.

Предлагаем прочитать статью Асинхронный python без головной боли (часть вторая). Начинается статья с наглядного примера асинхронности из жизни. Часто у начинающих разработчиков можно наблюдать ошибку, когда вместо подписки на событие, например, изменения файла, реализуется "жужжалка", которая в бесконечном цикле дёргает метаданные файла, загружая CPU на 100%.

Дальше на примере показывается async-await с разными нюансами, в том числе с необходимостью асинхронных функций. Потом показывается взаимосвязь корутин и генераторов, асинхронные контекстные менеджеры и приложение, которое асинхронно что-то делает с сервисом погоды.

Во второй части речь про event loop, про пример с API gateway, дополнение сервиса погоды переводчиком, асинхронным логгированием и базой.
#python

#career
Матрица компетенций в области SWE

https://sijinjoseph.netlify.app/programmer-competency-matrix/

#полезно
Довольно любопытный блог, в основном тут описываются идеи научных статей. Тематика: оптимизация, тензорные разложения, GAN-ы. Из последних интересных постов: качество на тестовой выборке почти совпадает с качеством на синтетической выборке, построенной с помощью GAN-a, обученного на обучении (т.е. предсказывается качество на тесте).

https://www.offconvex.org

#math #courses

https://ium.mccme.ru/s22/s22-Gasnikov.html

Можно еще это.

#dl #courses

Машинное и статистическое обучение от профессора Техасского Унивесритета в Остине Майкла Перча (Michael Pyrcz)

Я когда-то писал, но не лишне напомнить еще раз. У Майкла огромный опыт в статистическом и машинном обучении и их применении в геонауках. Он как раз делает упор на статистику и машинное обучение в геопроцессах. Он выкладывает все свои лекции вместе с презентациями и примерами кода бесплатно на своем гитхабе. Там можно найти кучу хорошо задокументированных рабочих процессов в Питоне, включая практические упражнения и демонстрации всех его лекций, которыми он свободно делится на своем ютуб канале. Вот, например, все его лекции его курса по машинному обучению.

Если хотели "войти" в программирование, статистику и машинное обучение находясь в геоиндустрии - самое оно.

Дисклеймер: его лекции не включают Глубокое Обучение.

P.S. Длинноволосый рокер - Майкл, чувак с глупой улыбкой - я.

Просматривая видосики (1, 2) на ютубе, наткнулся на интересную библиотечку для инференса моделек от avito - Акведук.

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

Фишки:
- Pure python
Работает на основе multiprocessing из питона и имеет всего одну внешнюю зависимость. "No vendor lock" - хвалятся нам из доклада
- Plug-and-play
От датасаентистов требуется установить библиотеку, реализовать пару функций у класса Task (пример) и определить пайплайн обработки.
Flow(
FlowStep(PreProcessorHandler()),
FlowStep(ClassifierHandler()),
FlowStep(PostProcessorHandler()),
)
- Таски переходят между этапами через очереди. При этом реализована возможность немного подождать, чтобы накопить батч
- Передача данных между этапами происходит через SharedMemory
- Production ready
Есть метрики (размеры очередей, время перехода между этапами и др.), подключается Sentry, Graceful Shutdown (если одна таска умерла, то начатые продолжат выполнение и завершатся), хелсчеки процессов.

Выглядит прикольно. 140 звезд на гите, комиты каждый месяц. Надо бы попробовать

https://www.kaggle.com/code/ogrellier/feature-selection-with-null-importances

Помню был вот такой старый ноутбук на каггле. Этот подход был долгое время популярен.