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 dbo:Settlement
dbo:PopulatedPlace
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.
Заключение
В данной короткой статье был представлен компонент для классификации ожидаемого типа ответа, который может использоваться в вопросно-ответных системах, работающих на основе графов знаний. Классификатор поддерживает многоязычный ввод и показывает довольно высокие результаты по качеству прогнозов. Оставляю важные ссылки: