The EU's AI regulation plan
The EU launched its plan to regulate AI, with draft rules and definitions. As with the DSA and DMA, and GDPR before, this is the beginning of a multi-year process of argument, lobbying and amendment. Also like GDPR, it contains some very odd ideas about the technology and industry structure that suggest the drafters have never really listened to anyone in the market they plan to regulate, and it will be full of unintended consequences.
There are certainly real policy questions around AI. Much like databases, we worry what bad people could do with it and we worry about mistakes. We worry what happens if it works and we worry what happens if it doesn't work. Machine learning offers plenty of scope for both, with face recognition on one hand and AI bias and the inscrutable nature of ML models on the other.
The problem is that we don't have a general law regulating databases - we have laws addressing specific questions. A law on consumer credit is not the same as a law on heath records. AI techniques will be part of every single piece of software - writing a law to cover all of that seems like the wrong level of abstraction. Meanwhile, you could write a law saying you're not allowed to have bugs, but would that have stopped Arizona keeping people in prison after their release date because the computer couldn't handle new sentencing rules? Should that have been handled by a database regulator, or the legal system? This is like trying to write a single law covering 'cars', that covers drunk driving, emissions standards, parking, and the tax treatment of highways. Link
The EU launched its plan to regulate AI, with draft rules and definitions. As with the DSA and DMA, and GDPR before, this is the beginning of a multi-year process of argument, lobbying and amendment. Also like GDPR, it contains some very odd ideas about the technology and industry structure that suggest the drafters have never really listened to anyone in the market they plan to regulate, and it will be full of unintended consequences.
There are certainly real policy questions around AI. Much like databases, we worry what bad people could do with it and we worry about mistakes. We worry what happens if it works and we worry what happens if it doesn't work. Machine learning offers plenty of scope for both, with face recognition on one hand and AI bias and the inscrutable nature of ML models on the other.
The problem is that we don't have a general law regulating databases - we have laws addressing specific questions. A law on consumer credit is not the same as a law on heath records. AI techniques will be part of every single piece of software - writing a law to cover all of that seems like the wrong level of abstraction. Meanwhile, you could write a law saying you're not allowed to have bugs, but would that have stopped Arizona keeping people in prison after their release date because the computer couldn't handle new sentencing rules? Should that have been handled by a database regulator, or the legal system? This is like trying to write a single law covering 'cars', that covers drunk driving, emissions standards, parking, and the tax treatment of highways. Link
KJZZ
Whistleblowers: Software bug keeping hundreds of inmates in Arizona prisons beyond release dates
According to Arizona Department of Corrections whistleblowers, hundreds of incarcerated people who should be eligible for release are being held in prison because the inmate management software
Forwarded from tldr_tany (Таня Савельева)
Безопасность и интерпретируемость моделей
https://www.arthur.ai/product
https://www.robustintelligence.com
https://arxiv.org/pdf/2010.10596.pdf
🔎В чем понт
В прошлом посте я писала про модели машинного обучения, которые по нашим характеристикам решают, как нам можно поступать, а где нужно доработать: кредитный скоринг, персонализированное ценообразование и тд. Авторы говорили, что очень важно делать модели интерпретируемыми, понимать, когда что-то идет не так, и не менее важно обьяснять людям решение ML. Кажется это следующий виток в области: с тем, что делать разобрались, теперь нужно контролировать качество, следить за безопасностью и понимать, как это работает (хаха). В этом посте я расскажу про 2 молодых стартапа, которые уже поднимают деньги на теме безопасного и интерпретируемого AI и помогают крупным компаниям.
🦄Что за компании, где я их нашла, сколько денег подняли
В последнее время часто смотрю CBInsights - это аггрегатор информации про компании, стартапы. Там выходят классные, новости, аналитика. Ребята каждый год несколько раз обновляют подборку AI-100 - туда они включают самые promising AI-компании. Выбирают по количеству поднятых инвестиций, профилю инвестора, анализу новостей, рыночному потенциалу, конкурентам, силе команды и новизне в технологиях. Из 100 компаний 2021 года подборки 2 было про интерпретируемость AI: Robust Intellegence и Arthur. На A-round (привлечение денег на начальных этапах, инвесторы требуют масштабируемости, обычно не требуют прибыли) подняли 14 и 12 млн$. Это достаточно много для этого раунда, хотя бывает и больше (китайский стартап грузоперевозок из той же подборки на A-round поднял 220 млн$). Компании основаны в 2018 и 2019 году, то есть совсем молодые.
🍒 Что они делают?
Arthur состоит из трех частей: мониторинги моделей, их аналитика и улучшатель моделей. Все 3 вещи можно смотреть и настраивать в их интерфейсе, к посту прикреплены скрины вкладок в максимально доступном качестве :). На этапе мониторинга Arthur смотрит на производительность модели, аллертит, если что-то изменяется, подсвечивает дрейф данных (если распределение в данных изменилось относительно истории). На втором этапе аналитики тулза выделяет bias, понимает, какие фичи и как влияют на итоговое предсказание и подбирает наиболее информативную метрику для оценки модели. Далее предлагается модель для починки поломок в модели (очень было бы интересно узнать как конкретнее он работает), экспорт отчетов, плюс можно моделировать для пользователя контрфактуалы (не просто информирование о том, что кредит не выдали, а обьяснение, что сделать по-другому в следующий раз, чтобы кредит дали). Arthur выпустил статью-обзор на эту тему, в ссылках наверху.
Robust Intellegence больше сфокусирован на безопасности, а не интерпретируемости (скрин с описанием работы системы в прикрепе). В тулзе есть модуль "профилактического” выявления уязвимости: в данные вносятся небольшие изменения и наблюдается поведение моделей. Также через модель прогоняются потециально проблемные данные: из которых признаки выкинуты или заполнены странными значениями, плохо классифицирующиеся обьекты. Также Robust Intellegence ищет проблемные данные и создают правило, которое помогает избежать ошибок модели на этом срезе.
🥂Что в итоге
Интересное и новое направление в исследованиях и стартапах. Оптимистично настраивает относительного будущего ML: data science не умрет, решив все задачи, а выйдет на новую ступень развития, где появляются все более глубокие проблемы и вызовы.
https://www.arthur.ai/product
https://www.robustintelligence.com
https://arxiv.org/pdf/2010.10596.pdf
🔎В чем понт
В прошлом посте я писала про модели машинного обучения, которые по нашим характеристикам решают, как нам можно поступать, а где нужно доработать: кредитный скоринг, персонализированное ценообразование и тд. Авторы говорили, что очень важно делать модели интерпретируемыми, понимать, когда что-то идет не так, и не менее важно обьяснять людям решение ML. Кажется это следующий виток в области: с тем, что делать разобрались, теперь нужно контролировать качество, следить за безопасностью и понимать, как это работает (хаха). В этом посте я расскажу про 2 молодых стартапа, которые уже поднимают деньги на теме безопасного и интерпретируемого AI и помогают крупным компаниям.
🦄Что за компании, где я их нашла, сколько денег подняли
В последнее время часто смотрю CBInsights - это аггрегатор информации про компании, стартапы. Там выходят классные, новости, аналитика. Ребята каждый год несколько раз обновляют подборку AI-100 - туда они включают самые promising AI-компании. Выбирают по количеству поднятых инвестиций, профилю инвестора, анализу новостей, рыночному потенциалу, конкурентам, силе команды и новизне в технологиях. Из 100 компаний 2021 года подборки 2 было про интерпретируемость AI: Robust Intellegence и Arthur. На A-round (привлечение денег на начальных этапах, инвесторы требуют масштабируемости, обычно не требуют прибыли) подняли 14 и 12 млн$. Это достаточно много для этого раунда, хотя бывает и больше (китайский стартап грузоперевозок из той же подборки на A-round поднял 220 млн$). Компании основаны в 2018 и 2019 году, то есть совсем молодые.
🍒 Что они делают?
Arthur состоит из трех частей: мониторинги моделей, их аналитика и улучшатель моделей. Все 3 вещи можно смотреть и настраивать в их интерфейсе, к посту прикреплены скрины вкладок в максимально доступном качестве :). На этапе мониторинга Arthur смотрит на производительность модели, аллертит, если что-то изменяется, подсвечивает дрейф данных (если распределение в данных изменилось относительно истории). На втором этапе аналитики тулза выделяет bias, понимает, какие фичи и как влияют на итоговое предсказание и подбирает наиболее информативную метрику для оценки модели. Далее предлагается модель для починки поломок в модели (очень было бы интересно узнать как конкретнее он работает), экспорт отчетов, плюс можно моделировать для пользователя контрфактуалы (не просто информирование о том, что кредит не выдали, а обьяснение, что сделать по-другому в следующий раз, чтобы кредит дали). Arthur выпустил статью-обзор на эту тему, в ссылках наверху.
Robust Intellegence больше сфокусирован на безопасности, а не интерпретируемости (скрин с описанием работы системы в прикрепе). В тулзе есть модуль "профилактического” выявления уязвимости: в данные вносятся небольшие изменения и наблюдается поведение моделей. Также через модель прогоняются потециально проблемные данные: из которых признаки выкинуты или заполнены странными значениями, плохо классифицирующиеся обьекты. Также Robust Intellegence ищет проблемные данные и создают правило, которое помогает избежать ошибок модели на этом срезе.
🥂Что в итоге
Интересное и новое направление в исследованиях и стартапах. Оптимистично настраивает относительного будущего ML: data science не умрет, решив все задачи, а выйдет на новую ступень развития, где появляются все более глубокие проблемы и вызовы.
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