Привет всем!👋
В выходные пробежался по предпоследней дистанции сезона - 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

Привет всем!👋
Отличной рабочей недели.
Начнем неделю с мема про бизнес реалий рынка DS.

Признавайтесь, было ли у вас хотя бы раз, что заказчик хотел "попробовать" LLM там, где он не применим?


#офтоп #fun

Привет всем!

Осень пора хондры новых знаний.
И так уж получилось, что 🦜 выпустило аж 2 отличных курса, которые идут всю осень для тех, кто хочет попробовать себя в чем-то новом, освежить базовые знания.

Natural Language Processing course
Курс ведет Валентин Малых, лекции проходят еженедельно по вторникам в 18:35 (UTC +3, МСК), начиная с 16 сентября.
Содержание курса достаточно базовое для классического НЛП курса и включает в себя информацию о эмбеддингах, сверточных и рекуррентных нейронных сетях, больших языковых моделях.
В курсе подразумевается 3 практических задания, 2 домашки + 1 финальный проект.

Классические модели ML
Обуздать классические модели, познать прелесть интерпретируемости линейных моделей можно в данном курсе. Ввиду того, что классический МЛ - базовые знания на любую DS позицию сейчас, то тем, кто все забыл или тем более ничего не знает крайне рекомендую.
Курс ведут Иван Комаров, Артем Шевляков, Дмитрий Лапочкин и Георгий Туркия. Длится с 18 сентября по 20 ноября.
Опять же, как и в предыдущем курсе присутствует практический материал, представленный в виде 7 домашних заданий.
На курсе есть LeaderBoard (LB), так что если соревновательная составляющая вас мотивирует, то милости прошу на курс. Кроме того, утверждается, что еще, после ДЗ, будет конкурс, формат правда на момент написания не известен, дающий дополнительные баллы.

#ds_лайфхаки

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

Количество постов явно коррелирует с загруженностью на работе. Прошлая неделя была посвящена модельному риску.

Кто не знает что такое модельный риск, дам небольшую вводную.
Модельный риск - событие риска, наступающее при ошибочных решениях на основе неточности/несовершенства использования моделей в бизнес процессах.

Любая модель в том или ином виде подвержена модельному риску!

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

Так уж случилось, что на той неделе произошло аж 2 инцидента по модельному риску.

- Что в таких случаях делает команда DS и в чем заключается сложность данного процесса?
Любая модель, так или иначе, стоит на мониторинге, в разных системах, которые в случае проблем дают симптомы. Чаще всего перераспределение признаков, либо целевой метки.

- Итак, мы видим на мониторингах странные вещи, в чем проблема их пофиксить?
Главная проблема в том, что симптомы общие для семейства проблем и DS оперативно выявить и локализовать проблему. Например, видим падение источника (фича перестала приходить, везде NaN) на источнике данные могут быть, но например, не подгружаться корректно инфрой. Тут уже надо бежать смотреть логи модели, проверяя как и первоисточник данных, так и систему, их выгружающую. В случае моей работы, это постоянное смотрение ручками + коммуникация и координация действий со смежными подразделениями по данным (DE) и инфраструктуре (MLOps).

- Выявили проблему, что дальше?
Это уже большая победа, ведь каждый день ошибки на модели - миллионы потерь для банка. Составляется план исправления в кратчайшие сроки. Когда понятны причины, заводится риск событие. Риск событие - формализация проблемы с указанием его первоисточника, процессов, затронутой проблемой и планом решения.

Данное событие обрабатывают риск-чемпионы - коллеги, которые принимают решение о критичности, формализуется оценка потери. Буквально коллеги оценивают полноту картины, в каких процессах что упало и где это влияет в денежном эквиваленте. Результатом их работы является поручение на анализ финансового эффекта потерь, подтверждение, что предложенный план исчерпывает проблему и дается правовая оценка события (если дело пахнет жареным и тянет на пару статей УК РФ).

Для нас как для DS данный процесс представляет собой формирование Ad-hoc упражнений, которые потом используются для подсчета потерь (чаще всего это некоторый what-if анализ, который мы проводим в сжатые сроки). Плюс на плечах DS лежит вывод патча + проверка и подтверждение, что после исправления работает все именно так, как и должно.

- Какой результат?
Исправление бага, действия со стороны бизнеса, которые минимизируют эффект (например, оперативный пересчет предложений, блокировка выдачи в конкретный момент), оценка прогнозируемых и фактических потерь (хорошая новость этого события, что потенциальные потери != фактические, нередко клиент может даже не заметить на себе что что-то случилось).

#трудовые_будни

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

Просто посмотрите какая красота - логотип новой версии 🐍.
Вчера официально вышел релиз Python 3.14.

- Какие изменения нас ждут в данном релизе?
1️⃣🔤 Прежде всего, важнейшим обновлением является тот факт, что теперь Python официально поддерживается на ОС Android.
2️⃣🔤Уже традиционное улучшение сообщений об ошибке.

whille True:
    pass
Traceback (most recent call last):
  File "<stdin>", line 1
    whille True:
    ^^^^^^
SyntaxError: invalid syntax. Did you mean 'while'?

3️⃣🔤Куча удаленных и deprecated функций.
4️⃣🔤Интересным нововведением является SyntaxWarning при использовании операторов return, break, continue, приводящих к выходу из блока finally
Код ниже даст SyntaxWarning

 def f():
     try:
         ...
     finally:
         return 42

 for x in o:
     try:
         ...
     finally:
         break  # (or continue)

Напротив, код ниже отработает без сигнализации проблем

 try:
     ...
 finally:
     def f():
         return 42

 try:
     ...
 finally:
     for x in o:
         break  # (or continue)

5️⃣🔤Выражение except теперь может вызывать несколько типов ошибок без использования скобок:

try:
    connect_to_server()
except TimeoutError, ConnectionRefusedError:
    print('The network has ceased to be!')

6️⃣🔤В встроенную библиотеку compression добавлен новый метод сжатия zstd
7️⃣🔤Новые t-strings. Т строки (Template Strings), иначе говоря шаблонные, включают в себя статичную и вставочную часть, при этом результат вывода не является строкой.

variety = 'Stilton'
template = t'Try some {variety} cheese!'
type(template)
<class 'string.templatelib.Template'>

list(template)
['Try some ', Interpolation('Stilton', 'variety', None, ''), ' cheese!']

Такие конструкции удобны для проверки входящих данных, например целых кусков HTML, ведь вводимые данные имеют тип Interpolation.
Например:

def lower_upper(template):
    """Render static parts lowercase and interpolations uppercase."""
    parts = []
    for part in template:
        if isinstance(part, Interpolation):
            parts.append(str(part.value).upper())
        else:
            parts.append(part.lower())
    return ''.join(parts)

name = 'Wenslydale'
template = t'Mister {name}'
assert lower_upper(template) == 'mister WENSLYDALE'

Обновление интересное, включает еще в себя кучу оптимизаций, включая freethreding, JIT, дополнительной оптимизацией по памяти, что разрушает стериотип о Python - медленный, но простой.

По традиции, 🔥, если понравилось
#ds_лайфхаки