Привет! Это Саша Ледовский. Сегодня начнём разговор об управлении версиями в проектах.

Разработчики живут в счастливом мире систем контроля версий. Мы в ML тоже, но к сожалению, нам этого недостаточно. Знакома проблема, что у вас в папке лежит несколько десятков ноутбуков, которые не запускаются? Тогда вы понимаете, о чём я.

Наверное, каждый дата сайентист попадал в следующую историю:

👉 Вы с коллегами начинаете работать над новой задачей. У вас появляются несколько ноутбуков с разными версиями модели.

👉 Довольно быстро в них становится много одинакового кода, например, с подготовкой данных, обучением, измерением метрик. И тогда вам приходит мысль: «а давайте вынесем переиспользуемый код в файлик lib.py»?

👉 И вот у вас появляются новые ноутбуки, в которых гораздо меньше копипаста. Однако со временем lib.py меняется, и старые ноутбуки на свежей кодовой базе не запустить. Можно, конечно, откатиться на старые коммиты, но сравнить старую и новую модель уже не получится.

Представьте боль, гнев и смирение продакта, к которому приходит DS и говорит:

Новая модель показала ROC AUC 0.8. А у старой модели 0.75. Правда, ROC AUC старой модели посчитан на датасете другой предобработкой. Но я считаю, что всё равно норм, и нужно в прод катить, потому что лучше метрик мы не получим.

Варианты решения проблемы. Я знаю несколько подходов:

✅ Поддерживать актуальную версию пайплайна в мастере. Как — расскажу в следующем посте.

✅ Выносить общий код в полноценную библиотеку с версиями.

✅ Использовать вычислительные платформы вроде Kubeflow.

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

Продолжаем разбираться с управлением версиями в ML-проектах, первый пост читайте выше.

Начну с подхода, который является моим основным выбором, как только я начинаю ощущать, что проект разрастается.

Поддержка актуальной версии в мастере. Надеюсь, вы не подумали, что суть подхода в том, чтобы задним числом актуализировать старые ноутбуки. Так можно сойти с ума, не дожив до DS-пенсии.

👉 Основой вашего проекта становятся параметризуемые скрипты или пайплайны, актуальная версия которых поддерживается в мастер-ветке.

👉 Простые эксперименты заключаются в запуске пайплайна с определённым набором параметров.

👉 Сложные эксперименты требуют изменения пайплайна и делаются в отдельных ветках. Если изменения успешны, то они мёрджатся в мастер.

👉 Изменения пайплайна добавляются двумя способами: в виде параметра или полностью перетирая старый код. Тут сами думайте, хотите ли вы оставить предыдущую логику или нет.

Несколько примеров:

💡 Хотите тестировать наборы фичей. Добавьте в пайплайн параметр features, куда будете передавать список

💡 Хотите поменять веса таргета в обучении. Добавьте параметр target_weights, который будет принимать словарь. Например {"click": 1, "like": 4}

💡Пайплайн не обязательно делать один. Точно стоит разделить подготовку датасета и обучение модели. Ну и для разных походов можно делать разные пайплайны.

Итог. Данный подход хорош и универсален. Его можно применить как для небольших проектов с локальным запуском кода, так и для крупных решений, использующих Airflow поверх Kubernetes.

Но недостатки всё-таки есть. Сложность пайплайна будет расти, а эксперименты — занимать все больше времени. Что-то не будет вписываться в архитектуру кода, что-то поломает половину тестов, которые нужно будет переписывать.

Есть и другие подходы работы с версиями ML-проектов. Расскажу о них в следующем посте.

Это заключительный пост в серии про управление версиями в ML проектах.

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

На всякий случай предупреждаю: здесь почти 2 000 символов.

Библиотека + ноутбуки. Библиотека — это не lib.py, а полноценная python-библиотека, с поддержкой версий. Мы активно используем библиотеки в работе, хотя и не на всех задачах. Например, с помощью библиотеки реализованы оффлайн-эксперименты над поиском.

👉 Каждый эксперимент фиксирует версию библиотеки. Например, указывает !pip install -U my-lib==1.00 в начале ноутбука.

👉 Нужно либо использовать локальный PyPI, либо устанавливать библиотеку прямо с гит репозитория.

