Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

в своей БД вместо текста — стало понятно, что модель наконец работает правильно: сервер создал сообщение, доставил его, сохранил метаданные, но так и не узнал содержимое.

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

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

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

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

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

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

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Как все начиналось?

Идея голосового управления исполнительными устройствами появилась отнюдь не в эпоху научно-технического прогресса — напротив, желание отдавать голосовые команды неодушевленным предметам испытывали уже дальние предки, что находит свое отражение в сказках народов мира: «Сим-сим, откройся», «Горшочек, не вари!», «Свет мой, зеркальце, скажи…». Знакомые с детства фразы демонстрируют не только наличие самой идеи голосового управления, но и существование концепции протокола взаимодействия с исполнительными устройствами. Это случилось задолго до появления первых гальванических элементов, не говоря уже об электронике.

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

Что касается распознавания речи, то эксперименты в этой области велись как минимум с середины XX века. В 1952 году Bell Telephone Laboratories (Bell Labs), исследовательское подразделение American Telephone and Telegraph Company (AT&T), представило Audrey — машину, способную «понимать» человеческую речь (она могла распознавать цифры от 0 до 9). Это стало возможным благодаря успехам в решении смежной задачи — синтеза речи, достигнутом в первой половине XX века в стенах той же Bell Labs. Как синтез речи, так и ее распознавание в те времена основывались на представлении звуков в виде формант — набора резонансных частот, создаваемых голосовыми связками человека в процессе разговора. Распознавание производилось путем сравнения формант говорящего с предварительно записанными образцами. Ожидаемо, устройство работало точнее, когда буквы называл тот человек, чей голос использовался при записи образцов.

В 1986 году компанией International Business Machines (IBM) была разработана печатная машинка с голосовым управлением Tangora. В основу ее работы было положено использование cкрытой модели Маркова (Hidden Markov model): устройство рассчитывало вероятность того, может ли обрабатываемый звук являться частью какого-либо из известных ему слов. Изменение подхода к распознаванию речи позволило существенно увеличить словарный запас устройства, который составил 20 тысяч слов. Функционировала машинка на базе компьютера IBM PС/AT, а для работы с новым пользователем ей требовалось 20-минутное обучение.

В 1987 году компания Worlds of Wonder выпустила в продажу кукол Julie. Куклы понимали 16 слов и были способны вести диалог посредством встроенного синтезатора речи. У кукол также были датчики освещенности и температуры, показания которых использовались для формирования ответных реплик, что позволяло сделать диалоги более осмысленными. Julie нужно было обучать воспринимать голос конкретного человека, как и в случае с печатными машинками Tangora.

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

Что происходит сегодня?

Принципы работы систем распознавания речи основаны на физике звука и практически не изменились с середины XX века. В современных исследованиях звуковой сигнал представляется как последовательность числовых значений звукового давления, измеренных через равные промежутки времени. Распознавание речи сводится к разбиению этого сигнала на фрагменты, преобразованию их из временной области в частотную и сравнение ее с эталонными образцами.

Методы обработки сигнала зависят от конкретной задачи. Например, при распознавании коротких голосовых команд можно обойтись без разбиения на отрезки, если подобрать подходящую корреляционную функцию и установить минимальный порог схожести. Однако такой подход не всегда дает точные результаты. Так, в мобильном телефоне Siemens C55 упрощенный алгоритм голосового управления мог путать похожие по звучанию слова, например, «свет» и «считать».

Несмотря на кажущуюся простоту, системы голосового управления широко применяются и сегодня. Более того, существует ряд решений, представляющих собой готовые модули, с помощью которых разработчики электроники могут реализовать голосовое управления своими устройствами без дополнительных трудозатрат. В качестве примеров подобных решений — Voice Recognition Module (аналогичные модули представлены у различных производителей) и Voice Interaction Module от Yahboom Tchnology.

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

Chat GPT и YandexGPT

Chat GPT (Generative pre-trained transformer – генеративный предобученный трансформер) — чат-бот с генеративным искусственным интеллектом, созданный американской научно-исследовательской организацией OpenAI, был выпущен 30 ноября 2022 года. Тогда это был прорыв в сфере искусственного интеллекта, даже несмотря на определенные неточности на старте его работы. Chat GPT писал код, тексты, создавал переводы, давал энциклопедические справки.

