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

Одно из самых заметных проявлений искажения заключается в следующем: как правило, исследователи тратят несравнимо больше времени и усилий на то, чтобы выдавить мельчайшие капельки целевой метрики из своего метода, чем на то, чтобы корректно выбрать и хорошо настроить бейзлайн. И немудрено: ведь то, пройдет ли статья ревью или нет, зависит от того, насколько хороший результат покажет новый метод, а не старый. При использовании новых датасетов, бейзлайны на которых еще неизвестны, особенно легко сделать бейзлайн плохим таким образом, чтобы ревьюеры этого не заметили. При чем иногда это происходит не совсем сознательно, просто от того, что человек не уделяет времени тому, чтобы подобрать своему бейзлайну подходящие гиперпараметры и сделать сравнение честным по всем аспектам.
Из-за мыслей об этом, в последние месяцы я довольно сильно озаботилась бейзлайнами и стала уделять больше времени их продумыванию, настройке и пиханию везде, где мне хватает на это времени и возможности. Это заметно, например, по статье Topological Data Analysis for Speech Processing (см. также пост https://news.1rj.ru/str/tech_priestess/755 ), и по еще одной про NLP домен, которую мы пока что не опубликовали из-за периода анонимности.
В первой статье я предложила добавить такой бейзлайн, в котором информация собиралась бы со всех слоев модели HuBERT не в виде топологических фичей (которые были нашим основным методом), а в виде какой-нибудь более простой аггрегации эмбеддингов с каждого слоя (коллеги в итоге взяли эмбеддинг первого токена и пулинг по эмбеддингам в качестве таких аггрегаций). Целью этого было проверить, действительно ли важную информацию несут именно топологические фичи, или же для хорошего результата достаточно просто пропустить информацию с промежуточных представлений модели. Ответ оказался неоднозначным, потому что для одних датасетов хорошо работало одно, а для других - другое (см. таблицу 1). 🥴 Кроме того, я просила коллегу попробовать потюнить HuBERT по-другому (полностью, а не только последний слой), но это, как ни странно, оказалось хуже других методов и потому не вошло в финальную таблицу.
Ну а во второй, анонимной, из-за того, что я главный автор, я уж совсем развязала себе руки и наплодила целую россыпь бейзлайнов, один из которых натюнила так, что мы его потом сами же и не смогли побить во многих подзадачах (думаю, вероятность того, что статью отвергнут, процентов 90 🥴).

А еще я против того, чтобы сравнивать слишком много (порядка нескольких десятков или, тем более, сотен) вариаций своего метода или фичей на out of domain множествах и потом использовать в статье именно те фичи или тот метод, который хорошо выступил на этом OOD. Я думаю, что если так делать, то OOD множество как бы превращается в множество валидации (так как если ты выбираешь из большого множества методов один, то это тоже получется как будто ты затюнил на этом множестве гиперпараметр). Несколько вариаций своего метода я по такому принципу сравнить ещё могу, но несколько десятков уже считаю подгонкой.

Иногда мне, однако, кажется, что я задалбываю окружающих своими заебомбами по этим поводам.
Сколько времени на самом деле разумно тратить на настройку бейзлайна? 🤷‍♂️ Сколько раз можно проверять точность методов на test или OOD множествах, прежде чем эти множества превратятся в valid и прекратят реально отображать обобщаемость наших решений? 🤷‍♂️
В общем, где грань разумного, за которой кончается реальная забота об объективности и начинается паранойя? 🥴

#рассуждения

🏆 Telegram ML Competition

Prize fund: $40,000 – from which the 1st place winner will receive $15,000 if any submissions qualify for 1st place.
Deadline: 23:59 on October 15th (Dubai time)
Who can participate: Everyone
Results: October 29th, 2023

Telegram is hosting a competition for ML engineers to identify programming and markup languages in code snippets.

The Task: implement a library that detects the programming and markup language of code snippets from message text. You can use any publicly available data to train your solution.

Details: https://contest.com/docs/ML-Competition-2023.

@ContestBot will begin accepting submissions at a later date. We will further clarify the submission instructions closer to the deadline.