3D DIT Distillation

Данные доступны к скачиванию

Правильная - та, что в score.py. Сейчас исправим в описании. Спасибо за внимательность!

Хорошая попытка )))

Добрый день! В лидерборде иногда появляется два третьих места \ два вторых (по иконкам медалей) - это баг системы? или действительно места будут распределены таким образом, что может быть несколько участников, занявшие например серебро или бронзу?

Добрый день! В лидерборде иногда появляется два третьих места \ два вторых (по иконкам медалей) - это баг системы? или действительно места будут распределены таким образом, что может быть несколько участников, занявшие например серебро или бронзу?

Добрый день. Иконка медали не отображает место в турнирной таблице. Медаль это внутриплатформенное достижение.

Тем временем квантовые сверхразумы из будущего пробили планку в миллион.

Поддерживаю

а разве можно по ходу менять правила?

А нужно ли? Там у чувака 1кк с х0.97

"а разве можно по ходу менять правила?"

Подозреваю, что организаторы могут делать все что хотят (так, во всяком случае, на Kaggle)

Это логичный поинт. Можете прочитать мой новый комментарий в ветке, там затрагивается этот вопрос.

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

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

Мои вышеизложенные предложения на самом деле являются прямым требованием Правил (пункты 1.8 и 3.6).

Добрый день!

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

В participant kit время меряется только внутри generate_impl. Метод

from_pretrained не меряется. Путь к данным приходит аргументом --cache-dir, он

объявлен обязательным, а решение исполняется в том же процессе — значит этот путь виден из sys.argv внутри from_pretrained. Поэтому весь тест можно посчитать в фазе загрузки, а в generate_impl возвращать готовый результат.

Решение при этом не знает данных заранее. Оно читает то, что ему передали. Если финальные итоги будут считаться по закрытой тестовой корзине с другими данными, решение прочитает и её.

Я это проверил. Отправил такое решение и получил:

Time = 1988298.89

Quality = 0.99373

Total = 1973475.65

Это один файл solution.py на 5 КБ, без папки weights. Метод generate не

переопределён, запрещённых путей в архиве нет.

Сабмит шёл 1 час 51 минуту до расчёта метрики. Это примерно столько же, сколько занял бы обычный прогон на 25 шагах. GPU-часы потрачены те же, изменилось только место, где выполняются вычисления.

------------------------

Что можно сделать.

Технически:

- Мерить время всего сабмита целиком, а не сумму вызовов generate_impl. Тогда работу некуда перенести: она остаётся внутри замера, в какой бы фазе ни выполнялась. Это ближе и к формулировке из описания задачи — итоговая скорость инференса пайплайна. Хотя в замер тогда попадают загрузка

весов и декод меша, которые участник не контролирует.

- не делать путь к корзине доступным в момент вызова

from_pretrained. Если каталог передаётся или монтируется только перед циклом

оценки, механизм перестаёт работать, потому что на этапе загрузки читать нечего. Требует правки харнесса, метрика при этом не меняется.

-------------------

И/или организационный вариант:

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

Код соревнования при этом не меняется вообще.

У этого варианта два ограничения.

• Критерий не формализован. Участник не может заранее проверить, проходит его решение или нет. Где именно проходит граница между прогревом ядер и компиляцией в from_pretrained, которые выглядят нормальными, и переносом вычислений — из правил не следует.

• Публичная таблица перестаёт быть справочной. Сейчас по ней видно хотя бы

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

@block7995, ручная проверка решений на использование несоответствующих правилам методов решений(прекеширование результатов, подгрузка каких-то внешних файлов помимо протоколов и другие методы читинга) предполагается. Критерии прописаны в правилах. Если участники начинают использовать методы, которые не генерализируются на других подсетах или не соответветствуют протоколам решений, то скорее что-то в решении не так.

@kemmer7671 согласно этим же правилам и в соответствии пунктам,которые вы указали, в метрике оценки в данной задаче указана метрика 1+log2S

@stroman4487
Да, я понимаю, но, пожалуйста, обновите общедоступный список лидеров и измените данные. В Objaverse сотни тысяч 3D-объектов, зачем делать их общедоступными? В настоящее время общедоступный список лидеров совершенно бесполезен.
Правила, на которые я указал, верны, но они противоречат описанию конкурса, а также расчёту метрик и, по сути, почти всему остальному.

@stroman4487, Спасибо за пояснения! Еще есть вопрос в том как будут трактоваться спорные моменты. Скажем прогрев на синтетических данных в from_pretrained допустим или нет? Прочая предварительная подготовка, к последующему быстрому выполнению генерации допустима?

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

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

@stroman4487, Ещё большая просьба прояснить фразу:

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

Q_min заложен в формулу метрики и прямо определяет цель. Сейчас в score.py семпл с LPIPS выше 0.25 получает качество 0. Если итоговое значение Q_min неизвестно до финала, то неизвестно, к какому качеству стремиться и при каком качестве семпл уже обнуляется. Под логарифмической формулой это особенно важно: дополнительное ускорение даёт немного, и выбор между скоростью и качеством определяется именно порогом.

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

Поэтому большая просьба до завершения соревнования опубликовать версию score.py, по которой будет идти финальный расчёт. Она сразу сняла бы все вопросы: какое значение Q_min, применяется ли коэффициент k, как агрегируется логарифм и с какими параметрами считается качество. Тогда было бы понятно, к какому качеству стремиться и где проходит граница, ниже которой семпл обнуляется.

Или применять этот финальный score.py, к новым сабмитам в паблике, чтобы было видно к чему стремится и где пороги. Потому что иначе цель которую нужно достичь остается довольно неопределенной.

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

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

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

На вебинаре затрагивали эту тему, там можно поподробнее посмотреть.

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

Будет доступно позднее, когда начнется процесс фиксации решений на финальный евал на скрытом подсете.

в разделе Решение задачи, если решение прошло загрузку и показало тотал метрику, то просто наведись на звездочки (их там 2), которые выглядят как этапы загрузки решения. там и будут метрики

Почти неделя прошла, а ответа нет.
До конца соревнования осталось меньше 3-х недель, параметры типа Q_min напрямую влияют на то, какой подход использовать для решения задачи.
Организаторы, напишите, пожалуйста, окончательные значения, которые будут использоваться при расчете метрики.

@stroman4487

@blanda7513

У организаторов есть ответы на заданные вопросы или обратиться за помощью квантовому сверхразуму из будущего? )
Судя по молчанию - несколько сабмитов надо сделать на пару кккк+ очков, для гарантии?

Коэффициент k будет равен 1. Это то, что касается конкретно этой части формулы.

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

По конкретному значению Q-min ровно, как и финальному скрипту подсчета могу сказать, что независимо от них, ваша задача никак не меняется, а именно максимально ускорить пайплайн, не потеряв в качестве мастер-модели, поэтому если у вас например из нескольких вариантов будет ускорение в 4 раза или в 32, но с критической потерей качества, то советую остановиться на первом варианте.

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