Правила участия

Нажимая кнопку «Участвовать» и/или «Отправить решение», вы соглашаетесь с Условиями конкурса Соревнования E-CUP «Ozon Tech»

Постановка задачи

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

В этом соревновании участникам предстоит решить упрощенную постановку задачи матчинга: сами пары кандидатов из Retrieval части задачи уже собраны заранее и подготовлены к тому, чтобы их классифицировали. Однако, не все так просто:

• Данных для подготовки решений предоставляется достаточно много – более 13 миллионов товаров из 20 категорий, и более 11 миллионов размеченных пар;
• Разметка пар происходит из двух источников: более достоверная ручная разметка людьми (365 тысяч пар), а также вероятностная разметка на основе LLM (более 11 миллионов пар);
• Ключевая особенность и ограничение для решений — они должны работать быстро. Лимиты времени достаточно жесткие, поэтому решения должны обязательно в них укладываться;
• Помимо обучения собственной модели матчинга, участники могут самостоятельно осуществить переразметку данных с использованием LLM. Однако для переразметки допускается использовать только модели с открытой лицензией; применение проприетарных больших языковых моделей запрещено. Код для обучения модели и выполнения разметки должен быть воспроизводимым.

Подробнее про данные и их структуру можно узнать на странице “Данные”. 

Формат решений

Это контейнерное соревнование:

1. Обучите модель на предоставленных данных;
2. Подготовьте Docker-контейнер и код с весами ваших обученных моделей;
3. Отправьте решение в виде архива;
4. Ваше решение будет автономно запущено на закрытых тестовых данных.

Входные аргументы решения

Решение получает на вход следующие именованные аргументы:

• --items_path -i путь к файлу с данными о товарах (например, items.parquet); 
• --matches_path -i путь к файлу с подготовленными парами id товаров (например, matches.parquet); 
• --output-path -o имя файла, в который вам нужно сохранить результат (например, submit.csv).

Формат выходного файла

Результатом работы решения должен быть .csv-файл с тремя столбцами: 

• Столбец id1 должен содержать предоставленные идентификаторы первых товаров в паре для сравнения;
• Столбец id2 должен содержать предоставленные идентификаторы вторых товаров в паре для сравнения;
• Столбец predict должен быть вашим результатом классификации (num — разрешены «сырые» результаты предсказаний).

Docker-образ

В архиве с решением должны быть все необходимые для работы модели файлы. 

Главное — в архиве должен быть файл metadata.json с указанием используемого докер-образа (рекомендуем начать с `odsai/ecup26-baseline:1.0`) и строки для запуска вашей модели:

{
   "image": "odsai/ecup26-matching-baseline:1.0",
   "entry_point": "python -u run.py"
}

Участники могут собрать свой собственный Docker-образ:

• Можно использовать стартовый baseline-образ, но при необходимости установки каких-либо дополнительных библиотек, вам нужно будет собрать новый образ под свое решение;
• Чтобы использовать свой образ при проверке решений, вы должны выложить его на dockerhub https://hub.docker.com. Укажите его в metadata.json и тогда проверочная система при запуске скачает архив вашего образа;
• У образов есть ограничение: в заархивированном виде они не должны превышать 15,000 MB;
• Если вы впервые сталкиваетесь с Docker, вам может помочь вебинар о том, как собрать докер. 

Проверка решений

Решения проверяются автоматически, а сама проверка проходит в 3 стадии:

1. Docker: решение должно успешно автономно отработать на закрытых тестовых данных, уложиться по времени и доступным ресурсам, и в результате сохранить .csv файлы с результатами классификации пар;
2. Result: сохраненные результаты классификации пар должны соответствовать заданному формату и быть предоставлены для всех тестовых пар товаров;
3. Подсчет метрики: если решение прошло все проверки и нигде не упало, на результатах классификации считается метрика соревнования.

Docker-стадия

• Запуск решений происходит в изолированной среде без доступа в интернет: 
  • Все библиотеки и их версии должны быть уже загружены в вашем Docker-образе;
  • Запуск происходит на полностью закрытых тестовых данных, которые не доступны и не передаются участникам;
  • Обратите внимание, что в тестовых данных будут другие товары. 
