knowledge graph что это

Knowledge Graph. Плюральность, темпоральность, деятельностный подход

Традиционно Knowledge Graphs, то есть информационные системы, поддерживающие концептуальное описание предметных областей (как самых общих, так и узко специальных) задумываются и строятся, как источники проверенной и единственно верной информации о мире. По такому принципу – как собрание исключительно правильных данных – построена и популярная народная энциклопедия Wikipedia.

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

Естественно, что такая информационная система не может быть сформирована ни единичными аналитиками, ни научным коллективом, ни согласованными усилиями множества рядовых пользователей. Создать мультитематический и многоуровневый Knowledge Graph, отражающий разнообразные точки зрения возможно только при условии привлечения максимального количества профессионалов, являющихся носителями этих знаний. А заинтересовать экспертов в этой работе можно только предоставив им удобный и полнофункциональный инструментарий для ввода, генерации и обработки данных. Современный Knowledge Graph для выполнения свой функций, прежде всего, должен быть рабочей средой для любой деятельности связанной с хранением и структурированием информации — от коллекционирования марок до бизнес планирования и научных исследований. Именно деятельностный подход, акцентирующий внимание не на конечном результате, а на самом процессе обработки информации, позволит сформировать внутренне согласованные системы знаний в пределах отдельных предметных направлений. Таким образом, Knowledge Graph в конечном итоге должен стать не только источником знаний, но функциональным инструментом для их генерации.

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

Для фиксации неявных связей между различными направлениями деятельности также существенно, чтобы современный Knowledge Graph был мультитематическим, предоставляющим пользователю инструменты для реализации своих планов по созданию, обработке и поиску информации во всех интересующих его сферах. Анализ поведения пользователя в одной области позволит успешнее предсказывать его поведение и в других, даст возможность точнее подстроить систему под его требования.

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

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

Источник

Google Knowledge Graph Search API заменит Freebase

Google выпустил API для своей базы знаний Google Knowledge Graph. Сервис уже выдает данные в формате JSON-LD (LD здесь означает Linked Data, да-да!) и использует типы schema.org. Помимо соблюдения стандартов, радостной новостью является наличие обратной совместимости с Freebase — всегда когда возможно, для идентификации сущностей используются ключи из Freebase. Программный интерфейс Freebase будет доступен в течение еще трех месяцев.
Напомню, что Knowledge Graph — это база знаний, которая в числе прочего формирует вот такие вот инфобоксы в результатах поиска:

На первый взгляд, новый API выглядит существенно слабее чем использовавшийся в Freebase язык запросов MQL, но будем надеяться, что программный интерфейс будет обновляться. Можно найти сущность по поисковому запросу, префиксу, плюс наложить ограничения по типам из списка типов schema.org. Результат можно получить на разных языках.

В ближайших планах команды Knowledge Graph обновление Freebase Suggest API, интерфейса, который выдавал объекты freebase в качестве поисковых подсказок:

Два года назад компания сообщила о прекращении поддержки базы знаний Freebase, и все это время Wikimedia Germany усердно работала над переносом данных в Викиданные. Сайт Freebase обещали демонтировать еще к июню, но пока все на месте.

Источник

Google Knowledge Graph

Внезапно Google объявил о запуске проекта, который готовился в недрах Evil Empire уже два года.
Придумав броский слоган things not strings (вещи — не строчки), нам хотят представить нечто вроде автоматической энциклопедии.

Через несколько дней в поисковой выдаче будут появлятся «баннеры» с краткими сводками данных об объектах, которые Google ассоциировал с тем, что вы ищете, и со связанными с ними объектами.
К примеру, при поиске фамилии известного человека в сводке можно будет увидеть его фото и краткие биографические данные.

Кроме этого, если поисковый запрос допускает много толкований, вам будет предложено уточнить область запроса и после этого будут выданы уточнённые результаты.
В корпорации эту систему называют Google Knowledge Graph, и для её рекламы показывают видеоролики про связь между объектами реального мира.

Люди, работающие над проектом, считают, что поиск будет давать лучшие результаты, если поисковик будет не просто обрабатывать строковые данные, а пытаться сопоставить их с объектами из базы данных (я тут не употребляю слово «понять» намеренно, хотя авторы постоянно допускают выражения типа «было бы здорово, если бы google смог понять..»).
В числе прочего, «граф знаний» будет формировать связи исходя из того, что уже искали и находили другие пользователи по данной теме.
На данный момент в «базе знаний» содержится информация более чем о 500 миллионах объектов (людей, мест и пр.).

Источник

Базы знаний. Часть 2. Freebase: делаем запросы к Google Knowledge Graph

Больше года назад Google объявил, что отныне в их поиске используется таинственная Сеть Знаний (официальный перевод Knowledge Graph). Возможно, не все знают, что значительная часть данных Сети доступна для использования всеми желающими и доступна по прекрасно описанному API. Этой частью является база знаний Freebase, поддерживаемая Google и энтузиастами. В этой статье мы сначала немного подурачимся, а потом попробуем сделать несколько простеньких запросов на языке MQL.
Эта статья — вторая из цикла Базы знаний. Следите за обновлениями.

Google Knowledge Graph с точки зрения рядового пользователя

Одним из видимых проявлений Google Knowledge Graph являются информационные панели, кратко описывающие тот объект, который вы ищете. Они часто возникают при поиске персоналий, чуть реже — географических наименований. Они чаще возникают для запросов, заданных на английском языке в английском интерфейсе, но мы будем придерживаться русского языка там, где это возможно.
Например, запрос Роджер Уотерс даёт следующий результат:

Покликайте по ссылкам в инфобоксе и обратите внимание на URL — в нем используется параметр stick, содержимым которого является некоторый идентификатор вида &stick=H4sIAAAAAAAAAONg[VuLQz9U3] AAAA
Когда Knowledge Graph только появился, это позволяло демонстрировать непосвященным небольшую уличную магию, например, добавлять &stick-параметр от Мерилин Монро к запросу от Стивена Кинга:

Сейчас такую возможность прикрыли, да и ни к чему она нам — лучше посмотрим на что-нибудь полезное. К примеру, недавно появилась возможность сравнить несколько объектов с помощью ключевого слова vs:

Гугл обещает добавить еще много вкусностей, связанных с умным поиском и ответами на вопросы, и Knowledge Graph будет одним из столпов, на котором эта интеллектуальность держится. Что особенно прекрасно для нас, так это то, что кусочек Knowledge Graph’a открыт для использования всеми желающими.

Freebase — подграф GNG

Начнем с исторического экскурса. Компания Metaweb начала работу над своей базой знаний в 2005 году. По способу наполнения данными Freebase больше всего походила на Dbpedia: львиную долю знаний, представленных во Freebase, являлись данные из Википедии. Отличием от Dbpedia была, во-первых, возможность поправлять введенные данные вручную, а во-вторых то, что Freebase не гнушалась и другими источниками данных. В отличии от команды DBpedia, представители Metaweb не слишком заботились о том, чтобы публиковать научные статьи (хотя в последнее время начали, вот тут интересный список), и признавались, что код основного компонента, graphd, вряд ли когда-нибудь увидит свет дня.
В 2010 году компания Metaweb была куплена Google, но, судя по рассылке Freebase, поисковый гигант не слишком вмешивался в дела свежеприобритенной команды. После выпуска красочного ролика, в котором Google рвет конкурентов, как пионерскую правду с помощью своих новых интеллектуальных семантических технологий, представители Metaweb (а затем и Google) подтвердили, что Freebase является очень важной частью Сети Знаний, наряду с Википедией и базой фактов ЦРУ. Во время большого субботника по унификации всех гугловых API, программный интерфейс Freebase сильным изменениям подвергать не стали, а его описание просто перенесли на developers.google.com. Для того, чтобы спросить что-нибудь у базы знаний мы по-прежнему используем язык запросов MQL (произн. «микл», Metaweb Query Language). За дело!

Первый запрос и редактор

Начнем с простенького вопроса: спросим у Freebase какой-нибудь факт, например дату рождения Леонардо да Винчи:
www.googleapis.com/freebase/v1/mqlread?query= <"/type/object/id":"/en/leonardo_da_vinci","/people/person/date_of_birth":null>
Получим вполне корректный результат:

Для того, чтобы нам было проще упражняться, мы будем использовать редактор запросов, любезно предоставляемый Freebase.

Редактор этот страшно удобен и имеет прекрасную функцию автодополнения запросов — в случае затруднений просто нажмите Ctrl+Enter и вы получите отличные контекстные подсказки. В нижней панели редактора расположились полезные инструменты, которые подробно описаны в руководстве. При самостоятельном изучении особенно советуем поглядеть на кнопку examples, содержащую примеры запросов, проясняющим многие возможности MQL.

Сложный запрос

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

Итак, вот наш запрос (взят из руководства по MQL):

JSON в MQL

JSON (JavaScript Object Notation) — это язык, созданный для обмена данными в формате «ключ-значение». Изначально JSON использовался для сериализации объектов JavaScript, но быстро стал языконезависимым и благодаря своей простоте, стал очень любим и уважаем программистами на разных языках и платформах.
Самый простой JSON-объект — пустой объект. Он записывается следующим образом:

Теперь давайте создадим объект, в котором хранится информация о Леонардо да Винчи. Для начала ограничимся только его именем. Для этого заключим ключ и значение в кавычки, разделив двоеточием

Добавляем несколько фактов о Леонардо, разделяя их через запятую:

Теперь стоит определить, что за профессия была у да Винчи. А профессий-то этих было много: и скульптор, и художник, и архитектор и еще много кто. Для того, чтобы присвоить одному ключу несколько значений, в JSON используются списки значений — заключенные в квадратные скобки значения, указанные через запятую:

Еще одна вещь о JSON, которую стоит знать, — это вложенные объекты. Они делаются крайне просто: после ключа вы просто вставляете новый набор пар ключей-значений в фигурных скобках. В случае с Леонардо мы можем попробовать отобразить данные о месте рождения Леонардо — селе Анкиано, находящемся в Италии. Мы скажем, что ключ «place_of_birth» соответствует некоторому объекту с именем Anchiano, находящимся в Italy:

Не совсем JSON

Вообще, MQL-запросы не являются корректными JSON-объектами. MQL — это надмножество JSON и в нём разрешаются разного рода вольности. Одна из идей продуктов Metaweb заключается в том, что программы должны уметь прощать пользователям ошибки и описки, которые те делают. Эта идея есть и в других языках и программах, а в первую очередь — в World Wide Web — ничего страшного, что некоторые части html написаны с ошибками, нужно все равно постараться отобразить документ.
Вот, например, корректный JSON-запрос, ищущий людей с редкой и ценной профессией:

Мы можем убрать кавычки и запрос продолжит работать:

Закрывать скобочки и разделять пары двоеточием тоже не обязательно, так что вот пример совсем уж безобразия:

Устройство Freebase

Универсальные свойства объектов

Идентификаторы

Вы можете ввести идентификатор в поле поиска на Freebase.com и получить страницу свойств объекта:

Свойство /type/object/name

У каждого объекта есть имя. Имя — вещь не уникальная, у объекта обычно несколько имен — по одному на каждый язык. Самое интересное, что это нисколько не усложняет запросы — вы заметите, что при запросе имен вам будет выдаваться только имя на языке, установленном во Freebase как текущий. Так что можно обращаться с объектами типа name как с обычными строками.

Свойство /type/object/type

Различные виды MQL-запросов

Запрос одного значения

Запрос массива значений

Если вы напротив, запросите массив вместо одиночного значения – в этот нет никаких проблем – Freebase преобразует результаты и выдаст массив с одним-единственным значением.

Запрос объектов

Также и Англия, откуда родом наш музыкант, это не просто строка «England», а полноценный объект. Чтобы получить объектное представление в запросе, используется конструкция < >, вот так:

В результате нам выдадут самую важную информацию об объекте: его идентификатор, название и список типов:

Вложенные запросы

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

Можно спуститься ниже: к какой языковой семье относится язык, на котором говорят в стране, откуда родом Эмерсон?

Запрос всех свойств объекта

Полезная вещь при конструировании запроса — получить все свойства объекта. Конструкция, используемая для этого очень проста и удобна: звездочка в качестве названия свойства и пустой массив, который заполнится значениями «*» : []

