О метриках рекомендательных систем можно тут почитать
https://www.evidentlyai.com/ranking-metrics/evaluating-recommender-systems
или тут
https://towardsdatascience.com/metrics-of-recommender-systems-cde64042127a
Даже если вы считаете основной метрикой "свою" кастомную, то это не означает, что другие - это мусор. Для принятия взвешенного решения нужно рассчитывать несколько метрик, чтобы понять плюсы и минусы различных решений.
В любом случае ваши оффлайн данные для обучения будут содержать баес по отношению к показам текущих товаров и только аб тест сможет сказать насколько то или иное решение лучше.
P.S. АБ теста или бейслайна тоже кстати не было
На собезах между прочим часто прошу назвать все метрики которые знаешь для регрессии. В больее чем в половине случаев ответ ограничивается 1й или 2мя метриками
Please open Telegram to view this post
VIEW IN TELEGRAM
Evidentlyai
10 metrics to evaluate recommender and ranking systems
How do you evaluate recommender and ranking systems? This guide gives an overview of popular ranking metrics and approaches to evaluating recommendations.
🙏1
Серия четвертая ❤️
Сайт для которого мы рекомендашки делали занимался реализацией разных активов - бензоколонок, кафешек, домов, машин, даже нефтяных месторождений. И у каждого актива в зависимости от его категории были какието свои фичи, а этих категорий было около 10. DS при этом очень уж хотел объеденить все эти фичи в одно пространство, но как это сделать?🤔
Короч, а что если взять фичи из 1 категории активов и натравить на них...PCA и взять первые 10 компонент. Потом взять фичи 2й категории, повторить и т.д. Получится что все активы содержат фичи pca1,pca2,...,pca10. Охеренно похоже ведь 🤣
У тебя в одной категории марка автомобиля с годом выпуска, а в другой площадь квартиры, а теперь ровно 10 фичей с одинаковым названием. Почему ds подумал, что компоненты нескольких pca совпадать будут мне не известно, но так вот было сделано. Собственно тогда я уже и решил, что эту модельку уже не спасти😦
Сайт для которого мы рекомендашки делали занимался реализацией разных активов - бензоколонок, кафешек, домов, машин, даже нефтяных месторождений. И у каждого актива в зависимости от его категории были какието свои фичи, а этих категорий было около 10. DS при этом очень уж хотел объеденить все эти фичи в одно пространство, но как это сделать?
Короч, а что если взять фичи из 1 категории активов и натравить на них...
У тебя в одной категории марка автомобиля с годом выпуска, а в другой площадь квартиры, а теперь ровно 10 фичей с одинаковым названием. Почему ds подумал, что компоненты нескольких pca совпадать будут мне не известно, но так вот было сделано. Собственно тогда я уже и решил, что эту модельку уже не спасти
Please open Telegram to view this post
VIEW IN TELEGRAM
🙈10❤1
Если вы плохо понимаете, как pca работает, то рекомендую почитать
https://setosa.io/ev/principal-component-analysis/
TLDR
PCA переводит фичи в новое пространство, где компоненты направлены в сторону наибольшей дисперсии, т.е. это все теже фичи, но развернуты таким образом чтобы корреляции в новом пространстве нулю равнялась. И клянусь впервые увидел, чтобы ктото это в прод пытался тащить
Please open Telegram to view this post
VIEW IN TELEGRAM
Explained Visually
Principal Component Analysis explained visually
🫡2❤1💘1
Forwarded from ODS Events
Всем привет!
Приглашаем всех на Дата Ëлку 2024 и голосование ODS Awards 2024 🎄
📆 Ëлка пройдёт после праздников — в субботу 18 января
В лучших традициях, вас ждут обзорные итоги года по 12 DS/ML областям 🔥
Более того, будут сразу 2 офлайн площадки куда можно прийти живьем:
💙 В Москве — в гостях у ВК, начало программы в 12:00
💚 В Питере — в гостях у ecom.tech, начало программы в 14:00
И конечно же будет онлайн трансляция с докладами итогов с обеих площадок сразу 🙀
Поторопитесь зарегистрироваться, места на площадках ограничены! Внимательно относитесь к заполнению анкет, все регистрации будут проходить модерацию.
🌟 Открыто голосование ODS Awards 2024 🌟
Это ежегодная премия за вклад в Open Data Science — лучшие треки, видео, статьи, менторы и погонщики гусей 🦾
Как и в предыдущие года, новогодние подарки достанутся и победителям, и тем кто голосовал.
Голосование открыто, итоги мы подведём как раз на Дата Ëлке 🎅
Ждём вас на Дата Ёлке, и ждём ваши голоса в ODS Awards 2024!
TL;DR:
🎄Дата Ёлка ждёт всех 18 января
🎁 Пройдут 2 офлайн Ëлки: в Москве в гостях у ВК и в Питере гостях у ecom.tech
🌟Ждём ваши голоса и номинации ODS Awards 2024
Приглашаем всех на Дата Ëлку 2024 и голосование ODS Awards 2024 🎄
📆 Ëлка пройдёт после праздников — в субботу 18 января
В лучших традициях, вас ждут обзорные итоги года по 12 DS/ML областям 🔥
Более того, будут сразу 2 офлайн площадки куда можно прийти живьем:
💙 В Москве — в гостях у ВК, начало программы в 12:00
💚 В Питере — в гостях у ecom.tech, начало программы в 14:00
И конечно же будет онлайн трансляция с докладами итогов с обеих площадок сразу 🙀
Поторопитесь зарегистрироваться, места на площадках ограничены! Внимательно относитесь к заполнению анкет, все регистрации будут проходить модерацию.
🌟 Открыто голосование ODS Awards 2024 🌟
Это ежегодная премия за вклад в Open Data Science — лучшие треки, видео, статьи, менторы и погонщики гусей 🦾
Как и в предыдущие года, новогодние подарки достанутся и победителям, и тем кто голосовал.
Голосование открыто, итоги мы подведём как раз на Дата Ëлке 🎅
Ждём вас на Дата Ёлке, и ждём ваши голоса в ODS Awards 2024!
TL;DR:
🎄Дата Ёлка ждёт всех 18 января
🎁 Пройдут 2 офлайн Ëлки: в Москве в гостях у ВК и в Питере гостях у ecom.tech
🌟Ждём ваши голоса и номинации ODS Awards 2024
Forwarded from AI.Insaf
Удалось побывать DS-ментором на одном из хакатонов в конце прошлого года, где моя команда заняла 3-е место 🎉 . Исходный проект был посвящён кластеризации событий брокера сообщений/логов.
Коллективным разумом были предложены следующие идеи ниже. Ожидаемо хотелось применить трансформеры, но из-за объёма данных и доступных ресурсов был выбран другой подход. Как вы думаете, какой?
1. Baseline: scaNN + любимый эмбеддер
• ScaNN — супербыстрый на CPU алгоритм поиска ближайших соседей (быстрее Faiss)
• Benchmarks алгоритмов кластеризаций
2. Готовый алгоритм ранжирования текстов: Rank-BM25 — улучшенный tf-idf, который может плохо выделять если признаков мало, и очень быстро растет размер словаря при увеличении кол-во n-gramm
3. Алгоритм с кастомным эмбеддингом
• Используем токенизатор (например, BPE). Обучаем его на логах
• Переводим логи в последовательность токенов
• Генерируем tf-idf для 1-, 2-, 3-грамм (размер словаря ~10⁶)
• Создаём эмбеддинги для токенов (например, с помощью предобученной модели)
• Кластеризуем эмбеддинги (например, на 100-800 кластеров)
• Для нового текста создаём вектор, учитывающий частоту кластеров
• Результат — компактные векторы, подходящие для кластеризации и обнаружения аномалий
4. Быстрая работа со строками + dbstream clustering
• RapidFuzz — библиотека с быстрыми реализациями функций string similarity.
• Jaro-Winkler Distance — быстрее Левенштейна на коротких строках.
5. Итеративное выделение кластеров с помощью LLM
• Генерируем ключевые слова и типы ошибок по существующим кластерам
• Покрываем базу кейвордами (~50%)
• Обрабатываем оставшиеся данные, выделяя новые кластеры
• Повторяем процесс, пока покрытие не станет полным
• Удобно выделяем ключевые виды ошибок (например, SQLException, JavaException, Timeout и т.д.)
6. Имплентация от Jetbrains (📕Статья: Aggregation of Stack Trace Similarities for Crash Report Deduplication, ⭐️ код на GitHub)
Внутри решение k-NN с хитрой агрегацией stack trace логов ошибок с временными метками
Коллективным разумом были предложены следующие идеи ниже. Ожидаемо хотелось применить трансформеры, но из-за объёма данных и доступных ресурсов был выбран другой подход. Как вы думаете, какой?
1. Baseline: scaNN + любимый эмбеддер
• ScaNN — супербыстрый на CPU алгоритм поиска ближайших соседей (быстрее Faiss)
• Benchmarks алгоритмов кластеризаций
2. Готовый алгоритм ранжирования текстов: Rank-BM25 — улучшенный tf-idf, который может плохо выделять если признаков мало, и очень быстро растет размер словаря при увеличении кол-во n-gramm
3. Алгоритм с кастомным эмбеддингом
• Используем токенизатор (например, BPE). Обучаем его на логах
• Переводим логи в последовательность токенов
• Генерируем tf-idf для 1-, 2-, 3-грамм (размер словаря ~10⁶)
• Создаём эмбеддинги для токенов (например, с помощью предобученной модели)
• Кластеризуем эмбеддинги (например, на 100-800 кластеров)
• Для нового текста создаём вектор, учитывающий частоту кластеров
• Результат — компактные векторы, подходящие для кластеризации и обнаружения аномалий
4. Быстрая работа со строками + dbstream clustering
• RapidFuzz — библиотека с быстрыми реализациями функций string similarity.
• Jaro-Winkler Distance — быстрее Левенштейна на коротких строках.
5. Итеративное выделение кластеров с помощью LLM
• Генерируем ключевые слова и типы ошибок по существующим кластерам
• Покрываем базу кейвордами (~50%)
• Обрабатываем оставшиеся данные, выделяя новые кластеры
• Повторяем процесс, пока покрытие не станет полным
• Удобно выделяем ключевые виды ошибок (например, SQLException, JavaException, Timeout и т.д.)
6. Имплентация от Jetbrains (📕Статья: Aggregation of Stack Trace Similarities for Crash Report Deduplication, ⭐️ код на GitHub)
Внутри решение k-NN с хитрой агрегацией stack trace логов ошибок с временными метками
👍16🔥2🙏1
Привет, друзья! 🤓
Вот и закончились праздники, и пришло время вернуться к нашим любимым историям. Сегодня хочу поделиться итогами одной из прошлогодних историй
Серия 1
Серия 2
Серия 3
Серия 4
Которая, как ни странно, оказалась настоящим приключением в мире data science и бизнеса.
Итак, начнем с того, что в той истории было слишком много накладок. Представьте себе: усложнение задач с использованием word2vec и NLP там, где это было совершенно не нужно, неправильный выбор метрик и полное непонимание базовых методов машинного обучения, таких как PCA. Да, такое бывает даже у самых опытных!
Почему это важно? Потому что бизнесу редко интересна внутренняя кухня обучения моделей. Начальники спешат отчитаться о завершении задач, и часто нет ни валидации, ни A/B тестов. Когда приходит время разбираться с последствиями, многие уже уволились, и разгребать ошибки приходится тем, кто остался.
В моей истории все вскрылось за месяц до завершения проекта. Времени было мало, и пришлось действовать быстро. Запросил логи посещения страниц, чтобы самостоятельно обучить рекомендательную систему. Вместо этого мне предложили весь дамп базы размером в 30 Мб. Мне стало понятно, почему разработчик был в шоке, когда я пытался впихнуть ему архив с эмбедингами на 10 Гб! 😅
Но в итоге я построил базовое решение, показывающее ранее просмотренные страницы, и более сложное на основе lightfm. Финальное решение состояло из трех сервисов в docker-compose:
1⃣ База Redis для хранения рекомендаций.
2⃣ Сервис, который забирает данные из бэкэнда, рассчитывает рекомендации и кладет оба решения в Redis для честного А/В теста. Всё запускалось с помощью cron.
3⃣ Flask, который отдавал рекомендации и решал, какое решение использовать — lightfm или базовое, по остаточному делению хеша client_id.
И знаете что? Всё развернулось практически с первого раза! 🚀 Конечно, из-за отсутствия интернета пришлось собирать docker-образы локально, что оказалось не всегда так просто, но мы справились.
Если бы было больше времени, возможно, сделал бы что-то иначе. Но учитывая сроки, считаю, что это был успех.
Мы обсуждаем такие истории, чтобы обратить внимание на важные моменты и улучшить нашу работу в data science. Учимся на ошибках и движемся вперед! 🙌
До новых историй, друзья! 💡
Вот и закончились праздники, и пришло время вернуться к нашим любимым историям. Сегодня хочу поделиться итогами одной из прошлогодних историй
Серия 1
Серия 2
Серия 3
Серия 4
Которая, как ни странно, оказалась настоящим приключением в мире data science и бизнеса.
Итак, начнем с того, что в той истории было слишком много накладок. Представьте себе: усложнение задач с использованием word2vec и NLP там, где это было совершенно не нужно, неправильный выбор метрик и полное непонимание базовых методов машинного обучения, таких как PCA. Да, такое бывает даже у самых опытных!
Почему это важно? Потому что бизнесу редко интересна внутренняя кухня обучения моделей. Начальники спешат отчитаться о завершении задач, и часто нет ни валидации, ни A/B тестов. Когда приходит время разбираться с последствиями, многие уже уволились, и разгребать ошибки приходится тем, кто остался.
В моей истории все вскрылось за месяц до завершения проекта. Времени было мало, и пришлось действовать быстро. Запросил логи посещения страниц, чтобы самостоятельно обучить рекомендательную систему. Вместо этого мне предложили весь дамп базы размером в 30 Мб. Мне стало понятно, почему разработчик был в шоке, когда я пытался впихнуть ему архив с эмбедингами на 10 Гб! 😅
Но в итоге я построил базовое решение, показывающее ранее просмотренные страницы, и более сложное на основе lightfm. Финальное решение состояло из трех сервисов в docker-compose:
1⃣ База Redis для хранения рекомендаций.
2⃣ Сервис, который забирает данные из бэкэнда, рассчитывает рекомендации и кладет оба решения в Redis для честного А/В теста. Всё запускалось с помощью cron.
3⃣ Flask, который отдавал рекомендации и решал, какое решение использовать — lightfm или базовое, по остаточному делению хеша client_id.
И знаете что? Всё развернулось практически с первого раза! 🚀 Конечно, из-за отсутствия интернета пришлось собирать docker-образы локально, что оказалось не всегда так просто, но мы справились.
Если бы было больше времени, возможно, сделал бы что-то иначе. Но учитывая сроки, считаю, что это был успех.
Мы обсуждаем такие истории, чтобы обратить внимание на важные моменты и улучшить нашу работу в data science. Учимся на ошибках и движемся вперед! 🙌
До новых историй, друзья! 💡
Telegram
Sberloga
Короч история длинная, сегодня будет первая серия 😁
Когда только в сбер устроился, дали задание поставить в прод рекомендательную систему для дочерней компании, которая с юл работает. Были артефакты, код для инференса, описание как поставить модель и сам…
Когда только в сбер устроился, дали задание поставить в прод рекомендательную систему для дочерней компании, которая с юл работает. Были артефакты, код для инференса, описание как поставить модель и сам…
👍7🙏7🔥3👻1
Forwarded from Из коммерса в е-коммерса
Ну и карьерная новость №1 на сегодня: тим лид продуктовой аналитики в Lamoda Tech Анжелика Шахурина стала порноакртисой под ником Lika Blackberry. Точнее она ей была, просто об этом никто не знал, а сейчас узнали. А Lamoda Tech зачем-то начал удалять все посты с упоминанием Анжелики, хотя могли бы наоборот поддержать, зарплату повысить, накинуть новый функционал по организации тим билдингов, или еще как-то...
с кем не бывает, однажды вы найдете и мои видео…….
с кем не бывает, однажды вы найдете и мои видео…….
😁12❤5🌭4🫡3🔥1🤡1