👉 Во время разработки библиотеку можно подключать локально через sys.path.append, чтобы дорабатывать одновременно и библиотеку, и код эксперимента.

С одной стороны, поддержка библиотеки — это дополнительные трудозатраты. Если вы что-то меняете не только в пайплайне с моделью, но и в библиотеке, то вам нужно делать дополнительный Pull Request.

С другой, сам эксперимент уместится в один ноутбук и не будет привязан к репозиторию.

Пайплайны из компонентов. Подход используется в нашей ML-платформе, построенной на Kubeflow, и мне он больше всего нравится. К сожалению, требователен к инфре, и дёшево сделать не получится.

👉 Пайплайны состоят из компонент, которые упакованы в Docker-контейнеры и запускаются на Kubernetes-кластере.

👉 Пайплайн собирается и запускается прямо в ноутбуке из существующих компонент, при необходимости можно дописать новые.

👉 Продовые пайплайны добавляются в репозиторий и ставятся на расписание.

Можно сказать, что этот способ сочетает лучшее от предыдущих подходов. Тут есть и контроль версий компонент, и возможность легко проводить эксперименты без обновления библиотеки.

Итог. Мы с вами посмотрели на целых три способа работы с версиями в ML проектах. Надеюсь, что было полезно, и теперь вашим проектам не грозит превратиться в кладбище из неработающих ноутбуков.

Всем привет! Недавно в посте я рассказывала про команду LLM и упомянула, что мы каждую неделю проводим LLM семинары: собираемся всей командой и рассказываем друг другу статьи, которые удалось прочитать за последнее время.

Обычно докладчик не готовит презентацию, а просто открывает статью и объясняет основную мысль, и дальше мы вместе обсуждаем результаты и подробности.

Стоит ли DS-командам в крупных компаниях тратить на это время? Я считаю, что стоит! А в доказательство этого я подготовила пару статей, идеи которых уже применяются у нас:

📝 Impact of Tokenization on LLaMa Russian Adaptation

У опенсорсных моделей токенизатор лучше адаптирован к английскому языку, чем к русскому. Как можно в этом убедиться? Мы взяли токенизатор Mistral и обучили свой на большом корпусе русскоязычных данных.

После обучения среднее число символов в токене для русских текстов увеличилось с 2,1 до 3,3. То есть, перейдя на новый токенизатор, мы бы смогли ускорить инференс в среднем в 1,5 раза.
Это очень здорово, но непонятно, как заменить токенизатор. Ведь сначала обучается он, а потом уже вся модель, и его нельзя просто взять и выкинуть. Так мы думали, пока не разобрали эту статью на LLM семинаре.

Основная идея статьи в том, что нужно обучить новый токенизатор, а дальше подставить его к сети и переделать embedding-слой. То есть инициализировать его по-новому:

берём токены от нового токенизатора → токенизируем их старым токенизатором → получаем их эмбеддинги → усредняем их.

И это будет эмбеддинг в новой сети. Потом нужно заморозить всю сеть, кроме embedding-слоев, и дообучить на большом корпусе данных — примерно в 100 ГБ.

Мы это проделали, но решили не останавливаться: разморозили веса сети и дообучили ещё раз на этих же 100 ГБ данных. Полученную модель теперь используем в проде.

📝 Spike No More: Stabilizing the Pre-training of Large Language Models

В статье рассказывают, как можно избежать взрывов градиента во время обучения претрейна LLM. Одна из идей: скейлить эмбеддинг слой, например, домножать эмбединги на корень из d. Используем данную технику в обучении своей модели.

📝 Stay tuned: в будущем поделюсь и другими статьями, в которых мы нашли полезные практики.

Объявляем ML-соревнование 🏆

Avito ML Cup 2025 — шанс прокачать навыки на прикладных задачах одному или с командой и заработать денежный приз.

Мы проводим ML Cup уже второй раз. В этом году будет сразу две задачи, а о прошлогоднем вызове можно почитать в этом посте.

👋 Как участвовать

Хакатон пройдёт с 31 марта по 28 мая: регистрируйтесь, выбирайте задачку или участвуйте сразу в обоих соревнованиях.

В конце наградим авторов трёх лучших решений для каждой задачи.

🧠 Какие задачи

1. Персональные рекомендации. Определите, на какие товары люди откликнуться с наибольшей вероятностью на основе их истории и метаинформации об объявлениях.

