ML Advertising

Сегодня простой #mltips В Jupyter Notebooks есть возможность по умолчанию импортировать нужные библиотеки. 1. Перейдите в: /Users/<user_name>/.ipython/profile_default/startup, или если она отсутствует, создайте ее 2. Создайте файл start.py. Название может быть любым - по сути будут выполнены все .py файлы находящиеся в этой папке 3. Добавьте в него нужные импорты. Теперь при каждом открытии ноутбука ваши библиотеки уже будут импортированы.

⚡️ Machine learning - самый крупный обучающий ресурс в Telegram, посвященный машинному обучению и ИИ. По контенту: 1. Опенсорс модели, которые не стоит пропускать 2. Составляем ежедневные дайджесты главных релизов и новостей из мира ии и мо, чтобы вы ничего не пропустили. 3. Публикуем бесплатные МЛ курсы 2024 года. 4. 2300 реальных задач с собесов с разбором А здесь целая папка для всех, кто любит и изучает машинное обучение. И многое другое. Это первоисточник всего, что появляется в платных курсах и популярных ресурсах по МО и ИИ. Подписывайтесь, такие знания в 2024-м году на вес золота: @ai_machinelearning_big_data

Netflix идет в AdTech Сегодня у нас новостная повестка. Netflix создает свою программатик платформу. Как заявлено, решению сопутствует значимый рост аудитории с 23М до 40М ежемесячных пользователей за полгода и возможность запустить новые партнерки. Продаваться инвентарь будет через SSP Rubicon Magnite, поэтому header bidding'а здесь пока не предвидится. Для медиа байеров закупка кампаний станет доступна в The Trade Desk и DV360. Поскольку сейчас стриминг продает свой инвентарь только через Microsoft и испытывает трудности с демандом, держась на топ-10 месте среди конкурентов, то партнерство с двумя крупными DSP поможет расширить спрос. Также заявлен план на увеличение доли досмотров среди аудитории (время просмотра стриминга для половины пользователей около 20 часов в месяц). Для этого заключены соглашения на трансляции Christmas Day NFL и WWE Насколько Netflix приуспеет на поприще адтеха, будем смотреть. Источник: AdExchanger

Зачем разработчику навыки управления продуктом? 🤔 Сейчас очень популярна концепция T-Shaped People, когда специалист является экспертом в своей доменной области (ML) и при этом имеет широкий кругозор за счёт базового погружения в смежные области. Управление продуктом – это именно та смежная область, в которой должен разбираться ML-менеджер, если он хочет быть востребованным и расти в грейде. Почему так? 1️⃣ Во-первых, понимание сути продуктовой работы позволяет создавать модели, которые не только технически совершенны, но и способствуют достижению бизнес-целей (а именно за это, рынок и готов платить деньги). 2️⃣ Во-вторых, понимание продуктовых метрик и как их можно забустить благодаря ML, радикально повышает эффективность коммуникаций и защиты своих решений не только внутри команды, но и с любыми группами стейкхолдеров. 3️⃣ В-третьих, решение реальных потребностей пользователей продукта, позволяет двигать ваши ML-проекты по приоритетам вверх и чаще видеть ваши ML-модели в проде (а не работать в стол). Поэтому, если вы хотите расти в грейде, развивать свой кругозор, то рекомендую подписаться на канал Ordinary PM. 👨‍💻Автор – Иван Меркурьев с 10+ лет реального опыта работы в ведущих российских бигтех компаниях – Яндекс, Сбер, МегаФон. Иван катко, ёмко и понятно описывает важнейшие подходы, которые вы сможете применять в вашей ежеденвной работе. Что вы узнаете? - Как благодаря JTBD понять почему люди выбирают (или нет) ваш продукт? - Как понять, кто в действительности ваш пользователь? - Как согласно AARRR правильно выстраивать путь для пользователя внутри продукта? Подписывайтесь, будет интересно!

Darty

Сегодня у нас инфографика об основных видах тестирования приложения

⚡️ Визуализация 9 типов тестирования API ▪Smoke Testing Выполняется после разработки API. Проверка того, что API работают и ничего не выходит из строя. ▪Functional Testing Позволяет создать план тестирования на основе функциональных требований и сравнить его с фактическими результатами. ▪Integration Testing Этот тест объединяет ряд вызовов API и выполняет сквозные тесты. Оцениваются коммуникации и передача данных в процессе эксплуатации. ▪Regression Testing Этот тест гарантирует, что исправления ошибок или новые функции не нарушат текущее поведение API. ▪Load Testing Измеряет производительность приложений при различных нагрузках. Мы можем определить емкость приложения. ▪Stress Testing API специально перегружаются, чтобы проверить, могут ли они функционировать должным образом. ▪Security Testing Этот тест сертифицирует API от всех потенциальных угроз извне. ▪UI Testing Гарантирует, что пользовательский интерфейс может взаимодействовать с этими API и отображать данные по мере необходимости. ▪Fuzz Testing Этот тест отправляет недействительные или неожиданные входные данные в API и пытается вызвать его сбой. Делается путем выявления уязвимостей API. #opensource #api #web @DevOPSitsec

АБ тесты Поскольку на работе для выкатки фичей в SSP я провожу АБ тесты, считаю, что можно освежить базу по их анализу и проверке стат. гипотез. Допустим, нам нужно сравнить две модели регрессии. Для примера возьмем открытый датасет sklearn.datasets.load_diabetes. Создадим два регрессора CatBoostRegressor и RandomForestRegressor. Прогоним для каждой из модели кросс валидацию на 5 фолдов и запишем метрики MSE двух моделей.

