Рекомендационная система на графах с EDG и Neo4j

В этом руководстве описывается процесс управления таксономией в EDG с последующей публикацией ее в экземпляре Neo4j, где она может быть дополнена дополнительными данными для работы рекомендательной системы. Таксономия, созданная и поддерживаемая в EDG от TopQuadrant, определяет структуру. Набор (фиктивных) статей из академических журналов выступает в роли экземплярных данных, заполняющих Neo4j. Для организации статей используется небольшая иерархия категорий STEM в качестве таксономии. Эти данные распространяются под лицензией Creative Commons CC0 1.0 Universal Public Domain Dedication.

Смысл такого подхода заключается в том, что значительная часть смысла содержится непосредственно в таксономии. Каждая статья помечается наиболее конкретной подходящей категорией, но поскольку таксономия кодирует отношения родитель-потомок, можно автоматически выводить связи на более высоком уровне. Например, если статья помечена как относящаяся к Mathematical Software, то она также касается Computer Science и STEM, даже без явной пометки. Таксономия не просто классифицирует, она позволяет рассуждать о связях между темами, поэтому источник данных должен фиксировать только наиболее релевантную метку, а иерархия дополнит остальное.

Здесь разделяется информация на экземплярном уровне о содержании отдельной статьи от метаданных о самих темах и их взаимосвязях.

Причины для использования такой архитектуры включают:

1. Вывод отношений: Помечайте контент одним понятием, но задействуйте таксономию для ассоциации с множеством других понятий. Вместо пометки статьи как Mathematical Software и Computer Science достаточно указать только Mathematical Software. Таксономия знает, что Mathematical Software является ветвью Computer Science. Родительское понятие Computer Science выводится на основе таксономии.
2. Согласование различных систем: Одна таксономия позволяет создать рекомендательную систему в Neo4j и приложение GraphRAG в GraphDB. Одна команда может применять векторную пометку для контента в SharePoint, а другая — пометку на основе правил NLP для контента в Adobe Experience Manager (AEM). Все приложения согласованы, поскольку опираются на одни и те же справочные данные.
3. Управление изменениями: Если требуется переклассифицировать Mathematical Software как ветвь Mathematics вместо Computer Science, достаточно изменить родителя в таксономии. Без отдельной таксономии пришлось бы перемаркировать каждый документ с Mathematical Software. При наличии нескольких downstream-приложений, использующих один список терминов, это превращается в сложную задачу. Необходимо перемаркировать каждую сущность с Mathematical Software во всех приложениях и убедиться в корректности остальных меток для документа.
4. Использование сильных сторон инструментов: EDG отлично справляется с управлением метаданными и таксономиями, обеспечивая их согласованность и хорошее управление. Neo4j и другие графовые базы данных превосходны в высокопроизводительном графовом анализе в масштабе, но слабы в управлении метаданными. Такая настройка позволяет получить преимущества от обоих инструментов.

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

1. Избыточность для простых случаев: В руководстве используется простая демонстрация, но архитектура оправдана при сложных данных и сценариях. Большинство графовых баз, включая Neo4j, позволяют определять схему или базовую онтологию и представлять таксономии с помощью иерархических отношений. Если данные относительно просты, таксономия прямолинейна или используется только одной командой, может не потребоваться столько инструментов.
2. Необходимые навыки и кривая обучения: Совместное использование EDG и Neo4j предполагает знакомство с двумя парадигмами: моделированием онтологий в RDF/SHACL и запросами к графам в property graphs/Cypher. Многие команды владеют одной, но не другой.
3. Больше компонентов: Отделение таксономии от маркируемых данных требует обеспечения соответствия меток таксономии. Если они расходятся, граф перестает аккуратно собираться в базе данных.
4. Зависимость от поставщиков: Neo4j и EDG — коммерческие продукты, поэтому всегда присутствует некоторая привязка и потенциальные затраты на миграцию. Стандарты, лежащие в основе EDG (RDF, SHACL и SPARQL), являются открытыми стандартами W3C, что смягчает общую техническую привязку.

Neo4j представляет собой помеченный граф свойств (LPG). EDG — инструмент для курации графов знаний, основанный на RDF и SHACL. LPG и RDF — две разные графовые технологии, исторически несовместимые. Однако EDG недавно добавил функцию интеграции с Neo4j, позволяющую строить системы на обеих технологиях.

Ниже приведено визуальное представление того, как эти технологии могут взаимодействовать.

В нижней части на розовом фоне показан уровень хранения данных. Он разделен на внутренние и внешние данные. Внутренние данные — это сырые данные, хранящиеся в озере данных, системе управления контентом (CMS) вроде SharePoint или реляционной базе данных. Могут быть также внешние наборы данных для интеграции в приложение. Это могут быть публичные бесплатные источники вроде WikiData, верхнеуровневые онтологии вроде gist или проприетарные справочные наборы вроде SNOMED или MedDRA (медицинские таксономии).

EDG может выступать семантическим слоем между базовыми данными и downstream-приложениями. Таксономии, онтологии, справочные данные и метаданные управляются в одном месте, а необходимые элементы передаются в приложения вроде Neo4j по требованию. Также можно загружать данные напрямую из базовых источников в Neo4j или любое другое приложение.

