Привет-привет!

Меня зовут Илья Иваницкий, и я отвечаю за DS-составляющую в двух крупных направлениях: Trust&Safety и Модерация.

Сегодня расскажу про направление Модерации. На Авито ежедневно размещают миллионы объявлений — это огромный поток контента, причём не только текстов, но ещё картинок и видео.

→ Статья «Как мы запустили автомодерацию видео в объявлениях»

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

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

В работе используем такие технологии:
👉 BERT-подобные модели с адаптерами, которые используются для быстрого запуска новых проверок, когда у нас есть буквально несколько примеров с нарушениями,
👉 CLIP для классификации нарушений на картинках,
👉 И целое море разноцветных градиентных бустингов, линейных моделей и регулярных выражений разной степени сложности (а как же в модерации и без регулярных выражений!), а ещё движки для векторного поиска по эмбеддингам картинок и текстов (faiss, sphinx).

Постепенно всё глубже заходим в удаление и изменение нарушений самостоятельно. То есть боремся с ними не только через блокировки и отклонение контента. Например, уже запустили inpainting для контактной информации на картинках в объявлениях и различных способов привлечь излишнее внимание.

Привет! На связи снова Илья Иваницкий — сегодня продолжаю знакомить вас с DS-командами, в этот раз поговорим про направление Trust&Safety. В нём можно выделить две большие группы задач.

Задачи классического антифрода. Например:
👉 Ищем автоматические регистрации через ботов и предотвращаем взломы аккаунтов
👉 Находим случаи, когда человек имеет сразу несколько учётных записей и каким-либо образом нарушает наши правила
👉 Строим модели с анализом поведения пользователей на разных этапах CJM
👉 Ищем недобросовестных пользователей, которые просят предоплату, а потом исчезают не отправив товар
👉 Не даём скликивать рекламные бюджеты конкурентов

Конечно, этим всё не кончается: поток задач как от бизнеса, так и изнутри приходит постоянно.

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

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

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

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

И команда автомодерации, и команда антифрода с репутационной системой отвечают за сервисы, которые работают под высокой нагрузкой, часто тысячи запросов в секунду.

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

Всем привет!

Меня зовут Егор Самосват, я руковожу юнитом эффективности монетизации.

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

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

Здесь возникает много вызовов, например:

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

Чтобы учесть долгосрочные эффекты, мы создаём специальные подходы в A/B-тестах и учимся предсказывать поведение пользователей.

→ Доклад «Split-тесты или как мы упростили тестирование новых механизмов Монетизации»

👉 Особенности в поиске и рекомендациях. В ранжировании мы учитываем подключённое продвижение через ожидаемую выручку с объявлений. Из-за этого при обучении моделей важно следить за их вероятностным смыслом 🎲 и скалиброванностью.

→ Доклад «Ранжирование или калибровка? Как измерять качество рекламных CTR-моделей»

👉 Это наукоёмкое направление. Ключевые слова: алгоритмический дизайн механизмов, теория аукционов, auto-bidding, динамическое ценообразование. Мы читаем много статей и думаем над оптимальным дизайном системы.

→ Дискуссия: VCG или First Price

Чтобы поддерживать дух инноваций и не отставать от достижений науки, мы выделили отдельную исследовательскую команду 🔎, которая уже этой весной в Сиднее 🦘 представит наш полигон для сравнения подходов к автоматическому выставлению ставок на Web Conf 2025.

→ Репозиторий BAT: Benchmark for Auto-bidding Task

Таким образом, мы не только непосредственно влияем на финансовые результаты компании 📈, но и стараемся развивать технологии и быть на острие прогресса 🚀.

Путеводитель по DS-командам Авито

Всем привет! На прошедших выходных мы провели Weekend offer: соискатели и нанимающие менеджеры благополучно нашли друг друга.

Мы представили в канале несколько команд DS-инженеров Авито, и теперь решили собрать эти рассказы в один общий пост, чтобы в следующий раз вам было проще выбрать себе дрим тим ↓

👉 Рекомендации

👉 Модерация

👉 Trust&Safety

👉 Монетизация

👉 LLM

👉 DSSWAT

👉 Вертикальные команды: Товары, Авто и Работа

В декабре прошлого года у нас прошёл хакатон Avito ML Cup 2024. На соревновании нужно было решить задачу ранжирования рекламных баннеров с профилями продавцов.

Володя Давидько, DS тимлид из монетизации, организовывал соревнование и рассказал про свой опыт:

Предсказание CTR для продвижения профиля — одна из задач, которой занимается наша команда.

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

Главный компонент соревнования — данные. Мы тщательно подготовили наш датасет:
👉 Убрали холодных пользователей, чтобы упростить задачу.
👉 Текстовую информацию почистили специальным сервисом, который удаляет чувствительные данные.
👉 Заменили id-шники и ценовые фичи.
👉 Чтобы соревнование можно было решать на ноутбуке, но при этом данных было как можно больше, мы тщательно их подрезали.

Решили много организационных вопросов: от согласования с юристами до раскачки контеста в соцсетях. Нам не повезло, потому что ML Cup Авито совпал с соревнованием VK по рекомендациям, где призовой фонд был выше. Но в итоге это не сказалось на интересе, и у нас было примерно столько же участников.

Я опасался, что будет много хейта и токсичных участников, но оказалось совсем не так. Хейта было мало, а среди участников образовалась активная группа, которая хорошо разобралась в данных и помогала другим, — эти люди в конечном счёте попали в победители.

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

Могу привести интересный бенчмарк, сколько дают «каглерские» приёмы по сравнению с обычным хорошо обученным бустингом. Наш обычный бустинг дает ROC-AUC в районе 0.6, а решение победителей дало скор 0.618.

Следите за новостями, новые соревнования уже совсем скоро! 😉

Почему мы не используем ассессоров для выкатки моделей в поиске

Осенью я участвовал в конференции IML в качестве эксперта. Моя роль была в том, чтобы после доклада Коли Смирнова про поиск «Лавки» поучаствовать с ним в дискуссии. И мы как раз затронули эту тему: ребята используют ассессоров, а я объяснял, почему у нас это не работает.

Идея ассессоров следующая:

👉 Допустим, вы переобучили поисковой ранкер и получили хорошие ML-метрики, условный NDCG.

👉 Затем вы посылаете на ассессоров заранее подготовленный пул запросов, отранжированных новой и старой моделью, и получаете оценку качества от людей.

Проблемы начинаются тогда, когда вы ранжируете не по релевантности. Мы учитываем сразу много факторов в выдаче: релевантность, кликабельность объявления, монетизацию, репутационные скоры. А ещё нужно не забыть, что частные продавцы на Авито должны получать свой трафик, чтобы их не выдавили профессионалы.

Поэтому никакой ассессор не сможет оценить, насколько хорошо мы собрали выдачу.

Мы используем специальную оффлайн-приёмку, где считаем метрики по заранее сформированным пулам запросов, но по скорам моделей и количеству объявлений разных типов. Например, если сильно просадили частников — плохо.

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

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

…или юхуууу, нас здесь становится всё больше!

Конечно, сейчас кто-то подумает: «ого, уже %n_subscribers», а кто-то: «всего-то %n_subscribers».

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

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

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

Разработчики живут в счастливом мире систем контроля версий. Мы в 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?
🤝 — обе
👍 — хотя бы одну
🤔 — не планирую участвовать