2. Поиск дублей. Разработайте алгоритм, который на основе текстовой информации, изображений и других атрибутов позволит выявлять в массиве повторные объявления.

💰 Что можно выиграть
250 000 ₽ за 1 место
200 000 ₽ за 2 место
150 000 ₽ за 3 место

Решать задачу про рекомендации →

Решать задачу про дубли →

Всем привет! На связи Толя Мастрюков и Миша Каменщиков. Сегодня расскажем о задаче по рекомендациям в нашем ML-соревновании.

В прошлый раз мы запускали конкурс по рекомендательным системам в далёком 2017-м на платформе DataRing, а сабмиты были по электронной почте.

✍️ Задача. Она максимально приближена к реальной задаче кросс-категорийных рекомендаций на Авито. Решения могут быть практически сразу протестированы в продакшене — конечно, если в них не окажется трёхуровневого стекинга из десятков моделей.

В классической постановке задача рекомендаций заключается в том, чтобы предложить пользователю сущности (фильмы, товары, треки) на основе его истории действий. У Авито это объявления, но их очень много (свыше 200 млн), и они недолговечны: ежедневно открывается и закрывается около 2 млн объявлений.

Поэтому мы упростили задачу: вместо объявлений рекомендуем группы товаров, например, конкретную модель телефона — iPhone 16. Затем выбираем свежие объявления из группы и показываем их пользователю. Именно так работает одна из наших моделей в продакшене.

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

И ещё один важный аспект. На Авито есть разные типы действий: просмотр, добавление в избранное, звонок, отправка сообщения и другие. Но почти никогда нет явного сигнала о покупке (кроме заказов с Авито Доставкой).

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

📊 Данные. Основные данные включают 68 млн взаимодействий пользователей с объявлениями. В них есть: дата, платформа, тип действия, источник (поиск, рекомендации и другие), ID объявления и группы товара.

Чтобы можно было строить более интересные модели, мы добавили информацию о контенте объявлений, а именно: локацию, категорийные параметры и эмбеддинг заголовка.

💻 Бейзлайн. Мы подготовили для участников jupyter-ноутбук со всем необходимым: как прочитать данные, обучить простую ALS-модель при помощи библиотеки implicit, сделать валидацию и собрать файл для отправки в систему. Для запуска будет достаточно компьютера с 16GB RAM.

📖 Что посмотреть по теме:

1. Доклад Толи про наш подход →

2. Мишин гитхаб с решениями соревнований →

3. Конкурсы по рекомендательным системам на Kaggle (подходы описаны на форуме):
Рекомендации для H&M →
Рекомендации для OTTO →

4. Решения ежегодных Recsys Challenge — тут стоит погуглить, участники выкладывают их на гитхабе.

Уже вписались в соревнование?
🤓— да, хочу решить как минимум одну задачку
🤔 — пока нет, но надо бы

Всем привет! На связи Настя Рысьмятова и часть команды моего юнита LLM (познакомиться с ними можно по фото ↑↑↑)

Мы опубликовали результаты нашей языковой модели A-Vibe в лидерборде Мера и стали первыми среди моделей до 10B.

Смотреть лидерборд →

🏆 За основу A-Vibe мы выбрали Qwen2.5-7B, подменили у модели токенизатор, следуя статье Impact of Tokenization on LLaMa Russian Adaptation.

🏆 Токенизатор обучили преимущественно на русских текстах, это позволяет модели быстрее генерировать тексты на русском языке.

🏆 После подмены токенизатора разморозили все слои и сделали continual pre-training — продолжили учить сеть на большом объеме текстовых данных.
Дальше проделали SFT и DPO.

Спасибо всей команде за проделанную работу!

Хакатон IT Purple Hack от Авито × МФТИ: как это было

Всем привет! Я Коля Калмыков из DS команды Goods, веду образовательные проекты в DS. В марте мы вместе с моим коллегой Владом Векленко провели хакатон, в котором участвовали студенты и опытные специалисты по Data Science. Сегодня расскажем, как всё прошло.

Хакатон был посвящён определению цвета товара по фото: участникам предстояло построить модель, способную распознавать один из 18 цветов.

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

🤖 Чем всё закончилось. Команды пробовали всевозможные подходы — от простых цветовых гистограмм до современных мультимодальных CLIP-моделей и сегментации (маттирования) фона.