Шаг 1: Получение бесплатных версий EDG и Neo4j

Сначала необходимо приобрести бесплатные версии этих продуктов для экспериментов.

Для EDG перейдите на сайт и запросите бесплатную пробную версию. В email придет ссылка на скачивание EDG вместе с лицензией. После завершения загрузки в папке edg найдется исполняемый файл edg. Дважды кликните по нему, и приложение запустится в браузере. Если Java не установлена, система предложит установить ее сначала.

EDG откроется в браузере в новой вкладке по адресу вроде http://localhost:8083. Но будет указано, что продукт не зарегистрирован. Нажмите Product Registration и загрузите файл лицензии из email. Затем кликните “Register Product”.

После загрузки лицензии вернитесь на главную страницу, кликнув по логотипу TopQuadrant в левом верхнем углу. Теперь должна отобразиться основная страница EDG.

Теперь требуется бесплатная версия Neo4j. Перейдите по ссылке для начала пробной версии. Если аккаунта нет, создайте его. После создания аккаунта Neo4j вы окажетесь на экране вроде этого:

Нажмите “Create instance” и выберите бесплатный вариант.

При клике на “Create instance” отобразятся имя пользователя и пароль. Имя пользователя обычно “neo4j”, но пароль уникален, поэтому запишите его.

Шаг 2: Настройка интеграции

В EDG в правом верхнем углу кликните по иконке пользователя (силуэт человека). Затем выберите “Server Administration”. Это приведет к экрану с множеством опций. Нажмите “Product Configuration Parameters”. В левой панели появятся варианты интеграций. Выберите “Neo4j”.

Можно настроить передачу в несколько баз Neo4j, но для руководства укажем только созданный экземпляр. Справа от пустой строки Neo4j базы данных есть плюс. Кликните его, и появится запрос на ввод учетных данных Neo4j.

Назовите конфигурацию произвольно, например “neo4jtest1”. ID заполнится автоматически. Для URL базы Neo4j проверьте экземпляр в Neo4j; он будет выглядеть как neo4j+s://cd227570.databases.neo4j.io.

Нажмите “Create and Select”. Теперь введите пароль, который Neo4j предоставил при создании экземпляра.

Настройка завершена.

Шаг 3: Импорт таксономии

Скачайте таксономию с GitHub. Это иерархический список тем STEM, то есть таксономия.

В EDG нажмите “New +” в верхней части экрана, затем “Import asset collections from TriG or Zip file”. Выберите zip-файл с GitHub и загрузите его в EDG. Нажмите Finish. Перейдите к таксономии — должна отобразиться иерархическая структура с различными категориями STEM.

Шаг 4: Передача таксономии в Neo4j

Кликните выпадающий список облака для управления интеграциями. В меню появится опция “Link to Neo4j Database”.

При клике выберите созданную в шаге 2 интеграцию Neo4j.

После выбора создастся интеграция между таксономией и экземпляром Neo4j. Она отобразится в попапе ниже. Кликните по интеграции для перехода к ней. В примере она называется “Integration with Neo4j database neo4jtest1”. Затем нажмите “Ok”.

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

Нажмите edit и прокрутите к “included classes”. Здесь указываются классы таксономии для передачи в экземпляр Neo4j. Для руководства выберите “Concept”. Это охватит всю таксономию. Это важно для крупных таксономий с множеством классов.

Также установите “always overwrite” в “True”. Это гарантирует перезапись содержимого в Neo4j при передаче.

Нажмите “Save Changes”.

Вернитесь в интерфейс редактора и кликните иконку облака со стрелкой в верхней панели, поскольку интеграция с Neo4j установлена. Появится попап вроде изображения ниже. Если настроено несколько интеграций, они все отобразятся. Для руководства видна только одна, и она выбрана автоматически. Нажмите “Ok”.

Отобразится прогресс-бар передачи понятий в Neo4j.

Шаг 5: Изучение данных в Neo4j

Вернитесь к экземпляру Neo4j Aura. Кликните Instances в левой панели — увидите созданный в шаге 1 экземпляр. Теперь в нем есть узлы и отношения!

Нажмите “Connect”, затем “Explore” — это откроет визуальное представление графа.

В визуальном исследователе Neo4j Aura выполните поиск по общему термину “Resource – BROADER – Resource”, чтобы увидеть все понятия, переданные из EDG, вместе с их родительскими понятиями.

Шаг 6: Загрузка статей в Neo4j

Скачайте список статей из академических журналов с GitHub. Это краткий перечень фиктивных статей. Идея в том, чтобы таксономия поступала из EDG, а метаданные статей — из другого источника.

В Neo4j нажмите “Import” в левой панели и “New data source”. Появится список опций. Экземплярные данные можно импортировать откуда угодно, но для руководства загрузим CSV-файл напрямую. Источник данных не важен; важно, чтобы экземплярные данные были помечены терминами из таксономии, управляемой в EDG. Так обеспечивается согласование метаданных статей с таксономией и более широким семантическим слоем.

