Робот с чувством юмора

Немецкие ученые создали робота с чувством юмора, но ужасно бестактного

На первый взгляд, детище ученых из Аугсбургского университета (Германия) выглядит забавной поделкой в сфере искусственного интеллекта. Но отношение к нему меняется, стоит роботу заговорить – создатели сознательно убрали ограничения приличия на шутки, генерируемые новым ИИ. Машина под названием «Irony Man» (Ироничный Человек. Отсылка к «Iron Man» — Железному Человеку Тони Старку. Прим. ред. Техкульт) понятия не имеет, когда остановиться в своих высказываниях, чтобы не обидеть собеседника.

«Irony Man» создавался не с целью потроллить людей — напротив, баварские ученые попробовали подступиться к решению сложнейшей задачи: как научить ИИ подавать важную информацию мягко, разнообразно и с юмором. Это крайне нужно для следующего поколения ИИ, которые будут уже не просто давать ответы на вопросы, как нынешние голосовые помощники, а смогут разговаривать с пользователем.

Хороший тренер знает, когда пошутить над спортсменом, когда упрекнуть, а когда и применить сильные выражения – для достижения искомой цели. «Irony Man», в теории, умеет все это делать, он удачно заменяет строгие казенные формулировки на ироничные замечания.

В тестированиях же на добровольцах «Irony Man» получил очень неоднозначные оценки. Все испытуемые отметили, что робот лучший собеседник, чем старые версии ИИ. Но вот шутит он почему-то обычно невпопад, а извиняться, подмечая реакцию людей на свои высказывания, не пытается вовсе. Как следствие, веселый и конструктивный разговор может быть испорчен всего одной фразой, а робот не понимает, что он наделал.

Источник

Японцы изобрели робота с чувством юмора

ИА SakhaNews. Специалисты японской компании «Хитати» представили свою новую разработку — робота EMIEW2, который, по их утверждениям, умеет поддержать с человеком короткий остроумный разговор, а также понять реакцию собеседника на свои шутки, сообщает ИТАР-ТАСС.

На демонстрации красно-белый андроид проявил своё чувство юмора весьма специфически. На вопрос сотрудника «Хитати» о том, сколько всего в этой компании занято людей, он немедленно сказал: «У нас есть два лебедя». После этого, определив, что его собеседник находится в замешательстве, робот добавил: » Я шучу. У нас работает около 800 человек«.

По словам одного из разработчиков Хисаси Икэды, робот ведет разговор без предварительно запрограмированного текста, выбирая ключевые слова из вопроса собеседника. Уловив, о чём именно его спрашивают, он спонтанно выдает ответ. Робот может понимать также невербальные знаки, например, кивки в знак согласия.

Шутки у андроида, может быть, несколько странные, признает Икэда. Но важнее, считает он, что робот способен уловить ответную реакцию человека на свои слова. А это уже серьёзный шаг вперед в робототехнике.

Поделиться в соцсетях

Добавить комментарий:

ЧТО ВЫ ДОЛЖНЫ ЗНАТЬ, ЕСЛИ ХОТИТЕ ОСТАВИТЬ КОММЕНТАРИЙ К СТАТЬЕ

Комментарии на портале SakhaNews удаляются, если они содержат:

