|
|
|
# 1 Архитектура сервиса
|
|
|
|
## 1.1 Описание архитектуры приложения
|
|
|
|
Архитектура приложения представляет собой набор микросервисов, общающихся через внутреннюю сеть по протоколам HTTP/REST. Каждый микросервис выполняет определенную задачу – сбор обратной связи, обработка данных одного сервиса Цифрового МИЭМа, предоставление API внешним сервисам. Схема взаимодействия микросервисов представлена на рисунке.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Каждый прямоугольник на рисунке 2 представляет собой отдельный Docker контейнер. Границей приложения является пунктирная линия. Все контейнеры запускаются и управляются через Docker Compose.
|
|
|
|
|
|
|
|
За счет использования различных вариантов docker-compose.yml файлов возможно создание нескольких вариантов конфигураций для запуска приложения. В свою очередь, использование контейнерной виртуализации Docker позволяет снизить количество проблемных ситуаций при развертывании приложения на серверах, так как все приложение работает в изолированной, заранее подготовленной и настроенной виртуальной среде.
|
|
|
|
|
|
|
|
Красным прямоугольником обозначен главный контейнер – «Competence Search». Это HTTP/REST сервер проекта, распространяющий публичный REST API. Он принимает извне поисковые запросы, затем делегирует исполнение запросов микросервисам-обработчикам, собирает их ответ, обрабатывает и выдает результат поиска обратно. Данный микросервис также занимается приемом запросов на сохранение обратной связи, обработку этих запросов он делегирует микросервису «Gtable».
|
|
|
|
|
|
|
|
Фиолетовым прямоугольником обозначен микросервис «Zulip bot». Это чат-бот в корпоративном чате Zulip, который является интерфейсом для взаимодействия с сервисом для обычных пользователей. Данный микросервис получает всю необходимую информацию в процессе взаимодействия с микросервисом «Competence Search» по открытому REST API.
|
|
|
|
|
|
|
|
За счет наличия открытого API, сервис может быть использован и другими сервисами, позволяя интегрировать функционал данного приложения в другие сервисы. Данная особенность отражена на рисунке 12 в виде облака «External service» в правой части.
|
|
|
|
|
|
|
|
В нижней части рисунка располагаются три контейнера. Каждый из них представляет собой микросервис-обработчик, который обрабатывает данные из одного сервиса. Внутри этих контейнеров располагаются два процесса, работающих параллельно в одном контейнере.
|
|
|
|
|
|
|
|
Верхние процессы являются локальными HTTP/REST серверами, которые принимают запрос на поиск по данным своих сервисов от главного сервера по локальному закрытому API, а также возвращают результат. В их оперативной памяти хранится экземпляр модели обработки данных, которая производит поиск.
|
|
|
|
|
|
|
|
Нижние процессы являются программами, которые по заданному расписанию собирают данные с соответствующих сервисов, обрабатывают их, а затем обучают модель на этих данных. По завершении обучения программы отправляют запрос на соответствующий им верхний процесс, сообщая ему, что новая версия модели сохранена в общей файловой системе и может быть загружена в оперативную память. Процессы-серверы получают бинарные файл модели из общей папки внутри контейнера.
|
|
|
|
Такой подход позволяет обеспечить работу обработчиков во время их обучения – сервисы не будут переставать отвечать на запросы во время обновления, так как обновлением занимается отдельный параллельный процесс. Сервис будет недоступен только во время короткого промежутка времени (по сравнению с обучением модели) загрузки модели из файловой системы в оперативную память.
|
|
|
|
|
|
|
|
Зеленый контейнер – микросервис «Gtable». Этот микросервис является HTTP/REST сервером, принимающим данные об отзывах пользователей и записывающим их в специальную Google Таблицу.
|
|
|
|
|
|
|
|
Все контейнеры взаимодействуют друг с другом с помощью REST API. В данной архитектуре существует два типа REST API запросов:
|
|
|
|
- Открытые;
|
|
|
|
- Локальные.
|
|
|
|
|
|
|
|
Запросы открытого типа предоставляет лишь микросервис «Competence Search», так как эти запросы могут быть использованы внешними сервисами. Остальные микросервисы используют только локальные запросы, недоступные извне, так как они являются служебными и служат лишь для работы внутри самого приложения.
|
|
|
|
|
|
|
|
Описанная архитектура приложения позволяет легко добавлять новые сервисы – достаточно написать микросервис-обработчик на подобие уже написанных, а также внести новый сервис в список обработчиков в главном микросервисе «Competence Search». При необходимости также стоит добавить отображение данных нового сервиса в чат-бот.
|
|
|
|
|
|
|
|
## 1.2 Описание алгоритма работы системы
|
|
|
|
Алгоритм работы системы можно описать следующей последовательностью действий:
|
|
|
|
1) Ожидание поискового запроса от чат-бота или внешнего сервиса;
|
|
|
|
2) Получение запроса микросервисом «Competence Search», отправка копий текстового запроса всем микросервисам-обработчикам (в данном случае это обработчики данных сервисов: Zulip, Wiki МИЭМ, Кабинет МИЭМ);
|
|
|
|
3) Параллельное формирование ответных сообщений каждым микросервисом-обработчиком, содержащих префиксы корпоративных почт кандидатов, оценку модели, а также дополнительную информацию (например, имя пользователя в корпоративном чате Zulip);
|
|
|
|
4) Асинхронный сбор ответов микросервисов-обработчиков главным микросервисом «Competence Search», вычисление итоговой оценки релевантности, сортировка списка кандидатов по убыванию итоговой оценки релевантности;
|
|
|
|
5) Отправка ответа на запрос;
|
|
|
|
6) В случае, если запрос был отправлен через чат-бот – форматирование ответа, отправка результата пользователю.
|
|
|
|
|
|
|
|
Асинхронный сбор ответов, а также параллельная и независимая друг от друга работа микросервисов позволяет ускорить время получения данных от микросервисов-обработчиков.
|
|
|
|
В случае, если один из сервисов не доступен, главный микросервис может отследить ошибку в отправке запроса и сформировать результат без использования данных проблемного сервиса, указав в ответе, что проблемный сервис недоступен. Это повышает степень отказоустойчивости приложения.
|
|
|
|
## 1.3 Описание алгоритма и принципа работы модулей системы
|
|
|
|
### 1.3.1 Описание алгоритма и принципа работы микросервисов-обработчиков
|
|
|
|
Алгоритм работы микросервисов-обработчиков представлен на рисунке.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Каждый обработчик в начале своей работы запускает два параллельных процесса. Слева изображен процесс-сервер. Большую часть времени сервер ожидает получения запроса. Как только запрос был отправлен, сервер принимает его и определяет тип запроса. Если запрос является поисковым, сервер использует обученную модель обработки данных для формирования ответа на поисковой запрос. В случае, если модель обработки данных не загружена в оперативную память (это происходит при первом запуске или при перезагрузке контейнера в случае сбоя), модель сначала загружается программой, затем формируется ответ. В конце ответ на запрос отправляется клиенту. HTTP статус запроса – 200 («Ok», «Успешно»). Если запрос является запросом на обновление модели, программа загружает из файла модель и отправляет клиенту сообщение с HTTP статусом 200 («Ok», «Успешно»). Все остальные запросы являются не валидными и клиенту возвращается сообщение с ошибкой и статусом HTTP 404 («Not found», «Не найден»).
|
|
|
|
|
|
|
|
Второй процесс ожидает времени начала обучения, установленного в конфигурационном файле. При наступлении времени обучения модель запускает функцию обучения модели, которая включает в себя загрузку новых данных сервиса и обучение самой модели. По завершении обучения модель сохраняется в бинарный файл. После этого процесс отправляет запрос на обновление на процесс-сервер и возвращается в режим ожидания времени обучения.
|
|
|
|
|
|
|
|
Все запросы локального REST API процесса-сервера представлены в таблице 1.
|
|
|
|
|
|
|
|
| URL и метод запроса | Описание |
|
|
|
|
| ------ | ------ |
|
|
|
|
| /ping (GET) | Запрос, возвращающий пустую JSON строку. Используется в отладочных целях для определения доступности сервиса. Возвращает ответ HTTP со статусом 200 («Ok», «Успешно»). |
|
|
|
|
| /handler (PATCH) | Запрос на обновление модели обработчика. Возвращает ответ HTTP со статусом 200 («Ok», «Успешно») в случае успешной загрузки модели. В случае отсутствия файла возвращает сообщение с HTTP статусом 500 («Internal Server Error», «Внутренняя ошибка сервера»). |
|
|
|
|
|/users (GET)|Запрос на поиск информации по запросу. В параметрах запроса должно быть задано ключевое слово «query» со значением в виде строки (поисковой запрос). Опционально можно передать параметр «more». Если его значение равно «true», запрос вернет дополнительную информацию. В иных случаях запрос вернет префиксы пользователей и оценку модели обработки данных. В случае отсутствия параметра «query» возвращает ответ с HTTP статусом 400 («Bad request», «Неправильный, некорректный запрос»). В случае, если модель не загружена, выполняет загрузку и, в случае ошибок, возвращает ошибки запроса PATCH /handle. В случае успешного выполнения запроса возвращает сообщение с HTTP статусом 200 («Ok», «Успешно»), а также телом в виде JSON строки.|
|
|
|
|
|
|
|
|
Формат возвращаемой запросом GET /users JSON строки представлен на рисунке.
|
|
|
|
|
|
|
|
|
|
|
|
Ключами корневого объекта JSON являются «data» и «message». Ключ «message» является опциональным и служит для передачи служебных сообщений (например, если запрос был выполнен, но часть данных не была загружена). По ключу «data» находится объект, хранящий почты пользователей в виде ключей объекта. Значениями этих ключей являются объекты, содержащие как минимум один ключ – имя модели (или обрабатываемого сервиса), нижнее подчеркивание и слово score. Значением является оценка релевантности пользователя моделей обработки данных. В объектах пользователей также может быть представлена любая другая дополнительная информация (например, имя пользователя в корпоративном чате Zulip), если в параметрах запроса был указан параметр «more» со значением «true».
|
|
|
|
|
|
|
|
### 1.3.2 Описание алгоритма и принципа работы главного микросервиса
|
|
|
|
Алгоритм работы микросервиса «Competence Search» можно описать следующей последовательностью действий:
|
|
|
|
1) Ожидание поискового запроса;
|
|
|
|
2) Получение запроса, асинхронная отправка копий текстового запроса всем микросервисам-обработчикам, хранящемся в списке обработчиков;
|
|
|
|
3) Асинхронный сбор ответов микросервисов-обработчиков, суммирование оценки с заранее проставленными весами для получения итоговой оценки, сортировка списка кандидатов по убыванию итоговой оценки релевантности;
|
|
|
|
4) Отправка ответа на запрос клиенту.
|
|
|
|
Список публичных REST API запросов, на которые может отвечать данные сервис представлен в таблице 2.
|
|
|
|
|
|
|
|
| URL и метод запроса | Описание |
|
|
|
|
| ------ | ------ |
|
|
|
|
| /ping (GET) | Описание |
|
|
|
|
| /help (GET) | Запрос на получение справочной информации. Возвращает информацию в виде JSON строки, где по ключу «message» находится строка со справочной информацией. HTTP статус ответа – 200 («Ok», «Успешно»). |
|
|
|
|
| /users (GET) | Запрос на поиск кандидатов. В параметрах запроса должно быть задано ключевое слово «query» со значением в виде строки (поисковой запрос). Опционально можно передать параметр «more». Если его значение равно «true», запрос вернет дополнительную информацию. В случае отсутствия параметра «query» возвращает ответ с HTTP статусом 400 («Bad request», «Неправильный, некорректный запрос»). Иначе возвращает JSON ответ с HTTP статусом 200 («Ok», «Успешно»). |
|
|
|
|
| /feedback (POST) | Запрос, сохраняющий обратную связь. В теле запроса должна находиться JSON строка с ключами «bot_answer», «user_answer» и «user_info». Перенаправляет всю информацию на метод /feedback микросервиса «Gtable» и возвращает те же сообщения, что и микросервис с обратной связью. |
|
|
|
|
|
|
|
|
Формат JSON ответа на запрос GET /ping представлен на рисунке.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Формат JSON ответа на запрос GET /users представлен на рисунке.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Обязательным ключом корневого объекта JSON является ключ «data». Он содержит массив, отсортированный по убыванию значения «total_score» (итоговой оценки релевантности). Элементами массива являются объекты, содержащие префикс корпоративной почты пользователя, оценку релевантности каждой модели обработки данных, суммарную оценку релевантности пользователя и дополнительную информацию (если в параметрах запроса был указан параметр «more» со значением «true»). В случае, если микросервис-обработчик не смог обработать запрос, к корневому объекту JSON добавляется ключ с названием сервиса. В нем хранится объект, содержащий сообщение-предупреждение, а также HTTP статус ошибки 503 – «Service unavailable», «Сервис недоступен».
|
|
|
|
|
|
|
|
|
|
|
|
# 2 Интерфейс общения с пользователем и обратная связь
|
|
|
|
## 2.1 Описание работы микросервисов обратной связи и чат-бота
|
|
|
|
### 2.1.1 Описание алгоритма и принципа работы микросервиса «Gtable»
|
|
|
|
Алгоритм работы микросервиса по сбору обратной связи можно описать следующей последовательностью действий:
|
|
|
|
1) Ожидание запроса на сохранение обратной связи;
|
|
|
|
2) Получение запроса микросервисом «Gtable», отправка данных обратной связи, указанных в запросе, в заранее заготовленную таблицу Google;
|
|
|
|
3) Отправка сообщению клиенту об успешном сохранении данных обратной связи.
|
|
|
|
Запросы локального REST API данного микросервиса представлены в таблице 3.
|
|
|
|
|
|
|
|
| URL и метод запроса | Описание |
|
|
|
|
| ------ | ------ |
|
|
|
|
| /ping (GET) | Запрос, возвращающий пустую JSON строку. Используется в отладочных целях. Возвращает ответ HTTP со статусом 200 («Ok», «Успешно»). |
|
|
|
|
| /feedback (POST) | Запрос, сохраняющий обратную связь. В теле запроса должна находиться JSON строка. Корневой объект должен иметь ключи: «bot_answer» (ответ бота, результат поиска), «user_answer» (отзыв пользователя) и «user_info» (информация о пользователе). В случае успешного сохранения возвращает ответ HTTP со статусом 200 («Ok», «Успешно»). В случае ошибки в теле запроса возвращает ответ HTTP со статусом 400 («Bad request», «Неправильный, некорректный запрос»). |
|
|
|
|
|
|
|
|
### 2.1.2 Описание алгоритма и принципа работы микросервиса «Zulip bot»
|
|
|
|
Алгоритм работы чат бота представлен на рисунке.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
В начале работы чат-бот читает файл с реквизитами. Затем запускается цикл ожидания сообщений. При поступлении сообщения чат-бот определяет тип сообщения. Если сообщение является обратной связью, бот вычленяет отзыв пользователя из сообщения, собирает информацию о пользователе и запоминает поисковой ответ. Далее бот отправляет информацию об обратной связи главному микросервису «Competence Search», а также отправляет сообщение пользователю об успешной отправке обратной связи. Если сообщение пользователя является командой, пользователю отправляется сообщение, содержащее справочную информацию. Если сообщение не является командой или сообщением обратной связи, бот классифицирует сообщение как поисковой запрос. После этого бот отправляет данное сообщение главному микросервису «Comptence Search». После получения ответа от главного микросервиса бот форматирует полученные данные и отправляет пользователю ответ. В конце всех операций бот возвращается в режим ожидания новых сообщений.
|
|
|
|
|
|
|
|
# 3 Подгрузка данных из сервисов и начальная предобработка
|
|
|
|
## 3.1 Загрузка данных Zulip и начальная предобработка
|
|
|
|
|
|
|
|
Для получения информации используется API Zulip. Полученный массив, включающий в себя темы, содержание сообщений и id авторов, записывается в текстовый файл. Далее этот файл поступает в модуль, взаимодействующий с моделью машинного обучения. В результате работы формируется рейтинг людей, которые участвовали в обсуждении определенной темы и которых сервис идентифицирует как экспертов в заданной области.
|
|
|
|
|
|
|
|
Алгоритм получения сообщений выглядит следующим образом:
|
|
|
|
1) Программа получает id последнего сообщения, которое написано на момент выполнения программы, и записывает его в переменную «last_anchor»;
|
|
|
|
2) При помощи эндпоинта GET «/api/v1/messages» сервис циклично производит запрос на получение 4500 сообщений за раз (рисунок 17). Такое число обусловлено лимитом сервиса на единовременное получение сообщений. Вводится переменная anchor, которой присваивается id последнего написанного сообщения в запросе. Когда ее значение превышает значение параметра «last_anchor», запросы на сообщения прекращаются;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3) При получении массива сообщений каждое из них обрабатывается в отдельной функции «preprocess_message». В ней происходит удаление HTML-тегов и специальных слов и предложений, которые часто повторяются в Zulip и не несут ценности для разрабатываемого сервиса, что показано на рисунке;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4) Если в результате сообщение является непустым и содержит больше одного слова, оно записывается в текстовый файл, в котором указываются тема и содержание сообщения. Данное действие показано на рисунке. Для определения оптимального варианта работы модели производилась запись в файл как сообщений с указанием темы, так и с ее отсутствием;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5) После обработки всех сообщений, полученных при запросе, переменной «anchor» присваивается идентификатор последнего полученного сообщения.
|
|
|
|
|
|
|
|
## 3.2 Загрузка данных «МИЭМ Wiki» и начальная предобработка
|
|
|
|
|
|
|
|
Принцип интеграции «МИЭМ Wiki» в сервис «Поисковик компетенций» следующий: сервис собирает тексты страниц и идентификаторы авторов, затем загружает их в модель машинного обучения и, найдя наиболее релевантные статьи под запрос, выдает список их авторов.
|
|
|
|
|
|
|
|
Для сбора информации о статьях, которые пользователи пишут непосредственно в «МИЭМ Wiki», разрабатываемый сервис использует GraphQL API.
|
|
|
|
Специфика данного сервиса заключается в том, что помимо оригинальных страниц, написанных студентами и преподавателями, он также агрегирует информацию из сервиса «Taiga» – инструмента для управления проектами. Соответственно, при получении данных из «МИЭМ Wiki» мы по-разному обрабатываем их.
|
|
|
|
|
|
|
|
Данные из сервиса «Taiga» являются наиболее полезными, так как содержат проектную документацию, в тексте которой возможно найти фразы, подтверждающие компетентность авторов (предполагается, что, например, если человек написал руководство администратора, то он имеет компетенции в решении вопросов администрирования). Однако существуют авторы таких статей, которые не авторизованы в «МИЭМ Wiki», поэтому мы не можем напрямую брать информацию о их. Для этого мы анализируем содержание страниц на предмет наличия специального блока текста, который указывает, что данная страница поступила из сервиса «Taiga».
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Первоначально в модель машинного обучения загружались страницы как единые документы. Однако средняя страница содержит слишком много тем в объеме текста, что не подходит для точного выделения компетенций. Поэтому было принято решение делить страницы на более мелкие документы по подзаголовкам. Так как для создания страниц в «МИЭМ Wiki» используются два способа: HTML и Markdown разметки – программа выделяет отдельные документы по тегам заголовков.
|
|
|
|
|
|
|
|
В результате модуль по работе с моделью машинного обучения передается два файла: текстовый массив с содержанием статей и файл в формате JSON, в котором порядок документов в первом файле соответствует данным об идентификаторе самой страницы и списке ее авторов.
|
|
|
|
|
|
|
|
Итоговый алгоритм получения данных из «МИЭМ Wiki» выглядит следующим образом:
|
|
|
|
1) Получение списка идентификаторов всех страниц «МИЭМ Wiki», используя запрос GraphQL API. Для отправки запросов используется библиотека Python «requests»;
|
|
|
|
2) Цикличное получение данных о заголовке, содержании, идентификатора страницы, email авторов каждой страницы;
|
|
|
|
3) Проверка, что идентификатор автора не равен единице (1 – это id административного аккаунта, а эта информация является нерелевантной для нашего проекта);
|
|
|
|
4) Если страница содержит специальный блок с именами авторов, характерный для документации из сервиса «Taiga», то производится обработка данных, чтобы получить список идентификаторов авторов из сервиса «Taiga»;
|
|
|
|
5) Предобработка страницы. Помимо других изменений, в этом блоке удаляются все HTML-теги, кроме тегов заголовков, так как они нужны для последующего разбиения страницы на отдельные документы;
|
|
|
|
6) Поиск авторов страниц, которые создавали или редактировали их непосредственно в «МИЭМ Wiki». Для этого программа вызывает функцию получения редакторов страницы из API «МИЭМ Wiki», показанной на рисунке.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
7) Добавление id пользователей Wiki в финальный список авторов;
|
|
|
|
8) Вызов функции, которая находит документы в заданной странице;
|
|
|
|
9) Разделение страницы на документы по HTML или Markdown заголовкам;
|
|
|
|
10) Обработка документа, удаление из него HTML и Markdown тегов. Функция, осуществляющая это, показана на рисунке;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
11) Запись каждого документ в текстовый файл;
|
|
|
|
12) Запись в JSON-файл идентификатора страницы и префиксов почт ее авторов.
|
|
|
|
|
|
|
|
## 3.3 Загрузка данных сервиса «Личный кабинет МИЭМ» и начальная предобработка
|
|
|
|
«Личный кабинет МИЭМ» хранит информацию об исследовательских и прикладных проектах факультета. Для каждого проекта программа получает его описание, список участников и набор их компетенций («вакансии»).
|
|
|
|
|
|
|
|
В функции предобработки из описаний проектов программа удаляет изображения, ссылки, дополнительные символы, которые снижают качество работы модели.
|
|
|
|
В модель передаются три типа документов: текстовый массив с описанием каждого проекта, JSON-файл, в котором помещены данные с id проекта и соответствующему ему списком id участников, а также файл с информацией о компетенциях каждого пользователя Личного кабинета.
|
|
|
|
|
|
|
|
# 4 Размещение приложения на сервере
|
|
|
|
## 4.1 Описание различных конфигураций запуска
|
|
|
|
Для запуска программы необходимо перейти в корневую директорию проекта. В корневой директории находятся два файла: «docker-compose.yml» и «docker-compose.prod.yml». Для запуска приложения необходимо ввести команду **«docker-compose -f <имя_конфигурационного_файла> up --build -d»** в консоли, указав нужное имя файла в параметре.
|
|
|
|
|
|
|
|
Первый файл является конфигурационным файлом запуска приложения в тестовом режиме. В этом режиме извне доступны все микросервисы. Уровень логирования всех микросервисов установлен на режим DEBUG (показываются сообщения всех уровней логирования). В данной конфигурации логи печатаются как в консоль, так и в файл в директорию logs. Установлена ротация файлов – максимальное количество лог-файлов равно 5, а размер каждого файла не превышает 10 миллионов байт.
|
|
|
|
Второй файл является конфигурационным файлом запуска приложения в финальном режиме. В этом режиме извне доступен только главный микросервис «Competence Search», а также чат-бот. Уровень логирования всех микросервисов установлен на режим DEFAULT. В данной конфигурации в консоль печатаются логи уровня INFO и выше, а в файл в директории logs – сообщения уровня INFO и выше. Также установлена ротация файлов – максимальное количество лог-файлов равно 5, а размер каждого файла не превышает 10 миллионов байт.
|
|
|
|
|
|
|
|
|
|
|
|
# 5 Описание процесса работы модели обработки данных Zulip и Wiki МИЭМ
|
|
|
|
Далее будут описаны основные методы и составляющие части библиотеки в том порядке, в котором они используются при инициализации модели и обработке данных.
|
|
|
|
|
|
|
|
Первым по порядку идет метод инициализации, выполняемый при создании модели. На этом этапе задаются основные параметры модели, её свойства и создаются важные внутренние переменные.
|
|
|
|
После того, как модель инициализировалась, она способна выполнить разбиение передаваемых ей документов и соответствующих им авторов по темам. Данный этап может быть разделён на несколько основных частей:
|
|
|
|
|
|
|
|
1) Преобразование полученных текстовых данных в числовые векторные представления. Стоит отметить, что это происходит при помощи выбранной заранее обученной нейросети-трансформера BERT из библиотеки TensorFlow. Также реализована возможность передачи методу уже готовых векторов.
|
|
|
|
|
|
|
|
2) Уменьшение размерности полученных на предыдущем шаге векторов при помощи алгоритма UMAP. Нейросеть возвращает вектора размерности 512, что является слишком большим числом для обработки на следующем этапе. В данном месте явно используются параметры (n_neighbors и n_components), которые были заданы при инициализации модели. Здесь они отвечают за размерность выходных векторов.
|
|
|
|
|
|
|
|
3) Разбиение преобразованных в вектора документов на группы и сопоставление текста его группе при помощи алгоритма HDBSCAN. На данном этапе явно используется параметр (min_topic_size), который был задан при инициализации модели. Здесь он отвечает за минимальное количество документов в группе.
|
|
|
|
|
|
|
|
4) Создание векторных представлений для каждой группы документов. На данном этапе происходит получение векторов, которые характеризуют информацию, хранящуюся в каждой из групп.
|
|
|
|
После завершения всех описанных выше этапов становится возможно получение полезной информации. Для этого в библиотеке реализован ряд методов. Например, метод get_topics_by_query позволяет найти заданное количество групп документов, которые наиболее точно передают суть указанного запроса.
|
|
|
|
|
|
|
|
Метод get_documents_by_topic просто возвращает документы, которые принадлежат указанной группе. Отметим, что документы отранжированы по тому, насколько хорошо они относятся к своей группе. Также существует возможность вывода указанного количества документов.
|
|
|
|
Метод get_documents_by_query возвращает максимально близкие (в векторном пространстве) к запросу документы, причем такие документы берутся только из заданного количества ближайших к запросу групп.
|
|
|
|
|
|
|
|
Метод get_users_by_query позволяет находить заданное количество пользователей по заданному запросу. Каждому сообщению присваивается определенное значение смысловой близости к указанному запросу, и пользователь является релевантным, если по сумме всех его сообщений метрика больше, чем у остальных. Именно этот метод является основным в контексте всей работы, поскольку с его помощью выполняется поиск людей по заданным компетенциям.
|
|
|
|
|
|
|
|
Также модель имеет внутренние методы, необходимые для работы описанных ранее основных методов. Одним из них является метод _c_tf_idf, помогающий найти слова, которые максимально ясно описывают каждый из топиков, за счёт использования информации о других группах. То есть выделяются слова, которые имеются в документах одной группы, но редко или никогда не встречаются в документах других групп. |
|
|
\ No newline at end of file |
