Из табл. 2.2 видно, что различные части анализируемого текста соответствуют различным шаблонам.
Наша задача выбрать шаблон, который описывает весь текст наиболее точно. Для этого был взят эвристический способ, при котором верным шаблоном является шаблон, границы текста которого наиболее широки. Исходя из этого результирующим шаблоном в нашем примере будет шаблон SKF. В рамках процесса получения ответа на вопрос указанная утилита LSPL будет вызываться дважды: в первый раз для определения должности сотрудника, во второй - для анализа заданного вопроса.
Студентам заранее не известны должности сотрудников, работающих в данном филиале. Поэтому студент может назвать должность не так, как она может быть заложена в системе. Эту проблему решает словарь синонимов. Каждый список синонимов представлен в виде ЛСШ. Утилита получает на вход все списки синонимов (соответствующие шаблоны) всех должностей в выбранном филиале, после чего они вместе с запрашиваемой должностью подаются на вход утилите. Утилита в свою очередь возвращает шаблон, которому соответствует запрашиваемая должность. Если утилита не возвращает ничего, пользователю возвращается сообщение о том, что сотрудник с такой должностью не работает в фирме.
Когда определен сотрудник, к которому адресован вопрос, из базы данных выбираются все компетенции, которыми располагает данный сотрудник. Далее названия шаблонов всех компетенций, вместе с заданным студентом вопросом, подаются на вход утилите. Утилита возвращает шаблон той компетенции, о которая была поставлена в соответствие заданному вопросу. Если такой шаблон найден, студент получат ответ, привязанный к найденному шаблону. Если утилита не вернула ни шаблона, студенту возвращается сообщение о том, что сотрудник не знает ответа на заданный вопрос. Такой алгоритм позволяет определить студенту как факт работы сотрудника в отделении, так и компетенции этого сотрудника. Для более наглядного представления работы алгоритма, были построены IDEF0 диаграмма (Рис 2.3.) и диаграмма последовательностей (Рис 2.4.)
Рисунок 2.3. IDEF0 диаграмма алгоритма
Рисунок 2.4. Диаграмма последовательностей алгоритма
2.4 Определение бизнес-процессов
Определим основные процессы, в которых будет задействована система. Поскольку предполагается, что студенты в начале игры знают только названия филиалов и не имеют список сотрудников, то студенты должны сами их определить. Было решено, что студенты будут определять, существует ли такой сотрудник в филиале в ходе постановки вопросов виртуальному собеседнику. Таким образом, для студентов виртуальный собеседник задействован в двух процессах: определение существования сотрудника в филиале и постановка самого вопроса виртуальному собеседнику относительно филиалов фирмы «ОбалдеИТ».
Перейдем к диаграмме прецедентов. Всего в системе будет два актора: студент, задающий вопросы собеседнику и администратор, поддерживающий систему. Определим прецеденты системы, после чего построим диаграмму, которая представлена на Рис. 2.5.
1. Название: Постановка вопроса системе
Акторы: Студент
Описание: Студент заходит в систему под своим именем и паролем, указывает сотрудника и задает вопрос системе.
2. Название: Определение существования сотрудника в филиале
Акторы: Студент
Описание: Студент заходит в систему под своим именем и паролем, указывает сотрудника и задает вопрос системе. Если такой сотрудник существует, он даст ответ на вопрос, либо ответит, что это не в его компетенции. Если такого сотрудника нет, система сообщит об этом.
3. Название: Редактирование компетенций сотрудников филиала
Акторы: Администратор
Описание: Администратор заходит в интерфейс администрирования системой, выбирает филиал, затем одного из сотрудников этого филиала. Перед администратором открывается список всех компетенций данного филиала, в котором уже указаны те, компетенции, которыми располагает выбранный сотрудник. Администратор может удалить существующие компетенции или добавить новые из списка.
4. Название: Просмотр заданных вопросов системе.
Акторы: Администратор
Описание: Администратор заходит в интерфейс администрирования, затем открывает окно заданных вопросов системе. Там он может увидеть информацию, какому сотруднику, в каком филиале и в какое время был задан вопрос, и какой ответ на него был дан.
Рисунок 2.5. Диаграмма активностей
Теперь, когда были определены прецеденты системы, была построена диаграмма активностей. На рисунке 2.6 представлена диаграмма последовательностей обращения к системе. На диаграмме обращения к системе показаны все возможные варианты реакции системы на действия пользователя: если пользователь указал сотрудника фирмы, который не работает в ней, если пользователь задал вопрос сотруднику, на который он не знает ответа или если пользователь не был идентифицирован системой в момент обращения к ней.
Рисунок 2.6. Диаграмма последовательностей
2.5 Проектирование системы
Теперь, когда были определены процессы, которые должна автоматизировать система, и была выбрана реализация, было начато проектирование приложения. Были определены сущности, которые будут в системе:
1. Филиал.
Свойства:
А) Имя. Тип - строковый
Описание: У каждого филиала свои уникальные характеристики такие как месторасположение, количество и комплектация ЭВМ, количество сотрудников и их квалификация.
2. Сотрудник.
Свойства:
А) Имя. Тип строковый.
Б) Название шаблона. Тип строковый.
Описание: Каждый из сотрудников филиалов фирмы «ОбалдеИТ» обладает своим набором компетенций. В зависимости от этих компетенций определяется, сможет ли сотрудник ответить на поставленный вопрос или нет. Поскольку ранее было решено, что система будет основана на лексико-синтаксических шаблонах, то у сотрудника было определено свойство «Название шаблона», в котором будет содержаться название того шаблона, который бы однозначно определял сотрудника.
3. Компетенция.
Свойства:
А) Название шаблона. Тип - строковый.
Б) Текст ответа. Тип - строковый.
В) Должность сотрудника
Описание: Небольшая область знаний, которой обладает сотрудник, прикрепленный к филиалу.
4. Запись о вопросе.
Свойства:
А) Время. Тип - DateTime
Б) Заданный вопрос. Тип - строковый
В) Имя сотрудника. Тип - строковый
Г) Ответ на вопрос. Тип - строковый
Описание: Поскольку было решено собирать данные о заданных вопросах, была введена сущность, которая бы отображала эти данные. Для этого она хранит точную дату и время заданного вопроса, точную формулировку самого вопроса, а также название сотрудника, которое было введено в текстовом поле. Эти данные помогут в дальнейшем пополнять и корректировать существующие шаблоны.
Диаграмма ERD представлена на Рис 2.7
Рисунок 2.7. ERD диаграмма
Ранее говорилось, что компетенции сотрудников филиалов могут пересекаться, а значит, ответ на один и тот же вопрос могут дать несколько сотрудников сразу. Поэтому было решено сделать связь типа «многие ко многим» между сущностями «Сотрудник» и «Компетенция».
Глава 3. Разработка системы
В этой главе будет подробно описан процесс разработки приложения, его базы данных и взаимодействие с утилитой для сопоставления текста с лексико-синтаксическими шаблонами.
3.1 Инструментальные средства разработки
Определим стек технологий для разработки веб-приложения виртуального собеседника. Было решено разрабатывать приложение на платформе .Net с использованием фреймворка Asp.Net для разработки сайта. Основным языком разработки является C#, однако помимо этого используются языки: HTML для описания веб-страниц, XML для задания конфигурации приложения и LSPL для задания лексико-синтаксических шаблонов.
Далее будут описаны основные инструменты, которые потребуются при разработке собеседника:
1. Яндекс словарь. Как ранее было сказано, в данной статье описан способ реализации собеседника, который не требует большого объема входной выборки. Однако исходная выборка для более широкой работы системы искусственно увеличивается за счет словаря синонимов. Однако, этот словарь нельзя использовать непосредственно во время использования, поскольку предоставляемое API имеет ежедневное ограничение на количество запросов.
2. LSPL. LSPL (Lexico-Syntaxic Pattern Language) - язык, предназначенный для формального описания конструкций русского языка с целью их представления в системах извлечения информации из текстов. К сожалению разработчики не предоставили dll файл для использования его в системе, таким образом инструмент используется через утилиту с помощью запуска bat файла. Стоит отметить, что для этого компонента нет актуальной документации, поэтому учиться его использовать придется в процессе разработки.
3. LemmaSharp. LSPL шаблоны требуют на вход слова в начальной форме. Для решения этого этапа потребовалась отдельная библиотека.
4. MS SQL. Как было написано выше, Яндекс словарь имеет ограничение на количество ежедневных запросов. Для того, чтобы во время работы не обращаться к словарю за синонимами, было решено получить их ранее и хранить их в базе данных.
3.2 Разработка базы данных
Для хранения данных для приложения было решено создать базу данных на основе SQL Server с названием ObaldeitChatBot. Под каждую из сущностей, описанных в предыдущей главе, была создана таблица в базе данных, а также дополнительные поля, которые служат уникальными идентификаторами и внешними ключами для других таблиц. Схема базы данных представлена на Рис 3.1.
Рисунок 3.1. Схема базы данных
3.3 Подготовка файла с входными данными
Для корректной работы системы потребуется заполнить базу данных. С предыдущих игр, где за каждого сотрудника отвечал преподаватель, сохранились файлы, содержащие вопросы студентом и ответы каждого сотрудника. Информация из этих файлов была объединена и структуризирована к виду: название филиала, должность сотрудника, вопрос, ответ.
Стоит отметить, что от игры к игре в некоторых филиалах менялись сотрудники или точная формулировка их должностей, поэтому перед исправлением объединенного файла была создана матрица принадлежностей сотрудников к филиалам (Рис 3.2.). Исходя из созданной матрицы, наименования должностей сотрудников филиалов приводилось к единому виду. Помимо наименований должностей сотрудников, менялись и их компетенции, поэтому для организации зон ответственности сотрудников была создана матрица зон ответственности сотрудников (Рис 3.3.).
Рисунок 3.2. Матрица принадлежностей сотрудников к филиалам
После того, как были определены зоны ответственности и наименования должностей сотрудников, было решено написать небольшую подпрограмму, проверяющую корректность сформированного файла. Эта программа проверяет, верно ли введено название филиала, наименование должности сотрудника, а также прикреплен ли сотрудник с указанной должностью к филиалу. Если какое-то из условий не совпадает, программа выдает номер строки с ошибкой. После нескольких проверок файла и исправления ошибок, файл был приведен в вид, пригодный для наполнения базы данных. Код валидации файла приведен ниже:
Рисунок 3.3. Матрица зон ответственностей сотрудников
private void ValidateFile(object sender, RoutedEventArgs e)
{
var filePath = GetExcelFilePath();
if (filePath == null)
return;
Excel.Application xlApp = new Excel.Application();
Excel.Workbook xlWorkbook = xlApp.Workbooks.Open(filePath);
Excel._Worksheet xlWorksheet = xlWorkbook.Sheets[1];
Excel.Range xlRange = xlWorksheet.UsedRange;
var errorsList = new List<int>();
using (var db = new ObaldeitChatBotEntities())
{
for (int i = 2; i < xlRange.Rows.Count; i++)
{
string subsidiary = xlRange.Cells[i, 1].Value2.ToString();
string employee = xlRange.Cells[i, 2].Value2.ToString();
string question = xlRange.Cells[i, 2].Value2.ToString();
if (!db.Subsidiary.Select(s => s.title).Contains(subsidiary))
{
Console.WriteLine("Строка " + i + " содержит невалидное название филиала");
}
if (!db.Employee.Select(s => s.name).Contains(employee))
{
Console.WriteLine("Строка " + i + " содержит невалидное название сотрудника");
}
if (question.Contains("\n"))
{
Console.WriteLine("Строка содержит непечатные символы: " + i);
}
if (!db.Employee.Include("Subsidiary").ToList().Any(emp => emp.name == employee && emp.Subsidiary.title == subsidiary))
{
Console.WriteLine(i + " - Сотрудник не работает в филиале");
}
}
}
xlWorkbook.Close();
xlApp.Quit();
}
3.4 Наполнение базы данных
После того, как база данных была спроектирована, следует её наполнить из созданного ранее файла. Для этого потребовалась дополнительная подпрограмма, поскольку объем работ слишком велик для ручного выполнения. Поэтому было решено создать несколько подпрограмм для наполнения базы данных и генерации шаблонов.
Процесс наполнения базы данных был разбит на несколько этапов. На первом этапе вручную в базе данных было наполнено несколько таблиц, данные из которых будут нужны для следующих этапов. Для проверки входного файла и дальнейшего заполнения таблицы с компетенциями были заполнены следующие таблицы: Subsidiary (филиал), Employee (Сотрудник), EmployeePattern (Шаблоны сотрудника). Первые две таблицы были заполнены исходя из матрицы принадлежностей сотрудников к филиалам. Шаблоны должностей созданы, используя словари синонимов. Помимо этого, была заполнена таблицы PartOfSpeech (Часть речи), которая понадобится для получения синонимов каждого слова для вопроса. Данные для этой таблицы были взяты из документации по языку LSPL (Рис 3.4.). Там указаны все поддерживаемые части речи и их перевод на английский язык. API словаря синонимов к каждому из слов возвращает его часть речи, что поможет после для составления шаблонов, используя эту таблицу.
Следующим этапом было заполнение таблицы с синонимами слов задаваемых вопросов. Для получения синонимов был использован словарь синонимов компании Яндекс. Ранее было задумано получать синонимы во время работы программы и генерировать шаблоны динамически. Однако Яндекс словарь ограничивает количество запросов в день, а на все запросы, которые посыпаются поверх допустимого лимита, словарь возвращает сообщение об ошибке. Поэтому было решено заранее сгенерировать синонимы и шаблоны.