1. Призывы к войне, свержению существующего строя, терроризму (в т.ч. хакерским атакам), экстремизму.
2. Публичные призывы к сепаратизму, к осуществлению действий, направленных на нарушение территориальной целостности Российской Федерации.
3. Пропаганду фашизма, геноцида, нацизма. Посягательства на историческую память в отношении событий, имевших место в период Второй мировой войны, отрицание фактов, установленных приговором Международного военного трибунала для суда и наказания главных военных преступников европейских стран оси, одобрение преступлений, установленных указанным приговором, а также распространение заведомо ложных сведений о деятельности СССР в годыВторой мировой войны.
4. Разжигание межнациональной, межрелигиозной, социальной розни, грубые высказывания в адрес представителей любых национальностей, рас и вероисповеданий.
5. Пропаганду курения, наркомании.
6. Угрозы физической расправы, убийства, сексуального насилия.
7. Описание средств и способов суицида, любое подстрекательство к его совершению.
8. Переход на личности, оскорбления в адрес официальных и публичных лиц (в т.ч. умерших), грубые выражения, оскорбления и принижения других участников комментирования, их родных или близких.
9. Заведомо ложную, непроверенную, клеветническую информацию.
10. Нарушают права несовершеннолетних лиц.
11. Оскорбления журналистов и других сотрудников SN, авторов, модераторов, администрации сайта, руководства издания, читателей «SN», грубые высказывания о самом портале.
12. Присвоение чужих имен и фамилий, комментирование от чужого имени.
13. Распространение персональных данных, нарушение тайны переписки и связи.
14. Брань (в т.ч. измененное написание мата).
15. Дублирование комментариев (флуд).
16. Бессмысленные комментарии (флейм).
17. Комментарии, не относящиеся к темам статей (офф-топ).
18. Реклама других сайтов (в т. ч. ссылки на другие сайты). Реклама товаров и услуг.
19. Сообщения, оставленные не на русском языке.
20. Сообщения, содержащие более 3000 символов и пробелов.
21. Прочие нарушения законодательства РФ.

Комментарии, нарушающие правила поведения на портае, удаляются без предупреждения. При вторичном размещении уже удалённого сообщения, модератор вправе заблокировать («забанить») пользователя.

Почему вы не можете оставить свой комментарий?

• Администрация портала оставляет за собой право по собственному усмотрению или решению автора закрыть материал для комментирования.
• Возможно, вы попали в черный список.

Источник

Как мы научили робота чувству юмора

В IT-кругах ходит такая шутка, что машинное обучение (machine learning, ML) — это как секс в среде подростков: все об этом говорят, все делают вид, что этим занимаются, но, на самом деле, мало у кого это получается. У FunCorp получилось внедрить ML в главную механику своего продукта и добиться радикального (почти на 40%!) улучшения ключевых метрик. Интересно? Добро пожаловать под кат.

Немного предыстории

Для тех, кто читает блог FunCorp нерегулярно, напомню, что самый успешный наш продукт — UGC-приложение iFunny c элементами социальной сети для любителей мемов. Пользователи (а это каждый четвёртый представитель молодого поколения в США) закачивают или создают прямо в приложении новые картинки или видео, а умный алгоритм выбирает (или, как мы говорим, «фичерит», от слова «featured») лучшие из них и формирует каждый день 7 выпусков по 30-60 единиц контента в отдельную ленту, с которой взаимодействует 99% аудитории. В результате, заходя в приложение, каждый пользователь видит топовые мемы, видео и смешные картинки. Если заходить часто, то лента быстро пролистывается и пользователь ждёт следующего выпуска через несколько часов. Однако если заходить реже, featured-контент накапливается, а лента за несколько дней может вырасти до 1000 элементов.

Соответственно, встала задача: показывать каждому пользователю наиболее релевантный для него контент, сгруппировав интересные лично ему мемы в начале ленты.

За 9 с небольшим лет существования iFunny было несколько подходов к этой задаче.
Сначала попробовали очевидный способ сортировки ленты по количеству смайлов (наш аналог «лайков») — Smile rate. Это было лучше, чем сортировка в хронологическом порядке, но в то же время привело к эффекту «средней температуры по больнице»: мало какой юмор нравится вообще всем, и всегда будут те, кому не интересны (и даже откровенно раздражают) популярные на сегодня темы. А ведь хочется ещё и все новые прикольные шутки из своего любимого мультика увидеть.

