Привет всем!👋

В целом, любому кто интересуется и работает в DS важно смотреть по сторонам, чем занимаются и что в тренде. Да и возможно ваша область применения вам наскучила и хотите узнать что и как у соседей за забором.

В целом собрали папку с ребятами, в ней есть много интересных ребят, например:

▪️Юра рассказывает про опыт внедрения ИИ на производстве. Мне понравились материалы с реальными примерами применения моделей и датасетами в разных индустриях.

▪️Саша, тот, кто отвечает за цифру в Я.Лавке после слов «Ваш заказ будет через …» научит вас вкатываться в DS бесплатно😂.

▪️Ваня специализируется на ранжировании и всем, что связано с рекомендациями, пишет отличные посты на эту тему.

▪️Виталий, который рассказывает как вкатился в аналитику в 30+ лет. У него есть крутой пост про неправильную формулу прироста в учебниках.

▪️Даня публикует активно различные датасеты.

▪️Захар специализируется на звуке и рассказывает про свой стартап Audio2MIDI.

Могу продолжать еще долго, советую просто подписаться на папку.

👉папка с крутыми специалистами👈

Кстати про то, как я работаю с папками, писал ранее тут, рекомендую ознакомиться.

#офтоп

Привет всем!👋

Разбавим этот четверг немного техническим материалом.
Сегодня поговорим, про встроенную функцию zip().

Данная функция используется для создания итератора, объединяя элементы из различных итераторов.
Рассмотрим следующий код:

names = ['Аня', 'Боря']
scores = [85, 92]
ages = [25, 27] 

result = list(zip(names, scores, ages))
print(result)

результат работы ниже:

>> [('Аня', 85, 25), ('Боря', 92, 27)]

Видим, что мы создали итератор, в котором 2 элемента, объединяющих целых 3 списка.

Функция удобна, но имеет ряд недостатков. Сделаем искусственно 3 списка разной длины и попробует объединить.

names = ['Аня', 'Боря', 'Вова'] # Обратите внимание: здесь 3  элемента
scores = [85, 92] # Обратите внимание: здесь 2  элемента
ages = [25, 27, 30, 35]  # Обратите внимание: здесь 4 элемента

result = list(zip(names, scores, ages))
print(result)

Результат исполнения кода довольно-таки интересный:

>> [('Аня', 85, 25), ('Боря', 92, 27)]

Видим, что, сгруппировалось по принципу наименьшей длины итератора, в данном случае scores.

- Как решить данную проблему?
Данную проблему решить на 100% не получится, так как, при разных длинах встает вопрос однозначности сопоставления. Но вариант сохранить максимальную размерность есть.
Тут на помощь приходит библиотека itertools с ее вариантом реализации zip_longest().

Основное отличие zip_longest() от zip() в том, что он тоже объединяет элементы, но работает до тех пор, пока не закончится самый длинный из переданных объектов

Таким образом, для аналогичного кода:

from itertools import zip_longest

names = ['Аня', 'Боря', 'Вова']
scores = [85, 92]
ages = [25, 27, 30, 35]

result = list(zip_longest(names, scores, ages))
print(result)

вывод будет следующим:

>> [('Аня', 85, 25), ('Боря', 92, 27), ('Вова', None, 30), (None, None, 35)]

Теперь все элементы на месте! Но там, где данных не хватило, появилось значение None.

- Хочу вместо None другое значение!
Без проблем! За это отвечает атрибут fillvalue.

result = list(zip_longest(names, scores, ages, fillvalue='N/A'))

Кстати, есть еще одно интересное и неочевидное применение zip() - обратная распаковка данных.
Предположим, у нас есть уже заzipованный итератор zipped_data:

zipped_data = [('Аня', 85, 25), ('Боря', 92, 27), ('Вова', 78, 30)]

из него мы можем обратно восстановить names, scores, ages распаковав их следующим образом:

names, scores, ages = zip(*zipped_data)

Аналогично работает и с zip_longest():

names, scores, ages = zip_longest(*zipped_long, fillvalue='N/A')

Ставь 🔥, если не знал!

#ds_лайфхаки

Привет всем!👋
В выходные пробежался по предпоследней дистанции сезона - 5 км Забег Ради Жизни 2025.

Самая тяжелая дистанция года. Болезнь, отсутствие на протяжении месяца регулярных тренировок и резкий перепад погодных условий дали о себе знать.
Результат прошлого года, правда, все равно побил на 1 минуту, хоть и с очень и очень большими трудозатратами.

Нравится, что традиционно это большая тусовка AlfaRunners, много ребят в клубных футболках на трассе. Я, собственно, не стал исключением.

#life

Привет всем!👋
Продуктивной рабочей недели!

Сегодня хотел бы поделиться мыслями про рекомендательные системы.
Рекомендательные системы стали неотъемлемой частью нашего дня, но их слепая оптимизация под формальные метрики часто ухудшает качество поиска и пользовательский опыт. Хотите вы послушать музыку, посмотреть фильм или заказать товар, вам подсовывают не то, что вы хотели или искали, а то, что по мнению системы "вы хотите послушать/посмотреть/купить". И вместо нужного, вы становитесь жертвой рекомендации, где лучше знают, что вы хотите. Но почему так происходит?

Многие платформы одержимы оптимизацией метрик вроде Precision@k, NDCG@k и других показателей "релевантности". Однако слепая погоня за этими цифрами создает системные проблемы, из-за которых поиск и рекомендации начинают работать против своих первоначальных целей .

Одна из самых известных проблем — создание информационных пузырей, где пользователь оказывается запертым в круге однотипных рекомендаций.

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

