TLDR

Одним из важных шагов, используемых людьми в поиске ответа на вопрос, является понимание того, какой именно тип ответа устроит автора. К примеру, на вопрос: "Который час?", мы ожидаем услышать ответ с типом "время", а на вопрос "Где родился Иван Петров?" — ответ с типом "населённый пункт".

То же самое верно и для вопросно-ответных систем (Question-Answering, QA) работающих на основе графов знаний (Knowledge Graphs), целью которых является поиск ответа на фактографические вопросы. В данной статье представлен модуль определения ожидаемого типа ответа на вопрос (Expected Answer Type, EAT), который способен предсказывать не только один класс, но и строить иерархию классов в качестве прогнозного значения. Модуль предоставляется как в виде веб-интерфейса (UI) так и в виде RESTful API. Данная функциональность позволяет конечным пользователям получать предсказания типа ответа для 104 языков, видеть достоверность прогноза и оставлять обратную связь. Кроме того, API позволяет исследователям и разработчикам интегрировать EAT-классификацию в свои системы.

Введение: вопросно-ответные системы на основе графов знаний

Существует две парадигмы разработки вопросно-ответных систем: (1) на основе неструктурированных данных (IR-based, ODQA), чьей целью является поиск наиболее релевантного параграфа в наборе текстовых документов, и (2) на основе структурированных данных и знаний (KBQA), такие системы преобразуют вопрос на естественном языке в формализованный запрос (SQL, SPARQL, и тд.). Отдельно, стоит отметить вопросно-ответные системы на основе графов знаний (KGQA), которые являются подмножеством KBQA и в последнее время становятся всё более и более популярными.

Парадигмы разработки вопросно-ответных систем

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

Вопросы, задаваемые KGQA системам ориентированы на конкретные факты. Например, задавая вопрос: "В каком городе родилась Ангела Меркель?", — мы ожидаем увидеть ответ с типом "населённый пункт", в данном примере — Гамбург. В данном случае, "населённый пункт" (или еще лучше: "город") является ожидаемым типом ответа (Expected Answer Type). Такие типы зачастую организуются в иерархические таксономии типов (напр. онтология DBpedia) в зависимости от конкретного графа знаний, используемого в QA-системе. Рассматривая вопрос: "В каком городе родилась Ангела Меркель?" иерархия ожидаемого типа ответа (на основе классов из онтологии DBpedia) будет выглядеть следующим образом: dbo:City $\to$ dbo:Settlement $\to$ dbo:PopulatedPlace $\to$ dbo:Place (dbo — префикс http://dbpedia.org/ontology). В данной иерархии первый тип является самым специфичным, тогда как последний — самым общим.

Для чего же вопросно-ответным системам необходимо знать ожидаемый тип ответа? Всё очень просто — это уменьшает пространство для поиска ответа в несколько раз. Это можно показать на простом примере (см. рисунок внизу) используя уже знакомый нам вопрос про Ангелу Меркель.

Мотивация для определения ожидаемого типа ответа на вопрос

Исходя из данного примера, очевидно, что пространство поиска ответа удалось снизить с 861 сущности до 6, что является впечатляющим результатом.

В рамках данной статьи, я бы хотел рассказать о разработанном нами модуле для иерархической классификации типа ответа на вопрос, который поддерживает 104 языка и работает на основе онтологии DBpedia. Модуль показывает результаты, сравнимые со state-of-the-art решениями (в частности, 3-е место в профильном лидерборде) и доступен в виде веб-интерфейса (UI) и RESTful API. Данная статья написана на основе материалов двух наших публикаций:

Архитектура решения и процесс разработки

Существует два подхода к иерархической классификации: локальный и глобальный. В локальном подходе используется несколько классификаторов для каждого из уровней иерархии, тогда как в глобальном подходе иерархия игнорируется, можно даже сказать уплощается, и в этом случае мы имеем дело с мульти-лейбл (multi-label) классификацией.

В данной статье мы используем смешанный подход (см. рисунок с архитектурой решения) к иерархической классификации ожидаемого типа ответа на вопрос. В основе решения лежат мультиязычные модели BERT-base, к которой добавляется слой из N-нейронов в конце, где N — число классов для предсказания на конкретном уровне иерархии.

Архитектура иерархического классификатора ожидаемого типа ответа

На схеме представлено 3 модели — классификатор категории (category classifier), классификатор литерала (literal classifier) и классификатор ресурса (resource classifier). Всего имеется три класса категории: boolean, literal и resource. Литералов также три: number, data и string. С ресурсом дела обстоят сложнее, так как там идёт полноценная иерархическая классификация (см. пример во введении). В случае нашего решения, классификатор ресурса предсказывает самый специфичный тип ответа (напр. dbo:City), далее мы просто достаем оставшуюся иерархию из DBpedia до самого верхнего уровня с помощью SPARQL запроса.

SELECT ?sType WHERE {
	<type> rdfs:subClassOf* ?sType .
  FILTER(CONTAINS(STR(?sType), "dbpedia.org/ontology"))
} 
# the ’<type>’ placeholder  is  replaced  with  the  predicted  type

Качество классификатора категорий измерялось метрикой Accuracy, тогда как остальные классификаторы оценивались с помощью метрик NDCG@5 и NDCG@10, которые созданы для оценки ранжированых списков. После прогонки оценочного скрипта, мы получили следующие результаты: Accuracy: 0.98, NDCG@5: 0.76, NDCG@10: 0.73. Эти результаты также находятся на публичном лидерборде по ссылке: https://smart-task.github.io/2020.

Заключение

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

Статья: http://ceur-ws.org/Vol-2980/paper349.pdf
GitHub: https://github.com/Perevalov/iswc-classification
Demo UI: https://webengineering.ins.hs-anhalt.de:41009/eat-classification
Demo API: https://webengineering.ins.hs-anhalt.de:41020/docs

Иерархическая классификация ожидаемого типа ответа на вопрос в вопросно-ответных системах на основе графов знаний