В следующем эксперименте попытались учесть интересы отдельных микросообществ: любителей аниме, спорта, мемов с котиками и пёсиками, и т.п. Для этого стали формировать несколько тематических featured-лент и предлагать пользователям выбирать интересующие их тематики, используя тэги и распознанный на картинках текст. Стало в чём-то лучше, но потерялся эффект соцсети: стало меньше комментариев к featured-контенту, которые играли большую роль в вовлечённости (engagement) пользователей. Да ещё по пути к сегментированным лентам растеряли много действительно топовых общепопулярных мемов. «Любимый мультик» посмотрели, а шутки о «последних Мстителях» не увидели.

Поскольку мы уже начали внедрять в наш продукт алгоритмы машинного обучения, о чём делали доклад на нашем собственном митапе, очередной подход захотели сделать с использованием этой технологии.

Решено было попробовать построить рекомендательную систему на основе принципа коллаборативной фильтрации. Этот принцип хорош в случаях, когда у приложения есть очень мало данных о пользователях: немногие указывают при регистрации свой возраст или пол, и лишь по IP-адресу можно предположить их географическое местоположение (хотя и без гадалок известно, что подавляющее большинство пользователей iFunny — резиденты Соединённых Штатов), а по модели телефона — уровень доходов. На этом, в общем-то, всё. Коллаборативная фильтрация работает так: берётся история положительных оценок контента пользователя, находятся другие пользователи с похожими оценками, далее ему рекомендуется то, что уже ранее понравилось тем самым пользователям (с похожими оценками).

Особенности задачи

Мемы — достаточно специфический контент. Во-первых, он весьма подвержен быстро сменяющимся трендам. То содержание и та форма, которые выходили в топ и заставляли улыбаться 80% аудитории ещё неделю назад, сегодня могут вызывать раздражение своей вторичностью и неактуальностью.

Во-вторых, очень нелинейная и ситуационная интерпретация смысла мема. В подборке новостей можно зацепиться за известные фамилии, тематики, которые достаточно стабильно заходят у конкретного пользователя. В подборке кинофильмов можно зацепиться за актёрский состав, жанр и многое другое. Да, за всё это можно зацепиться и в подборке персональных мемов. Но как обидно будет упустить настоящий шедевр юмора, который использует образы или лексику, совершенно не ложащиеся на смысловое содержание!

Наконец, очень большое количество динамически создаваемого контента. В iFunny ежедневно пользователи создают десятки тысяч постов. Весь этот контент необходимо «разгребать» максимально быстро, а в случае персонализированной рекомендательной системы не только отыскивать «бриллианты», но и уметь предсказывать оценку контента самыми разными представителями социума.

Что эти особенности значат для разработки модели машинного обучения? В первую очередь то, что модель постоянно должна быть натренирована на самых свежих данных. На самом старте погружения в разработку рекомендательной системы ещё не совсем понятно, идёт ли речь о десятках минут или о паре часов. Но и то, и другое означает необходимость постоянного ретрейнинга модели, а ещё лучше — онлайн-обучение на непрерывном потоке данных. Всё это — не самые простые задачи с точки зрения поиска подходящей архитектуры модели и подбора её гиперпараметров: таких, которые бы гарантировали, что через пару-тройку недель метрики не начнут уверенно деградировать.

Отдельную сложность составляет необходимость следовать протоколу а/б-тестирования, принятому у нас. Мы никогда не внедряем ничего без предварительной проверки на части пользователей, сравнивая результаты с контрольной группой.

После долгих прикидок было решено стартовать MVP со следующими характеристиками: используем только информацию о взаимодействии пользователей с контентом, обучение модели проводим в реальном времени, прямо на сервере, оснащённом большим объёмом памяти, позволяющим хранить всю историю взаимодействия тестовой группы пользователей за достаточно длинный срок. Время обучения решили ограничить 15-20 минутами, чтобы поддерживать эффект новизны, а также успеть использовать самые свежие данные от пользователей, массово приходящих в приложение во время выпусков.

Модель

