В последнее время мы много писали о соревнованиях по машинному обучению, в основном рассматривая их с точки зрения участников.
Но правильно организовать и провести конкурс – тоже непростая задача.
Компании учатся на своих ошибках и в следующий раз меняют структуру соревнований.
Например, RecSys Challenge 2017 с учетом опыта предыдущих лет проводился в два последовательных этапа.
Об этих этапах, различных признаках на основе истории поведения пользователей и о том, всегда ли необходимо использовать сложные модели для решения проблемы, рассказывает Андрей Остапец из Авито.
Команда Андрея заняла седьмое место в RecSys Challenge. - Всем привет! Меня зовут Андрей, я работаю на Авито, и сегодня я расскажу об участии нашей команды в конкурсе RecSys Challenge 2017. Сначала расскажу о самом конкурсе и о том, какая задача решалась.
Далее я расскажу о решении нашей команды и, в конце, о результатах.
RecSys Challenge — соревнование, проводимое в рамках конференции RecSys. Это масштабная конференция, в этом году она пройдет в 11-й раз.
На конференции довольно много научных докладов, но с самого начала у организаторов была традиция проводить конкурс по рекомендациям.
Каждый год какая-то компания организует соревнование, в котором участвуют разные команды.
В результате все приходят на мастер-классы и рассказывают о своих решениях.
В этом есть преимущество по сравнению с Kaggle: вы можете рассказать о своем алгоритме, опубликовать статью в отдельном журнале, посвященном семинару конференции, узнать некоторые подробности у организаторов конкурса и посмотреть, какие решения использовали другие участники.
В прошлом году, как и в этом году, конкурс проводила компания XING. Это немецкий аналог LinkedIn, посвященный рекомендациям по работе.
В прошлом году команда Авито также участвовала в RecSys Challenge, мы заняли седьмое место и рассказали об этом на тренировке в ШАД.
Вот ссылка к нашей истории.
В прошлом году нам поставили довольно стандартную задачу.
Были даны данные за год взаимодействия, и задача заключалась в том, чтобы предсказать, на какие сайты вакансий нажмут пользователи.
Мы получили довольно хорошие результаты, использовали факторизационные машины, все было неплохо, но у организаторов возникли некоторые проблемы.
Прежде всего, хорошо работали те алгоритмы, которые отбирали лучшие вакансии среди рекомендованных платформой XING. Общеизвестный факт, что рекомендации влияют на действия пользователя.
Таким образом, алгоритмы работали хорошо, пытаясь предсказать, что покажет платформа, и на основании этого ранжировали вакансии.
С одной стороны, это неплохо, но если вы попытаетесь реализовать такой алгоритм в производстве, то столкнетесь с проблемой, когда алгоритм существенно зависит от другого алгоритма.
Вторая проблема заключалась в том, что пользователи часто совершали повторные клики.
Примерно 30% кликов были повторными.
И это была довольно сильная особенность.
Если пользователь уже нажимал на эту вакансию, порекомендуйте ее еще раз.
Возможно, это не такая уж большая проблема, но вряд ли пользователи захотят видеть в рекомендациях только те пункты, на которые они уже нажимали.
Скорее всего, они хотят увидеть что-то новое.
В 2017 году XING устранила эти проблемы.
Для решения первой задачи организовали двухэтапный конкурс.
Офлайн — все стандартно, вам предоставляется обучающая выборка, тестовая выборка, которая является исторической, нужно отправлять решения и пытаться угадать, как пользователи кликали.
Все это основано на исторических данных.
Вторым этапом был онлайн-этап, когда каждой команде давался отдельный раздел трафика, на котором отображались только рекомендации команды.
Таким образом, весь трафик полностью зависел от команды и все клики зависели от рекомендаций, которые давала команда.
Чтобы решить проблему повторных кликов, организаторы сосредоточились на проблеме холодных запусков в отношении вакансий.
Все опубликованные вакансии были новыми.
На них не было истории кликов; можно было полагаться только на содержание вакансии.
Необходимо было выявить пользователей, которые могли бы быть заинтересованы в получении толчка к онлайн-сцене.
После того как команда отправила решение, пользователи, если у них было установлено приложение, получили push-уведомление.
Они могли нажать на эту вакансию.
Необходимо было выявить тех пользователей, которые подходят кандидатами на указанную вакансию.
Подробнее об этом позже.
На обоих этапах использовались почти одни и те же показатели и наборы данных.
Офлайн-этап служил лишь отбором команд для второго этапа соревнований.
Те команды, которые заняли первые места, прошли во второй этап, и им уже был выделен участок трафика, в котором они могли отправлять рекомендации.
Второй этап длился пять недель.
Рекомендации приходилось отправлять каждый день.
Конечный результат – это сумма за две лучшие недели.
Как использовать рекомендации? С оффлайн этапом все понятно; это исторические данные.
Вы отправляете файл с решением и сразу получаете результат. Единственное ограничение: на вакансии можно было рекомендовать не более ста пользователей.
На онлайн-сцене все интереснее.
Организаторы разместили целевые вакансии среди целевых пользователей, и им было дано 24 часа на подготовку файла подачи, включающего этих пользователей и эти вакансии.
По каждой вакансии может быть предоставлен список не более 255 пользователей.
Это сделано для того, чтобы какая-то вакансия не получила смещения, когда все рекомендации пойдут на эту вакансию.
Пользователь мог получать не более одного пуша в день, чтобы не нагружать пользователей и чтобы они не уставали от рекомендаций.
Существовало четыре различных метода предоставления рекомендаций.
Во-первых, это список рекомендаций.
Это настольная версия.
Если у пользователя была установлена мобильная версия, то он получал пуш, переходил по ссылке и сразу видел рекомендованные ему вакансии.
Если была настольная версия, там была ссылка «Вакансии».
Когда поступала новая рекомендация, все это обновлялось на сайте, и пользователь мог видеть новую вакансию.
Затем рекомендации были показаны на главной странице.
Когда пользователь заходит на сайт, ему показываются новости, среди которых может быть показана рекомендация.
Третий вариант — электронная почта.
Если организаторы видели, что пользователь не зашел на сайт, они отправляли ему письмо о том, что вам рекомендована новая вакансия.
Если вам интересно, перейдите по ссылке.
Четвертая часть довольно интересна.
Это рекомендательный лист для рекрутера.
XING ориентирован не только на пользователей, но и на рекрутеров, поэтому для каждой вакансии есть отдельная страница, где рекрутер может увидеть рекомендации, которые ему дает XING. В них содержатся те пользователи, которые, по мнению XING, подходят на данную вакансию.
Здесь для каждого человека указано его нынешнее место работы, предыдущее место работы и возможность связаться с человеком, если рекрутер считает, что он подходит на данную вакансию.
На слайде показаны данные, которые были предоставлены участникам.
Для пользователей данные в основном брались из анкеты.
Что интересно, хосты предоставили ключевые слова из текущей или, возможно, предыдущей работы пользователя, но они сами выполнили текстовую обработку, а данные были предоставлены в виде списка натуральных чисел.
Это сократило спектр работы с текстами.
Много чего можно было применить, но здесь мы не знали исходных слов и не знали, были ли эти числа исходными словами или биграммами, триграммами и т. д. Также был указан текущий уровень карьеры – натуральное число от 1 до 6. Чем выше, тем выше уровень карьеры.
Дисциплина, промышленность, география и т. д. Для офлайн-этапа предусмотрена интересная особенность - заинтересованность в смене места работы.
Но на втором этапе ее уже не было.
Пользователь мог быть премиум-классом, он мог платить XING деньги.
Это повлияет на функциональность и качество.
Аналогичные характеристики были предусмотрены для вакансий.
Разница в том, что ключевые слова были взяты из названия должности и описания компании.
Все остальные признаки аналогичны.
Также вакансия может быть платной или неоплачиваемой.
В файле взаимодействия было всего четыре поля: какой пользователь на какую вакансию в какой момент нажимал и каков был тип взаимодействия.
Всего было шесть типов.
Первый — показ: пользователю показали эту вакансию.
Второй — вариант закладки: пользователь добавил вакансию в закладки, чтобы вернуться позже.
В-третьих, он нажал кнопку «Связаться с рекрутером».
Четвертое - он удалил вакансию, сказал, что она мне больше не интересна, я больше не хочу ее видеть.
Последнее — интерес рекрутера: рекрутер перешел со своей страницы на профиль этого пользователя.
Для некоторой статистики показано распределение обучающего набора на онлайн-этапе.
У тренинга было миллион пользователей, 750 тысяч вакансий, около 90 миллионов показов, около 4 миллионов взаимодействий.
То есть пользователи не так часто кликают, при этом большинство взаимодействий являются кликами.
На втором месте — удаление рекомендации.
Пользователи довольно часто удаляют рекомендации и говорят, что больше не хотят их видеть.
Других типов было меньше.
Какой качественный функционал использовался? Он был весьма необычным.
Участники должны были предоставить список рекомендаций по каждой вакансии.
Общая сумма, которую получило решение, была рассчитана для всех вакансий.
Причем оценка по каждой вакансии делилась на две части: успех пользователя, определявший, насколько он был успешен у пользователей, и успех предмета — был ли этот список рекомендаций успешным для данной вакансии.
Успех пользователя считался простым.
Если пользователь кликнул на вакансию, он получил 1 балл.
Если он нажал кнопку «Добавить в закладки» или «Ответить» — 5 баллов, а если выполнил оба действия, то все равно добавлялось только 5 баллов.
Если рекрутер проявлял к нему интерес, к его счету добавлялось 20 баллов.
Если пользователь удаляет вакансию, минус 10 баллов.
Причем вся эта сумма умножалась на два, если пользователь был премиум-классом и платил деньги XING. С успехом предмета дела обстоят немного интереснее.
По каждой вакансии был предоставлен список пользователей, и если рекомендация была успешной хотя бы для одного пользователя, то если товар был платным, то получалось 50 баллов, а если он был бесплатным, то 25. Ну а если не было ни одного успешного кандидата на вакансию, ни один человек не кликнул и не получил сумму больше нуля, потом к баллу прибавилось 0, мы ничего не получили.
Сразу может возникнуть вопрос: какой максимальный балл можно получить за одну пару пользователь-вакансия на основе этого функционала? 102. Нажал на вакансию - плюс 1, добавил в закладки - плюс 5, рекрутер проявил интерес - плюс 20, премиум пользователь - умножить на два.
Получаем 52, и этот пользователь является успешной рекомендацией на данную вакансию.
Если товар оплачен, мы получаем еще 50 баллов, итого 102. Очевидно, что минимум для рекомендации составляет всего 1 балл.
Это если пользователь просто кликнул на вакансию и есть уже успешный по этой вакансии товар.
Какие задачи стоят перед организаторами? Баланс между интересами пользователей и рекрутеров основан на качественном функционале.
Щелчок пользователя ничего не значит; гораздо выгоднее, если к этому проявит интерес рекрутер.
Вторая проблема — это баланс между актуальностью и доходом.
Как показано, оценка сильно зависела от того, были ли пользователь и товар премиум-классом и получала ли платформа XING от них деньги.
В-третьих, проблема «холодного старта».
У всех вакансий не было истории, что является более сложной задачей, поскольку мы могли использовать только рекламный контент. В-четвертых, умные push-уведомления.
Необходимо определить, какому пользователю отправлять пуш, а кому нет и в какое время.
Подробнее об этом позже.
Во-первых, организаторы, как и во многих соревнованиях, предоставили базовый уровень.
Оно было предельно простым, но показало хорошие результаты.
У него было всего шесть атрибутов, и пять из них были двоичными: количество совпадений между должностями пользователя и вакансией, натуральное число, а затем простое сопоставление дисциплины, уровня карьеры, отрасли, страны и региона.
Для обучения использовалось только взаимодействие.
Если пользователь удалил вакансию, целевая переменная была равна нулю, а если пользователь совершил положительное действие, целевая переменная была равна единице.
Он был обучен на XGBoost и набрал 10 000 очков в таблице лидеров.
Довольно хорошо.
Если просто порекомендовать топ-100 самых активных пользователей на все вакансии на оффлайн этапе, то получим результат 519. XGBoost дает гораздо больше.
Каков был размер выборки? Всего 300 миллионов взаимодействий, 75 миллионов целевых пользователей, для которых нужно было построить рекомендации, и примерно 50 тысяч целевых вакансий.
Одна из особенностей датасета, которую можно было заметить сразу: взаимодействие содержит огромное количество полных дубликатов.
Если их почистить, то уже получим 220 миллионов взаимодействий, что позволило ускорить работу алгоритма.
Мы учимся только через взаимодействие.
Взаимодействий меньше — всего 6 миллионов.
Получаем обучающую выборку в 6 миллионов.
Чтобы ускорить процесс, прогноз по паре делался только в том случае, если имелось перекрытие заголовков.
В результате выборка, для которой XGBoost должен построить прогноз, составляет примерно 50 миллионов.
Когда я попытался воспроизвести эту базовую версию, я столкнулся с проблемой, что на сервере не работал XGBoost, и я просто переписал ее на H2O, но существенного влияния на решение это не оказало.
Казалось бы, логично просто добавить новые возможности в эту базовую версию.
Пять бинарных функций дают хороший результат, поэтому давайте просто добавим функции и получим лучший результат. После того, как я добавил еще 19 и получил 25, мне действительно удалось немного улучшить результат. Стало примерно 11 тысяч, но дальнейшего улучшения добиться не удалось.
Более того, в итоге были разные эксперименты: по-другому составить обучающую выборку, присвоить разным событиям разные веса, просто добавить к ним просмотры с небольшим весом, который больше веса удаления, но меньше веса положительного действия.
Но все это привело к тому, что оценка упала, пока, наконец, результат не стал минус 5000. Плохо, мы в основном рекомендуем то, что пользователи удаляют. 
Почему это случилось? Скорее всего есть две проблемы.
Во-первых, я не мог настроить отрицательную выборку.
Когда я просто добавил представления, алгоритм начал делать много прогнозов относительно простых представлений.
Вторая проблема в том, что я оптимизировал стандартное отклонение в XGBoost, и это, наверное, плохо.
Функционал ориентирован на деньги, и мы оптимизируем RMSE. Но с этим нужно было что-то делать.
Очевидно, что добавленные функции логичны и должны улучшить оценку.
Поэтому я решил использовать простой алгоритм для проверки качества функций.
Для расчета оценки пары пользователь-вакансия я просто использовал суммы трех типов, что тоже разумно.
Близость профиля пользователя к профилю вакансии — мы смотрим только на соответствие контента между ними.
Далее строим различные интересы по параметрам на основе истории пользователя.
Мы никак не используем профиль пользователя, мы только смотрим, что он нажал и что удалил.
Третья часть, актуальная для офлайн-этапа: для некоторых предметов и пользователей были указаны предыдущие взаимодействия.
Их было немного, но они все же позволили нам немного поднять счет. Логично, что если 50 тысяч пользователей и 50 тысяч вакансий, то ускорить их всех невозможно.
Необходимо подобрать какой-то набор подходящих.
Для уменьшения объема прогнозов использовалась следующая эвристика: для пары мы рассчитываем балл только в том случае, если есть какое-то пересечение названий вакансии и профиля пользователя, или если пользователь просмотрел объявление, перекрывающееся с вакансией.
.
Например, пользователь указывает, что он аналитик, а однажды он сделал всего один клик по Data Scientist. Потенциальные рекомендации — это вакансии, которые содержат слова «аналитик», «специалист по данным» и все.
Очевидно, что это не лучшая эвристика, но она позволяет существенно уменьшить размер выборки, для которой нужно делать прогнозы.
Как рассчитывались различные расстояния? В качестве примера рассмотрим близость ключевых слов к названию должности.
Основная идея в том, что мы можем использовать некий аналог IDF для трех словарей, то есть у нас есть слова из профиля пользователя и из названия элемента, а также теги элемента.
Для них был рассчитан аналог ЦАХАЛа.
Мы просто берем логарифм количества уникальных токенов по встречаемости токенов, и чем реже встречается токен, тем больший вес он получает. Когда мы рассчитываем близость по профилю, мы просто нормализуем ее по количеству уникальных ключевых слов, которые имеет пользователь.
Чем меньше ключевых слов, тем больший вес получит эта сумма.
Для каждого типа близости выбираем свой вес W. В результате итоговый балл для пары пользователь-вакансия рассчитывается как сумма всех листингов ключевых слов пользователя из заголовка вакансии с этими весами.
Такие суммы были рассчитаны для всех возможных вариантов, указанных в профиле пользователя и в вакансии.
Мы уже получаем много знаков.
Еще один вариант подсчета текста — полное встраивание ключевых слов, ключевых слов из названия вакансии.
Это также выглядит логично, если пользователь, например, указывает «аналитик», а вакансия — «аналитик банка».
Вероятно, это тоже сигнал.
Но особенность здесь в том, что неизвестно, как организаторы получили эти ключевые слова, удалили они стоп-слова или нет. Итак, был использован довольно стандартный подход, и он сработал вполне хорошо.
Как рассматривалась близость на основании других критериев? По уровню карьеры все было довольно просто: от 1 до 6, так что по профилю можно просто посмотреть разницу.
Если разница небольшая, увеличиваем вес; если оно велико, уменьшаем его.
Забавно, что пользователи, указавшие, что они студенты, тоже иногда просматривали вакансии, требующие директоров компаний.
Очевидно, они не подходят на эти вакансии, но определенный интерес был.
Необъяснимо.
Как следствие, в этом случае вы не можете установить нулевой вес.
Мы просто использовали похудение.
Трудолюбие и дисциплина служили категориальными характеристиками, которые были анонимизированы.
Здесь нечего особенного сказать.
Использовалась довольно простая эвристика: при точном совпадении оценка умножалась на вес, который был больше 1, а в противном случае немного уменьшался.
По взаимодействиям мы можем посмотреть не профиль пользователя, а вакансии, на которые он кликал.
Тогда мы получим не одно число, соответствующее пользователю, а целую раздачу.
Нам необходимо измерить близость к единственному номеру, указанному в вакансии.
Здесь просто рассматривалась разная близость, и были найдены такие ключевые правила.
Например, если пользователь имеет богатую историю, кликает много, но кликает очень редко на данном карьерном уровне, то оценка снижается.
Если она кликает часто, 95% приходится на данный карьерный уровень, значит, она повысилась.
В данном случае все нормируется на общее количество кликов пользователя.
Также использовались несколько других ранкеров.
Первый основывался на предыдущих кликах пользователя.
Хорошим знаком, который мог серьезно улучшить оценку, было то, что пользователь нажимал на вакансии с одинаковым названием: уровень карьеры, отрасль, дисциплина.
Пользователя интересует вакансия с таким же названием и другими параметрами.
Он кликнул не на эту вакансию, а, когда-то в прошлом, на похожую.
Также было рассчитано соотношение негативных и позитивных действий для пользователя, что тоже логично: если пользователь часто удаляет вакансии, то не нужно ему ничего рекомендовать.
Лучше рекомендовать тем, кто кликает чаще.
Для офлайн-этапа использовалась последняя активность пользователя, а также были попытки оптимизировать сам функционал задачи, поскольку он выглядел необычно.
Был ли пользователь премиум-пользователем и является ли задание VIP-статусом.
В таких случаях общий балл увеличивался.
Как проводилась локальная проверка? Все с ней было довольно интересно.
Во-первых, все времена, указанные в событии, были анонимизированы, то есть точное значение использовать было невозможно.
Но организаторы гарантировали, что порядок мероприятий будет соблюден.
Если в данных одна вакансия располагалась позже другой, то фактически они были размещены на сайте одна позже другой.
Чтобы сделать валидацию быстро, просто выбиралось P последних дней, чтобы примерное количество пользователей в вакансии и валидации совпадало с тестом.
А все целевые пользователи вакансии — это те, кто получил или совершил хотя бы одно действие.
Недостатки валидации.
За последние дни не было ни одного события типа «заинтересованность рекрутера»; неясно, как проверить это событие.
Но на деле получилось интересно: на самом деле это мероприятие проходило не в онлайн-сцене.
Либо организаторы ошиблись в каких-то данных, либо их статистика неверна.
Самое дорогое действие, принесшее наибольшее количество баллов за успех пользователя, в какой-то момент перестало появляться на сайте.
Либо статистика упала, либо пользователи не привлекли рекрутеров.
И такая валидация совпадала с публичной таблицей лидеров примерно в 70% случаев.
Таким образом, проверка была основана на улучшениях локальной проверки с использованием ссылки на общедоступную таблицу лидеров.
Если оба были одинаковыми, то алгоритм был обновлен.
Если нет, то искали что-то новое.
На онлайн-этапе, где каждый день производились новые данные и сначала выдавался обучающий набор, просто происходила валидация всех событий, произошедших с момента начала этапа.
Проверка увеличивалась с каждым днем.
Полученные улучшения.
Использование такого алгоритма позволило увеличить скорость примерно до 20 тысяч, а позже удалось достичь и 32 тысяч.
Более того, оценка не всегда улучшалась, поскольку локальная проверка не всегда отражала реальный порядок и улучшения.
Краткий обзор основных шагов.
Простая сработавшая модель дала результат 19 тысяч за 30 минут, а после отправки файла с решением наша команда оказалась на четвёртом месте.
Другими ключевыми моментами, которые помогли, были просто добавление титула, полное совпадение титула, уровня карьеры, отрасли и дисциплины, а также повторный выбор шкал.
Это позволило нам существенно улучшить результат. Еще одним довольно важным улучшением, которое было сделано в конце, было добавление IDF. После этого наша команда оказалась на шестом месте, причем такого результата удалось добиться через две недели после начала соревнований.
Потом мои идеи исчезли, решения мы больше не присылали, и конкурс продлился еще месяц.
Во второй этап прошли 20 лучших команд. Наша команда ничего не отправляла, она потихоньку падала, но в итоге мы оказались на 18 месте и вышли в онлайн-этап.
На онлайн-этапе общее решение было следующей схемы: за несколько дней до начала соревнований XING выдавала тренировочный набор, а после начала соревнований каждый день происходила следующая процедура.
XING автоматически опубликовал таргет пользователей и вакансии, для которых необходимо построить рекомендации, а также предыдущие взаимодействия за последние 24 часа.
После этого им дали 24 часа на то, чтобы дать рекомендации.
Если команда отправляет результат, то рекомендации сразу показываются пользователям.
Если оно не успеет завершиться в течение 24 часов, то пользователям ничего не будет показано.
После этого отзывы пользователей измеряются в течение семи дней.
Если пользователь нажмет на эту вакансию в течение 7 дней, то команда получает результат, какие-то баллы, а если он нажмет на вакансию через 8 дней, команда не получит ничего.
Так продолжается до конца соревнований.
Наш алгоритм немного изменился для конкурентов, но не слишком сильно.
По итогам первой недели мы заняли 11 место.
Это было связано с тем, что первые два дня пришлись на майские праздники и мы ничего не отправляли, а потом, несмотря на то, что форматы данных должны были быть одинаковыми, они немного отличались.
В первые три дня после отправки мы получали неверные рекомендации, их присылали на сайт в небольшом количестве, а оценка была крайне низкой.
В последние два дня это было исправлено, и счет пошел вверх.
На второй неделе появился некоторый оптимизм.
На второй неделе ситуация улучшилась.
Мой алгоритм занял четвертое место, и до последних дней шла борьба: наша команда оказывалась то на втором, то на третьем месте, а отставание от 10-го места было достаточно серьезным, что позволяло нам с энтузиазмом смотреть в будущее.
На третьей неделе, несмотря на то, что изменений не было, балл упал.
На втором было 4800, на третьем 3800, причем алгоритм вообще не менялся.
Это может быть связано с тем, что в кусок трафика, который отдавался каждой команде, входило примерно 50 тысяч пользователей, и каждый день нужно было строить рекомендации примерно по 10 тысячам вакансий.
Кажется, 50 тысяч пользователей — это очень много.
Все равно их поведение случайно, и в один день можно получить больше, а в следующий – меньше.
Мы решили это с командой Авито, но договорились пойти параллельными путями: каждый принял свое решение.
Мое решение с самого начала было лучше, но за две недели мне удалось создать линейную комбинацию решений.
Василий Лексин построил решение на базе LCE, он рассказывал о нем неделю назад на митапе Avito Data Science по рекомендациям — можно идти связь и слушай.
Мы посмотрели локальную проверку и получили улучшение на 8 %, и это хорошо.
Сам алгоритм Василия показал результаты примерно на треть хуже, но в линейной комбинации мы получили улучшение.
Мы попробовали отправить алгоритм на основе линейной комбинации, но балл не увеличился.
При этом забавная вещь: начиная с четвёртой недели счёт всех команд упал в несколько раз.
Если раньше победители набирали около 5 тысяч в неделю, то начиная с четвертой недели они набирали максимум 2 тысячи.
На форуме организаторов спросили, почему это произошло, и они ответили, что, скорее всего, это естественный процесс.
Пользователям надоедают рекомендации.
Ответ, может быть, и логичен, но как-то странно, что три недели все было хорошо, а на четвертой неделе балл упал.
Возможно, если пользователи будут получать push-уведомления каждый день на свой телефон в течение 21 дня, им действительно станет скучно, и они отключат push-уведомления.
Но то, что есть такая точка, развилка, когда счет у всех упал, кажется не очень логичным.
В результате, несмотря на то, что мы получили улучшение локальной валидации, по рейтингам мы остались примерно на том же уровне и даже немного упали.
Неясно, связано ли это с тем, что другие команды улучшили свои результаты, или с тем, что общий балл у всех упал.
Адекватны ли эти оценки – вопрос.
На пятой неделе результат упал еще больше, до 300 баллов.
Как я уже говорил, итоговые результаты были подсчитаны по итогам двух лучших недель, поэтому вот статистика всех команд. Теги: #Машинное обучение #Алгоритмы #вакансии #спортивное программирование #Аномальное программирование #xgboost #рекомендации #рекомендующие системы #история просмотра #h2o
-
Система Отзывов В Windows Phone Marketplace
19 Oct, 24 -
Мобильный Firefox 4 Бета 5
19 Oct, 24 -
Робот-Бегун
19 Oct, 24
