Сколько диалогов может реализовывать программное обеспечение

Обновлено: 28.06.2024

Если вы исполняли рассмотренные выше программы на компьютере, то почувствовали определенное неудобство при работе с машиной. Во-первых, непонятно, когда машина начинает ожидать ввода данных, какие данные и в каком порядке нужно вводить (это ведь можно и забыть). Во-вторых, результаты получаются в виде чисел на экране, без всяких пояснений их смысла. Ясно, что люди между собой так не общаются.

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

Прежде чем начать составление программы, нужно продумать сценарий такого диалога.

Например, составим сценарий работы программы, вычисляющей сумму двух целых чисел. На экране компьютера последовательно должны появляться следующие строки (для примера предположим, что будем вводить числа 237 и 658):

Введите первое слагаемое: А = 237
Введите второе слагаемое: В = 658
А + В = 895
Пока!

Здесь курсивом записаны символы, которые выводит компьютер по программе, а прямым жирным шрифтом - символы, вводимые пользователем.

Любой вывод на экран происходит по оператору вывода, записанному в программе.

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

Вот программа, которая реализует наш сценарий:

Program Summa;
var А, В : integer;
begin write ('Введите первое слагаемое: А = ');
readln(A);
write('Введите второе слагаемое: В = ');
readln(В);
writeln;
writeln('A + В = ', А+В) ;
writeln('Пока!')
end.

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

Еще обратите внимание на оператор writeln без списка вывода. Он обеспечивает пропуск строки на экране.

Пример программирования диалога

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

Вариант 1:
Ты вчера был болен. Измерь-ка температуру! Сообщи, какая у тебя температура: 36.5
Ты здоров, дружок! Можешь идти в школу.
Желаю успехов!

Вариант 2:
Ты вчера был болен. Измерь-ка температуру!
Сообщи, какая у тебя температура: 37.3
Ты еще болен! Раздевайся и ложись в постель.
Поправляйся, дружок!

Алгоритм этой программы содержит ветвление. Идея алгоритма состоит в том, что значение температуры ребенка сравнивается с величиной нормальной температуры человека: 36,6 °С. И если у ребенка температура выше, то он нездоров. Вот соответствующий алгоритм на АЯ:

алг НЯНЬКА
вещ Т
нач вывод "Ты вчера был болен. Измерь-ка температуру!"
вывод "Сообщи, какая у тебя температура:
ввод(Т)
если Т> 36.6
то вывод "Ты еще болен! Раздевайся и ложись в постель."
вывод "Поправляйся, дружок!"
иначе вывод "Ты здоров, дружок!
Можешь идти в школу."
вывод "Желаю успехов!"
кв
кон

По этому алгоритму получается следующая программа на Паскале:

Program NANNY;
Var T: real;
begin writeln( 'Ты вчера был болен. Измерь-ка температуру! ');
write ( 'Сообщи, какая у тебя температура: ');
readln(T);
if T>36.6 then begin
writeln ( 'Ты еще болен! Раздевайся и ложись в постель. ');
writeln( 'Поправляйся, дружок! ')
end
else begin
writeln('Ты здоров, дружок! Можешь идти в школу. ') ;
writeln( 'Желаю успехов! ')
end
end.

Обратите внимание на два момента: во-первых, перед словом else ни в коем случае нельзя ставить точку с запятой; во-вторых, в записи и при вводе вещественных чисел целая и дробная части числа отделяются десятичной точкой.

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

1. Что обозначает понятие "диалоговый характер программы"?

2. Какими средствами программируется диалог между пользователем и компьютером?

3. Что обозначает понятие "дружественный интерфейс"?

4. Выполните на компьютере все программы, приведенные в данном параграфе.

5. Постройте алгоритм и составьте программу, по которой будет реализован следующий сценарий: компьютер запрашивает номер дня недели, после ввода компьютер сообщает название этого дня. Например, если ввели 1, то выведется фраза "Это понедельник" и т. д.

Аннотация: Лекция посвящена изучению работы с диалогами. Приводятся многочисленные примеры, а также рассматриваются принципы работы с графическими файлами.

Цель лекции

