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

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

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

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

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

Участникам предлагается попробовать свои силы в новых возможностях LLM и VLM на реальных данных онлайн маркетплейса:

• Данные предоставлены в двух очень разных по своим распределениям категориям: «БАД-ы» и «Легковоспламеняющиеся» товары; 
• Для каждого товара вам предстоит работать и с текстовыми данными, и с изображениями (от 1 до 5 штук);
• В качестве ответов ваши решения должны выдавать и результат классификации, и генерировать объяснения к полученному результату. 

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

VLM-модели

Помочь справиться с задачей могут малые VLM-модели и мультимодальные эмбеддинги: 

• Список моделей, с которыми предстоит работать, заранее известен и ограничен; 
• Разрешено использовать малые (до 4B) модели с открытой лицензией, которые будут доступны вашим решениям в процессе их запуска;
• Модель может быть включена в сам архив с решением при условии, что размер архива с решением будет в пределах допустимого (до 5ГБ), а модель будет иметь открытую лицензию и легальный статус (qwythos-like модели запрещены);
• Допустимым и ожидаемым является обучение участниками своих LoRA-адаптеров под задачу. При этом весь pipeline обучения, включая подготовку обучаемых объяснений, должен также соответствовать правилам (особенно в части открытости и легальности; обучение на объяснениях закрытой проприетарной модели запрещены правилами).

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

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

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

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

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

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

• --test_data_path -i путь к файлу с тестовыми товарами (например, test.csv); путь к папке с изображениями товаров получается напрямую на основе этого пути, см. пример baseline решения;
• --output-path -o имя файла, в который вам нужно сохранить результат (например, submit.csv).

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

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

• Столбец id должен содержать предоставленные идентификаторы товаров.
• Столбец result должен быть сгенерированным ответом в строго заданной форме:
  • <комментарий>...<вердикт>, без закрывающих тегов;
  • вердикт должен быть строго бинарным: либо бан, либо не бан;
  • комментарий должен быть строго от 50 до 300 символов.

Docker-образ

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

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

{
   "image": "odsai/ecup26-quality-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, отладочные 10 примеров, которые не идут в рейтинг;
  2. Public test, для результатов на Public-лидерборде в течение соревнования;
  3. Private test, для итоговых результатов Private-лидерборда.
• Решение считается успешно прошедшим Docker-стадию на одном из тестовых наборов данных, если: 
  • Решение успешно сгенерировало выходной файл;
  • Решение уложилось в ресурсные и временные ограничения;
  • Если решение упало на одном из тестовых наборов данных – оно не оценивается, а процесс проверки завершается.

Result-стадия

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

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

Метрика соревнования — Macro Averaged F1 score. 
По обеим категориям считается F1 мера, после чего оба результата метрики усредняются. 

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

from sklearn.metrics import f1_score

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

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

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

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

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

• Check: 3 минуты
• Public: 20 минут
• Private: 40 минут

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

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

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

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

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

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

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