• Решения запускаются последовательно на 3 закрытых наборах тестовых данных:
  1. Check, отладочные 1000 пар товаров, которые не идут в рейтинг;
  2. Public test, для результатов на Public-лидерборде в течение соревнования;
  3. Private test, для итоговых результатов Private-лидерборда.
• Решение считается успешно прошедшим Docker стадию на одном из тестовых наборов данных, если: 
  • Решение успешно сохранило выходной файл с результатами классификации пар;
  • Решение уложилось в ресурсные и временные ограничения;
  • Если решение упало на одном из тестовых наборов данных – оно не оценивается, а процесс проверки завершается.

Result-стадия

• Успешно сохраненные выходные файлы должны соблюдать ряд требований:
  • Файл должен строго соответствовать описанному .csv-формату;
  • Каждой без исключения предоставленной тестовой паре товаров должен соответствовать результат классификации; 
  • Если сохраненный файл не соответствует этим требованиям, решение считается некорректным, а его дальнейшее исполнение завершается с ошибкой.
• Результат работы решения осуществляется путем сопоставления с известными истинными метками тестовых пар товаров:
  • Если решение успешно прошло все проверки на каждом тестовом наборе товаров, для решения считается метрика соревнования;
  • Истинные метки в тестовых данных доступны только организаторам.

Метрика соревнования

Метрика соревнования — Macro Averaged PR-AUC (Area Under Precision-Recall Curve; площадь под кривой «полнота-точность»). 
По каждой из 20 категорий считается PR-AUC, после чего все полученные результаты метрики усредняются. 

Для расчета метрики используется ее sklearn имплементация: 

from sklearn.metrics import average_precision_score

Обратите внимание, что использование функции auc для самой Precision-Recall кривой средствами sklearn приведет к завышению показателей метрики ввиду особенностей процедуры подсчета (интерполяции точек кривой). 

Соотношение public/private в соревновании составляет приблизительно 30/70: 

• ~30%, или в районе 115 тысяч пар товаров используются для результатов на public-лидерборде.  
• ~70%, или в районе 275 тысяч пар товаров используются для результатов на private-лидерборде.

Доступные ресурсы для решений

• 20 ядер CPU
• 200Gb RAM
• Видеокарта NVidia Tesla H100 (80Gb)

Ограничения по времени:

• Check: 1 минута
• Public: 6 минут
• Private: 13 минут

Ограничения для решений

1. Архив с решением: 5GB
2. Docker-образ: 15GB

Ограничения для команд:

• Максимальное число решений в день: 5
• Максимальное число участников в команде: 5
• Число выбранных финальных решений: 2

Определение призеров

В соответствии с правилами, соревнование проходит в несколько этапов:

1. Онлайн-этап соревнования:
   • В рамках онлайн-этапа соревнования участники отправляют свои решения и улучшают свой результат на public-лидерборде. 
   • В конце онлайн формата участники выбирают свои финальные решения, а на их основе формируется итоговый private-лидерборд.
   • Топ-15 команд с private-лидерборда переходят на следующий этап.
2. Этап определения финалистов: 
   • Жюри смотрят и оценивают как сами отправленные финальные решения, так и запрашивают для оценки исходные репозитории этих решений у команд. Также результаты работы команд проверяются на соответствие правилам.
   • Полученные репозитории и решения оцениваются по дополнительным критериям на усмотрение жюри. Оцениваются качество работы с данными и моделями, ресурсоемкость решений, изящность и новизна подходов решений. 
   • Специфичной для задачи матчинга является максимальный приоритет скорости работы решений. Хоть каждое решение и оценивается в совокупности со всеми остальными критериями, скорость работы решений имеет сопоставимо высокий вес с итоговым результатом и местом на private-лидерборде.
   • В результате всех проверок жюри утверждает 5 команд-финалистов.
3. Финальный этап и определение призеров: 
   • Команды-финалисты приглашаются для участия в питч-сессии очно в Москве и онлайн.
   • Команда должна будет презентовать свое решение и ее репозиторий перед жюри.
   • На основе презентаций жюри утверждает 3 команды победителей.
   • Награждение победителей пройдёт на конференции E-CODE.