YandexGPT — нейросеть российской корпорации “Яндекс”, была выпущена в мае 2023 года. Российские создатели сразу заявили ее как собственную версию ChatGPT в рамках развития языковой модели из семейства YaLM (Yet another Language Model). YandexGPT. На момент старта сеть уже могла редактировать и генерировать тексты, предлагать новые идеи. Разработчики сделали ставку на запоминание контекста: сеть может задавать уточняющие вопросы и генерировать шутки. И даже использовать нецензурные выражения. Хотя создатели российского чат-бота пишут, что стараются быть корректными.

Как пользоваться

ChatGPT можно использовать как отдельную программу. ЯндекGPT встроен в сервис “Алиса” и является одной из его функций. Для этого требуется установка Яндекс Браузера, что усложняет легкость использования. Функции создания текстов и рисования разделены на два разные окна.

Однако в России ChatGPT недоступен, по крайней мере, напрямую. Сейчас появилось много программ-посредников, которые работают на платформе ChatGPT и оформлены по тем же принципам. “Алисой” же можно пользоваться напрямую.

Национальный акцент

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

Что касается “Яндекса” и “Алисы”, то там огромное количество роликов с матом. И люди над этим смеются. На мой вкус, возможность весьма спорная.

Авторские права

ChatGPT работает по американскому законодательству, где вопрос авторства сгенерированного контента определен четко. При использовании ChatGPT авторское право на созданный контент будет принадлежать пользователю. U.S. Copyright Office, признал возможность регистрации произведения, содержащего элементы, созданные человеком, совместно с использованием искусственного интеллекта. При условии, что автор докажет: ИИ являлся лишь инструментом для создания, а существенный вклад остается за человеком.

В России законодательная база в отношении ИИ лишь начинает прорабатываться на государственном уровне. И права на произведение, созданное YandexGPT, довольно размыты. Пока действуют законы, позволяющие лишь косвенно регулировать вопрос об авторском праве на продукты нейронок.

Практические возможности

Для сравнения работы платформ возьмем тему продвижения кофе.

Тексты

Для начала предложим обеим платформам создать короткий текст с шуткой о кофе. Такой текст можно использовать, например, в качестве поста в тематическом тг-канале.

Вот ответ ChatGPT:

Конечно, вот одна из шуток про кофе: “Знаете, почему кофе такой важный на работе? Потому что без него невозможно говорить на одном дыхании до обеда!”

А вот шутка от "Алисы":

Однажды мимо кофейни проходил маленький любопытный зверёк. Заглянул он в окошко и спрашивает: “А что это у вас так вкусно пахнет?” Бариста, недолго думая, отвечает: “Да это мы учим кофе мурлыкать!” Зверёк был заинтригован. “Мурлыкать? А как это?” – спросил он. Бариста улыбнулся и ответил: “А ты приходи завтра и услышишь!” На следующий день зверёк пришел снова и прислушался. А из кофейни доносится громкое и довольное “мур-р-р… мур-р-р…” Так кофе научился мурлыкать, а зверёк стал постоянным клиентом кофейни!

Видео

Зададим один и тот же запрос на изображение двум чатам. Нарисовать фарфоровую чашку на блюдце с горячим кофе у окна.

ChatGPT выдал сразу четыре варианта, “Алиса” в ее функции “Давай нарисуем”(YA Art) – всего один. Для сравнения приведу наиболее похожие визуально варианты.

Вот результат ChatGPT:

А вот YandexGPT:

У “Яндекса” изображение чуть более размыто. Кроме того, есть баг с ручкой.

Задачи

Обоим чат-ботам была предложена задача предложить идеи, как прорекламировать кофе.

Ответ GhatGPT:

