У этой темы много граней, и все они довольно противные.
Случаи, когда доклад отклоняют на одной конференции, а потом берут на другую, и он там нормально выстреливает, нередки. Конечно, если доклад отклонили по ошибке (т.е. не разобравшись), то развёрнутый ответ даёт возможность докладчику дать нужные пояснения и вернуть события в позитивное русло. Обтекаемый отказ такой возможности не даёт, потому что непонятно, на что отвечать.
Так что да, такая практика создаёт некоторое количество потерь. Тут каждый сам для себя решит, какие потери страшнее.
А грубо отвечать не надо. «У нас нет времени ответить всем» у меня бы отбило охоту с этими людьми общаться вообще когда-либо в будущем.
Экспофорум — очень большая площадка, она способна вместить заметно больше людей, чем 2000. От этого, возможно, создалась иллюзия относительной пустоты.
Конкретный список с именами обещать вот прямо сейчас не могу, иначе он бы был в статье, но work in progress items примерно такие (что-то из этого сделать труднее, что-то легче):
1. Хочется поймать и привезти кого-нибудь из заметных разработчиков, например, Spark.
2. Есть идея рассказа «что надо сделать с вашей инфраструктурой, чтобы начать в проде гонять машиннообученные вещи, если раньше их у вас не было». Не все понимают, что меняется, когда в прод приходит первая формула. Понятно, что это рассказ скорее для новичков, но на грабли тут наступают многие.
3. Отмечу, что рассказ Александра Тоболя не только про DS, про построение инфраструктуры для быстрого распознавания лиц там тоже довольно много. Система всё ещё развивается, поэтому это не будет повтором того, что Александр уже рассказывал на других конференциях.
4. Год назад Дмитрий Бугайченко выступал про то, как устроены DS-пайплайны в Одноклассниках. Будет по крайней мере одна другая крупная компания, которые поделится тем, как это устроено у них, и почему именно так.
5. ClickHouse довольно триумфально идёт по планете, я надеюсь, что и нашу конференцию он не обойдёт стороной.
6. Если есть что-то, что хотелось бы увидеть, то сейчас очень подходящее время об этом написать!
Да, нельзя просто бросать в тест всё подряд. нельзя перебирать параметры руками пользователей. Нужно иметь гипотезу, обоснованную какими-то другими соображениями, и уже потом её проверять.
С новым дизайном, кстати, можно сначала дать пользователям привыкнуть (например, неделю, показывать новый дизайн экспериментальной группе), и рассчитывать результаты эксперимента только по следующей неделе. Конечно, надо мониторить, и если всё в первую неделю ОЧЕНЬ плохо, то выключать, а если просто плохо — стиснуть зубы и ждать второй недели, и там всё может стать норм.
Всё правда. Но как бы мы ни множили эксперименты, важно иметь в любое парочку чистых контрольных групп (т.е. таких пользователей, которые ни в каких экспериментах не состоят). Тогда, в частности, на них можно проводить A/A тесты. И на них же можно потом проводить множественные A/A тесты, о которых я говорил.
Эти A/A тесты, как и любые тесты, не могут служить доказательством корректности, тут односторонний алгоритм: если они не сходятся к заданному проценту срабатываний — надо бить тревогу, точно что-то сломано. Если сходятся — надо смотреть на все остальные мониторинги и держать пальцы крестиком. Это просто ещё одна проверка, которую делать относительно дёшево и которая ловит часть проблем.
Даже обобщу: в любых задачах анализа данных очень важно не просто брать цифры и применять к ним алгоритмы. Важно совмещать это со знанием предметной области (которое энергично собирать). Тогда результаты получаются лучше.
Например, в поиске можно сломать в эксперименте один запрос [в контакте], и результаты окажутся катастрофическими. Но чтобы это понять, надо знать иметь представление о структуре запросов, а не только видеть общее число.
Тема для Гейзенбага не совсем профильная. Мы довольно много обсуждали с программным комитетом, что именно рассказать, чтобы попасть в аудиторию, и весь космос безжалостно вымели. Поэтому в докладе, действительно, оказались довольно базовые вещи.
На экспериментах в несколько слоёв не хотелось заострять внимание: там свой набор проблем, которые не заменяют, а дополняют проблемы классических AB-тестов.
Касательно сорока одного оттенка синего, их всех, конечно, надо запускать в параллель одновременно. Дело даже не в том, что пользователь, который видел оттенок 12, потом не так отреагирует на оттенок 37 (хотя возможно и это), а в том, что результаты экспериментов, проведённых в разное время, вообще нельзя сравнивать: от сезонности зависит в среднем больше, чем от качества системы, которую мы проверяем, и две последовательные недели дают разные результаты. Условно, в России результаты любого интернет-сервиса сильнее всего зависят от того, дождливый в Москве день или солнечный.
Трудности —это всего лишь новые условия задачи, а не повод отказываться от полезного метода. Конечно, есть знаменитые истории типа Опры Уинфри, которая в своём шоу заявила о том, что Киндл — теперь её любимый девайс, на следующий день после обновления сайта Киндла (успели ли разработчики получить премию, я не знаю). Есть способы мониторить результаты экспериментов, находить среди них подозрительные и, возможно, невалидные. Опять же, выборки в вебе больше, тут не двадцать пациентов с плацебо и двадцать с лекарством, а таки тысячи.
В общем, свои трудности есть, но есть и свои ответы на них.
Принято, и как минимум явно помечать, к чему тот или иной рассказ относится, будем. Если есть в области инструментов громкие имена, с носителями которых было бы здорово пообщаться, то вы знаете, кому их сообщить.
Слайды же нужны в первую очередь для того, чтобы показать что-то такое, что голосом объяснить трудно. Графики, схемы, визуальные эффекты и вот это всё.
То есть очень трудно научить человека не читать со слайдов, зато его довольно легко научить делать такие слайды, с которых читать невозможно.
Крутые темы первичны. Если человеку нечего сказать, то как бы технично он ни выступал ни о чём, пользы ноль. Но ничто не мешает быть одновременно умным и красивым.
Я пока ещё тешу себя надеждой, что, если сфокусировать человека на поиск конкретных минусов (тех, которые я перед этим ему объяснил и показал, как их искать), то он на них и сосредоточится. Т.е. будет искать логические неувязки и их исправлять. Возможно, практика меня переубедит, но в данный момент я считаю, что смотреть можно, просто надо правильно сфокусироваться.
От того, КАК мы говорим, всё может меняться очень сильно. Тут речь скорее о том, что количественные измерения с этой аудиторией плохо работают: тут же находится человек, который интересуется первоисточником, а когда мы докапываемся до первоисточника, часто оказывается, что на самом деле он был немного не про то. =)
А теперь давайте вспомним, что мы выполняем проверку стат. гипотез.
Стат. тест, как алгоритм, обладает особенностью: если для какой-то разности X_0
стат. тест предсказал 1, то для всех |X| > |X_0| стат. тест также будет предсказывать 1.
В общем случае это, если я правильно понял утверждение, неверно. Статтесты (многие, во всяком случае) учитывают не только величину разности, но и свойства выборки. Т.е. можно себе представить ситуацию, когда при меньшей по модулю разности средних между A и B тест говорит, что изменения значимы, а при большей по модулю разности между тем же A и неким C тот же тест скажет, что значимой разницы нет.
Поэтому ошибку второго рода надо проверять всё-таки отдельно.
Случаи, когда доклад отклоняют на одной конференции, а потом берут на другую, и он там нормально выстреливает, нередки. Конечно, если доклад отклонили по ошибке (т.е. не разобравшись), то развёрнутый ответ даёт возможность докладчику дать нужные пояснения и вернуть события в позитивное русло. Обтекаемый отказ такой возможности не даёт, потому что непонятно, на что отвечать.
Так что да, такая практика создаёт некоторое количество потерь. Тут каждый сам для себя решит, какие потери страшнее.
А грубо отвечать не надо. «У нас нет времени ответить всем» у меня бы отбило охоту с этими людьми общаться вообще когда-либо в будущем.
1. Хочется поймать и привезти кого-нибудь из заметных разработчиков, например, Spark.
2. Есть идея рассказа «что надо сделать с вашей инфраструктурой, чтобы начать в проде гонять машиннообученные вещи, если раньше их у вас не было». Не все понимают, что меняется, когда в прод приходит первая формула. Понятно, что это рассказ скорее для новичков, но на грабли тут наступают многие.
3. Отмечу, что рассказ Александра Тоболя не только про DS, про построение инфраструктуры для быстрого распознавания лиц там тоже довольно много. Система всё ещё развивается, поэтому это не будет повтором того, что Александр уже рассказывал на других конференциях.
4. Год назад Дмитрий Бугайченко выступал про то, как устроены DS-пайплайны в Одноклассниках. Будет по крайней мере одна другая крупная компания, которые поделится тем, как это устроено у них, и почему именно так.
5. ClickHouse довольно триумфально идёт по планете, я надеюсь, что и нашу конференцию он не обойдёт стороной.
6. Если есть что-то, что хотелось бы увидеть, то сейчас очень подходящее время об этом написать!
С новым дизайном, кстати, можно сначала дать пользователям привыкнуть (например, неделю, показывать новый дизайн экспериментальной группе), и рассчитывать результаты эксперимента только по следующей неделе. Конечно, надо мониторить, и если всё в первую неделю ОЧЕНЬ плохо, то выключать, а если просто плохо — стиснуть зубы и ждать второй недели, и там всё может стать норм.
Эти A/A тесты, как и любые тесты, не могут служить доказательством корректности, тут односторонний алгоритм: если они не сходятся к заданному проценту срабатываний — надо бить тревогу, точно что-то сломано. Если сходятся — надо смотреть на все остальные мониторинги и держать пальцы крестиком. Это просто ещё одна проверка, которую делать относительно дёшево и которая ловит часть проблем.
Даже обобщу: в любых задачах анализа данных очень важно не просто брать цифры и применять к ним алгоритмы. Важно совмещать это со знанием предметной области (которое энергично собирать). Тогда результаты получаются лучше.
Например, в поиске можно сломать в эксперименте один запрос [в контакте], и результаты окажутся катастрофическими. Но чтобы это понять, надо знать иметь представление о структуре запросов, а не только видеть общее число.
На экспериментах в несколько слоёв не хотелось заострять внимание: там свой набор проблем, которые не заменяют, а дополняют проблемы классических AB-тестов.
Касательно сорока одного оттенка синего, их всех, конечно, надо запускать в параллель одновременно. Дело даже не в том, что пользователь, который видел оттенок 12, потом не так отреагирует на оттенок 37 (хотя возможно и это), а в том, что результаты экспериментов, проведённых в разное время, вообще нельзя сравнивать: от сезонности зависит в среднем больше, чем от качества системы, которую мы проверяем, и две последовательные недели дают разные результаты. Условно, в России результаты любого интернет-сервиса сильнее всего зависят от того, дождливый в Москве день или солнечный.
В общем, свои трудности есть, но есть и свои ответы на них.
Принято, и как минимум явно помечать, к чему тот или иной рассказ относится, будем. Если есть в области инструментов громкие имена, с носителями которых было бы здорово пообщаться, то вы знаете, кому их сообщить.
То есть очень трудно научить человека не читать со слайдов, зато его довольно легко научить делать такие слайды, с которых читать невозможно.
Мысль готовить две версии слайдов — хорошая.
В общем случае это, если я правильно понял утверждение, неверно. Статтесты (многие, во всяком случае) учитывают не только величину разности, но и свойства выборки. Т.е. можно себе представить ситуацию, когда при меньшей по модулю разности средних между A и B тест говорит, что изменения значимы, а при большей по модулю разности между тем же A и неким C тот же тест скажет, что значимой разницы нет.
Поэтому ошибку второго рода надо проверять всё-таки отдельно.