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 логов ошибок с временными метками
Напомнило мне вот этот ролик
https://youtu.be/UFqXDpMMwtA?si=FKH3We7MX3VomiF1
https://youtu.be/UFqXDpMMwtA?si=FKH3We7MX3VomiF1
Привет, друзья! 🤓
Вот и закончились праздники, и пришло время вернуться к нашим любимым историям. Сегодня хочу поделиться итогами одной из прошлогодних историй
Серия 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
Короч история длинная, сегодня будет первая серия 😁
Когда только в сбер устроился, дали задание поставить в прод рекомендательную систему для дочерней компании, которая с юл работает. Были артефакты, код для инференса, описание как поставить модель и сам…
Когда только в сбер устроился, дали задание поставить в прод рекомендательную систему для дочерней компании, которая с юл работает. Были артефакты, код для инференса, описание как поставить модель и сам…
Forwarded from Из коммерса в е-коммерса
Ну и карьерная новость №1 на сегодня: тим лид продуктовой аналитики в Lamoda Tech Анжелика Шахурина стала порноакртисой под ником Lika Blackberry. Точнее она ей была, просто об этом никто не знал, а сейчас узнали. А Lamoda Tech зачем-то начал удалять все посты с упоминанием Анжелики, хотя могли бы наоборот поддержать, зарплату повысить, накинуть новый функционал по организации тим билдингов, или еще как-то...
с кем не бывает, однажды вы найдете и мои видео…….
с кем не бывает, однажды вы найдете и мои видео…….
Forwarded from Maxim.ML - канал
Подготовил для вас актуальные идеи pet-проектов в ML на 2025 год
Всем data-привет! 🚀
Новый 2025 год уже начался, а значит самое время взяться за реализацию (и довести до конца😬 ) крутого pet-проекта, который бустанёт ваши навыки и карьеру в сфере ML.
На карточках ниже перечислил проекты, за которые я и сам бы взялся, честно говоря, настолько они интересные и актуальные. Все они, очевидно, связаны с использованием нейронных сетей, а большинство - с большими языковыми моделями.
Выберите один проект, и начните его прорабатывать. Уверяю вас, что навыки, которые вы приобретете в процессе создания проекта, вам пригодятся в для текущей или будущей работы.
Чуть более детальное описание можно найти на habr
#pet_проект
#карьера
Всем data-привет! 🚀
Новый 2025 год уже начался, а значит самое время взяться за реализацию (и довести до конца
На карточках ниже перечислил проекты, за которые я и сам бы взялся, честно говоря, настолько они интересные и актуальные. Все они, очевидно, связаны с использованием нейронных сетей, а большинство - с большими языковыми моделями.
Выберите один проект, и начните его прорабатывать. Уверяю вас, что навыки, которые вы приобретете в процессе создания проекта, вам пригодятся в для текущей или будущей работы.
Чуть более детальное описание можно найти на habr
#pet_проект
#карьера
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
История о том, как неудачный джойн чуть не испортил всё
Привет, друзья! Сегодня расскажу вам одну историю из жизни, которая случилась со мной на работе. Она о том, как важно иметь опыт работы с базами данных и почему критическое мышление и ответственность — это не просто слова, а жизненно необходимые навыки.
Итак, работал я в компании, где мы решили начать использовать данные из Бюро Кредитных Историй (БКИ). Если вы не в теме, это такие данные, которые помогают моделям кредитного скоринга стать почти волшебными. Они дают около 95% всей силы модели, и это намного лучше, чем универсальные модели, которые продаёт БКИ.
Наша задача была начать собирать эти данные и складывать их в хранилище. Но сначала нужно было убедиться, что данные корректные, чтобы через несколько месяцев можно было строить фичи и потом саму модель. Данные эти, скажу я вам, хранятся в очень странной структуре — около 40 таблиц, и джойнить их между собой — это квест, которому позавидует любой ролевик.
У меня уже был опыт работы с этими данными, поэтому я знал, как их джойнить. Описал всё в задаче, приложил примерный код. Инженеры начали загружать данные, а я поручил коллеге проверить, всё ли ок. Ответ был: всё ОК. Мы начали копить данные. Копили их полгода, и вот настало время строить модель.
Что-то меня насторожило — может, объём данных был в 10 раз больше ожидаемого, или что-то ещё. В общем, решил я уточнить, что же именно проверял мой коллега. Оказалось, что в моём скрипте был джойн нескольких таблиц. В каждой таблице был serial key (Hijid) — просто последовательные цифры 1, 2, 3, ... А чтобы джойнить, нужно было использовать foreign key из таблицы 1 (поле называлось похожим образом как название таблицы 2) с serial key (Hijid) из таблицы 2
Коллега мой взял скрипт, воспроизвёл его на Spark, но ничего не заджойнилось. Он подумал, что скрипт фигня, и решил джойнить по своему - все таблицы по полю Hijid, которое было во всех таблицах. И это у него прекрасно получилось, потому что во всех были значения от 1 до N. В итоге он проджойнил все 5 таблиц по этому полю и получил не пустые результаты. Раз данные собрались то все ОК, так ведь?🤣
Вывод из этой истории такой: важно иметь опыт работы с базами данных и понимать, хотя бы что такое serial key и foreign key. А ещё самостоятельность — это не просто делать всё самому, а критически относиться к своей работе и задавать вопросы, если есть сомнения. В итоге мы потеряли около 2 месяцев на то, чтобы прогрузить корректные данные и получить правильные результаты. И хорошо, что мы вовремя заметили ошибку, ведь могли бы обучить модель на неправильных данных и получить "не те" результаты.
Так что, друзья, не забывайте задавать вопросы и проверять свою работу. Удачи вам в ваших проектах!
Привет, друзья! Сегодня расскажу вам одну историю из жизни, которая случилась со мной на работе. Она о том, как важно иметь опыт работы с базами данных и почему критическое мышление и ответственность — это не просто слова, а жизненно необходимые навыки.
Итак, работал я в компании, где мы решили начать использовать данные из Бюро Кредитных Историй (БКИ). Если вы не в теме, это такие данные, которые помогают моделям кредитного скоринга стать почти волшебными. Они дают около 95% всей силы модели, и это намного лучше, чем универсальные модели, которые продаёт БКИ.
Наша задача была начать собирать эти данные и складывать их в хранилище. Но сначала нужно было убедиться, что данные корректные, чтобы через несколько месяцев можно было строить фичи и потом саму модель. Данные эти, скажу я вам, хранятся в очень странной структуре — около 40 таблиц, и джойнить их между собой — это квест, которому позавидует любой ролевик.
У меня уже был опыт работы с этими данными, поэтому я знал, как их джойнить. Описал всё в задаче, приложил примерный код. Инженеры начали загружать данные, а я поручил коллеге проверить, всё ли ок. Ответ был: всё ОК. Мы начали копить данные. Копили их полгода, и вот настало время строить модель.
Что-то меня насторожило — может, объём данных был в 10 раз больше ожидаемого, или что-то ещё. В общем, решил я уточнить, что же именно проверял мой коллега. Оказалось, что в моём скрипте был джойн нескольких таблиц. В каждой таблице был serial key (Hijid) — просто последовательные цифры 1, 2, 3, ... А чтобы джойнить, нужно было использовать foreign key из таблицы 1 (поле называлось похожим образом как название таблицы 2) с serial key (Hijid) из таблицы 2
Коллега мой взял скрипт, воспроизвёл его на Spark, но ничего не заджойнилось. Он подумал, что скрипт фигня, и решил джойнить по своему - все таблицы по полю Hijid, которое было во всех таблицах. И это у него прекрасно получилось, потому что во всех были значения от 1 до N. В итоге он проджойнил все 5 таблиц по этому полю и получил не пустые результаты. Раз данные собрались то все ОК, так ведь?
Вывод из этой истории такой: важно иметь опыт работы с базами данных и понимать, хотя бы что такое serial key и foreign key. А ещё самостоятельность — это не просто делать всё самому, а критически относиться к своей работе и задавать вопросы, если есть сомнения. В итоге мы потеряли около 2 месяцев на то, чтобы прогрузить корректные данные и получить правильные результаты. И хорошо, что мы вовремя заметили ошибку, ведь могли бы обучить модель на неправильных данных и получить "не те" результаты.
Так что, друзья, не забывайте задавать вопросы и проверять свою работу. Удачи вам в ваших проектах!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Дата канальи — про «специалистов» в данных / ML / AI
В комментариях к этому посту попросили поделиться ссылками на антифрод, их есть у меня
Прям в цельную картинку вместе они собраны в курсе ML в бизнесе, но здесь поделюсь кусочками, из которых она состоит.
А для совсем начинающих – хендбук
Как вообще устроен антифрод (на примере фин. мониторинга):
1. Правила (известные схемы, например из профильных обнальных тг-чатов -- для обнала: распыление, слом назначения платежа, вексели, слом ндс, транзит и пр) и экспертные модели (регрессии на известных фичах -- доли контрагентов, коэффициента налоговой нагрузки, корп карты, учредитель - подставное лицо и пр.). Известные фичи "ломаются" уже со стороны нарушителя -- например, КНН можно увеличить отправляя ошибочные платежки в налоговую и получая возвраты
2. Модели (supervised модели, построенные по отловленным правилами и руками кейсам). Здесь тоже работает PseudoLabelling. Но и фродеры не стоят на месте, на это намекал в самом первом начале канала https://yangx.top/datarascals/3
Кейс-менеджмент и эксперты (разбор найденных примеров, новых схем, мотивированное суждение). Разбор кейса может занимать, например, 2 недели, включая запрос документов от клиента
3. Exploration -- unsupervised -- outlier detection -- наша задача найти несколько десятков примеров, передать их на разбор, сделать supervised модель
4. Мониторинг качества работы и схем и отдельных фичей, симуляции новых схем атак
Мониторинг мошеннических заявок на кредит, определение компаний, искажающих финансовую отчетность -- все это тоже про антифрод.
На Forex вообще фродовыми считаются клиенты, которые выживают и выводят деньги.
Таргетом может быть как компания / физик так и конкретная сомнительная транзакция.
Итак, сами материалы
Поиск аномалий в табличках (для того чтобы быстро разные алгоритмы перебрать):
1. PYOD – база, даже вариационный автоэнкодер включили (вообще автоэкнодеры в разных формах полезны в этих задачах)
2. PYTOD – ускоренная версия (за счет использования GPU) – вообще большинство классических алгоритмов редко применяют из-за того что они очень медленные, мне нравится Isolation Forest из всех, но перебирать всегда приходится несколько
Здесь важно сделать отступление – что для многих классических алгоритмов придется как-то умозрительно задать ожидаемую долю аномалий, что не очень удобно. По факту нам интереснее ранжирование на более аномальные и менее – а дальше сколько мы возьмем будет зависеть от цены ошибки в каждом кейсе и мощности офицеров чтобы эти кейсы руками разобрать и подтвердить.
Поиск аномалий на транзакциях:
1. PYGOD– смотрим на задачу как на поиск аномалий в графах (и то, насколько аномалия должна быть более структурной чем контекстной – необучаемый параметр в лоссе), здесь в основном графовые автоэнкодеры
Но это прям затравочка, тема популярная, плюс графы меняются по времени (и структура и свойства вершин / ребер), даже на последнем NIPS (а это декабрь) показали новый алгоритм поиска аномалий на графах UniGAD. И еще на KDD’24 (сам еще не успел прочесть читал, но denoising диффузионка звучит как что-то интересное)
Подборка актуальных статей по теме
2. PTLS от Sber AI лабы сначала ssl-эмбеддим транзакции, потом закидываем в табличные методы
Если уже нашли и даже добились какой-то разметки, но единичек не очень много сотни), то помогает pseudolabelling– строите график того как метрика (обычно recall) зависит от того, с какого порога предикты единичек первой моделью досыпать в трейн второй. Выбираете порог, максимизирующий recall -- не панацея конечно, но до +10% полноты получалось выжимать.
Ну и supervised – здесь относительно понятно, кроме того на какой event rate калиброваться, да и надо ли )
Прям в цельную картинку вместе они собраны в курсе ML в бизнесе, но здесь поделюсь кусочками, из которых она состоит.
А для совсем начинающих – хендбук
Как вообще устроен антифрод (на примере фин. мониторинга):
1. Правила (известные схемы, например из профильных обнальных тг-чатов -- для обнала: распыление, слом назначения платежа, вексели, слом ндс, транзит и пр) и экспертные модели (регрессии на известных фичах -- доли контрагентов, коэффициента налоговой нагрузки, корп карты, учредитель - подставное лицо и пр.). Известные фичи "ломаются" уже со стороны нарушителя -- например, КНН можно увеличить отправляя ошибочные платежки в налоговую и получая возвраты
2. Модели (supervised модели, построенные по отловленным правилами и руками кейсам). Здесь тоже работает PseudoLabelling. Но и фродеры не стоят на месте, на это намекал в самом первом начале канала https://yangx.top/datarascals/3
Кейс-менеджмент и эксперты (разбор найденных примеров, новых схем, мотивированное суждение). Разбор кейса может занимать, например, 2 недели, включая запрос документов от клиента
3. Exploration -- unsupervised -- outlier detection -- наша задача найти несколько десятков примеров, передать их на разбор, сделать supervised модель
4. Мониторинг качества работы и схем и отдельных фичей, симуляции новых схем атак
Мониторинг мошеннических заявок на кредит, определение компаний, искажающих финансовую отчетность -- все это тоже про антифрод.
На Forex вообще фродовыми считаются клиенты, которые выживают и выводят деньги.
Таргетом может быть как компания / физик так и конкретная сомнительная транзакция.
Итак, сами материалы
Поиск аномалий в табличках (для того чтобы быстро разные алгоритмы перебрать):
1. PYOD – база, даже вариационный автоэнкодер включили (вообще автоэкнодеры в разных формах полезны в этих задачах)
2. PYTOD – ускоренная версия (за счет использования GPU) – вообще большинство классических алгоритмов редко применяют из-за того что они очень медленные, мне нравится Isolation Forest из всех, но перебирать всегда приходится несколько
Здесь важно сделать отступление – что для многих классических алгоритмов придется как-то умозрительно задать ожидаемую долю аномалий, что не очень удобно. По факту нам интереснее ранжирование на более аномальные и менее – а дальше сколько мы возьмем будет зависеть от цены ошибки в каждом кейсе и мощности офицеров чтобы эти кейсы руками разобрать и подтвердить.
Поиск аномалий на транзакциях:
1. PYGOD– смотрим на задачу как на поиск аномалий в графах (и то, насколько аномалия должна быть более структурной чем контекстной – необучаемый параметр в лоссе), здесь в основном графовые автоэнкодеры
Но это прям затравочка, тема популярная, плюс графы меняются по времени (и структура и свойства вершин / ребер), даже на последнем NIPS (а это декабрь) показали новый алгоритм поиска аномалий на графах UniGAD. И еще на KDD’24 (сам еще не успел прочесть читал, но denoising диффузионка звучит как что-то интересное)
Подборка актуальных статей по теме
2. PTLS от Sber AI лабы сначала ssl-эмбеддим транзакции, потом закидываем в табличные методы
Если уже нашли и даже добились какой-то разметки, но единичек не очень много сотни), то помогает pseudolabelling– строите график того как метрика (обычно recall) зависит от того, с какого порога предикты единичек первой моделью досыпать в трейн второй. Выбираете порог, максимизирующий recall -- не панацея конечно, но до +10% полноты получалось выжимать.
Ну и supervised – здесь относительно понятно, кроме того на какой event rate калиброваться, да и надо ли )