Некоторые участники даже перезапускали разметку датасета с помощью продвинутых внешних сервисов и получили существенный прирост метрик макро-F1, precision и recall.

Были и забавные истории, когда ребята испытывали AI-модели, случайно перегружали демо-сервисы и искали обходные пути.

В итоге лучшие команды показали отличные результаты, а их наработки мы обязательно учтём в наших проектах. Самое главное: все участники получили реальный опыт решения бизнес-задачи, а у нас появилось сразу несколько любопытных идей, как повысить качество поиска по цвету на Авито.

🔮 Что дальше. Мы убедились, что совместные мероприятия с университетами — отличный способ решать сложные задачи и вдохновлять новое поколение специалистов в области Data Science. Уже думаем над следующим хакатоном, так что следите за анонсами!

Спасибо всем, кто участвовал: организаторам из МФТИ, нашим коллегам из Авито и, конечно, талантливым участникам. Было круто!

Путеводитель по статьям о DS в Авито

Всем привет! Делимся подборкой наших статей: узнаете, как устроены команды DS, что синьоры Авито советуют для карьерного роста и что под капотом у некоторых моделей, которые помогают следить за качеством миллионов объявлений.

✍️ Чем вообще занимаются дата сайентисты в Авито. Полный разбор большинства наших задач с примерами — самая полезная статья для знакомства.
Читать →

✍️ Как DS-инженеру расти в профессии: советы синьоров. Света Морозова и Серёжа Кляхандлер в подробностях рассказывают о нашей системе грейдов и своём пути по ним, а ещё дают рекомендации для ускорения карьерного роста.
Читать →

✍️ Как работает поисковое ранжирование. Илья Валяев, тимлид DS, объясняет, как формируются результаты поиска на Авито и какие есть методы для улучшения выдачи.
Читать →

✍️ Как мы обучили Mistral 7B русскому языку. Настя Рысьмятова, руководитель команды LLM, описывает процесс адаптации языковой модели, которая помогает пользователям создавать тексты для объявлений.
Читать →

✍️ Как устроена автомодерация видео и изображений. Владимир Морозов, старший DS-инженер, в двух статьях рассказывает о том, как модели присматривают за качеством контента в объявлениях.
Читать о модерации видео →
Читать о модерации картинок →

Привет! С вами команда Дублей и её представители Баяр Пак и Андрей Бибиков, сегодня мы расскажем про нашу задачу на Avito ML Cup.

О второй задаче про рекомендации можно почитать в другом посте.

Прошло почти девять лет, как мы запускали первое соревнование по поиску дублей на Kaggle. С тех пор многое изменилось: модели стали умнее, а нарушения — хитрее.

✍️ Задача. Иногда пользователь, пытаясь ускорить сделку, публикует несколько похожих объявлений об одном и том же. Это усложняет поиск для покупателей и снижает эффективность для других продавцов.

В рамках хакатона вам предстоит решать задачу, практически идентичную продовой. Единственное отличие — масштаб. В проде для каждого объявления наша система скорит сотни потенциальных дублей, тогда как в хакатоне мы ограничиваемся максимум 10 кандидатами для опорного объявления.

Всё было бы просто, если бы продавцы не старались замаскировать свои дубли. Одни переписывают описания, меняют абзацы местами, другие используют разные фотографии: слегка изменяют ракурс товара или немного аугментируют изображения.

Иногда отличия кроются в деталях: товар один и тот же, но цвет другой — на это можно обратить внимание только по изображению.

Бывают и обратные случаи, когда изображения и текст почти идентичны, но в описании разные ключевые параметры, например, размер кроссовок. Такие нюансы могут оказаться критичными: именно они определяют, будем ли мы считать пару дублем.

И последний нюанс. В проде мы сравниваем тысячи пар объявлений в секунду, и нам важно, чтобы построенная скоринговая модель была не только точной, но и достаточно быстрой.

📊 Данные. Мы подготовили обучающую выборку из 1,87 млн пар объявлений. В неё входят ID, заголовки, описания, титульные изображения и дополнительные параметры объектов. В качестве целевой переменной мы использовали фидбек от модераторов.

