Forwarded from TechSparks
Вот сижу на зум-встрече, одновременно занят онлайн-жюрением «Серебряного Меркурия» и попутно читаю статью, как раз по теме, статистика мультитаскинга во время онлайновых совещаний :))
Очень познавательно и полезно, хотя у Майкрософта данные лишь по своей экосистеме, и чатики в телеге, например, туда не попали.
Логично, что чем длиннее совещание, тем больше народ отвлекается, а чем раньше оно в течение дня, тем больше народ лезет в почту — утром как ее не проверить. Полезно осознавать, что внимание во время регулярок и многолюдных встреч очень сильно уплывает, а вот если встреча отдельная и по реальной теме — то отвлекаются участники куда меньше.
https://www.techrepublic.com/article/getting-distracted-during-video-meetings-youre-not-alone-says-microsoft/
Полный текст серьезной статьи, где куда больше данных и графиков — https://www.microsoft.com/en-us/research/uploads/prod/2021/01/CHI2021_RemoteMeetingMultitask_CameraReady-2.pdf
Кстати, я ведь помимо перечисленного в начале ещё и этот пост пишу, а зум идёт себе своим чередом…
Очень познавательно и полезно, хотя у Майкрософта данные лишь по своей экосистеме, и чатики в телеге, например, туда не попали.
Логично, что чем длиннее совещание, тем больше народ отвлекается, а чем раньше оно в течение дня, тем больше народ лезет в почту — утром как ее не проверить. Полезно осознавать, что внимание во время регулярок и многолюдных встреч очень сильно уплывает, а вот если встреча отдельная и по реальной теме — то отвлекаются участники куда меньше.
https://www.techrepublic.com/article/getting-distracted-during-video-meetings-youre-not-alone-says-microsoft/
Полный текст серьезной статьи, где куда больше данных и графиков — https://www.microsoft.com/en-us/research/uploads/prod/2021/01/CHI2021_RemoteMeetingMultitask_CameraReady-2.pdf
Кстати, я ведь помимо перечисленного в начале ещё и этот пост пишу, а зум идёт себе своим чередом…
Forwarded from Цифровой геноцид
Коллаборация и HCI. Часть I
Современные технологии предоставили много полезных инструментов для взаимодействия пользователей друг с другом. Рабочие чаты, совместный доступ к документам и облачные хранилища уже сейчас привели к многочисленным организационным и социальным изменениям. Если телеграф и телефон расширили рамки коммуникаций, а телевидение и радио границы информирования, то инструментым совместного доступа — расширили географические и хронологические рамки человеческой деятельности.
Поддержка на уровне интерфейса деятельности групп и организаций — это классная история, которая сфокусирована на поддержки соместных действий на разных уровнях географии и времени (в одном месте/в разных местах — в одной время/асинхронно).
Немного генеалогии понятий: за прошедшие десятилетия названия коллаборативных технологий сильно изменились. Если раньше их называли «групповым программным обеспечением», то теперь используют нейтральные названия и речь идет уже отнюдь не только о работе. В итоге в западных исследованиях утвердилась computer-supported cooperative work или сокращенно CSCW.
Первые попытки создания единого рабочего пространства при помощи технологий относятся к концу войны — Вановер Буш в своем манифесте «Как мы можем мыслить» аж 1945 года предполагал создание единой машины коллективной памяти — своеобразного Мемекса. Мы много писали о этом проекте на страницах ЦГ, поэтому не будем останавливаться на этом подробно. CSCW стали формальной областью изучения в середине 1980-х годов, когда появились конференции, журналы, книги и университетские курсы, в которых активно использовалось это название. Работа по автоматизации делопроизводства включала в себя множество элементов групповой работы, таких как управление рабочим процессом в группе, календарь, электронная почта и обмен документами — все 80-ые годы активно шла работа в этом направлении. Большинство офисного ПО обычного менеджера может похвастаться аристократическими предками, ведь к ним приложили руку отцы-основатели вроде самого Дугласа Энгельбарта.
Совместная функциональность стала широко распространенной и знакомой вещью. Тем не менее, по-прежнему существует много исследовательских вопросов о том, как проектировать такие системы и как они влияют на отдельных пользователей, группы и организации, которые их используют.
Проектирование понятных бенефитов. Большинство пользователей заинтересовано в совместной работе только ради выгоды. Задача геймификации и юмора попадает даже в такие скучные вещи как гугл-докс — смотри шутливые обозначения других пользователей как животных.
Дилемма заключенного. Как и в теории игр совместное использование инструментов может быть саботировано одним пользователем без надлежащих навыков.
Нарушение социальных процессов. Групповое ПО может вести к деятельности, которая нарушает социальные табу, угрожает существующим политическим структурам или иным образом подрывает стабильность. Вы можете смеятся, но эта проблема юзабилити существует в большинстве западных исследований вплоть до учебных пособий.
Обработка исключений. Групповое программное обеспечение может не суметь в импровизацию и сложные узкие случаи, типа креативных индустрий со сложными и нетривиальными задачами
Интеграции. Тут все просто: совместным инструментам нужна большая сеть партнерств и интеграций с обычными сервисами для пользователя.
Контринтуитивность использования и сложность оценки вклада каждого участника. Это менеджерская проблема.
Отдельной проблемой и перспективой коллаборативных технологий является появление социальных сервисов, типа социальных сетей, когда все стало публичным и интегрированным.
Друг любит во всякое время
Притчи 17:17Современные технологии предоставили много полезных инструментов для взаимодействия пользователей друг с другом. Рабочие чаты, совместный доступ к документам и облачные хранилища уже сейчас привели к многочисленным организационным и социальным изменениям. Если телеграф и телефон расширили рамки коммуникаций, а телевидение и радио границы информирования, то инструментым совместного доступа — расширили географические и хронологические рамки человеческой деятельности.
Поддержка на уровне интерфейса деятельности групп и организаций — это классная история, которая сфокусирована на поддержки соместных действий на разных уровнях географии и времени (в одном месте/в разных местах — в одной время/асинхронно).
Немного генеалогии понятий: за прошедшие десятилетия названия коллаборативных технологий сильно изменились. Если раньше их называли «групповым программным обеспечением», то теперь используют нейтральные названия и речь идет уже отнюдь не только о работе. В итоге в западных исследованиях утвердилась computer-supported cooperative work или сокращенно CSCW.
Первые попытки создания единого рабочего пространства при помощи технологий относятся к концу войны — Вановер Буш в своем манифесте «Как мы можем мыслить» аж 1945 года предполагал создание единой машины коллективной памяти — своеобразного Мемекса. Мы много писали о этом проекте на страницах ЦГ, поэтому не будем останавливаться на этом подробно. CSCW стали формальной областью изучения в середине 1980-х годов, когда появились конференции, журналы, книги и университетские курсы, в которых активно использовалось это название. Работа по автоматизации делопроизводства включала в себя множество элементов групповой работы, таких как управление рабочим процессом в группе, календарь, электронная почта и обмен документами — все 80-ые годы активно шла работа в этом направлении. Большинство офисного ПО обычного менеджера может похвастаться аристократическими предками, ведь к ним приложили руку отцы-основатели вроде самого Дугласа Энгельбарта.
Совместная функциональность стала широко распространенной и знакомой вещью. Тем не менее, по-прежнему существует много исследовательских вопросов о том, как проектировать такие системы и как они влияют на отдельных пользователей, группы и организации, которые их используют.
Проектирование понятных бенефитов. Большинство пользователей заинтересовано в совместной работе только ради выгоды. Задача геймификации и юмора попадает даже в такие скучные вещи как гугл-докс — смотри шутливые обозначения других пользователей как животных.
Дилемма заключенного. Как и в теории игр совместное использование инструментов может быть саботировано одним пользователем без надлежащих навыков.
Нарушение социальных процессов. Групповое ПО может вести к деятельности, которая нарушает социальные табу, угрожает существующим политическим структурам или иным образом подрывает стабильность. Вы можете смеятся, но эта проблема юзабилити существует в большинстве западных исследований вплоть до учебных пособий.
Обработка исключений. Групповое программное обеспечение может не суметь в импровизацию и сложные узкие случаи, типа креативных индустрий со сложными и нетривиальными задачами
Интеграции. Тут все просто: совместным инструментам нужна большая сеть партнерств и интеграций с обычными сервисами для пользователя.
Контринтуитивность использования и сложность оценки вклада каждого участника. Это менеджерская проблема.
Отдельной проблемой и перспективой коллаборативных технологий является появление социальных сервисов, типа социальных сетей, когда все стало публичным и интегрированным.
http://databricks.com/blog/2021/06/09/how-to-build-a-scalable-wide-and-deep-product-recommender.html
Databricks
How to Build a Scalable Wide & Deep Product Recommender System
Get the details and access to Databricks’ latest solution accelerator: a novel DL recommender that combines customer purchase and preference data for greater customer intimacy and engagement.
Introduction to Recommender Systems Handbook
Francesco Ricci, Lior Rokach and Bracha Shapira
Recommender Systems (RSs) are software tools and techniques providing suggestions for items to be of use to a user. In this introductory chapter we briefly discuss basic RS ideas and concepts. Our main goal is to delineate, in a coherent and structured way, the chapters included in this handbook and to help the reader navigate the extremely rich and detailed content that the handbook offers.
http://www.inf.unibz.it/~ricci/papers/intro-rec-sys-handbook.pdf
Francesco Ricci, Lior Rokach and Bracha Shapira
Recommender Systems (RSs) are software tools and techniques providing suggestions for items to be of use to a user. In this introductory chapter we briefly discuss basic RS ideas and concepts. Our main goal is to delineate, in a coherent and structured way, the chapters included in this handbook and to help the reader navigate the extremely rich and detailed content that the handbook offers.
http://www.inf.unibz.it/~ricci/papers/intro-rec-sys-handbook.pdf
Exploring Data Splitting Strategies for the Evaluation of Recommendation Models
https://arxiv.org/abs/2007.13237
https://arxiv.org/abs/2007.13237
https://www.facebook.com/100000998741278/posts/4275112192532030/?d=n
На этой неделе мы сделали, чтобы рекомендации вакансий уже на самом первом этапе, при предварительном выборе, применялись RNN DSSM нейросети. Это даёт примерно +400 дополнительных наймов в день, при том, что вакансий, в среднем стало рекомендоваться меньше (да лучше).
Многие рекомендательные системы основаны на вертикальном стеке моделей. На предварительном этапе у них простые эвристики и модели с не очень высоким качеством, зато позволяющие очень быстро сделать из всех элементов «короткий» список (в нашем случае – около 50 тыс. вакансий). Когда-то у нас на первом этапе был эвристический фильтр, который пропускал через себя только вакансии, у которых город совпадал с указанным в резюме соискателя, а для крупных городов – у которых совпадала ещё и профобласть/специализация.
Порой, например, IT-директора жаловались, что в их Железнодорожном для них есть работа максимум эникейщиками. Поэтому мы стали учитывать, что люди могут хотеть переехать, а ещё что часть работы может формально находиться в другом городе, а фактически – в пределах ежедневной транспортной доступности.
Дальше мы увидели жалобы, что нет подходящей работы, хотя находится ведь, например, для швей. Оказалось, что специализаций «швея» несколько, в искусстве и в производстве. Соискатели предпочитают настраивать в резюме «искусство», работодатели – «производство». Таких примеров тысячи, люди переходят из одной профобласти в другую, тенденции в таких переходах изменяются, особенно в связи с коронакризисом, писать исправления для каждого вручную – не вариант. Профобласти и специализации – как и любой ручной классификатор, не идеален, он большой и неоднозначный, и когда люди настраивают его для своих резюме и вакансий, там есть 2 вида ошибок: регулярные (из-за неоднозначности) и случайные (например, когда пользователь отнесся к нему, как к формальности, и выбрал первую попавшуюся специализацию). Чтобы бороться с регулярными, применили PPMI, чтобы со случайными – расширение «короткого» списка с помощью быстрой оценки, сначала сходства резюме и вакансии по тексту (симхеши LSH, т.к. kNN/HNSW оказались слишком медленными), потом по вероятности приглашения (симхеши на обучаемый функции хеширования, MLH).
К тому моменту в эвристическом фильтре особо не осталось эвристик, и он потерял свой единственный плюс - интерпретируемость. А у нас появились нейросети RNN DSSM, хорошо, на основе последовательностей и слов, оценивающие вероятность найма, а также учитывающие числовые и категориальные статические признаки. Метапризнак на RNN DSSM - топ 1 по силе в остальных моделях. Поэтому мы заменили PPMI и MLH на быстрый фильтр на RNN DSSM. Теперь рекомендациям вакансий не страшны ошибки в профобластях и специализациях, потому что они их совсем перестали использовать и учитывая результат – это правильно.
Это важный шаг к тому, чтобы избавиться от линейных моделей и ансамблей решающих деревьев и сделать всё на end-to-end state-of-the-art нейросетях.
Ещё на этой неделе мы применили в рекомендациях по резюме улучшенную, с тонко подобранными гиперпараметрами, RNN DSSM, теперь это даёт ещё около +320 дополнительных наймов в день. В целом, рекомендации резюме в июне дали 1,4 раза больше наймов по базе резюме, чем все виды поиска резюме. По видам поиска, поиск по соответствию, на ML, дал в 1,7 раза больше, чем поиск по дате. Работодатели голосуют за ML, который экономит им время, своим поведением.
Кроме того, на этой неделе мы сделали, чтобы поиск по вакансиям учитывал регион и расстояние от соискателя до интересных ему вакансий в течение 5 мин, обеспечили +20 дополнительных наймов в день. Рекомендации вакансий, конечно, тоже дают в 1,4 раза больше наймов, чем поиск по вакансиям (интересное совпадение), но мы продолжаем развивать и поиск по вакансиям, потому что он даёт бустинг премиальным вакансиям. Для Премиумов и Стандарт+ за счёт прямого бустинга в поиске система не только обеспечивает больше откликов, но и накапливает больше данных о том, какие пользователи на них откликаются и кого из них потом приглашают.
На этой неделе мы сделали, чтобы рекомендации вакансий уже на самом первом этапе, при предварительном выборе, применялись RNN DSSM нейросети. Это даёт примерно +400 дополнительных наймов в день, при том, что вакансий, в среднем стало рекомендоваться меньше (да лучше).
Многие рекомендательные системы основаны на вертикальном стеке моделей. На предварительном этапе у них простые эвристики и модели с не очень высоким качеством, зато позволяющие очень быстро сделать из всех элементов «короткий» список (в нашем случае – около 50 тыс. вакансий). Когда-то у нас на первом этапе был эвристический фильтр, который пропускал через себя только вакансии, у которых город совпадал с указанным в резюме соискателя, а для крупных городов – у которых совпадала ещё и профобласть/специализация.
Порой, например, IT-директора жаловались, что в их Железнодорожном для них есть работа максимум эникейщиками. Поэтому мы стали учитывать, что люди могут хотеть переехать, а ещё что часть работы может формально находиться в другом городе, а фактически – в пределах ежедневной транспортной доступности.
Дальше мы увидели жалобы, что нет подходящей работы, хотя находится ведь, например, для швей. Оказалось, что специализаций «швея» несколько, в искусстве и в производстве. Соискатели предпочитают настраивать в резюме «искусство», работодатели – «производство». Таких примеров тысячи, люди переходят из одной профобласти в другую, тенденции в таких переходах изменяются, особенно в связи с коронакризисом, писать исправления для каждого вручную – не вариант. Профобласти и специализации – как и любой ручной классификатор, не идеален, он большой и неоднозначный, и когда люди настраивают его для своих резюме и вакансий, там есть 2 вида ошибок: регулярные (из-за неоднозначности) и случайные (например, когда пользователь отнесся к нему, как к формальности, и выбрал первую попавшуюся специализацию). Чтобы бороться с регулярными, применили PPMI, чтобы со случайными – расширение «короткого» списка с помощью быстрой оценки, сначала сходства резюме и вакансии по тексту (симхеши LSH, т.к. kNN/HNSW оказались слишком медленными), потом по вероятности приглашения (симхеши на обучаемый функции хеширования, MLH).
К тому моменту в эвристическом фильтре особо не осталось эвристик, и он потерял свой единственный плюс - интерпретируемость. А у нас появились нейросети RNN DSSM, хорошо, на основе последовательностей и слов, оценивающие вероятность найма, а также учитывающие числовые и категориальные статические признаки. Метапризнак на RNN DSSM - топ 1 по силе в остальных моделях. Поэтому мы заменили PPMI и MLH на быстрый фильтр на RNN DSSM. Теперь рекомендациям вакансий не страшны ошибки в профобластях и специализациях, потому что они их совсем перестали использовать и учитывая результат – это правильно.
Это важный шаг к тому, чтобы избавиться от линейных моделей и ансамблей решающих деревьев и сделать всё на end-to-end state-of-the-art нейросетях.
Ещё на этой неделе мы применили в рекомендациях по резюме улучшенную, с тонко подобранными гиперпараметрами, RNN DSSM, теперь это даёт ещё около +320 дополнительных наймов в день. В целом, рекомендации резюме в июне дали 1,4 раза больше наймов по базе резюме, чем все виды поиска резюме. По видам поиска, поиск по соответствию, на ML, дал в 1,7 раза больше, чем поиск по дате. Работодатели голосуют за ML, который экономит им время, своим поведением.
Кроме того, на этой неделе мы сделали, чтобы поиск по вакансиям учитывал регион и расстояние от соискателя до интересных ему вакансий в течение 5 мин, обеспечили +20 дополнительных наймов в день. Рекомендации вакансий, конечно, тоже дают в 1,4 раза больше наймов, чем поиск по вакансиям (интересное совпадение), но мы продолжаем развивать и поиск по вакансиям, потому что он даёт бустинг премиальным вакансиям. Для Премиумов и Стандарт+ за счёт прямого бустинга в поиске система не только обеспечивает больше откликов, но и накапливает больше данных о том, какие пользователи на них откликаются и кого из них потом приглашают.
Facebook
Log in or sign up to view
See posts, photos and more on Facebook.
Эти данные используются и в рекомендациях вакансий, за счёт чего откликов на них из рекомендаций становится совсем немного больше – и они при этом становятся намного более релевантными.
Это что касается этой недели. А на прошлой и позапрошлой у нас был перерыв в продуктовых запусках. Дело не в моём отпуске, а в том, что мы оптимизировали и перезапустили саму систему экспериментов. В поиске мы почти ничего не запускаем без экспериментов, которые показывают, становится ли пользователям лучше. Стандартная продолжительность экспериментов – 2 недели. Система контролируемых экспериментов состоит из системы TDI- и A/B-тестов, а также экспериментальных экземпляров рекомендательных и поисковых систем, которые выдают результаты пользователям, для которых включен эксперимент.
Работа систем на ML связана с постоянным расчётом признаков, при каждом изменении данных о резюме, вакансии, действии пользователя, изменении его местоположения. Многие эксперименты связаны с тем, что мы добавляем или изменяем признаки и метапризнаки. Действий пользователя становится всё больше, а метапризнаки, особенно нейросетевые – всё более ресурсоёмкими, экспериментов – тоже всё больше, например, за Q2 в поиске проверили 67 продуктовых гипотез, в среднем по 3 эксперимента на каждую. Но чтобы быстрее повышать качество выдач и расти, нужно ещё больше экспериментов, и по количеству, и по ресурсоёмкости.
Раньше мы могли себе позволить, для упрощения системы, пересчитывать для каждого экспериментального экземпляра системы и те признаки, которые в нём изменились, и те, которые не изменились, по сравнению с другими экземплярами, экспериментальными и production. Но в последнее время это стало для нас узким местом, ограничивающим количество экспериментов, особенно со сложными (нейросети) и быстрыми (поведение, гео) признаками. Теперь мы сделали, чтобы каждый признак считался только один раз. В результате, сэкономили примерно 40% ресурсоёмкости подсистем, считающих признаки, и сможем улучшать систему быстрее, ну или хотя бы с той же скоростью. В запусках сделали 2-недельный перерыв, но это, даже если брать только последние 3 запуска, того стоило. Пользуйтесь на здоровье!
Ссылка на классическую статью про трансформеры и картинка, пожалуй, самой большой проблемы с ними в production – для привлечения внимания. https://jalammar.github.io/illustrated-transformer/
Это что касается этой недели. А на прошлой и позапрошлой у нас был перерыв в продуктовых запусках. Дело не в моём отпуске, а в том, что мы оптимизировали и перезапустили саму систему экспериментов. В поиске мы почти ничего не запускаем без экспериментов, которые показывают, становится ли пользователям лучше. Стандартная продолжительность экспериментов – 2 недели. Система контролируемых экспериментов состоит из системы TDI- и A/B-тестов, а также экспериментальных экземпляров рекомендательных и поисковых систем, которые выдают результаты пользователям, для которых включен эксперимент.
Работа систем на ML связана с постоянным расчётом признаков, при каждом изменении данных о резюме, вакансии, действии пользователя, изменении его местоположения. Многие эксперименты связаны с тем, что мы добавляем или изменяем признаки и метапризнаки. Действий пользователя становится всё больше, а метапризнаки, особенно нейросетевые – всё более ресурсоёмкими, экспериментов – тоже всё больше, например, за Q2 в поиске проверили 67 продуктовых гипотез, в среднем по 3 эксперимента на каждую. Но чтобы быстрее повышать качество выдач и расти, нужно ещё больше экспериментов, и по количеству, и по ресурсоёмкости.
Раньше мы могли себе позволить, для упрощения системы, пересчитывать для каждого экспериментального экземпляра системы и те признаки, которые в нём изменились, и те, которые не изменились, по сравнению с другими экземплярами, экспериментальными и production. Но в последнее время это стало для нас узким местом, ограничивающим количество экспериментов, особенно со сложными (нейросети) и быстрыми (поведение, гео) признаками. Теперь мы сделали, чтобы каждый признак считался только один раз. В результате, сэкономили примерно 40% ресурсоёмкости подсистем, считающих признаки, и сможем улучшать систему быстрее, ну или хотя бы с той же скоростью. В запусках сделали 2-недельный перерыв, но это, даже если брать только последние 3 запуска, того стоило. Пользуйтесь на здоровье!
Ссылка на классическую статью про трансформеры и картинка, пожалуй, самой большой проблемы с ними в production – для привлечения внимания. https://jalammar.github.io/illustrated-transformer/
jalammar.github.io
The Illustrated Transformer
Discussions:
Hacker News (65 points, 4 comments), Reddit r/MachineLearning (29 points, 3 comments)
Translations: Arabic, Chinese (Simplified) 1, Chinese (Simplified) 2, French 1, French 2, Italian, Japanese, Korean, Persian, Russian, Spanish 1, Spanish…
Hacker News (65 points, 4 comments), Reddit r/MachineLearning (29 points, 3 comments)
Translations: Arabic, Chinese (Simplified) 1, Chinese (Simplified) 2, French 1, French 2, Italian, Japanese, Korean, Persian, Russian, Spanish 1, Spanish…
Forwarded from data.csv (Алексей Смагин)
Wall Street Journal выпустили увлекательное видео о том, как работают алгоритмы тиктока.
Они натренировали несколько десятков ботов с разными интересами, чтобы те смотрели определённые видео, и выяснили, что тиктоку хватает от 40 минут до 2 часов, чтобы построить персональную и удивительно точную ленту рекомендаций, основанную на том, что смотрит пользователь.
У алгоритма есть не очень приятная особенность. Тикток будет показывать вам не те видео, которые вам нравятся, а те видео, которые вы будете смотреть.
В некоторых случаях тикток может стать триггером для мрачных состояний — например, одного бота WJS натренировали для того, чтобы смотреть грустные видео, и вскоре его лента на 93% стала лентой депрессивных роликов.
Смотрите исследование:
https://youtu.be/nfczi2cI6Cs
Они натренировали несколько десятков ботов с разными интересами, чтобы те смотрели определённые видео, и выяснили, что тиктоку хватает от 40 минут до 2 часов, чтобы построить персональную и удивительно точную ленту рекомендаций, основанную на том, что смотрит пользователь.
У алгоритма есть не очень приятная особенность. Тикток будет показывать вам не те видео, которые вам нравятся, а те видео, которые вы будете смотреть.
В некоторых случаях тикток может стать триггером для мрачных состояний — например, одного бота WJS натренировали для того, чтобы смотреть грустные видео, и вскоре его лента на 93% стала лентой депрессивных роликов.
Смотрите исследование:
https://youtu.be/nfczi2cI6Cs