Изучение стандартных диалогов и компонента-контейнера изображений TImage .

Диалоги

В любой большой программе есть диалоги.

Диалоги - это стандартные системные окна, предназначенные для получения информации от пользователя. В Lazarus диалоги - невизуальные (невидимые пользователю) компоненты, работа которых приводит к выводу на экран стандартных диалоговых окон операционной системы.

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

TOpenDialog и TSaveDialog

Диалоги TOpenDialog и TSaveDialog предназначены, как нетрудно догадаться из их названия, для открытия и сохранения файлов:

Изучать работу диалогов мы с вами будем сразу на конкретных примерах. Чтобы не делать лишней работы, воспользуемся проектом MyNotebook из прошлой лекции, который вы должны были сохранить в папку 14-01. Если вы помните, в том проекте для хранения текста мы использовали файл MyText.txt, что не очень удобно - а вдруг пользователю захочется работать со многими файлами, а не только с одним? Вот как раз для этого нам и понадобятся два этих диалога.

Итак, откройте Lazarus. Если у вас открылся новый проект (или предыдущий), закройте его командой Файл -> Закрыть. Далее, командой Файл -> Открыть найдем и откроем проект MyNotebook (для этого нужно указать файл MyNotebook.lpi или MyNotebook.lpr). Обратите внимание: только что мы воспользовались стандартным диалогом открытия файла!

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

Со свойствами разобрались, остался метод. Метод этот - Execute .

Execute вызывает стандартное диалоговое окно , и дает пользователю сделать выбор. Если пользователь сделал свой выбор, то Execute вернет True . Если пользователь отказался делать выбор и закрыл окно, не указав файла, метод вернет False .

Настроим наш TOpenDialog :

Теперь займемся фильтром. Выделите свойство Filter и щелкните по кнопке "…" справа от него. Откроется редактор фильтров, который мы заполним следующим образом:

Когда вы нажмете "ОК", Lazarus в свойстве Filter сгенерирует следующий фильтр:

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

Теперь, когда мы настроили наш диалог открытия файлов OD, займемся кодом. Если вы помните, то загрузка текста из файла у нас происходила при нажатии кнопки "Читать", то есть, bRead . Щелкните дважды по этой кнопке, и вы попадете на код её события OnClick . Приведу текст этого события:

Помните, мы вначале проверяли, существует ли этот файл , и затем, в зависимости от результата, предпринимали либо одно, либо другое действие. Так вот, с диалогами этого делать не нужно! Если пользователь выбрал файл , то нет смысла проверять - существует ли он. Конечно, существует, иначе пользователь не смог бы его выбрать. Чувствуете разницу? Новый код события будет таков:

А теперь разница видна? Мы проверяем - если диалог сработал, то мы вызываем метод LoadFromFile , передавая ему в качестве параметра выбранный пользователем файл . Не забывайте, что в свойстве FileName диалога содержится имя выбранного файла вместе с его адресом и расширением. Если же диалог не сработал, то и делать ничего не нужно.

Теперь займемся диалогом сохранения файла TSaveDialog . А тут нам все уже известно - все свойства и метод Execute у него в точности такие, как и у TOpenDialog , разве что текст в свойстве Title другой. Именно поэтому я и дал эти диалоги парой.

Измените имя компонента на SD . Свойства DefaultExt и Filter настройте так же, как в OD. Все остальное остается без изменений. Теперь нам нужно вписать код сохранения файла. Делается это в событии OnClick кнопки "Сохранить". Новый код события такой:

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

TColorDialog

TColorDialog - диалог выбора цвета. Он очень прост. Все, что нам от него нужно, это свойство Color и метод Execute . Если диалог состоялся, то сложное свойство Color будет содержать выбранный пользователем цвет. Этот цвет можно присвоить свойству Color какого-то другого компонента. Например, свойство Color компонента TMemo отображает цвет фона данного компонента. Я, правда, говорил, что не стоит использовать в проекте попугайские расцветки, но наша программа учебная, к тому же мы будем устанавливать только те расцветки, которые выберет пользователь . А потому, установите на форму еще одну кнопку TButton , свойство Name которой переименуйте в bColor , а в свойстве Caption напишите Цвет . Не забудьте снять в свойстве Anchors закрепление к верхнему краю, и установить закрепление к нижнему, как мы делали это с остальными кнопками.