💡 Небольшая подсказка. Обратите особое внимание на group_id. При некорректном разбиении данных на тренировочную и валидационную части возможна утечка информации между выборками, а это — необъективные метрики. Лучше убедиться, что при разбиении на обучение и валидацию выборки не пересекаются по группам.

Ждём ваших решений и желаем удачи:
К задаче про дубли →

Сколько задач будете решать на Avito ML Cup?
🤝 — обе
👍 — хотя бы одну
🤔 — не планирую участвовать

В нашей DS-команде недавно завелась страничка с мемами.

Не просто ради шутки (хотя и ради неё тоже), а чтобы всем было понятно, почему кто-то на синке говорит «Жаль, конечно, этого добряка…» или почему фраза «Пацан к успеху шёл, но не фортануло» вызывает улыбки.

🎤 Олеся Моисеенко, хранитель странички, комментирует это так:

«Некоторые из нас используют мемы как ёмкий способ передачи эмоций и чувств по поводу ситуации, но не всем понятно в моменте, почему именно эта фраза была сказана.

Поэтому мы решили собрать в Confluence страничку с пояснениями, чтобы можно было в любой момент сделать по ней по ctrl+F и влиться в контекст или освежить свои познания.

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

Уважение к контексту, подробный онбординг и немножко юмора — всё, как мы любим!»

Всем привет! На связи Илья Валяев, DS Team Lead, сегодня хочу рассказать о нашей команде поискового ранжирования.

Наша миссия — вырастить количество сделок через поиск. Каждый день миллионы пользователей ищут товары и услуги на Авито, и мы отвечаем за то, чтобы они не просто находили подходящие объявления, а совершали сделки.

Над чем мы работаем?

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

🔹 Предсказание всех этапов воронки — улучшаем конверсию на каждом шаге: от просмотра до сделки.

🔹 Оценка релевантности — учим модели понимать, насколько объявление соответствует запросу.

🔹 Зоопарк моделей — масштабируем обучение моделей, чтобы внедрять изменения сразу везде.

🔹 Быстрая проверка фичей — запускаем эксперименты сразу на всех моделях, а не по одной.

🔹 Персонализация — учитываем интересы и поведение пользователей, чтобы показывать самые подходящие варианты.

🔹 Полнота поиска — экспериментируем с новыми кандидатогенераторами, чтобы находить больше подходящих объявлений.

Что у нас интересного?

✨ Влияние на продукт — наши модели напрямую влияют на опыт миллионов пользователей.

✨ Свобода в выборе задач и решений — от нас ждут приростов метрик, а идеи мы придумываем и тестируем сами.

✨ Сложные задачи — работаем с большими данными и высоконагруженными системами.

✨ Эксперименты — постоянно тестируем гипотезы и внедряем улучшения.

Хотите более глубокий разбор?

✍️ Посмотрите нашу статью на Хабре: там мы подробно разбираем, как устроено поисковое ранжирование.
Читать статью →

✍️ А если интересно больше узнать про другие команды, ориентируйтесь по нашему путеводителю →

Всем привет! На связи Илья Петряшин, DS-инженер из команды Horizontal ML Technologies. Сегодня расскажу, как мы делаем главную продуктовую метрику Авито.

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

Большинство сделок заключается напрямую — в чате, по телефону или при личной встрече. Это создаёт проблему: нет нативного способа определить наличие сделки.

🧠 Отсюда и формулируется задача: научиться по косвенным признакам в поведении пользователей определять, состоялась ли у них сделка.

❓ Первый вопрос: можно ли вообще таким образом зафиксировать наличие сделки? На практике оказывается, что чаще можно определить не сам её факт, а то, насколько люди близки к ней. Значит, в метрике мы будем считать не сделки, а некоторые целевые действия, которые с ними коррелируют.

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

Чтобы получить такое описание, нужно привлекать всех заинтересованных: бизнес, аналитиков и команду, которая делает метрику.

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

💡 Здесь помогает data-driven подход. Мы не придумываем описание «в вакууме», а калибруем его на реальных данных.

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

✅ В итоге получаем откалиброванное описание целевого действия, которое устраивает всех. А дальше — дело техники: учим ML-модели, которые предсказывают наличие целевого действия в поведении. А уже из этого, с помощью нехитрой аналитики, строим метрику.

Профит! Метрика готова — можно использовать её для А/В-тестов, постановки целей или оценки бизнес-эффектов.