Всем привет!

Приглашаем всех на Дата Ëлку 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

Удалось побывать 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 логов ошибок с временными метками

Напомнило мне вот этот ролик
https://youtu.be/UFqXDpMMwtA?si=FKH3We7MX3VomiF1

AI видимо добить его решил

Привет, друзья! 🤓

Вот и закончились праздники, и пришло время вернуться к нашим любимым историям. Сегодня хочу поделиться итогами одной из прошлогодних историй
Серия 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. Учимся на ошибках и движемся вперед! 🙌

До новых историй, друзья! 💡