Далее, нам потребуется установить на форму компонент TColorDialog :

Этот компонент , как и все остальные компоненты, невизуальный, поэтому устанавливайте его, куда хотите. Свойство Name диалога переименуйте в CD . Обработчик OnClick для кнопки bColor очень простой:

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

TFontDialog

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

Свойство Name компонента переименуйте в FD . В коде нам потребуется его сложное свойство Font , которое будет содержать тот шрифт , что выбрал пользователь , и которое мы сможем присвоить свойству Font другого компонента.

Также нам потребуется кнопка с именем bFont и текстом Шрифт в свойстве Caption . Не забывайте про привязки кнопок к нижней границе формы. Обработчик OnClick для кнопки такой:

Лекция № 5. Разработка структуры диалога.

- участники диалога должны понимать язык друг друга;

- участники диалога не должны говорить одновременно;

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

Если собеседники обсуждают вопросы, относящиеся к какой-либо специальной области, они должны придерживаться единой терминологии; при объяснении следует сначала пояснить основные термины и понятия.

Очень краткие ответы и слишком большие паузы могут сбить собеседника с толку, а злоупотребление специальными терминами или жаргонизмами вообще может привести к преждевременному завершению беседы.

Перечисленные выше факторы существенно влияют на структуру диалога, т.е. на форму общения.

Т.о. при проектировании диалога, необходимо определить:

- возможный сценарий развития диалога;

Выбор структуры диалога.

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

Диалог на основе меню.

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

Существует несколько основных форматов представления меню на экране:

- список объектов, выбираемых прямым указанием, либо указанием номера (или мнемонического кода);

- меню в виде блока данных;

- меню в виде строки данных;

- меню в виде пиктограмм.

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

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

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

Меню в виде пиктограмм представляет собой множество объектов выбора, разбросанных по всему экрану; часто объекты выбора содержат графическое представление вариантов работы.

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

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

Диалог на основе экранных форм.

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

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

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

Поскольку эта структура имеет последовательную, а не древовидную организацию, она в меньшей степени подходит для работы в режиме выбора вариантов. Еще одной областью применения экранных форм является задание параметров запроса в базах данных. Этот механизм иногда называют запросом по образцу ( Query by Example ).

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

Диалог на основе командного языка.

Структура диалога на основе командного языка столь же распространена, что и структура типа меню. Она очень часто используется в операционных системах. Исторически это первая из реализованных структур диалога.

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

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

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

Диалог должен управлять данными. В интерфейсах на основе командного языка это достигается с помощью составных командных строк, где команда предшествует списку параметров (входным данным). Параметры в списке можно задавать в одной из двух форм – позиционной и ключевой.

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

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

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

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

Выбор подходящей структуры диалога на основе таблицы выполняется следующим образом.

4. Подсчитать число совпадений для каждого типа диалога.

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

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

Содержание

Диалоговые системы (англ. conversational agents, CAs) — компьютерные системы, предназначенные для общения с человеком. Они имитируют поведение человека и обеспечивают естественный способ получения информации, что позволяет значительно упростить руководство пользователя и тем самым повысить удобство взаимодействия с такими системами.

Диалоговую систему также называют разговорным искусственным интеллектом или просто ботом.

Диалоговая система может в разной степени являться целеориентированной системой (англ. goal/task-oriented) или чат-ориентированной (англ. chat-oriented). Как правило, чат-ориентированные системы, в отличие от целеориентированных, поддерживают большое количество доменов, но не способны различать много вопросов в рамках кажного из них.

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

Этапы обучения общего кодера (блок 3):

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

Обучение блоков 4 и 5:

предобучение для каждой задачи,
тонкая настройка на всех специфичных для задач данных.

Блоки 6 и 7 обучаются на всех специфичных для задач данных.

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

Классический метод построения целеориентированных систем заключается в использовании цепочки модулей (конвейера), которая изображена на рисунке 2.