Пример в соцсетях:
В большинстве известных соцсетей лента новостей формируется на основе метрик вовлеченности (engagement metrics, таких как лайки, комментарии, время просмотра). Это приводит к тому, что после одного случайного клика на конспирологический материал пользователь начинает получать все больше похожего контента, попадая в информационную ловушку, где вам навязывают, что это интересно именно вам.

Пример на маркетплейсах:
На большинстве маркетплейсов при поиске конкретной модели кроссовок определенного размера система первым делом показывает популярные модели, которые лишь отдаленно соответствуют запросу. Точные соответствия оказываются на втором-третьем экране, а иногда и вовсе отсутствуют в первых результатах. Это особенно критично для мобильных пользователей, которые редко листают дальше первой страницы.

Кроме того, популярна проблема излишней персонализации в стриминговых сервисах кино.

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

- Почему так?
Разработчики рекомендательных систем стремятся оптимизировать формальные метрики качества - Precision@k, MAP@k, NDCG@k. Эти показатели измеряют, насколько рекомендации соответствуют ожиданиям пользователя, но имеют серьезные ограничения .

Precision@k - измеряет долю релевантных элементов среди первых k рекомендаций. Проблема: система учится манипулировать статистикой, предлагая только "безопасные" популярные товары .

NDCG@k - учитывает порядок релевантных элементов в выдаче. Проблема: не учитывает разнообразие рекомендаций.

#статьи

Привет всем!

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

В качестве источника данных у нас каменные базы данных, буквально глиняные таблички древних шумеров, некоторые из которых датируются 30-31 веком до н.э и описывают количество отданных или полученных мешков ячменя и солода.
Мы хотим залить в БД и делать привычные select * from, но вот тут начинаются интересные моменты.
В единичной записи в нашей БД - кол-во товаров и конечно же дата. Но дело в том, что у каждого диалекта SQL есть свои ограничения.

Рассмотрим основные примеры:
1️⃣MySQL:
🔵Минимальная дата в формате DATETIME - 1000 год н.э.
🔵 Однако MySQL может обработать, хоть и не всегда некорректно даты вне диапазона, например, даты до 1000 года. В некоторых случаях он может проигнорировать такие значения или вернуть неожиданные результаты (например, преобразовать дату 0024-06-21 в 2024-06-21).

2️⃣SQL Server:
🔵Минимальная дата в формате DATETIME - 1753 год н.э
🔵 Тут источники рознятся в причинах выбора, так как дата появления календаря 1582 год н.э., но в целом, выбор даты обусловлен историческими особенностями перехода большей части мира на григорианский календарь.

3️⃣PostgreSQL
🔵Минимальная дата в формате DATE - 4713 год до н. э. (BC)
🔵Дата в том числе юлианского календаря считается по пролептическому григорианскому календарю (расширенный в прошлое григорианский календарь), что приводит к некоторым трудностям и расхождениям в интерпретации дней и года из-за расхождения календарей.

4️⃣SQLite
🔵Аналогично PostgreSQL

5️⃣Impala
🔵Минимальная дата в формате DATE - 1 год н. э.
🔵Дата считается по пролептическому григорианскому календарю (расширенный в прошлое григорианский календарь), что приводит к некоторым трудностям и расхождениям в интерпретации дней и года из-за расхождения календарей.

Таким образом, для использования в нашем примере, рекомендуется использование PostgreSQL и SQLite. Все другие диалекты могут давать неожиданные для нас результаты и ошибки.

Ставь 🔥, если не знал.

#ds_лайфхаки

Да не умер он в конце спринта, просто немного устал...

Привет всем! 👋
Возвращаюсь к вам небольшими новостями, спустя почти 2 недели тишины.

Да, действительно, куча дел выбили меня из рабочего ритма.
В последнее время начал часто болеть, на работе активная фаза вывода одной модели и инфраструктурные проблемы по другой высасывают все соки. Плюс ключевые исполнители болели/были в отпуске, а так как ребята забирали на себя почти всю технику (за что им огромное спасибо), при их отсутствии я сразу превращаюсь в онлайн-кодера.

Почему онлайн-кодер?
Да потому что team lead things никто не отменял, при этом надо толкать написание моделей, предобработки и продовых инференсов, в параллель со статусами демо и презентациями. Вот и получается, что никто менеджерские забавы не отменял, только еще свободную минутку ты погружен в написание кода.

Помимо этого, я активно участвовал во внутреннем мероприятии "Сто глупых вопросов про ИИ", где в качестве эксперта отвечал на вопрос, заданный про модельный риск. Объективно, учитывая нагруженность и болезнь, само выступление, хоть и короткое, получилось достаточно провальным.
Изначально, я не должен был выступать, но пришлось подхватить ответ моего руководителя. А кто часто выступает знает, что короткий ответ на вопрос, который написан и сформулирован не тобой, очень сложно адаптировать, особенно в короткие сроки. Результат - пэк мэк на 1.5 минуты. В общем, я недоволен, но опыт есть опыт, не всегда на выступлении тебе дают говорить и делать что хочешь, при этом давая на подготовку 3 недели.

Сейчас объективно стало легче, ребята вернулись в строй, чем разгрузили меня, даже получилось (спустя аж месяц) полноценно поиграть в настольный теннис.

Как результат описанного выше, я полностью выпал из Kaggle соревнования, 18 дней без экспериментов, вжух и я уже далеко от бронзы на 220 позиции. Остается 20 дней и надо постараться вернуть прежнее величие позиции.

А как у вас дела?

#life

Привет всем!👋
Сегодня на Practical ML Conf!
Рад буду пообщаться, ищите, думаю два метра Андрея вы увидите сразу😂

#life