автор Гржегож Рыбак, инженер по обработке данных, deepsense.ai
Введение
Мы можем сделать гораздо больше с данными, чтобы сделать системы более интеллектуальными, прежде чем мы перейдем к конвейеру машинного обучения, — д-р Джим Уэббер, главный научный сотрудник Neo4j [Графики для искусственного интеллекта и машинного обучения, доклад на конференции» ]
Использование графов в ИИ в последнее время стало совершенно очевидным благодаря увеличению числа исследовательских работ [рис. 1] и некоторым впечатляющим примерам в отрасли использования архитектур на основе графовых нейронных сетей, таких как AlphaFold 2, которые привлекли внимание сообщества к GraphML.
Но, возможно, фокус на этой области затмевает более широкий взгляд на применение графов в науке о данных и некоторые другие преимущества, которые они могут принести в целом?
Эта статья призвана ответить на вопрос: существуют ли способы улучшить реализацию проекта с помощью графов еще до того, как они достигнут GraphML?
Спойлер: да — бывает.
Графики знаний и базы данных графов
Начнем с основ,графы — это абстрактный тип данных, существующий в различных формах и формах реализации. Вот несколько примеров объектов графа для контекста:
● Графические алгоритмы (в частности, знаменитый Dijkstra для поиска кратчайшего пути или PageRank, оригинальный алгоритм поисковой системы Google).
● Концепция Semantic Web Тима Бернера-Ли.
● GraphQL (графоподобный дизайн API)
● 3D сетчатые структуры
Для нужд этой статьи я сосредоточусь на одном конкретном типе графового приложения: графовых базах данных.
Базы данных графов — это реализация графов, улучшенная за счет эффективного сохранения данных, надежного языка запросов к графам для запроса данных и их взаимосвязей, а также (в зависимости от поставщика БД) интерактивной визуализации графических данных в БД для упрощения исследования и анализа данных. .
Базы данных графов вводят терминологию «узлов» для субъектов/объектов данных и «ребер» для отношений между данными.
Они также могут расширять саму структуру данных графа новыми функциями — в частности, базы данных Labeled Property Graph позволяют давать метки различным узлам данных (которые могут работать как система типов или даже «тегов») и добавлять свойства как на узлы, так и на отношения.
В то время как можно смоделировать свою базу данных так, чтобы отношения могли иметь любое значение (или даже вообще не иметь значения, и их цель состоит в том, чтобы только соединить данные, например, в определенном геометрическом образце), особенно интересный аспект графовых баз данных для науки о данных цель состоит в том, что они поддерживают формирование графов знаний — представления данных в виде графа, в котором связи между объектами имеют определенное семантическое значение, позволяющее расширить возможности рассуждений при перемещении по графу.
Для графов знаний требуется база знаний — ресурс (или множество ресурсов вместе взятых), определяющий семантику отношений между объектами в графе. В строгом смысле (обычно воспринимаемом сообществом графов знаний как правильный) такая база знаний должна представлять собой формальное описание всех возможных взаимосвязей в предметной области — например, можно построить граф знаний, ориентированный на автомобильную промышленность. поверх таксономии schema.org для понятия «транспортное средство».
Однако я ослаблю это строгое определение базы знаний и буду рассматривать любую модель данных, описывающую объекты и отношения между ними, также как базу знаний, так как это упростит введение будущих концепций, оставаясь при этом фактическим. Другими словами, до тех пор, пока данные вашего графа отражают значения, которые вы определили с помощью любой онтологии, таксономии или модели данных, созданной специально для вашего проекта, в этой статье они будут считаться графом знаний.
На рынке есть две основные технологии графовых баз данных, и обе, в принципе, поддерживают создание графов знаний:
- RDF (структура описания ресурсов)
- LPG (графики свойств с метками)
Хотя прямое сравнение двух технологий выходит за рамки этой статьи, вот полезная статья, показывающая основные различия между ними.
Определив общее понимание концепции графа знаний в контексте баз данных графов, давайте теперь приступим к изучению того, как их можно использовать.
Graphs в проекте по науке о данных — что там еще, кроме graphML?
Чтобы ответить на этот вопрос, я воспользуюсь великолепной презентацией доктора Виктора Ли (вице-президент по машинному обучению в Tigergraph — одной из компаний-поставщиков БД для сжиженного нефтяного газа) на последнем выпуске конференции Connected Data World:
«Графические алгоритмы и графическое машинное обучение: осмысление сегодняшнего выбора»
Во время выступления доктор Ли разбивает типичный проект ИИ на пять основных этапов:
- Получение данных
- Очистка данных
- Извлечение/выбор признаков
- Обучение модели
- Развертывание модели
Первые три этапа составляют прекрасную основу для списка преимуществ, который я хотел бы расширить на основе личных выводов из прошлых граф-проектов — они следующие:
- Интуитивное моделирование данных.
- Улучшенное исследование данных и обнаружение данных.
- Более быстрые итерации модели данных и повышенная гибкость при изменении модели данных.
- Расширенные возможности разработки/выбора функций, в частности:
- Более простой запрос взаимосвязанных (или косвенно связанных) данных, чем в табличных данных — улучшенный выбор функций.
- Обогащающие данные преобразования графа (прежде всего: создание путей к данным, вычисляемые свойства, реструктуризация данных в графе).
- Алгоритмы обработки графических данных (в зависимости от поставщика БД), в том числе:
- Обнаружение центральности и сообщества, прогнозирование ссылок, сходство графиков и другие полезные алгоритмы, добавляющие дополнительные информационные измерения к вашим данным.
Давайте теперь проанализируем эти преимущества один за другим в контексте выделенных этапов проекта ИИ из презентации доктора Ли.
Диаграмма преимуществ на разных этапах проекта
Этап 1. Сбор данных
Преимущество 1. Интуитивное моделирование данных
Графики просты в дизайне моделирования данных (другими словами, они удобны для доски). По сути, это карты разума, которые упрощают интуитивное планирование потока данных и разработку модели данных графа, поскольку нет необходимости беспокоиться о каких-либо первичных/внешних ключах или правилах структуры, которым должны следовать ваши данные.
Кроме того, интеллект-карты помогают объяснить идеи моделирования данных заинтересованным сторонам проекта, потому что они обычно более понятны, чем, например. Сопоставления отношений SQL.
Дополнительные преимущества: использование открытых стандартов данных с помощью онтологий данных (функция, характерная для баз данных RDF).
В том, что можно охарактеризовать как наиболее близкое к переносному обучению в мире баз данных, базы данных RDF поддерживают построение графов знаний поверх онтологий данных с открытым исходным кодом, то есть общедоступных моделей данных графов знаний конкретных или общих предметных областей. Это, в свою очередь, может значительно ускорить процесс модификации вашей модели данных. Как описал один из поставщиков БД RDF, Ontotext, в одной из своих статей:
"Сейчас вы можете подумать: "Это все хорошо, но создание реалистичной карты всех этих отношений с самого начала кажется геркулесовой задачей". Вы не ошибетесь, если не считать того, что вам не нужно строить диаграмму знаний с нуля».
Статья Графики на местах, часть I: сила графов знаний в финансовой отрасли, раздел: Использование внешних знаний [Источник]
Например, если вам нужно отобразить финансовые данные в вашем проекте, вы можете использовать всю или фрагменты бизнес-онтологии финансовой отрасли как часть своей собственной модели данных.
Обратите внимание, что некоторые поставщики LPG DB также предоставляют способы использования внешних онтологий в LPG через расширения базы данных, например Neo4j с их плагином неосемантики (пример: FIBO в neo4j LPG DB).
Этап 2. Очистка данных
Преимущество 2. Улучшенное исследование и обнаружение данных
Упростите визуализацию, исследование и взаимодействие с данными
Одним из ключевых преимуществ преобразования данных в формат графа является то, что многие базы данных графов обеспечивают интерактивную визуализацию ваших данных. Это означает, что разработчик/специалист по данным часто может получить больше информации и «видеть» данные лучше, чем когда они представлены в табличном формате. Это также означает, что легче найти несоответствия и неправильные шаблоны данных в ваших данных и исправить их на этом этапе, чем проводить анализ плохо работающей модели ML.
Более эффективное разрешение сущностей, управляемое человеком
Часто источники данных, используемые в проекте, имеют различную степень качества в отношении дубликатов. В ситуациях, когда в вашем проекте есть несколько источников данных — особенно когда данные являются взаимодополняющими, проблема может значительно увеличиться — объединение данных приводит к конфликтам или скрытым повторяющимся объектам, скрывающимся во всех ваших данных.
Приведенный ниже набор данных из серии статей что приготовить, создающий граф знаний о пищевых показателях из коллекции рецептов https://medium.com/neo4j/whats-cooking-part-5-dealing-with-duplicates-a6cdf525842a показывает это на реальных данных (и это только из одного источника данных):
Таким образом, возможность визуализации данных упрощает выборочную проверку таких явлений по сравнению со стандартными табличными данными. Кроме того, в применимых сценариях это позволяет более эффективно сотрудничать с вашими аналитиками данных или экспертами в предметной области для выявления и устранения таких случаев, не зная технических деталей вашей базы данных (или языка запросов).
Преимущество 3: более простые итерации модели данных
Гибкость и простота итераций
Базы данных графов не содержат схемы и не требуют определения какой-либо структуры/ограничений/правил заранее, когда вы начинаете строить/расширять структуру своего графа (так называемую «модель данных»).
Кроме того, практически любую задачу можно представить в виде графа, потому что графы концептуально просты — они представляют собой просто набор вершин и ребер между ними.
Эти две характеристики делают базы данных графов очень гибкими и гибкими. И поскольку они не ограничены какими-либо правилами проектирования, они очень удобны для итераций — изменение модели данных графа доставляет гораздо меньше хлопот, чем, например. денормализация схемы SQL.
Все это открывает дополнительную степень свободы в проекте — вы можете сосредоточиться на обнаружении ваших данных «по мере их развертывания», а не настраивать схему ваших данных на ранней стадии (возможно, когда вы еще не знаете данные), а затем бороться с любыми проблемами. изменения или, что еще хуже, придерживаться схемы, которая не позволит вам ответить на критически важные вопросы проекта.
[https://youtu.be/GekQqFZm7mA?t=640 фрагмент выступления с 10:40 до 13:14 говорит об этом подробнее.]
Этап 3. Извлечение/выбор функций
Преимущество 4: расширенные возможности разработки/выбора признаков с помощью языка запросов графа
Простота запроса косвенно связанных данных
Одним из основных преимуществ графов является то, насколько «дешево» их просматривать по сравнению с дорогостоящими объединениями в реляционных базах данных.
На рисунке выше показано, как выполнить довольно нетривиальный запрос для всех людей, упомянутых в любом твите, связанном с твитом, который прокомментировал наш «основной пользователь». Такие запросы данных требуют нескольких «переходов» через наши данные, но они занимают примерно 4 строки.
Вот пример того, как аналогично взаимосвязанный запрос данных может в крайних случаях сравниваться с данными в реляционной базе данных:
Если ваш проект часто опирается на такие вопросы, как: «Каковы следующие N-е соединения с элементом X и как они изменятся, если я изменю X?» Или, если вам нужно ежедневно запрашивать пути между вашими данными — хранение данных в графе может быть большим преимуществом из-за того, сколько времени вы сэкономите при запросе этих данных — как с точки зрения разработки, так и поддержки запросов, а также с точки зрения производительности БД.
Примечание: этот раздел использовался с Cypher — языком запросов графа, реализованным в нескольких базах данных LPG, включая Neo4j, RedisGraph и Memgraph — в качестве примера для сравнения с SQL. Запрос к базе данных графа RDF (с использованием языка запросов SPARQL) будет выглядеть немного иначе; вот сравнение.
Обогащающие данные преобразования графов
Удобные языки запросов к графам, способные преобразовывать данные, дают еще одно преимущество таблице — вы можете использовать их для выполнения вычислений с данными графа и их сохранения.
Известные примеры улучшения ваших данных:
— Определение и создание новых путей/отношений данных между заданными точками данных.
– Создавайте вычисляемые свойства на основе близких и удаленных отношений.
– Реструктурируйте/изменяйте форму данных непосредственно в графе.
Именно это преимущество баз данных графов использует trase.finance — платформа на основе базы данных графов для отслеживания, мониторинга и расчета крупнейших факторов, влияющих на вырубку лесов в регионах тропических лесов Бразилии и Индонезии.
Как показано на рисунке ниже, trase.finance использует преобразования графов, обогащающие данные (в частности, генерацию вычисляемых свойств), для динамического распространения параметров риска обезлесения и объема обезлесения по юридической иерархии компании и цепочкам владения акциями.
Преимущество 5: Наука о графических данных
Наконец, в качестве последней части сверхспособностей, связанных с данными, хранящимися в базах данных графов, давайте кратко упомянем различные полезные алгоритмы графов, часто непосредственно встроенные в базы данных графов. Поскольку это та область, в которой «просто» наука о данных и что такое graphML, является наиболее размытым, я дам здесь только общий обзор, чтобы его можно было подробнее изучить вместе с другими решениями ML в будущей статье. посвященный GraphML.
Этот аспект, как правило, больше всего различается между RDF и LPG, а внутри них, их различными поставщиками и реализациями БД, но основная концепция основана на одном и том же — использовать структуру данных для выполнения алгоритма над ними и получения значимой аналитики. .
Обычный сценарий для баз данных графов, особенно наблюдаемый у поставщиков баз данных Labeled Property Graphs, состоит в том, чтобы содержать отдельную «дополнительную» библиотеку, которая реализует набор алгоритмов «из коробки».
Одним из примеров этого является база данных TigerGraph с ее библиотекой данных Graph Data Science:
Другим примером является Neo4j DB с ее библиотекой GDS, вот полезная инфографика их примера набора алгоритмов графа:
Что касается мира RDF, то их дополнительная сила заключается в том, что помимо потенциальных встроенных графовых алгоритмов, поставщики БД RDF, благодаря интеграции с онтологиями на уровне ядра, реализуют так называемый механизм рассуждений, который позволяет БД двигатель, чтобы сделать выводы из соединений.
Например, представьте, что у вас есть граф знаний для случая использования в автомобильной промышленности. Из-за рассуждений вы можете запросить данные для всего, что является транспортным средством, и результаты дадут нам именно это, даже если граф не имеет какой-либо связи это тип транспортного средства для наших узлов. Это связано с тем, что при условии, что данные правильно построены на онтологиях и, следовательно, соединения имеют истинную семантику, механизм БД может сделать вывод, что, например. любые мотоциклы также являются транспортными средствами, поскольку сущность мотоцикла определяется через онтологию (такую, как эта: https://schema.org/Motorcycle). Следовательно, вы можете рассматривать эту особенность баз данных RDF как форму машинного обучения, поскольку, пока вы сохраняете согласованную семантику связей между данными в модели данных, механизм БД имеет понимание того, что представляют собой объекты в базу данных.
С точки зрения примеров библиотек графовых алгоритмов, похожих на выделенные поставщики LPG, это выглядит менее заметно, чем в LPG — например, Ontotext, один из ведущих поставщиков RDF DB, предоставляет несколько функций графовой аналитики через свои плагины. Наиболее похожим примером поставщика БД, предлагающего сопоставимую библиотеку готовых графовых алгоритмов, является Stardog с их модулем графических алгоритмов.
Хотя продемонстрированную графовую аналитику можно считать в значительной степени представляющей неконтролируемое машинное обучение, в обоих типах графовых баз данных также есть примеры контролируемого машинного обучения.
Stardog DB расширяет идею рассуждений и позволяет создавать модели классификации, регрессии и подобия, используя семантически определенные объекты на графике в качестве меток. Подробнее можно узнать в их документации.
Для LPG библиотека Neo4j GDS также недавно начала поддерживать контролируемые алгоритмы машинного обучения — на момент написания этой статьи это: методы логистической регрессии и случайного леса, а также два встроенных конвейера машинного обучения: классификация узлов и предсказание ссылок, которые основаны на упомянутые методы.
Наконец, некоторые поставщики баз данных также предоставляют пользователям интерфейсы для создания собственных алгоритмов и моделей графов, если это необходимо. Например, Memgraph DB предоставляет объект модуля запросов, расширяемый с помощью Python, вместе с документами, содержащими объяснения того, как его расширить [источник]
Вероятно, для определенных случаев использования — например. Обнаружение сообщества или для определенных бизнес-требований ограниченного поиска пути — готовые графовые алгоритмы могут быть достаточными для любых потребностей ИИ в проекте и стать единственной причиной попробовать использовать графовые базы данных.
Выводы и дальнейшие действия
Вышеупомянутые пять преимуществ использования графов в проекте по науке о данных отвечают на первоначальный вопрос, поставленный во вводной части — можно улучшить реализацию проекта с помощью графов, даже не достигая стадии graphML.
Помещение данных в вашем проекте в структуру графа знаний через одну из графовых баз данных может принести несколько преимуществ рабочему процессу данных, а в некоторых случаях, из-за появления функций науки о графовых данных, уменьшить потребность во внедрении общепринятого подхода graphML в целом. .
В следующей статье серии будут рассмотрены способы интеграции реальных конвейеров машинного обучения с графами (с предварительным использованием баз данных графов или без них), а также рассмотрены потенциальные проблемы с данными, возникающие при их использовании в проекте. Оставайтесь с нами!
Дополнительные учебные ресурсы
● Введение в теорию графов: перспектива компьютерных наук — полезное введение (или повторение) в тему графов как абстрактного типа данных.
● 6 — Graph Data Science 1 6 What’s New — отличная презентация как общего обзора ИИ в графах с точки зрения поставщика БД графов, так и обзора функций библиотеки графовых данных Neo4j (обратите внимание, что существует версия 2.0). недавно выпущенная версия библиотеки, подробнее здесь)
● Доктор. Виктор Ли — Алгоритмы графов и машинное обучение графов: осмысление сегодняшнего выбора | CDW21 — обзор ландшафта ИИ в графиках
● https://levelup.gitconnected.com/knowledge-graph-app-in-15min-c76b94bb53b3 — интересный пример графа, не зависящий от БД, того, как быстро создать прототип приложения графа знаний, чтобы проверить полезность графа в проекте без использование любой из двух основных технологий графовой базы данных.