Обычно после распознавания именованных сущностей выполняется заполнение слотов (англ. slot filling), в ходе которого каждая найденная сущность приводится к своей нормальной форме с учетом ее типа и множества возможных значений. Заполнение слотов позволяет не учитывать морфологию сущности при дальнейшей ее обработке. Простейшим подходом к нормализации сущностей является поиск с использованием расстояния Левенштейна. После определения типа сущности, она сравнивается с другими сущностями того же типа из базы данных. В качестве нормальной формы выбирается та, до которой расстояние наименьшее, либо можно выбрать несколько сущностей с наименьшим расстоянием и предоставить выбор пользователю (такой подход также применим для исправления опечаток).

Для получения численного представления текста используются различные языковые модели: Word2Vec, ESIM, GPT, BERT. Каждой определяется свой способ представления слов или их последовательности для наиболее точного извлечения смысловых значений. С хорошей языковой моделью достаточно около 100 примеров для хорошей классификации намерения [4] .

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

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

Описание каждой части:

Intent Network. Кодирующая сеть, которая преобразует последовательность токенов [math] w_0^t, w_1^t, \ldots, w_N^t [/math] в вектор [math] \mathbf_t [/math] . В качестве вектора [math] \mathbf_t [/math] может выступать скрытый слой LSTM-сети [math] \mathbf_t^N [/math] :
[math] \mathbf_t = \mathbf_t^N = \operatorname(w_0^t, w_1^t, . w_N^t) [/math]

Belief Tracker. В реализации используется RNN-сеть, на вход которой поступает предобработанная фраза пользователя. Дает распределение вероятностей [math] \mathbf
_s^t [/math] по всем значениям определенного слота [math] s [/math] .

Database Operator. Выполняет запрос к базе данных по сущностям [math] \ < \operatorname\mathbf
_s^t \> [/math] и возвращает вектор [math] \mathbf_t [/math] , где единицей отмечается та запись (сущность в БД), которая соответствует запросу.

Policy network. Объединяет системные модули. Выходом является вектор [math] \mathbf_t [/math] , который представляет системное действие. Распределение вероятностей для каждого слота [math] \mathbf
_s^t [/math] пребразуется в вектор [math] \mathbf<\hat p>_s^t [/math] , который состоит из трех компонент: суммарная вероятность, вероятность, что пользователь выразил безразличие к слоту, и вероятность, что слот не был упомянут. Также вектор [math] \mathbf_t [/math] сжимается в one-hot-вектор [math] \mathbf<\hat x>_t [/math] , где каждая компонента определяет количество подходящих записей.
[math] \mathbf_t = \tanh(W_ \mathbf_t + W_ \mathbf<\hat p>_t + W_ \mathbf<\hat x>_t), [/math]
где матрицы [math] W_ [/math] , [math]W_ [/math] и [math] W_ [/math] — параметры, а [math] \mathbf<\hat p>_t = \bigoplus \mathbf<\hat p>_s^t [/math] — конкатенация.

Generation Network. Генерирует предложение, используя вектор действия [math] \mathbf_t [/math] и генератор языка. Предложение содержит специальные токены, которые заменяются на сущности из базы данных по указателю.

Данную архитектуру также называют сквозной (англ. end-to-end trainable), так как на данных обучается каждая ее часть. Модель с данной архитектурой можно обобщить на намерения, которые не наблюдались во время обучения.

Детерминированность,
свободное расширение,
интерпретируемость.

Самостоятельно обучается,
не нужно думать о структуре разговора.

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

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

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

Системы с ограниченными ответами (англ. retrieval/example-based) по последовательности фраз выдают наиболее подходящий ответ из списка возможных. Преимуществом таких систем является то, что ответы строго контролируются: можно удалить нежелательные шутки, нецензурные или критикующие выражения.

Первая фраза пользователя попадает в модуль инициализации, который обеспечивает приветствие пользователя и извлечение его имени. Имя пользователя используется менеджером диалога, чтобы инициализировать вектор истории диалога. Если пользователь не известен системе (его имя отуствует в Vocabulary Learning), то система инициализирует историю случайным вектором из хранилища историй. Когда инициализация заканчивается, система спрашивает пользователя, чего он хочет.