Конечно! Вот несколько идей:
1. Видеоролик о процессе обжарки кофе: Создайте видеоролик, показывающий весь процесс от обжарки кофейных зерен до приготовления чашки ароматного кофе. Подчеркните качество и свежесть вашего кофе.
2. Участие в событиях сообщества: Организуйте дегустацию вашего кофе на местных мероприятиях, фермерских рынках или фестивалях. Создайте пространство, где люди могут попробовать ваш кофе и узнать о ваших уникальных методах обжарки и смешивания.
3. Сетевой маркетинг: Постройте программу лояльности для ваших постоянных клиентов и предложите им бонусы за привлечение новых клиентов.
4. Информационный контент: Создайте блог или отправляйте информативные рассылки о кофе, в которых будете делиться новостями из мира кофе, рецептами приготовления и интересными фактами.
5. Социальные сети: Активно взаимодействуйте в социальных сетях, публикуйте креативный контент о вашем кофе, отзывы клиентов, рецепты и вдохновляющие истории.
Надеюсь, эти идеи помогут вам успешно рекламировать ваш кофе!

Ответ Алисы (навык “Давай придумаем”):

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

В целом, оба чат-бота неплохо справились с задачей, но лично мне ответ ChatGPT нравится больше: он содержит приветствие, структурирован и более детален.

Будущее

Обе сети постоянно развиваются.

YandexGPT 2 в октябре прошлого года смогла доказать свой уровень подготовки, “сдав” ЕГЭ по литературе на 55 баллов — это на 15 баллов выше минимального проходного балла в вуз. Для России это первый случай в практике нейросетей. Также с осени прошлого года российская разработка создает короткие пересказы больших видеороликов. что существенно может упростить работу с большими объемами информации. Буквально в конце марта этого года YandexGPT представил третью версию чат-бота. Впрочем, ориентирован он будет преимущественно на бизнес-задачи.

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

В качестве вывода

На мой взгляд, обращаться к помощи ЯндексGPT имеет смысл, если вам нужно решение к задаче, связанной с российским менталитетом. К примеру, обыграть какую-то шутку в тексте или на картинке. ChatGPT, по моему опыту, выигрывает в визуальном качестве и в составлении текстов. Особенно, если вам нужен материал на иностранном языке.

Теперь водители могут строить маршруты и искать места прямо на экранах своих автомобилей.

Поддержка сервисов в Apple CarPlay и Android Auto станут доступны только для пользователей с подпиской «Яндекс.Плюс».

При этом встроенные в «Карты» и «Навигатор» сервисы «Заправки», «Алиса» и «Музыка» с экрана автомобиля работать не будут — этого не позволяют правила CarPlay и Android Auto.

Ими всё так же можно будет воспользоваться со смартфона — для этого на экране автомобиля появится кнопка «Продолжить в телефоне».

Источник: Блог Яндекса

Тосты

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

Для обучения голосового ассистента новому навыку, специалисты «скормили» ему множество текстовых материалов: книг, статей и других документов. Затем функцию довели до ума на примере уже существующих тостов.

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

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

Открытки

Вторая новая функция, которая появилась в Алисе — это создание открыток.

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

Обучение первого алгоритма проходила на готовых новогодних открытках. Это, по словам разработчиков, помогло добиться аутентичности в итоговых рисунках нейросети. К слову, для этой части формирования открыток использовалась архитектура StyleGAN2-ADA.

Для того, чтобы Алиса сделала для вас открытку, её опять же достаточно попросить об этом, произнеся «Алиса, покажи открытку». Поздравление можно как сохранить для себя, так и отправить другу. Если же творчество помощника вам не понравилось, его можно попросить переделать работу. Для этого снова надо попросить Алису показать открытку.

Источник: Блог Яндекса

По словам разработчиков, в основу функции легла нейросеть с архитектурой StyleGAN2. Её созданием занимались специалисты из NVIDIA. Правда, специалисты Яндекс внесли столько изменений в оригинальную технологию, что на основе проделанной работы написали полноценную научную работу. Ознакомиться с ней можно кликнув по ссылке.

На данный момент Алиса может «превратить» пользователя в эльфа/орка/вампира/женщину/мужчину/старика/героя аниме». Планируется ли дополнить этот список в будущем — неизвестно. Доступна новая функция в приложении «Яндекс» и в Яндекс.Браузере для iOS и Android.

Источник: Блог Яндекса

Чтобы создать такую продвинутую экосистему умных устройств, совсем не обязательно штурмовать магазины электроники. Яндекс предоставляет API для интеграции ваших собственных решений через платформу навыков.

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

Как работает такой умный дом?

Чтобы создать умный дом своими руками, потребуется навык Домовёнок Кузя. Через него можно не только контролировать умный дом, но и интегрировать виртуальные устройства напрямую в Яндекс.Алису. Это значит, что вам не придётся постоянно открывать навык, чтобы просто выключить лампочку. С микроконтроллером навык будет связываться через веб-хуки.

Для веб-хуков отлично подходит платформа Blynk — панель управления устройствами на Arduino и Raspberry Pi. Там вы сможете без труда создать графический интерфейс, через который можно будет управлять устройством по Wi-Fi (а ещё по Ethernet, USB, GSM и Bluetooth).

Какие устройства можно интегрировать в умный дом?

Через навык можно взаимодействовать с обширным количеством устройств: лампочки, розетки, шторы, замки, роботы-пылесосы, термостаты, очистители воздуха, кондиционеры и  чайники. Кроме этого, можно переключать каналы на телевизоре (через универсальный пульт) и менять цвета RGB-ламп.

Все устройства имеют базовую пару функций: включение и выключение (открытие и закрытие для штор и замков). Некоторые из устройств могут работать с диапазоном значений (яркость лампы, температура поддержки тепла для чайника).

Аппаратная и программная часть

Для того, чтобы собрать умный дом своими руками, мы будет использовать Wi-Fi модуль ESP8266. Процесс разработки на нём почти не отличается от традиционной разработки на Arduino.

Для начала нужно скачать приложение Blynk из GooglePlay или AppStore и зарегистрироваться в нём. После этого нужно создать новый проект и выбрать соответствующий микроконтроллер. Перед вами появится пустая панель, на которой можно размещать элементы управления. Это могут быть кнопки, иконки, слайдеры, индикаторы, выпадающие списки и многое другое.

После создания проекта на вашу почту придёт токен доступа. Его нужно будет указать в скетче и веб-хуках.

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

Примечание Виртуальные порты в Blynk можно представить как переменные, которые синхронизируются между устройством и сервером.

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

Для этого скетча в панели управления Blynk нужно добавить элемент «Button». В его настройках OUTPUT выставить V0, а режим работы переключить в Switch.

Теперь к указанному порту можно подключать реле. Если всё правильно, то при нажатии на кнопку в панели управления реле будет открываться и закрываться.

Голосовое управление светом не мешает управлению им аппаратно. К микроконтроллеру можно подключить физическую кнопку или выключатель, которые тоже будут включать и выключать свет. Если это необходимо, то изменять состояние виртуального порта можно методом Blynk.virtualWrite(port, value). Тогда изменения будут отображаться и на панели управления.

Примечание При работе с механическими кнопками и выключателями не забывайте про дребезг контактов.

Всё работает? Тогда можете переходить к следующему этапу.

Получение веб-хуков

От Blynk вам потребуется не панель управления, а контроль виртуальных портов через GET-запросы. Вот так выглядит веб-хук на изменение состояния порта:

Чтобы включить виртуальный порт, <value> нужно указать как 1, чтобы выключить — как 0.

Помимо этого, значение с порта можно получить таким запросом:

Настройка навыка «Домовёнок Кузя»

Перейдите на сайт навыка и авторизуйтесь там через Яндекс. Далее жмите на Добавить правило HTTP (GET). Перед вами откроется форма настройки правила.

Активационная фраза — название запроса, которое будет отображаться в списке (например «свет на кухне, включение»). Если вы не планируете контролировать умный дом конкретно изнутри навыка, то больше фраза нигде не понадобится. Поле Ответ Кузи тоже оставляйте пустым. В поле URL вставляете соответствующий веб-хук на включение света (виртуального порта). Остальные параметры можно не изменять. После этого нужно сделать идентичное правило на выключение света.

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

В Правило на включение/выключение из списка выбираете соответствующие запросы. В лампе имеется возможность управления яркостью. Для этого нужно создать ещё одно правило, но значение параметра value установить как {value}. Тогда в запрос будет подставляться число от 0 до 100, которое будет обозначать требуемую яркость. Вам лишь остаётся обработать это значение в скетче.

Примечание Если вы планируете изменять яркость, то параметр value в веб-хуке на включение нужно изменить с 1 на 100.

Настройка Алисы

В приложении Яндекс перейдите в раздел Устройства→Управление устройствами. Нажмите на кнопку «Добавить»→«Другое устройство». В открывшемся списке найдите навык «Домовёнок Кузя».

Авторизуйтесь в нём. Возможно, нужно будет ввести код объединения устройств, указанный в панели управления умным домом. Потом нажмите на Обновить список устройств.

На этом этом этапе вы уже создали умный дом своими руками. Теперь система полностью готова к голосовому контролю. К ней имеет доступ лишь ваш аккаунт. В настройках виртуальных устройств можно расширить доступ на другие аккаунты.

— Алиса, включи свет.

Недавно в Яндекс.Диалогах вышел большой пакет обновлений в формате Dev Preview для разработчиков голосовых приложений.

Среди новых фич:

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

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

Для проекта команда «Яндекса» разработала интерфейс, через который сотрудники отеля управляют всем парком колонок.

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

Alisa встроена в турецкий аналог «Навигатора», она помогает находить адреса, строить маршруты, рассказывать о погоде и ситуации на дорогах. Режим болталки она тоже поддерживает.

Сегодня прошло слушание по иску москвички Алёны Поповой к МВД и ДИТ Москвы. Об иске мы рассказывали в обзоре 7 октября. Попова требовала запретить распознавание людей через городскую систему видеонаблюдения и удалить из базы её фотографию, из-за которой активистку оштрафовали в 2018 году. Если говорить коротко, иск отклонили.

По словам корреспондента «Медиазоны», представительница ДИТ заявила, что департамент не хранит никакой базы для распознавания лиц. Специалисты оперируют камерами и алгоритмом для сопоставления потоков видео с фотографиями от силовиков. Точно так же можно распознавать, к примеру, снежные завалы и мусорные контейнеры, сказала она.

Кажется, нам не хватает юридического понятия распознавания лиц.

Алиса, где ты

В Турции: специалисты «Яндекса» адаптировали Алису для работы в Турции. Это первая зарубежная версия голосовой помощницы. Её зовут Alisa с ударением на последний слог, голос она взяла у турецкой актрисы дубляжа Селяй Ташдоген. Alisa встроена в турецкий аналог «Навигатора», она помогает находить адреса, строить маршруты, рассказывать о погоде и ситуации на дорогах. Режим болталки она тоже поддерживает.

В отелях: сеть Crown Plaza Moscow закупила Яндекс.Станции с Алисой для дорогих номеров. Гость отеля может на время привязать к колонке собственный аккаунт в «Яндексе» или создать временный, который уничтожат при выезде из номера. «Станция» в номере поддерживает стандартные функции: просмотр фильма, прослушивание музыки, таймеры, будильники и прочее. Но кроме этого гость может через Алису передавать персоналу отеля просьбы и поручения, например, заказать уборку или ужин.

Для проекта команда «Яндекса» разработала интерфейс, через который сотрудники отеля управляют всем парком колонок.

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

Нейросети на GitHub

Для музыки: стриминговый сервис Deezer опубликовал на GitHub код инструмента Spleeter. Он разделяет песню на составляющие, вплоть до конкретных инструментов. Spleeter может выделить дорожки с вокалом, партией басов, ударных или пианино. Иногда на них остаются артефакты, с этим пока ничего нельзя сделать. Дорабатывать инструмент и выпускать его как отдельный продукт компания не собирается.

Для видео: на GitHub появился код ML-модели, которая позволяет осветлить видео, снятое почти в полной темноье. Становятся видны даже цвета. Подробного описания нет, разработчик обещает добавить его позже. Зато есть видео — видео ведь всегда интереснее текста:

Гибкая мышка

Microsoft разработала новые модели аксессуаров: лёгкую и компактную беспроводную Mavis Arc Mouse и клавиатуру Kili.

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

На клавиатуре Kili есть специальная клавиша для перехода к Office 365 и недавним документам. В отличие от мышки, клавиатура проводная.

Нейросеть «Яндекса» узнаёт страны по фотографиям. Алгоритм работает так же, как предыдущая версия с российскими городами.

Разработчики использовали свёрточную нейросеть SE-ResNeXt-50. Ей показали подборку фотографий из Яндекс.Карт с указанием стран. ИИ самостоятельно выделил признаки, по которым можно узнать ту или иную страну. Например, Нидерланды алгоритм узнаёт по сочетанию тёмных кирпичных стен и белых контуров на окнах.

Из нейросети сделали игру с «Алисой». Она профи, но и у человека есть преимущества. Во-первых, алгоритм не распознаёт номера машины, флаги, тексты вывесок и дорожных знаков. Во-вторых, подглядывать в Яндекс.Картинки ему нельзя. В-третьих, в игре участвуют только те картинки, которых алгоритм раньше не видел.

Использование голосов

Сейчас голоса доступны только разработчикам команд-навыков для голосового помощника. Пока неясно, смогут ли обычные пользователи выбирать голос «Алисы» или он будет жёстко зависеть от навыка или приложения. Послушать примеры голосов и выбрать подходящий можно в настройках навыка в «Диалогах». Если голос Оксаны используется в Яндекс.Навигаторе, то голос Эркан Явас применяется для озвучивания Яндекс.Новостей. Создатели «Алисы» рекомендуют его для чтения длинных текстов.

Идеи на будущее

Разработчики «Алисы» спросили, какие голоса ещё нужны. От себя они предложили зомби, а в комментариях пользователи уже попросили добавить голоса Дарта Вейдера и Никиты Джигурды. Представитель «Яндекса» Елена Першина ответила, что эти варианты записаны и могут быть использованы в будущем. Как, например, и голос известного советского диктора Юрия Левитана.

В октябре 2018 года «Яндекс» объявил ежемесячный конкурс «Премия Алисы». Для участия в нём нужно разрабатывать навыки для голосового помощника. Первая пятёрка победителей была названа 1 ноября и включала разработчиков обучающих и логических игр, а также «йоги для глаз».

Пятёрка победителей

Организаторы считают, что разработка навыков для голосовых ассистентов только начала развиваться и видят в этом направлении большой потенциал. Компания выплатит 150, 100, 85, 70 и 50 тыс. рублей за 1−5 места соответственно, а список октябрьских победителей таков:

• «Викторина Пандарина». Викторина создана для индивидуальной или коллективной проверки эрудиции.
• Йога для глаз. Программа помогает выполнять зарядку для глаз с учётом предпочтений пользователя.
• Шахматные задачи. Программа обучает игре в шахматы на разных уровнях сложности и даёт подсказки.
• Игра Наоборот. Суть игры заключается в подборе антонимов к словам. Поддерживаются однопользовательский и многопользовательский режимы.
• Кто на картинке. Игра для детей, которая учит отличать животных. Для одной особи предусмотрены разные правильные варианты ответа, например: «кошка», «кошечка».

«Яндекс» запустила ежемесячный конкурс на лучшие навыки для «Алисы» в начале октября 2018 года. Конкурс продлится до конца года, при этом компания будет ежемесячно выбирать 5 лучших решений для голосового помощника, за которые разработчики получат денежные вознаграждения.

Подробнее о NER

Именованные сущности — это все лексические конструкции, описывающие тот или иной объект. Команда «Яндекса» привела в пример ответы на простой вопрос «Алисы» о том, когда надо привезти пиццу:

• завтра;
• послезавтра в 9 утра;
• послезавтра в 9 часов 40 минут;
• через два часа;
• 4 октября в 18 часов;
• в 6 часов вечера.

Предусмотреть все подобные варианты — задача сложная, поэтому разработчики «Яндекса» разбили её на части и научили «Диалоги» распознавать:

