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

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

Предварительная обработка текста:

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

Разрешение базовой ссылки:

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

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

Тройное извлечение:

Это ключевой компонент системы, в которой мы извлекаем триплеты в формате [субъект, предикат, объект]. Со всеми подстановками кореференций и предварительной обработкой текста деятельность по сопоставлению сущностей упрощается.

Для этой задачи используется открытое извлечение информации Стэнфорда (открытый IE). И сегодня нам нужно некоторое ручное вмешательство после этого шага, чтобы сгенерировать правила для сопоставления отношений, а также для тройной очистки. Мы постоянно работаем над улучшением этого шага, поскольку он является ядром нашей системы.

Сгенерированные тройки можно хранить в постоянном хранилище. Обычным выбором для этого были бы некоторые графовые базы данных, такие как neo4j, dgraph и другие. Но здесь для этой простой системы мы сохранили триплеты в базе данных NoSQL [MongoDB]. И мы заметили, что для KG, сгенерированного из одного документа, возникает проблема с производительностью. Но как только система станет зрелой, планируется перейти к графовой БД, чтобы использовать ее возможности.

Поиск/запрос KG(Triples)

Как уже упоминалось, тройки хранятся в MongoDB. Каждая тройка хранится как один документ с источником, отношением и целью в виде отдельных полей. Текстовый индекс строится по всем трем полям. Одно из сделанных здесь предположений состоит в том, что пользовательский запрос будет иметь дело только с одним отношением. Мы выполняем текстовый поиск по индексу сохраненных документов, чтобы получить 5 лучших документов, соответствующих запросу пользователя.

И теперь задача состоит в том, чтобы найти, какой компонент, будь то источник или объект, должен быть возвращен пользователю. Это легко сделать, найдя перекрытие текста. Но бывают случаи, когда может существовать несколько отношений с идентифицированным источником или объектом. Чтобы снова решить эту проблему, мы рассмотрим соответствие между запросом пользователя и отношениями всех 5 документов с учетом всех его синонимов. Мы использовали пакет NLTK WordNet для списка синонимов и выбрали лучший документ в качестве ответа.

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

Дальнейшие шаги:

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

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