1-2: квалификации проходили с 11 по 17 июня. Мы обновляли комплекты задач каждые несколько дней :) Так что каждый сам мог решить, когда именно начинать соревнование. Сравнительно большое количество участников в первой квалификации поэтому объясняется только тем, что для многих первые дни соревнования были более удобными.
3. Это не единственная задача такого рода. В первой квалификации, как видите, тоже была такая необходимость (задача про Decision Stump). Не стоит думать, что ML — это только про данные и запуск каких-то известных тулов. Это ещё и про способность написать необходимый метод самостоятельно. Во всяком случае, специалисты, которые могут это делать, более востребованы на рынке — поэтому нестранно, что и в контесте у них есть преимущество.
1. Квалификации — это турниры для неограниченного числа участников с более простыми задачами относительно финала. Они требуются для того, чтобы определить участников собственно финала.
2. Участники сами решают, в какой именно квалификации примут участие.
3. Я не согласен с тем, что задача вычисления метрики не имеет отношения к машинному обучению. Умение правильно и эффективно запрограммировать необходимый функционал потерь бывает весьма востребованной, без этого исследователю могут быть просто недоступны некоторые решения. Хорошее понимание процесса вычисления метрики (и его крайнее выражение — умение эту метрику запрограммировать) часто помогает придумать хорошее решение.
Так ведь совершенно разные механики использования. На десктопах пословные подсказки в их простейшей реализации будут неудобными — нужно будет то использовать клавиатуру, то мышку. Если говорить о расширяющемся поле ввода, то на десктопе, опять же, поле ввода в несколько раз длиннее, чем на мобильных, поэтому проблема не так актуальна. И так далее :)
Почему просто не поставить многстрочное поле, без мимикрии и без всяких красивостей?
Это будет иметь очевидные негативные последствия: такое поле крадёт и без того ограниченное пространство у страницы выдачи. Уменьшать удобство для 100% пользователей ради функциональности, хотя и важной, но полезной лишь в какой-то доле случаев, было бы неправильно. Об этом, в том числе, свидетельствует и провал нашей первой реализации (смотрите первый скриншот с расширяющимся полем ввода).
И тестировать на мобилках надо и на скорость работы полей ввода (красивые — тормозят, да и не так удобные в использовании, скажем, курсор в них позиционировать неудобно, исправление орфографии не работает), и на поведение в каждом из возможных браузеров на телефонах за последние года четыре.
Вы совершенно правы. Именно так мы и делаем! Наше тестирование затрагивает огромное количество платформ, версий ОС и вариантов браузеров.
Десктопы, конечно же, сохраняют свою актуальность. Однако, ввод запросов на мобильных устройствах — намного более сложное дело, поэтому именно там пользователям нужно помогать особенно сильно.
Вы совершенно правы! В таких ситуация довольно тяжело ёмко описать, что же за оси на графике. Пожалуй, в будущем буду делать пояснения хотя бы под самим графиком.
График нормирован на значение в некоторый день из начала 2016 года (это упоминается в посте). Поэтому график показывает увеличение доли примерно на 60%, если сравнивать с началом 2016 года.
Во-первых, компенсация опционами по определению выше, чем аналогичная компенсация за счёт величины оклада. Действительно много денег вы можете зарабатывать только за счёт опционов.
Во-вторых, возможность влияния «обычного разработчика» на стоимость акций компании сильно недооценивается, даже в больших компаниях :)
Если говорить об опционах в стартапах, то это любопытная штука. Проблема в том, что, пока стартап «не взлетит», опционы этого стартапа не стоят вообще ничего, поэтому учитывать их в качестве полноценной части компенсации не получается. Из-за этого сотрудник, имеющий опционы и переходящий из «большой компании» в стартап, может очень сильно терять в деньгах.
По-моему, вы просто слишком узко трактуете слово «амбициозны». Ожидать, что твои идеи будут реализовываться, сильные стороны — применяться, ну и вообще, требовать, чтобы твой труд тратился на достижение какого-то ощутимого результата — вполне распространённые проявления амбициозности, даже оставляя за рамками амбиции карьерные или материальные. По-моему, они настолько широко распространены, что использование квантора всеобщности вполне оправдано.
В любом случае, рад, что статья порождает дискуссию!
> все, кто составляют ядро разработки должны непосредственно иметь долю с прибыли этого сервиса, на протяжении всей жизни этого сервиса
Примерно для решения этой проблемы существуют программы премирования опционами, кажется. Если сотрудники регулярно получают опционы, то:
1. Их доход просто существенно больше.
2. Их доход зависит от стоимости компании, т.е. от её общей успешности.
3. Чтобы продолжать получать доход опционами, нужно держать себя в форме длительное время, пока происходит вестинг.
Просто некоторым красивым образом (имеющим мало отношения к методу Уэлфорда) линеаризованная фотография. Один мой друг такие картинки производит в больших количествах и вот поделился со мной, чтобы проиллюстрировать мощь линейных методов!
В такого рода задачах невыгодно использовать сколь-нибудь general purpose решения, т.к. они гарантированно будут в разы или даже на порядки хуже специализированной структуры данных. В нашем случае, например, нужно держать десятки тысяч RPS, время ответа на уровне десятков миллисекунд, при этом успевать делать ещё некоторую специфическую постобработку результатов (скажем, формирование пословных подсказок). Ну и ещё нужно экономить память, потому что нам нужно, чтобы на каждую машинку помещалось как можно больше подсказок.
Коротко говоря, основная структура данных в саджесте — по-особому плотно упакованный бор, некоторые узлы которого помнят, какие подсказки являются самыми вероятными для конкретного префикса.
Бывают и другие структуры — скажем, для хранения крайне редких подсказок мы используем другую структуру, т.к. позволяем себе в этом случае знать намного меньше информации про каждый запрос, и это позволяет упаковывать данные ещё плотнее.
Возможно, однажды расскажем об используемых алгоритмах в отдельной статье :)
Да, любопытный случай. К сожалению, это ошибка в нашем опечаточнике: он считает, что слово «синэо» с некоторой вероятностью является опечаткой и исправляет его на слово «цена». Передал этот пример коллегам!
Обращайте на это внимание. В условиях всегда явно указывается возможность ввода-вывода с использованием стандартных потоков.
3. Это не единственная задача такого рода. В первой квалификации, как видите, тоже была такая необходимость (задача про Decision Stump). Не стоит думать, что ML — это только про данные и запуск каких-то известных тулов. Это ещё и про способность написать необходимый метод самостоятельно. Во всяком случае, специалисты, которые могут это делать, более востребованы на рынке — поэтому нестранно, что и в контесте у них есть преимущество.
2. Участники сами решают, в какой именно квалификации примут участие.
3. Я не согласен с тем, что задача вычисления метрики не имеет отношения к машинному обучению. Умение правильно и эффективно запрограммировать необходимый функционал потерь бывает весьма востребованной, без этого исследователю могут быть просто недоступны некоторые решения. Хорошее понимание процесса вычисления метрики (и его крайнее выражение — умение эту метрику запрограммировать) часто помогает придумать хорошее решение.
Вы совершенно правы. Именно так мы и делаем! Наше тестирование затрагивает огромное количество платформ, версий ОС и вариантов браузеров.
Во-вторых, возможность влияния «обычного разработчика» на стоимость акций компании сильно недооценивается, даже в больших компаниях :)
Если говорить об опционах в стартапах, то это любопытная штука. Проблема в том, что, пока стартап «не взлетит», опционы этого стартапа не стоят вообще ничего, поэтому учитывать их в качестве полноценной части компенсации не получается. Из-за этого сотрудник, имеющий опционы и переходящий из «большой компании» в стартап, может очень сильно терять в деньгах.
В любом случае, рад, что статья порождает дискуссию!
Примерно для решения этой проблемы существуют программы премирования опционами, кажется. Если сотрудники регулярно получают опционы, то:
1. Их доход просто существенно больше.
2. Их доход зависит от стоимости компании, т.е. от её общей успешности.
3. Чтобы продолжать получать доход опционами, нужно держать себя в форме длительное время, пока происходит вестинг.
Перенормировка — действительно хороший способ. Уэлфорд всего-лишь позволяет выполнить её за один проход.
В такого рода задачах невыгодно использовать сколь-нибудь general purpose решения, т.к. они гарантированно будут в разы или даже на порядки хуже специализированной структуры данных. В нашем случае, например, нужно держать десятки тысяч RPS, время ответа на уровне десятков миллисекунд, при этом успевать делать ещё некоторую специфическую постобработку результатов (скажем, формирование пословных подсказок). Ну и ещё нужно экономить память, потому что нам нужно, чтобы на каждую машинку помещалось как можно больше подсказок.
Коротко говоря, основная структура данных в саджесте — по-особому плотно упакованный бор, некоторые узлы которого помнят, какие подсказки являются самыми вероятными для конкретного префикса.
Бывают и другие структуры — скажем, для хранения крайне редких подсказок мы используем другую структуру, т.к. позволяем себе в этом случае знать намного меньше информации про каждый запрос, и это позволяет упаковывать данные ещё плотнее.
Возможно, однажды расскажем об используемых алгоритмах в отдельной статье :)