Сначала принялись крутить самую классическую коллаборативную фильтрацию с разложением матрицы и обучением на ALS (alternating least square) или SGD (stochastic gradient descent). Но достаточно быстро надумали: а почему бы сразу не стартовать с простейшей нейронной сети? С простой однослойной сетки, в которой только один линейный embedding-слой, и отсутствует накрутка скрытых слоёв, чтобы не закопаться в неделях подбора её гиперпараметров. Немного за гранью MVP? Возможно. Но натренировать такую сетку едва ли сложнее, чем более классическую архитектуру, если имеется оборудование, снаряжённое хорошим GPU (пришлось на него раскошелиться).

Изначально было понятно, что есть только два варианта развития событий: либо разработка даст значимый результат в продуктовых метриках, тогда потребуется копать дальше в параметры пользователей и контента, в дообучение на новом контенте и новых пользователях, в глубокие нейросетки, либо персонализированное ранжирование контента не принесёт ощутимой прибавки и «лавочку» можно прикрывать. Если случится первый вариант, то всё перечисленное придётся докручивать к стартовому Embedding-слою.

Решили остановить свой выбор на Neural Factorization Machine. Принцип её работы следующий: каждый пользователь и каждый контент кодируются векторами фиксированной одинаковой длины — эмбеддингами, которые в дальнейшем обучаются на наборе известных взаимодействий между пользователем и контентом.

В обучающем наборе задействованы все факты просмотра контента пользователями. За положительный фидбек о контенте кроме смайлов было решено считать нажатия на кнопки «поделиться» или «сохранить», а также написание комментария. При его наличии взаимодействие размечается 1 (единицей). Если же после просмотра пользователь не оставил положительного фидбека, взаимодействие размечается 0 (нулём). Таким образом, даже в отсутствии явной шкалы оценок используется explicit-модель (модель с явной оценкой от пользователя), а не implicit, которая учитывала бы только положительные действия.

Implicit-модель тоже попробовали, но она сходу не заработала, поэтому сосредоточились на explicit модели. Возможно, для implicit-модели нужно использовать более хитрые, чем простая бинарная кросс-энтропия, ранжирующие лосс-функции.

Отличие Neural Matrix Factorization от стандартного Neural Collaborative Filtering в наличие так называемого Bi-Interaction Pooling слоя вместо обычного полносвязного слоя, который бы просто соединял эмбеддинг-векторы пользователя и контента. Bi-Interaction слой конвертирует набор эмбеддинг-векторов (в iFunny всего 2 вектора: пользователя и контента) в один вектор путём их поэлементного умножения.

В отсутствии дополнительных скрытых слоёв поверх Bi-Interaction получаем скалярное произведение этих векторов и, добавляя bias пользователя и bias контента, обворачиваем в сигмоиду. Это и есть оценка вероятности положительного фидбека от пользователя после просмотра данного контента. Именно согласно этой оценке ранжируем имеющийся контент перед демонстрацией его на конкретном девайсе.

Таким образом, задача обучения — сделать так, чтобы эмбеддинги пользователя и контента, по которым есть положительное взаимодействие, были близки друг к другу (имели максимальное скалярное произведение), а эмбеддинги пользователя и контента, по которым есть отрицательное взаимодействие, — далеки друг от друга (минимальное скалярное произведение).

В результате такого обучения эмбеддинги пользователей, которые смайлили одно и то же, становятся близки друг к другу сами собой. А это удобное математическое описание пользователей, которое может быть использовано во множестве других задач. Но это уже другая история.

Итак, пользователь заходит в ленту и начинает смотреть контент. При каждом просмотре, смайле, расшаривании и т.п. клиент отправляет статистику в наше аналитическое хранилище (о котором, если интересно, мы писали ранее в статье Переход с Redshift на Clickhouse). По дороге мы отбираем интересующие нас события и отправляем их на ML-сервер, где они сохраняются в памяти.