Модель с такой архитектурой можно обучить на субтитрах фильмов. Данные для русского языка можно найти на Толоке [7] [8] .

AliMe Assist — помощник для пользователей магазина AliExpress. Его архитектура представлена на рисунке 5. Серым цветом выделены блоки, где используются методы машинного обучения. Система состоит из 3 подсистем: поиск информации или решения, выполнение задачи для клиента и простое общение в чате. Для извлечения намерения вопрос [math] q [/math] проверяется на соответствие шаблонам при помощи бора (англ. trie-based pattern matching). Если соответствие найти не удалось, то вопрос передается классификатору, построенному на сверточной сети. На вход сети подаются вектора слов вопроса и семантических тэгов, которые относятся к нему и контексту (предыдущему вопросу). Для получения векторного представления используется FastText. Выбор CNN-сети вместо RNN основан на том, что первая сеть учитывает контекстную информацию слов (слова перед и после текущего слова) и работает быстрей. Точность классификации 40 намерений составляет 89,91%.

Xiaolce — чат-бот, развиваемый китайским отделением Microsoft. Состоит из множества навыков, которые делятся на эмоциональные и рациональные. Имеется навык для комменирования картинок или сочинения по ним стихов. Сценарии диалога делятся на персональные и социальные. Бот старается установить эмоциональную связь с пользователем, чтобы продлить диалог с ним.

Microsoft Cortana — виртуальный голосовой помощник. Состоит из можества навыков, натренированных на конкретные задачи. В отличие от классической архитектуры, где выбирается подходящий навык, здесь текст проходит через все навыки, после чего выбирается подходящий ответ. Каждый навык использует контекст (результаты обработки предыдущей фразы), сформированный всеми навыками. При таком подходе требуется больше ресурсов, но он позволяет существенно увеличить точность. Схематично процесс обработки фразы пользователя представлен на рисунке 6.

Яндекс Алиса — виртуальный голосовой помощник от компании Яндекс. Относится к классу чат-ориентированных систем, но имеет множество навыков, каждый из которых может быть представлен в виде целеориентированной системы. Алиса запускает навык по его активационной фразе. Фактически навык является веб-сервисом, который реализует DM и NLG модули классической архитектуры. При помщи платформы Яндекс Диалоги разработчики могут создавать свои навыки и монетизировать их, но перед публикацией навык проходит обязательную модерацию. Распознавание голоса выполняется сервисом SpeechKit.

Сири — виртуальный помощник компании Apple. Является неотъемлемой частью iOS и доступна для большинства устройств, выпускаемых компанией. Поддерживает широкий спектр пользовательских команд, включая выполнение действий с телефоном, проверку основной информации, планирование событий и напоминаний, управление настройками устройства, поиск в интернете, взаимодействие с приложениями. Приспосабливается к каждому пользователю индивидуально, изучая его предпочтения в течение долгого времени.

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

Основывается на таких библиотеках как TensorFlow, Keras и PyTorch. Включает множество компонентов, каждый из которых решает отдельную задачу диалоговых систем. Имеется модель для распознавания именованных сущностей, намерений, обработки истории диалога, анализа поведения пользователя и другие. Поведение агента диалоговой системы определяется набором навыков, каждый из которых строится из модулей. Когда агент получает фразу пользователя, специальный менеджер решает, какому навыку передать ее для обработки. Схема ядра представлена на рисунке 7. Пример использования на языке Python:

Лучшие модели по качеству отслеживания состояния диалога (англ. dialogue state tracking):

Модель	Точность связок	Точность слотов	Особенности
CHAN	52.68	97.69	Использование контекстной иерархической сети внимания, динамическое регулирование весов различных слотов во время обучения.
SAS	51.03	97.20	Применение механизма внимания к слотам, разделение информации слотов.
MERET	50.91	97.07	Обучение с подкреплением.

Качество определяется по двум метрикам: точность слотов (англ. slot accuracy) — запрошенный слот верный, и точность связок (англ. joint goal accuracy) — каждый слот в стостоянии верный. Для оценки по данному криетрию обычно используется набор данных MultiWOZ.

Читайте также: