Для начала хочу сказать, что на платформе Яндекс.Диалогов есть страничка, посвящённая проектированию навыков. На этой странице написано, что одним из самых сложных этапов создания навыка является разработка сценария. В этой оценке я абсолютно согласен с Яндексом и именно об этом я хочу сегодня поговорить, в надежде облегчить самому себе (и другим) дальнейшие разработки. Итак, поехали!
Что такое сценарий навыка. Проектирование любого навыка начинается с разработки сценария. Сценарий навыка — это план, в котором прописаны все возможные события и диалоги, их последовательность и содержание. Чтобы было понятнее о чём идёт речь, давайте сравним сценарий навыка с другими сценариями.
Самыми простыми вариантами сценариев являются киносценарии или сценарии каких-нибудь театральных спектаклей. Их можно описать как набор выстроенных в строго определённом порядке сцен (включая декорации, а также действия и реплики актёров в этих сценах). Отсюда, собственно, и само название — сценарий — набор сцен. При этом каждую логически обособленную сцену можно назвать эпизодом. В целом, все эти сценарии можно описать линейным алгоритмом смены эпизодов.
Сценарий компьютерной игры немного сложнее, поскольку здесь добавляется вариативность. Развитие сюжета (смена эпизодов) зависит действий игрока. Алгоритм такого сценария уже не будет линейным, скорее его можно представить древовидной структурой. Эпизодов много, но количество эпизодов, которые будут отыграны, как и порядок их следования заранее точно не определён.
Теперь посмотрим, что представляет собой сценарий навыка для Алисы:
- Здесь, также, как и в других сценариях, есть главные действующие лица. Их трое — человек (пользователь), скрипт навыка (сторонний веб-сервис) и Алиса (веб-сервис Яндекса).
- Человек и скрипт навыка обмениваются репликами в режиме диалога. Но репликами они обмениваются не непосредственно друг с другом, а через посредника — Алису. Причём как Алиса подклеивает к сообщениям человека кучу своей служебной информации, так и скрипт навыка подклеивает к своим сообщениям служебную информацию, предназначенную Алисе. То есть получается как бы два диалога в одном: человек <-> скрипт навыка + Алиса <-> скрипт навыка.
- Сценарий навыка, также, как и сценарий компьютерной игры, имеет нелинейный сюжет.
- Сценарий навыка также можно разделить на эпизоды. Например, эпизодом можно считать каждое логически обособленное событие обмена репликами человека со скриптом навыка и сопряжённые с этим событием действия скрипта.
- Во время каждого эпизода могут происходить ошибки, поэтому каждый эпизод должен содержать их обработчик.
Вообще говоря, делить сценарий навыка на эпизоды можно по разному, но с точки зрения программирования удобнее делить так, чтобы каждый новый эпизод начинался с реплики пользователя и заканчивался реакцией на неё скрипта навыка. Тогда шаблон обработки каждого эпизода со стороны скрипта будет таким: «получение реплики пользователя (с приклеенной служебной информацией от Алисы) -> анализ полученной информации -> реакция (ответная реплика и/или действия)». Если мы хотим продолжать диалог, то обработка каждого эпизода должна заканчиваться отправкой пользователю ответной реплики, так как именно это и определяет переход к следующему эпизоду, — к ожиданию новой реплики пользователя.
Общение с пользователем вообще говоря имеет некоторую сложность. Дело в том, что мы (разработчики навыка) не знаем заранее реплики пользователя, так же как и пользователь не читал наш сценарий и не знает, что ему делать для достижения намеченных целей. Как быть? Нужно просто предположить, что пользователь будет вести себя логично и строить реплики навыка таким образом, чтобы подсказывать пользователю возможные варианты его реплик. Скажем, если мы задаём пользователю какой-то вопрос, то он либо должен содержать в себе варианты ответов, либо предполагать односложные ответы, типа «да» или «нет».
И сразу же отметим второй момент. А если пользователь всё же ответит не так как мы предполагали? Такой вариант тоже всегда нужно учитывать. В этом случае веб-сервис может просто сообщить пользователю, что он этот ответ не понял (не знает что делать дальше) и попросить ответить по другому. Или можно вообще прекратить диалог (впрочем, это уже не очень вежливо).
Математическая модель сценария. С тем, что такое сценарий более или менее разобрались, теперь давайте подумаем как его описать и посчитать. На мой взгляд, главные задачи математической модели: облегчить визуальное восприятие связи всех эпизодов друг с другом, а также упростить анализ и последующее программирование. С этой точки зрения, опять же по моему мнению, для описания сценария идеально подойдёт теория графов.
В этом случае сценарий можно представить как направленный (ориентированный) граф, в каждой вершине которого располагается отдельный эпизод. Каждый переход от одной вершины к другой можно представить как результат реакции веб-сервиса на произошедшие в исходящей вершине события: обработка реплики пользователя, служебной информации от Алисы, возникшие ошибки. Каждое ребро можно подписать причиной, по которой происходит переход в указанном направлении, а также репликой скрипта навыка, сопровождающей указанный переход. Скажем, если в рассматриваемом эпизоде веб-сервис получил ответ пользователя на ранее заданный вопрос, то исходящие ребра можно подписать ответами пользователя и новыми вопросами скрипта, сопровождающими переход в каждом из возможных направлений.
Теперь давайте немного над нашей моделью поразмышляем.
Ну, во-первых, у нашего графа только один вход. Когда пользователь называет Алисе активационную фразу — она запускает навык, при этом отправляя на указанный разработчиком webhook сообщение с установленным признаком новой сессии (по нему скрипт навыка понимает, что начался новый диалог с пользователем). Это единственное условие, указывающее на начало нового диалога, поэтому и вершина входа всего одна. В остальном описывающий этой вершиной эпизод полностью соответствует шаблону: «получение реплики пользователя (с приклеенной служебной информацией от Алисы) -> анализ полученной информации -> реакция (ответная реплика и/или действия)». Давайте в дальнейшем на каждой схеме закрашивать вход красным цветом для наглядности.
Синим цветом будем закрашивать выходы графа. Попадание в такую вершину означает, что диалог уже закончен, предыдущей реакцией была отправка сообщения с признаком конца сессии. В соответствующих эпизодах не ожидается продолжение диалога, поэтому их не нужно заканчивать отправкой реплики пользователю.
Отмеченный ранее момент, когда пользователь отвечает не так, как мы предполагали, и мы просим его ответить ещё раз, теперь означает, что в каждой вершине нашего графа, исключая вход и выходы, должна быть петля.
Ну и напоследок небольшая картинка на тему того, как может выглядеть граф сценария навыка. Для примера опишем графом простейший навык, который будет спрашивать, любит ли пользователь огурцы или помидоры и, в зависимости от ответа, сообщать, что у любителей противоположного овоща нет вкуса.
На этом, пожалуй всё. Теперь у нас есть всё необходимое чтобы начать разрабатывать свой собственный навык. Этим мы в следующий раз и займёмся, — начнём разрабатывать свой собственный навык управления устройствами умного дома. У Алисы уже есть встроенные сценарии управления умным домом, но свой собственный навык написать всегда интереснее (тем более свой я писал, когда Алиса такого ещё не умела 🙂