Загрузите CSV с GitHub. Затем укажите, как определить модель. Выберите “Generate from schema”.

Articles.csv отобразится как узел. Кликните по узлу. Укажите свойство для первичного ключа. В списке статей есть свойство “id”, которое используем как ключ. Кликните иконку ключа в правом нижнем углу для строки “id”. Затем выберите “Run Import”.

Введите пароль экземпляра, который записали ранее. Импорт займет секунду, затем появится попап с результатами.

Видно, что создано 15 узлов. CSV содержал 15 статей, и каждая стала узлом. Вернитесь к Explore и выполните поиск “Articles.csv”. Статьи отобразятся в визуале розовым цветом рядом с категориями STEM зеленым. Это хорошо, но они еще не связаны. Для соединения экземплярных данных (статей) с категориями требуется Cypher-запрос.

Шаг 7: Связывание экземплярных данных с таксономией

Нажмите Query в левой панели. Введите в поле запроса:

// 1) Match every imported article node that has a topicUri MATCH (a:`Articles.csv`) WHERE a.topicUri IS NOT NULL // 2) Find the corresponding Concept by its uri property MATCH (c:Concept {uri: a.topicUri}) // 3) Create the TAGGED_WITH relationship (idempotent) MERGE (a)-[:TAGGED_WITH]->(c) // 4) Return a sanity check RETURN count(*) AS totalTaggedRelationships;

Это должно выглядеть так:

Нажмите “Run”. Под запросом отобразится “Created 15 relationships”. Это положительный знак. Вернитесь к Explorer. Выполните поиск “Articles.csv – TAGGED_WITH – Resource”. Теперь все розовые узлы связаны с зеленой таксономией!

Шаг 8: Создание рекомендательной системы

Выполним простые запросы на схожесть, чтобы показать использование построенного графа для рекомендаций. Сначала посмотрим на статью и ее категории. Введите Cypher-запрос в интерфейс. Он перечислит категории для статьи “Advances in Mathematical Software Studies #7”.

MATCH (a:`Articles.csv` {title: 'Advances in Mathematical Software Studies #7'}) MATCH (a)-[:TAGGED_WITH]->(c:Concept) RETURN a.title AS article, c.prefLabel AS tag, c.uri AS uri ORDER BY tag;

Должен отобразиться вывод с категорией “Mathematical Software”.

Предположим, нужно найти похожие статьи для рекомендации читателям. Можно искать другие статьи с Mathematical Software, но также использовать структуру таксономии. Mathematical Software — подкласс Computer Science по STEM-таксономии. В EDG можно изучить категории и их потомков. Для рекомендательной системы, чтобы найти похожие на статью Mathematical Software, ищем другие статьи с Mathematical Software, а также с другими ветвями computer science.

Это достигается следующим Cypher-запросом:

// 0) Seed article by its real label MATCH (me:`Articles.csv` {title: 'Advances in Mathematical Software Studies #7'}) // 1) get each tagged topic plus its parent MATCH (me)-[:TAGGED_WITH]->(child:Concept)-[:BROADER]->(parent:Concept) // 2) find any other article tagged with a sibling under that same parent MATCH (siblingChild:Concept)-[:BROADER]->(parent)<-[:BROADER]-(child) MATCH (rec:`Articles.csv`)-[:TAGGED_WITH]->(siblingChild) WHERE rec <> me // 3) compute recommendation score WITH rec, count(DISTINCT parent) AS score // 4) now pull in all the direct tags on each recommended article OPTIONAL MATCH (rec)-[:TAGGED_WITH]->(t:Concept) // 5) return title, score, and full tag list RETURN rec.title AS recommendation, score AS sharedParentCount, collect(DISTINCT t.prefLabel) AS allTaggedTopics ORDER BY score DESC, recommendation LIMIT 5;

Результаты должны быть следующими:

Нет других статей с Mathematical Software, но есть с другими ветвями computer science. “Advances in Computers and Society Studies” помечена “Computers and Society”. Она рекомендуется, поскольку граф знает, что Computers and Society и Mathematical Software — ветви Computer Science.

Шаг 9: Корректировка таксономии

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

Предположим, требуется переклассифицировать Mathematical Software как ветвь Mathematics вместо Computer Science. В таксономии достаточно перетащить термин в дерево структуры EDG.

Теперь передайте таксономию обратно в Neo4j с помощью той же кнопки облака.

Вернитесь в Neo4j и запустите алгоритм рекомендаций снова — результаты полностью изменятся. Это потому, что исходная статья помечена Mathematical Software, теперь классифицированной как ветвь Mathematics. Рекомендуемые статьи теперь касаются математики, а не computer science.

Заключение

Эта простая демонстрация показывает, как таксономия добавляет структуру, гибкость и интеллект приложениям для работы с данными. Отделяя таксономию (в EDG) от экземплярных метаданных (в Neo4j), достигается возможность вывода отношений, согласования систем и эволюции модели со временем без перемаркировки или перестройки downstream-приложений. В итоге получается модульная архитектура, которая делает граф умнее по мере роста понимания домена.