X, y = load_diabetes(return_X_y=True)
rf = RandomForestRegressor()
cb = CatBoostRegressor(verbose=False)
folds = KFold(n_splits=5)
scores_rf = cross_val_score(rf, X, y, scoring='neg_mean_squared_error', cv=folds)
scores_cb = cross_val_score(cb, X, y, scoring='neg_mean_squared_error', cv=folds)

Когда мы получили метрики, нам нужно выбрать какой тест проводить: - параметрический в предположении, что наши метрики лежат в каком-то распределении - или более консервативный непараметрический. Рассмотрим три самых популярных ▶️ Т-тест Стьюдента Допустим, мы считаем распределение метрик нормальным и их дисперсии равны. Тогда мы можем использовать параметрический Т-тест Стьюдента. Чтобы попрактиковаться, мы можем посчитать Т-тест руками - Сформулируем гипотезы - нулевую H0 avg(scores_cb) != avg(scores_r) - альтернативную гипотезы H1 - двухсторонняя гипотеза avg(scores_cb) != avg(scores_r) - односторонняя гипотеза avg(scores_cb) < avg(scores_r) - Вычислим попарные разницы diff между метриками MSE моделей - Вычислим среднюю разницу M между метриками - Вычислим стандартное отклонение разниц sd - Вычислим стандартную ошибку SE = sd / sqrt(n) - Посчитаем Т-статистику: t = M / SE - Посчитаем число степеней свободы df = n - 1 (количество значений для расчета стат. величиный, которые могут свободно меняться) - Далее вносим T-статистику t и df в калькулятор T-распределения и по таблице находим уровень значимости pvalue (вероятности ошибки первого рода) - Сравним pvalue с порогом alpha (как правило, берем 0.05). - Если тест односторонний, т.е. мы предполагаем, что scores_cb < scores_rf, то при pvalue < 0.05 мы можем опровергнуть нашу нулевую гипотезу и сказать, что MSE катбуста значимо меньше случайного леса - Для двусторонней гипотезы мы делим порог значимости пополам и уже опровергаем H0 из условия pvalue < 0.025 На питоне тест Стьюдента выглядит следующим образом

stats.ttest_rel(scores_rf, scores_cb)
# output: Ttest_relResult(statistic=1.9353919550011929, pvalue=0.12503)

поскольку pvalue > 0.05, мы не можем опровергнуть нулевую гипотезу ▶️ Т-тест Уэлча Давайте предположим, что мы по проводили кроссвалидацию с разным числом фолдов:

scores_rf = cross_val_score(rf, X, y, cv=5, scoring='neg_mean_squared_error')
scores_cb = cross_val_score(cb, X, y, cv=10, scoring='neg_mean_squared_error')

В таком случае, тести Стьюдента нам не подходит, поскольку мы уже не можем вычислить попарные разницы. Тогда прибегаем к тесту Уэлча. Здесь нет предположения о равенстве дисперсий, соответственно и выборки могут быть разного размера. Алгоритм следующий: - H0, H1 формулируем аналогично - Вычислим средние метрик M1, M2 - Вычислим дисперсии метрик var1, var2 - Посчитаем Т-статистику: t = (M1 - M2) / sqrt(var1/n1 + var2/n2) - Посчитаем число степеней свободы df = n - 1 - Далее также по таблице из t и df считаем pvalue и сравниваем с порогом значимости На питоне для этого есть функция ttest_ind

stats.ttest_ind(scores_rf, scores_cb, equal_var=False)
# output: Ttest_indResult(statistic=0.8564592491178395, pvalue=0.4077)

▶️ Критерий Вилкоксона Теперь давайте представим, что разницы метрик не распределены нормально. В таком случае нужны непараметрические тесты. Самый распространненый это критерий Вилкоксона. Его еще называют критерием знаковых рангов. - Для начала переформулируем гипотезы и вместо средних будем сравнивать медианы - H0 median(scores_cb) != median(scores_r) - H1 - двухсторонняя гипотеза median(scores_cb != median(scores_r) - односторонняя гипотеза median(scores_cb) < median(scores_r) - Также, как и для Т-теста Стьюдента вычислим попарные разницы diff между моделями (здесь то же самое ограничение на равенство дисперсий и соответсвенно размеров выборок) - Проранжируем в порядке возрастания их модулей (при этом для повторяющихся значений назначается одинаковый ранг, равный среднему их рангов) - Суммируем ранги с положительной разницей и обозначим результат, как W+ - То же самое делаем для суммы рангов с отрицательной разницей W- - Расчитем W-статистику, как W = min(W-, W+) и сравниваем ее с табличным порогом, чтобы опровергнуть или нет H0. На питоне пользуемся встроенной функцией

stats.wilcoxon(scores_rf, scores_cb)
# output: WilcoxonResult(statistic=1.0, pvalue=0.125)

trtexec В продолжение поста о TensorRT Для быстрой проверки latency модели можно использовать утилиту командной строки trtexec. Она оценивает latency / throughput с различными опциями оптимизации, а также сохраняет собранный engine с возможностью дальнейшей загрузки и запуска. Она содержит много опциональных флагов, которые включают определённые опции оптимизации. Команды на trtexec выглядят следующим образом

trtexec --workspace=4096 --onnx=model.onnx --saveEngine=engine.trt --best --useSpinWait --outputIOFormats=fp16:chw --inputIOFormats=fp16:chw --verbose

- Здесь первый аргумент задаёт максимальный объём используемой памяти в мегабайтах, то есть для вычисления модели будет доступно 4 гигабайта видеопамяти. - Следующие два аргумента указывают пути до модели в формате ONNX и до собранного engine (один из результатов запуска утилиты). - Флаг --best разрешает использовать любые типы данных для достижения максимальной производительности. Чаще - это низкоразрядные типы данных. - Следующие флаги задают порядок осей и тип входных / выходных данных модели (как правило FP16).