Раз в 15 минут на сервере запускается переобучение модели, после завершения которого новая статистика пользователя начинает учитываться в рекомендациях.

Клиент запрашивает очередную страницу ленты, она формируется стандартным образом, но по дороге список контента отправляется в ML-сервис, который сортирует его согласно весам, выданным обученной моделью для данного конкретного пользователя.

В результате пользователь видит сначала те картинки и видео, которые, по мнению модели, ему будут наиболее предпочтительны.

Внутренняя архитектура сервиса

Сервис работает по HTTP. В качестве HTTP-сервера используется Flask в связке с Gunicorn. Он обрабатывает два запроса: add_event и get_rates.

add_event запрос добавляет новое взаимодействие между пользователем и контентом. Оно складывается во внутреннюю очередь и затем обрабатывается в отдельном процессе (в пике до 1600 rps).

get_rates запрос рассчитывает веса для user_id и списка content_id согласно модели (в пике порядка сотни rps).

Основной внутренний процесс — Dispatcher. Он написан на asyncio и реализует основную логику:

1. обрабатывает очередь add_event запросов и сохраняет их в огромном хешмапе (за неделю 200М событий);
2. пересчитывает модель по кругу;
3. раз в полчаса сохраняет новые события на диск, при этом удаляет из хешмапа события старше недели.

Обученная модель помещается в shared memory, откуда её вычитывают HTTP-воркеры.

Результаты

Графики говорят сами за себя. 25%-ный рост относительного числа смайлов и почти 40%-ный — глубины просмотров, который мы видим на них — это результат раскатки нового алгоритма на всю аудитории по окончании А/Б-теста 50/50, то есть реальный прирост относительно базовых величин был ещё почти вдвое больше. Поскольку iFunny зарабатывает на рекламе, то рост глубины означает пропорциональный рост доходов, который, в свою очередь, позволил нам достаточно спокойно пережить кризисные месяцы 2020 года. Рост числа смайлов переходит в большую лояльность, а значит, — меньшую вероятность отказа от приложения в будущем; лояльные пользователи начинают заходить в другие секции приложения, оставлять комментарии, общаться между собой. А главное, мы не только создалинадёжную основу для улучшения качества рекомендаций, но и заложили фундамент для создания новых функций, основанных на колоссальном количестве анонимных поведенческих данных, накопленных нами за годы работы приложения.

Заключение

Сервис ML Content Rate — результат большого количества мелких доработок и улучшений.
Во-первых, в обучении стали учитывать и незарегистрированных пользователей. Изначально по ним были вопросы, так как они априори не могли оставлять смайлы — наиболее частый фидбек после просмотра контента. Но вскоре стало понятно, что эти опасения были напрасны и закрывали очень большую точку роста. Много экспериментов делается с конфигурацией обучающей выборки: помещать в неё бОльшую долю аудитории или расширять временной интервал учитываемых взаимодействий. В ходе этих экспериментов выяснилось, что не только количество данных играет значительную для продуктовых метрик роль, но и время обновления модели. Зачастую прирост качества ранжирования тонул в лишних 10-20 минутах на пересчёт модели, из-за чего приходилось отказываться от новшеств.

Многие, даже самые небольшие доработки, дали результаты: либо улучшили качество обучения, либо ускорили процесс обучения, либо экономили память. Например, была проблема с тем, что взаимодействия не влезали в память, — пришлось их оптимизировать. Кроме того, код модифицировался и появилась возможность засунуть в него, например, больше взаимодействий на пересчёт. Также это привело к улучшению стабильности сервиса.

Сейчас ведётся работа над тем, чтобы эффективно использовать известные параметры пользователя и контента, сделать инкрементную быстро дообучаемую модель, а также появляются всё новые гипотезы для будущих улучшений.

Если вам интересно узнать о том, как мы развивали этот сервис и какие ещё улучшения сумели внедрить — пишите в комментарии, через некоторое время мы будем готовы написать вторую часть.

Источник