• имена — фамилию, имя, отчество, а также разделять имена разных людей;
• местоположение — страну, город, улицу, номер дома, название аэропорта;
• дата и время — абсолютные (5 октября 2018 года, 20:00) и относительные (послезавтра, через два часа);
• числа — десятичные дроби и целые.

Технологию NER можно подключить к любому навыку «Алисы» через Яндекс.Диалоги. Платформа для создания чат-ботов вышла из беты в мае 2018 года, а до того два месяца провела в режиме тестирования.

Подробнее о сертификации

Чтобы пройти сертификацию, необходимо получить оценку специалистов по трем критериям:

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

Преимущества

Компании, прошедшие сертификацию, становятся бизнес-партнерами «Яндекса». Корпорация рекомендует такие агентства и студии клиентам, желающим получить возможности Яндекс.Диалогов для взаимодействия со своей аудиторией, а также дает доступ к тестированию новых функций «Алисы» и «Диалогов».

В марте 2018 года «Яндекс» открыла бета-тестирование платформы «Диалоги», с помощью которой можно создавать чат-ботов на основе «Алисы» и разрабатывать новую функциональность для голосового помощника и других сервисов компании.

Возможности Яндекс.Станции

Устройство сможет проигрывать музыку, находить фильмы в сети, выполнять несложные действия, например, установить будильник или рассказать сказку на ночь. Помимо уже известных функций «Алисы», умная колонка взаимодействует с охранной системой «Гольфстрим». Такая связка позволит управлять домашней сигнализацией.

Перспективы развития

Константин Круглов отметил, что система умного дома будет развиваться вокруг устройства, а не интегрироваться в существующую систему, как на Западе.

По словам Круглова, функциональность Яндекс.Станции будет развиваться и в других направлениях, например, управлении простейшими электронными приборами.

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

Продажи умной колонки на базе голосового помощника «Алиса» стартовали во вторник, 10 июля 2018 года, в музее и магазине «Яндекса». По предварительным данным, первая партия устройств была распродана в первые часы работы магазина.

Новые возможности

Все десять команд разработаны на платформе «Яндекс.Диалоги» и доступны в каталоге «Алисы». А в мобильном приложении «Яндекс.Бета» голосовая помощница с новыми навыками поможет вести счет в играх, подбирать синонимы к словам и давать определения.

Игровые форматы очень популярны в общении с голосовым помощником. Поэтому темой хакатона для первых выпускников «Яндекс.Лицея» стали именно игры для «Алисы». Результаты показали, что знаний, которые школьники получили за время обучения, достаточно, чтобы самостоятельно создать серьёзный проект, которым будут пользоваться тысячи людей.

«Яндекс» представила «Алису» осенью 2017 года. С тех пор голосовая помощница научилась играть, петь песни, управлять компьютером на Windows и диктовать текст.

Большие перспективы

Навык (Диалог) — это некоторая функция, которую умеет выполнять голосовой помощник. Например, сейчас «Алиса» умеет играть в «Города», «гадать» на будущее и читать рэп. Ранее создавать эти модули могли только разработчики «Яндекс», но теперь такая возможность появилась у всего сообщества заинтересованных кодеров.

Взаимодействие с «Алисой» будет происходить через открытую консоль разработчика Now. Писать свои модули можно на любом языке — ограничений авторы площадки на инструменты не накладывают. Навыки для голосового помощника могут быть любого размера — их опубликуют, если они не нарушают законодательство РФ.

Во время тестирования, на которое создатели планируют выделить несколько месяцев, все разработанные навыки после прохождения модерации будут доступны в «Алисе» бета-версии поискового приложения от «Яндекс». После официального релиза все опубликованные в бете функции можно будет заново добавить уже в стабильную версию программы, а также в мобильные браузеры.

По словам представителей компании, платформа Яндекс.Диалоги открывает широкие перспективы для развития бизнеса, что, в свою очередь, может помочь начинающим разработчикам заявить о себе и своих способностях. Такая возможность обусловлена, прежде всего, большой аудиторией «Алисы», которая, по словам аналитиков, растёт с каждым месяцем и уже составляет несколько миллионов активных пользователей ежедневно.