Запрос

Ответ

Как лучше запрашивать объекты Для тех, кто успел запутаться в скобочках, вот сводка по тому, как во Freebase можно запрашивать объекты: Конструкция Её смысл запрашивается значение свойства в виде одной строка. В качетсве этой строки будет выдано значение default-свойства объекта: value (для литералов) или name (для объектов). Если значением свойства является массив, выдается ошибка! запрашивается массив строк. Результатом может быть пустой, массив, массив с одним значением или массив с несколькими значениями на каждое свойство объекта запрашивается массив его значений запрашивается краткая информация об объекте. Для обычных объектов выдается их имя, идентификатор и тип запрашивается массив объектов в кратком виде. Работает аналогично <>, но для массивов у объекта-значения свойства спрашивается все, что указано в запросе вложенный запрос относится ко всем объектам в массиве значений свойств. Действует аналогично предыдущему для массивов. Для начала достаточно. Понятное дело, что в MQL есть различные компараторы, регулярные выражения, всякие там И, ИЛИ и НЕ. Еще прекрасен язык Acre, который позволяет форматировать результаты запросов подобно тому, как это делается в Semantic MediaWiki. Ну и впереди рассказ о Dbpedia и Wikidata. Что бы вам было интересно почитать в первую очередь? Источник Граф знаний в Поиске: построение из нескольких источников Я хочу рассказать о том, что такое граф знаний и об одном из способов его построения из нескольких тематических источников. Большое количество запросов в поиске содержат единственную сущность — объект, про который спрашивает пользователь. Это могут быть запросы про каких-то людей, фильмы, сериалы, музыкальные или географические объекты. Когда пользователь задает такой запрос, в выдаче ему можно показать дополнительную информационную карточку в надежде, что информация в карточке будет интересна пользователю. Карточки украшают выдачу и повышают ее наглядность. С помощью информационных карточек мы даём человеку понять, что он пользуется интеллектуальным сервисом, потому что поисковая система поняла, что он имел в виду, о каком именно объекте спрашивал. Более того, эту интеллектуальность можно расширить, отвечая на запрос пользователя прямо на странице выдачи. Например, в ответ на «что посмотреть в Праге» мы можем сразу показать достопримечательности этого города. Бывают случаи, когда пользователь хочет узнать что-то о каком-то объекте, но совершенно ничего о нём не знает, кроме факта его существования. Или пользователь хочет продолжить исследования по какой-то теме. Специально для этого случая в карточке показывается то, чем известен этот объект, а также возможные варианты для продолжения исследования в блоке «cмотрите также». Граф знаний В основе всех этих семантических технологий лежит граф знаний — это граф, узлами которого являются объекты реального мира, а переходами — типизированные отношения между объектами (например, отношение для места рождения отличается от отношения даты рождения). Пример маленького графа знаний показан на рис. 1. Рис. 1. Пример графа знаний Существуют открытые графы знаний, которые можно скачать и использовать. Примеры и некоторая статистика по самым известным открытым графам знаний представлена в табл. 1. Таблица. 1. Статистика по открытым графам знаний Граф знаний Количество записей Количество объектов Частота обновления Freebase Более 3 миллиардов 49 миллионов Не обновляется Викиданные 748 миллионов 18 миллионов Раз в неделю (инкрементально — раз в сутки) DBpedia 411 миллиона 4 миллиона Последнее обновление в августе 2019 Проблема открытых графов заключается в том, что не все сферы знаний освещены достаточно глубоко. Например, российские сериалы. Они не очень популярны во всем мире, но нам особенно дороги, потому что пользователи спрашивают про них. Это значит, что мы должны найти какую-то информацию об этих сериалах и принести её на SERP (Search Engine Result Page). Вторая проблема — это довольно редкие обновления. А ведь когда случается какое-то событие, мы хотим как можно скорее принести эту информацию и показать её на страницах с результатами поиска. Существует как минимум три возможных решения этих проблем. Первое: ничего не делать, смириться, закрыть на это глаза и продолжать жить. Второе: аккуратно вручную добавлять информацию в открытые графы знаний, а потом пользоваться данными оттуда. И третий вариант: автоматически слить с графом знания из какого-то тематического источника. Для тех же фильмов и сериалов таких источников довольно много: КиноПоиск, IMDb, Кино Mail.ru. Причем в графах знаний, как правило, у объектов присутствуют ссылки на популярные тематические ресурсы. Мы начали реализовывать третий подход. Прежде, чем приступать к решению этой задачи, нужно подготовиться. Дело в том, что данные в источниках представлены в разных форматах. Например, в Викиданных — это JSON, в КиноПоиске — HTML. Их нужно сконвертировать в одинаковый формат. Мы конвертируем в N-Triples, потому что его удобно обрабатывать параллельно, а в данном случае это действительно важно, так как мы работаем с большими данными. Разжатый JSON-дамп Викиданных занимает около 720 Гб, а HTML-страницы КиноПоиска 230 Гб, поэтому почти все задачи решаются на кластере с помощью парадигмы MapReduce. Склейка дублей Одной из самых сложных задач при слиянии графов знаний является склейка дублей. Например, у нас есть графы и два каких-то объекта в них, которые являются одним объектом реального мира. Мы хотим в нашем результирующем графе склеить их вместе так, чтобы это был один объект в графе знаний. Решение, которое мы придумали с самого начала, довольно простое. Давайте мы возьмем и склеим все объекты, у которых одинаковые имена. Так мы узнали, что существует, как минимум, два известных человека с именем Брэд Питт, чуть менее сорока фильмов и сериалов под названием «Мост», и примерно столько же Иванов Ивановых про которых есть статья на Википедии. Очевидно, что такой простой подход не работает, требуется что-то посложнее. И тогда мы придумали решение из трёх частей. Первая часть — это генератор кандидатов для связывания. Вторая — классификатор, который пытается ответить на вопрос, нужно ли склеивать между собой пару объектов. И третья — это дополнительный шаг склейки: мы доклеиваем то, что не получилось по каким-то причинам склеить на предыдущем шаге. Генератор нужен для того, чтобы сократить количество кандидатов для связывания (пытаться связать каждый объект с каждым слишком дорого). Поэтому мы ограничиваемся лишь небольшим множеством кандидатов и после запускаем классификатор только для этого небольшого множества. Основная идея заключается в том, что имена объектов, которые могут быть связаны, должны каким-то образом быть похожи. Мы решили начать с полного совпадения подстрок, но с возможностью перестановки слов. Это значит, что если у двух объектов порядок слов в имени не совпадает (например, имя и фамилия человека перепутаны местами), они всё равно будут сопоставлены. Мы используем как русские имена, так и оригинальные иностранные. Также мы используем прозвища, псевдонимы и синонимы объектов, которые мы собрали из перенаправлений Википедии. Прежде чем обучать модель, неплохо бы откуда-то получить данные. Нам повезло, всё необходимое уже было в открытых графах знаний. Например, в Викиданных чуть менее 200 тыс. объектов, ссылок на фильмы и сериалы КиноПоиска, и чуть менее 100 тыс. ссылок на персон КиноПоиска. На этих данных мы и будем обучаться. В основе всех признаков лежит идея, что один и тот же объект в двух графах должен иметь схожий контекст. Похожая идея используются при решении задачи Entity Linking. Причем под контекстом в графе подразумеваются не соседние объекты к данному объекту, а их строковые описания. Более формально контекстом объекта в графе будут считаться все смежные ему строки, а также имена инцидентных ему объектов и типы. На рис. 2 строки, которые принадлежат контексту этого объекта, выделены жирным. Рис. 2. Контекст объекта Работать со строками можно несколькими способами. Во-первых, считать совпадение строк, сопоставляя их целиком, то есть учитывая только полное совпадение. Во-вторых, можем пользоваться строкой как мешком слов, разбить строку на слова и пожертвовать порядком. Мы используем оба подхода. Строки можно либо использовать сразу все вместе, либо группировать по видам отношений, которыми они связаны с объектом. Считаются также абсолютные и относительные совпадения по группам. Возьмём два объекта: Лионель Месси (Lionel Messi) и Лайонел Ричи (Lionel Richie), табл. 2. Таблица. 2. Некоторые отношения для объектов «Лионель Месси» и «Лайонел Ричи». Имя отношения Лионель Месси Лайонел Ричи name «Lionel Messi» «Lionel Richie» birthday «June 24, 1987» «June 20, 1949» football_club «FC Barcelona» — Имена не совпадают целиком, поэтому полное совпадение в имени будет равно нулю. Но количество совпадений слов в имени равно 1, потому что оригинальное имя «Lionel» совпадает у обоих объектов. Коэффициент Жаккара (отношение размера пересечения к размеру объединения) для имени будет равен 0.2: Мы не сразу поняли, что если у какого-то объекта не хватает нужного отношения, то не имеет смысла торопиться и записывать в этот признак нуль, лучше записать Missing value. Ведь когда мы добавляем к большому графу какой-то тематический граф, в нём часто отсутствуют какие-то отношения, и нужно иметь возможность различать случаи, когда в двух отношениях ничего не совпало, и когда у какого-то из объектов просто не хватает нужного отношения. Следуя этой логике количество совпавших слов для отношения «football_club» будет равно Missing value. Количество полных совпадений строк по всем отношениям равно нулю, а количество совпавших слов — два («Lionel» и «June»). Рейтинг лучших признаков, используемых моделью показан на рис. 3. Рис. 3. Самые важные из используемых признаков Лучшим признаком у нашей модели считается суммарное относительное совпадение слов. За этим сложным названием скрывается сумма коэффициентов Жаккара по всем отношениям. Интересно, что если вообще выбросить всё машинное обучение из этой задачи и оставить более-менее адекватную отсечку по значению этого признака, то качество модели по -мере упадет всего на 20 %. Если взять признаки, которые описаны выше, обучить на них XGBoost из коробки, 250 деревьев высотой 4, то мы получим довольно неплохие метрики. Таблица. 3. Метрики качества модель на тестовых данных. Имя метрики Значение Точность (precision) 0.961531 Полнота (recall) 0.963220 0.962375 AUC 0.999589 Но есть проблема: на этих метриках не видно некоторых объектов, которые мы не склеиваем. Это так называемые «большие объекты» у которых много отношений. Города, страны, род занятий — это те объекты, которые связаны с большим количеством других объектов. На рис. 4 показано, как это может выглядеть на SERP. Кажется, что все довольно безобидно: Рис. 4. Проблема «больших» объектов У нас в карточке есть дубли. Казалось бы, ничего страшного, но на самом деле проблема намного глубже, страдает согласованность данных. Так происходит потому, что в наших обучающих данных совсем нет подобных объектов. Здесь нужно применить другой подход, использовать большое количество отношений этих объектов себе во благо. На рис. 5 показана схема такого подхода. Пусть есть два объекта X и Y, которые связал классификатор. Эти объекты принадлежат разным графам и каждый объект связан с какими-то другими объектами в своем графе. Объект X связан с объектами A, B, C с помощью отношений , , , а объект Y с объектами D, E и F c помощью отношений , и . Но теперь нам известно, что объекты X и Y на самом деле являются одним объектом реального мира. Рис. 5. Дополнительная склейка Давайте выдвинем две гипотезы: Итоговое решение получилось довольно универсальным, поэтому похожим образом можно склеивать дубли и для других тематических источников, постоянно увеличивая охват и глубину тем в графе знаний. Заключение В статье рассмотрено одно из возможных решений задачи склейки одинаковых объектов разных графов знаний. Когда граф знаний уже построен, мы можем показать информационные карточки на странице с поисковыми результатами, использовать знания из графа для ответа на вопросы-фактоиды или придумать еще какое-то интересное применение, чтобы порадовать пользователей. Надеюсь, что было интересно почитать немного о том, как это все работает изнутри. Если остались какие-то непонятные моменты, пожалуйста, задавайте вопросы, попробую на них ответить. Источник ← произведения лескова левша какой жанр что делать если айфон прослушивают → Вам также понравится kite python что это 27.10.202304.07.2023 admin 0 при каком прокате колесных пар по кругу катания у локомотивов мотор вагонного 27.10.202308.07.2023 admin 0 bol684 что это такое билайн 29.10.202304.07.2023 admin 0 Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Δ