Здесь Женя Малютин рассказывал на примере хгбуста: vk.com/video-133150806_456239018 Там даже датасета как такового не было — просто попытали XGBoost завернуть в типа model-agnostic обертку и кормили её векторами с ложечки. Без реста — все инпроцесс в яве.
Попробую. Spark в режиме master=local[*] подойдет? В кластерном режиме Python еще гемора с дистрибуцией пакетов докидывает и другие задачи будут интерферировать.
Из недавнего — считали per-user AUC, нужно было пройтись по датафрейму, сгруппировать по пользователю записи, собрать списки и скормить roc_auc из scikit (для Python) или своей реализации на Scala. В одной партиции ~1М юзеров. Scala работает за секунды, Python за минуты.
Мы пробовали JPMML, но не завелся совсем по скорости. В итоге пришли к тому что пока в прод выдергиваем только «ядро» — бинарник хгбуста или матрицы весов. Но! Сейчас смотрим в сторону варианта со Structured Streaming — основная проблема с использованием батч режима и master=local[*] в том что постоянно крутится постороение плана и оптимизация, а в стриминге он построится один раз. Но пока готового решения нет — когда допилим, отдельно расскажем.
Можно и на Java, получится неплохо. Но кода придется написать все-таки побольше — в Scala есть много и не очень лютой, а вполне удобной и безопасной функциональщины :). Да и Java все больше дрейфует в ту сторону.
Насчет мартышкиного труда в точку — именно тот факт что этот мартышкин труд пока не автоматизирован и приводит к перегреву рынка ДС. Но ситуация меняется и термин auto-ml звучит все чаще. В рамках того же PravdaML мы уже начинаем внедрять разные его аспекты.
Ну и в этом же кроется и ответ в чем Scala лучше Python — в Python все работает быстро только до тех пор, пока вы пользуетесь стандартными бибилотеками через стандартный API. Как только появляется необходимость сделать что-то нестандартное, хотя бы apply(lambda ...) в Pandas, производительность падает в разы — приходится подключать интерпретатор к массовой обработке. Когда вы используете Scala — смело можно креативить, негативного эффекта на производительность не будет.
Это если начать заигрывать с лютой функциональщиной. Если держаться в рамках «понятных среднему пользователю» конструкций то все ± безопасно. В Python, кстати, ничем не лучше в этом плане — одно неловкое движение и у тебя в памяти лишняя копия данных да еще и с адским боксингом.
Ну pandas это стандарт для «типичного датасаентиста», поэтому в бэйзлайн брали его а не Dask, PyTables и т.д. Да даже сам arrow можно было использовать на прямую. В целом по памяти колоночный формат пандаса неплох и хорошо интегрирован со скайкитом. Проблемы создаются в первую очередь когда вместо передачи колонки целиком в нативный код приходится делать итерацию по элементам в питоне.
Для формирования ленты работает несколько тысяч серверов, все это стоит весьма недешево, поэтому соцсеть, конечно, должна приносить прибыль. Но при этом прибыль очень хорошо скоррелирована с удовлетворенностью пользователя, поэтому алгоритмы ленты работают в первую очередь на неё. Но они не идеальны и, как и все МЛ алгоритмы, идут по пути наименьшего сопротивления, что приводит к целому сонму проблем — кликбэйтный контент, разного рода накрутки, неадекватная работа для пользователей, относящихся к «редким видам» и т.д.
Собственно уже скоро появится возможность попробовать свои силы и сделать по настоящему умный алгоритм ;)
Это вполне расспространенный паттерн — есть пользователи, которые «ответственно» подходят к тому на кого подписываются, вдумчиво перевариваривают информацию — им алгоритмы пока чаще мешают чем помогают.
Есть такое — называется «вертикали». Но тут пока как — делать их руками под себя сможет 0.1% пользователей по самым оптимистичным оценкам. При этом процентов 10 попробуют настроить, но получится плохо и активность от них упадет. И автоматика пока получается достаточно сложная. На самом деле на данных конкурса вполне можно будет поробовать поиграться и с вертикалями.
«Вперед» или нет сильно зависит от того, куда Вы хотите придти. Конечно бороться с технологической безработицей попытками остановить развитие технологий безсмысленно, но и забывать про то, что за безликими цифрами стоят живые люди тоже нельзя. Радоваться тому что люди теряют работу достатоно странно, на мой взгляд. Хотите сделать акцент на деньги — назовите «Как сэкономить до 90% затрат на дата сайнс». А провокаций жизнь нам и так подкидывает не мало.
В развитых сообществах проблема технологической безработицы уже стоит в актуальной повестке дня и пока оптимальным вариантом решения считается поддержка трансфера лишающихся работы людей в новые области. А здесь ДС может очень много что предложить: и прямой трансфер через создание новых типов рабочих мест, например «МЛ-разметчик», и создание вторичных рабочих мест в около-ДС индустрии, и стимуляци развития трудоустройства по пир-ту-пир модели и много что еще. Так что, надеюсь, увидим мы и работы о том как ДС помог найти работу паре сотен тысяч человек — вот это будет заголовок.
Сложно что-то возразить… Но я идеалист и верю в превосходство просветительских мер над репресивными. Гораздо лучше постараться неприятность предотвратить чем потом искать (чаще читай назначать) и наказывать виновных.
Все правильно, для получения результата нужны все компоненты: и методы, и технологии, и процессы, и культура. Вообще вопрос о том как организовать работу дата сайентиста так, чтобы при этом он не мог нарушить приватность пока далек от хорошего решения, но международное сообщество активно работает в этом направлении (собственно о части полученных в это области результатов я рассказывал на мэйджоре и в постах-обзорах КДД).
Да, незакрытые лица и номера на Яндексе это тоже особеность Российского дата сайнс (технически это реализовать, кстати, не то чтобы большая проблема). И дело тут в первую очередь в головах тех, кто с персональными данными работает, т.е. дата сайентистов.
Ну и в этом же кроется и ответ в чем Scala лучше Python — в Python все работает быстро только до тех пор, пока вы пользуетесь стандартными бибилотеками через стандартный API. Как только появляется необходимость сделать что-то нестандартное, хотя бы apply(lambda ...) в Pandas, производительность падает в разы — приходится подключать интерпретатор к массовой обработке. Когда вы используете Scala — смело можно креативить, негативного эффекта на производительность не будет.
фичейпризнаком вранжированииупорядочивании ленты.Собственно уже скоро появится возможность попробовать свои силы и сделать по настоящему умный алгоритм ;)
В развитых сообществах проблема технологической безработицы уже стоит в актуальной повестке дня и пока оптимальным вариантом решения считается поддержка трансфера лишающихся работы людей в новые области. А здесь ДС может очень много что предложить: и прямой трансфер через создание новых типов рабочих мест, например «МЛ-разметчик», и создание вторичных рабочих мест в около-ДС индустрии, и стимуляци развития трудоустройства по пир-ту-пир модели и много что еще. Так что, надеюсь, увидим мы и работы о том как ДС помог найти работу паре сотен тысяч человек — вот это будет заголовок.