Позже создатели обещают оснастить платформу инструментами для работы и с другими продуктами «Яндекс».

Возможностями «Диалогов» уже начали пользоваться небезызвестные компании. Например, HeadHunter учит «Алису» подбирать подходящие вакансии по критериям и помогать пользователям узнать свою цену на рынке труда. Ознакомиться с основными функциями и ограничениями площадки можно в официальной документации.

Во что сыграем?

Сейчас умный помощник способен играть в «Города» и «Слова», правила которых знакомы каждому из детства. Кроме того, «Алиса» может рассказать невероятный факт, которому пользователь может поверить или сказать, что это ложь. В «Фантастическом квесте» вашей задачей будет спасти ничего не помнящего о своём прошлом космического путешественника. Полный список игр представлен на официальной странице помощника.

Где доступна «Алиса»?

В дополнение к этому, с сегодняшнего дня «Алиса» работает и в мобильной версии Яндекс.Браузера. Запустите его и нажмите на значок с микрофоном, и голосовой помощник в вашем распоряжении. И, конечно, «Алиса» доступна в поисковом приложении компании, а также в бета-версии программы для Windows.

До 25 ноября «Яндекс» добавит ещё семь игр. Для запуска каждой необходимо просто обратиться к голосовому помощнику с фразой: “Алиса, давай сыграем в <название игры>«.

Доступные игры

• «Угадай песню» — назовите строчку из песни на русском языке, а «Алиса» подскажет название трека и исполнителя, строчки из песни, а также предложит прослушать композицию на Яндекс.Музыке;
• «Этот день в истории» — интересные факты из прошлого, произошедшие в этот день;
  
• «Шар судьбы» — получение ответа методом «пальца в небо»;
• «Гадание» — гадание происходит по книге «Мастер и Маргарита», где пользователь задает вопрос и называет номер страницы и строчки произведения. Для запуска игры необходимо обратиться к помощнику при помощи «Алиса, давай погадаем»;
• «Найди лишнее» — игра, в которой пользователю надо найти лишнее слово из 4 предложенных. В случае неправильного ответа «Алиса» объяснит, что именно и почему надо было выбрать.

Немного об «Алисе»

Напомним, что «Яндекс» запустил «Алису» 10 октября 2017 года. На данный момент сервис доступен в приложениях компании для пользователей iOS, Android и в качестве бета-версии для Windows. Помощник умеет работать с большинством сервисов компании, включая Поиск, Карты, Погоду и Музыку. В настоящий момент он может открывать приложения «ВКонтакте» и Instagram по запросу пользователей.

Помощник умеет работать с большинством сервисов компании, включая Поиск, Карты, Погоду и Музыку. Этот список должен расшириться со временем; кроме того, многие компании могут предоставить «Алисе» доступ к своим продуктам. В настоящий момент она может открывать приложения «ВКонтакте» и Instagram по запросу пользователей.

Главным отличием «Алисы» от своих именитых конкурентов Cortana и Siri является её способность общаться с пользователем, не используя ограниченный набор заранее заданных ответов. В этом ассистенту помогают нейронные сети, которые при необходимости позволяют «Алисе» импровизировать, а также учитывать контекст беседы и восстанавливать опущенные части предложений, как это делают люди. В арсенале голосового помощника есть запас интересных историй, сказки и анекдоты для поддержания неформальной беседы.

Распознавание речи, определение значения сказанного и синтез ответов возможен благодаря разработанной в «Яндекс» технологии SpeechKit. «Алиса» обладает голосом актрисы Татьяны Шитовой, озвучивающей персонажей Скарлетт Йоханссон в российском прокате (также в игре «Ведьмак 3: Дикая Охота» её голосом говорит чародейка Йеннифэр из Венгерберга).

По словам разработчиков, «Алиса» способна понимать как детей, так и взрослых — и даже тех, кто говорит по-русски с акцентом. Точность распознавания в SpeechKit сопоставима с уровнем человека. Денис Филиппов, руководитель направления речевых технологий «Яндекса», добавил:

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

Подробнее о том, как устроена «Алиса», можно почитать в блоге компании на Хабрахабре.