На пути к глубокому обучению для реляционных баз данных

к Глубокому реляционному обучению

На пути к глубокому обучению для реляционных баз данных

Обобщение архитектур глубокого обучения для естественной интеграции с принципами и практикой реляционных баз данных.

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

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

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

Представления обучения

Несмотря на то, что в сотнях фреймворков и библиотек имеется бесчисленное множество готовых статистических моделей и моделей машинного обучения, один их аспект остается в основном универсальным — представление данных для обучения. Независимо от того, устраивает ли вас базовая логистическая регрессия, хотите ли вы перейти к древовидным ансамблям или создавать продвинутые модели глубокого обучения, независимо от того, решите ли вы платить за проприетарные решения с помощью SPSS или программировать с нуля с помощью Tensorflow, вы всегда ожидается предоставление данных в виде числовых тензоров, то есть n-мерных массивов чисел.

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

Здесь идея состоит в том, что характерные особенности появляются как часть самого процесса обучения, обычно называемого вложениями, т. е. числовыми векторными представлениями объектов, встроенных в общее n-мерное пространство.

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

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

Теперь возникает очевидный вопрос — не можем ли мы просто превратить эти структуры данных в наши векторы признаков (числовые тензоры) и напрямую использовать все хорошее машинное обучение (глубокое обучение), которое мы уже разработали? И хотя это очень заманчиво, у такого подхода есть глубокие проблемы:

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

Кстати, тензор тоже является примером реляционной структуры данных (это сетка). Если примерный тензор больше, чем ожидаемые входные данные модели, у нас большая проблема.

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

Для простоты предположим здесь только структуру данных графа. Если бы существовало однозначное инъективное отображение между графами и тензорами, оно тривиально решило бы (жесткую) проблему изоморфизма графов.

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

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

И хотя такое создание реляционных признаков полезно на практике, возможно, это не круто, поскольку оно несовместимо с основной идеей глубокого (представления) обучения. Итак, можем ли мы каким-то образом решить эту проблему, чтобы применять глубокое обучение к реляционным структурам принципиальным образом? Это, как ни странно, потребует решений, выходящих за рамки обычных средств глубокого обучения (таких как передача больших данных в больший Transformer…).

Реляционные представления

Что же это за реляционные представления и зачем они нам нужны? Начнем с популярного векторного представления данных обучения. Такие данные также можно рассматривать как таблицу, где каждый столбец соответствует функции (или целевому ярлыку), а каждая строка соответствует одному независимому учебный пример — вектор признаков. Следовательно, мы можем легко хранить векторы признаков в любой базе данных с помощью всего одной таблицы. Теперь предположим, что векторы признаков больше не являются такими независимыми, и один элемент в одном векторе признаков может фактически представлять тот же объект, что и другой элемент в другом векторе признаков. Это на самом деле очень распространено на практике, когда люди используют такие векторы для представления перекрывающихся последовательностей данных временных рядов, слов в предложении, предметов в корзине или фигур на шахматной доске. Во всех таких случаях элементы в этих векторах больше нельзя рассматривать как простые независимые значения, а ссылкина базовые объекты, которые затем нести реальные черты. Следовательно, концептуально мы теперь получаем 2 таблицы, где первая содержит, возможно, повторяющиеся ссылки на объекты во вторую таблицу, которая содержит (уникальные) значения характеристик объектов.

В формальной терминологии базы данных таблица также называется отношением, так как она связывает объекты из столбцов вместе.

Возможно, такие векторы также можно рассматривать как последовательности объектов. Затем это позволяет нам подумать об обобщении в векторы различной длины, что можно использовать в моделях последовательностей, таких как рекуррентные нейронные сети. Кроме того, такие последовательности могут начать разветвляться, приводя к представлению данных в виде дерева, например данных дерева синтаксического анализа предложений, и таких моделей, как рекурсивные нейронные сети. Наконец, мы можем обобщить данные, структурированные на основе графа, представляющие что угодно, от молекул до социальных сетей, что является представлением, в котором работают современные нейронные сети графов.

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

Подпадают ли все эти модели под реляционный формализм (базы данных)? Конечно, да — все это примеры обработки бинарных отношений. Это означает, что для хранения графа (последовательности, дерева) в базе данных достаточно создать единую таблицу с двумястолбцами, соответствующими двум узлам, соединенным край. Тогда каждый граф представляет собой просто набор таких ребер, каждое из которых хранится в отдельной строке. Для графов с различными метками связанные атрибуты могут быть снова эффективно сохранены в таблице с отдельными ссылками, как и раньше.

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

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

обратите внимание, что все используемые на практике языки для хранения и обработки структурированных данных, такие как SQL и ERM, следуют из реляционной алгебры и логики.

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

Реляционное машинное обучение

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

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

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

Глубокое реляционное обучение

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

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

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

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

Пример: Граф нейронных сетей

Итак, теперь мы уже знаем, что граф — это просто набор ребер (edge(X,Y)) между некоторыми узлами (X и Y). Суть любой модели GNN состоит в том, чтобы просто распространять и агрегировать представления узлов от их соседей (так называемая «передача сообщений»). В терминах реляционной логики это правило передачи сообщений может быть помещено в логическое правило как:

message2(X) <= message1(Y), edge(X, Y)

который можно интуитивно прочитать как:

Чтобы вычислить представление 'message2' объекта X, агрегируйте представление 'message1' всех таких объектов Y, где 'край' находится между X и Y.

Теперь давайте подробнее рассмотрим, что это означает с точки зрения формальной, декларативной, реляционной логики. Логические предикаты“message2”, “message1”и “edge” здесь представляют имена отношений, а логические переменные «X» и «Y» представляют собой ссылки на некоторые объекты. И «сообщение1», и «сообщение2» являются унарными отношениями, обычно представляющими некоторые атрибуты объекта, в то время как «ребро» — это бинарное отношение, связывающее два объекта вместе, то есть соединяющее два узла в графе с ребром здесь. Оператор «‹=» — это импликация, обычно записываемая справа налево в логическом программировании, означающая, что (истинное) значение правой части («тело» правила) подразумевает левое часть («голова» правила). Наконец, запятая "," представляет собой союз, означающий, что отношения "сообщение1(Y)" и "ребро(X, Y)" должны выполняться одновременно, т. е. для одних и тех же объектов Y и Х.

А теперь давайте посмотрим на тот же принцип с точки зрения базы данных (SQL), которая показывает, что происходит под капотом, с немного более знакомой, практической точки зрения. Мы уже знаем, что логические отношения соответствуют таблицам в базе данных. Точно так же логические переменные соответствуют своим столбцам. Таблица в «шапке» правила (левая часть) должна быть подразумеваемой (‹=), т. е. создана путем вычисления «тела» правила (правая часть). Логическое соединение «,» в теле соответствует соединению между соответствующими таблицами с ограничениями, следующими за соответствующей привязкой переменной. Например, здесь мы хотим объединить таблицы «message1» и «edge» в соответствующем столбце Y и сохранить столбец X (проекцию) результата в новую таблицу с именем «message2». И хотя может быть несколько объектов, для которых действует такое ограничение, т. е. несколько Y с «краем» от определенного X, нам также потребуется группировать X при объединении атрибуты соседних Y (мы также можем агрегировать значения из двоичного «ребра»). Таким образом, правило GNN на самом деле также соответствует простому SQL-запросу, который можно прочитать как:

Соедините таблицы «message1» и «edge» в столбце Y, сгруппируйте по X и объедините полученные значения в новую таблицу «message2».

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

там вы обычно видите представление таблицы «ребро» в виде матрицы смежности (вместо этого списка/таблицы смежности) и таблицы «сообщение1» в виде матрицы признаков/встраивания узлов. Шаг распространения, т. е. объединение и агрегирование, может быть выражен посредством матричного умножения двух.³

Теперь нам просто нужно добавить некоторые обучаемые параметры к этому шаблону вычислений, чтобы сделать его статистической моделью машинного обучения в обычном смысле. Это делается путем простого связывания каждого отношения в правиле с обучаемым (тензорным) весом.

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

Подводя итог, мы только что показали, как представить классическую модель GNN с глубоким обучением в виде простого параметризованного SQL-запроса. Разве это не красиво и странно? И хотя это может звучать как какая-то абстрактная концепция, которую вы могли прочитать в исследовательской статье, но которая на самом деле не работает на практике, давайте теперь проясним, что мы понимаем это очень буквально, с помощью следующего практического руководства по созданию в базе данных GNN.

Создание GNN в базе данных

Теперь давайте переключимся на практическую структуру, реализующую все вышеупомянутые принципы глубокого реляционного обучения, которые мы обсуждали до сих пор. Он называется PyNeuraLogicи подробнее о нем вы можете прочитать в предыдущей статье. Здесь давайте сразу перейдем к одному из его (недавних) модулей, касающихся сопоставления между представлениями реляционной логики, используемыми внутри фреймворка, и реляционными базами данных.

В отличие от обычных фреймворков глубокого обучения, ориентированных на тензоры, PyNeuraLogic строит все на логических отношениях. А поскольку отношения (таблицы) являются первоклассными объектами в структуре, нет необходимости в каком-либо специальном (проблемном) тензорном преобразовании, что делает его взаимодействие с реляционными базами данных чрезвычайно естественным. В частности, инфраструктура PyNeuraLogic оснащена набором инструментов для прямого сопоставления данных реляционной таблицы, обучения современных глубоких реляционных моделей непосредственно на ней и даже экспорта в простой код SQL, чтобы вы могли оценивать свои обученные модели непосредственно в своей базе данных!

Пример базы данных

Во-первых, давайте представим данные, с которыми мы будем работать в этой простой демонстрации. Наш пример базы данных содержит структурированную информацию о молекулах. Каждая молекула имеет некоторые атрибуты и состоит из различного количества атомов. Атомы также имеют некоторые атрибуты и могут образовывать атрибутные связи с другими атомами. Поэтому наша база данных состоит из трех таблиц — «молекула», «атом» и «связь».

В этом сценарии наша задача состоит в том, чтобы определить мутагенность молекулы, которая является одним из наиболее часто используемых тестов в реляционном обучении и GNN. Следовательно, нашей целевой меткой будет поле «мутагенный» в таблице «молекула». Теперь эти 3 таблицы, естественно, уже будут соответствовать 3 отношениям во фреймворке PyNeuraLogic. Однако мы также можем немного настроить это сопоставление. Например, нам может понадобиться сопоставить каждую строку таблицы «атом» с отношением «R.atom», используя только столбцы «atom_id» и «molecule_id» в качестве терминов отношения, а « заряд» в качестве значения отношения.

Обратите внимание, что присвоение значенийотношениям (реляционным фактам) выходит за рамки стандартного формализма реляционной логики, где значение ограничено либо True (присутствует), либо False (отсутствует). Расслабление до полного диапазона (тензорных) значений — это то, что позволяет PyNeuraLogic интегрировать функциональность глубокого обучения в принципы реляционной логики.

Обратите внимание, что это отображение очень гибкое. Конечно, мы могли бы взять «заряд» просто как еще один термин (в этом случае значение по умолчанию просто равно True или «1»), включить также столбцы «элемент» и «тип», или мы могли бы даже разделить таблицу на несколько вновь определенных отношений.

Чтобы создать экземпляр этого сопоставления таблицы отношений, мы затем создаем экземпляр объекта «DBSource» с «именем отношения», «именем таблицы» и «именами столбцов» (которые будут сопоставлены с терминами) в качестве аргументов. Для простоты мы будем использовать здесь только данные из таблиц «связь» и «атом»:

from neuralogic.dataset.db import DBSource, DBDataset

atoms = DBSource("atom", "atom", ["atom_id", "molecule_id"], 
                  value_column="charge")
bonds = DBSource("bond", "bond", ["atom1_id", "atom2_id", "type"],
                  default_value=1)

Далее, для контролируемого обучения нам также понадобятся метки запроса — то есть просто поле «мутагенный» в таблице «молекула». Поскольку это текстовые метки, мы просто хотим превратить их в числовые значения для стандартной (кроссэнтропийной) оптимизации ошибок, которую также можно настроить:

queries = DBSource("mutagenic", "molecule", ["molecule_id"], 
                    value_column="mutagenic",
                    value_mapper=lambda value: 1 if value == "yes" else 0
)

Наконец, мы просто объединяем эти сопоставления и устанавливаем соединение с базой данных через какой-либо совместимый драйвер базы данных (например, psycopg2 или MariaDB), чтобы создать реляционную logic_dataset:

import psycopg2

with psycopg2.connect(**connection_config) as connection:
    dataset = DBDataset(connection, [bonds, atoms], queries)
    logic_dataset = dataset.to_dataset()

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

Пример шаблона модели GNN

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

Это позволяет универсально трактовать задачу с различным объемом и структурой входных данных. Например, один пример молекулы здесь хорошо соответствует одной строке в таблице молекул, которую можно напрямую использовать в качестве входных данных для стандартных моделей (деревьев, SVM, нейронных сетей и т. д.). Но одна и та же молекула также охватывает разное количество строк в таблицах атом и связь, что очень проблематично для стандартных моделей, как объяснялось в предыдущей статье. Отсюда и обобщение моделей на шаблоны.

Шаблон, который мы определим здесь, сначала вычисляет вложения для каждого типа химической связи (тип связи — это просто ее кратность в range(1,8)). Затем мы добавляем два правила передачи сообщений (слои GNN), аналогичные описанным ранее в этой статье, для распространения представлений атомов и связей по всей молекуле. Наконец, шаблон определяет правило «считывания», которое объединяет представления всех узлов из всех слоев в одно «мутагенное» значение, которое передается в сигмовидную функцию и сопоставляется с меткой бинарного целевого запроса для классификации мутагенности.

это классическая архитектура модели GNN с пропущенными соединениями и дополнительным распространением встраивания ребер (связей), аналогично GIN.

from neuralogic.core import Template, R, V, Transformation

template = Template()

template += [R.bond_embed(bond_type)[1,] for bond_type in range(1, 8)]

template += R.layer1(V.A)[1,] <= (
    R.atom(V.N, V.M)[1,], R.bond_embed(V.B)[1,], R._bond(V.N, V.A, V.B) )

template += R.layer2(V.A)[1,] <= (
    R.layer1(V.N)[1,], R.bond_embed(V.B)[1,], R._bond(V.N, V.A, V.B) )

template += (R.mutagenic(V.M)[1,] <= (
    R.layer1(V.A)[1,], R.layer2(V.A)[1,], R.atom(V.A, V.M)[1,] )
) | [Transformation.IDENTITY]

template += R.mutagenic / 1 | [Transformation.SIGMOID]

PyNeuraLogic перегружает Python логическим программированием, так что вы можете писать шаблоны нейронных моделей с помощью таких параметризованных правил. R означает генератор отношения, V – переменная, [1,] – связанные весовые размеры (в данном случае скаляры), а <= соединяет реляционный шаблон из тело (правая сторона) к голове правила (левая сторона). Можно добавить дополнительную информацию, такую как функции активации не по умолчанию. Если это не имеет смысла, см. документацию для быстрого запуска.

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

from neuralogic.nn import get_evaluator
from neuralogic.core import Settings, Optimizer
from neuralogic.nn.init import Glorot
from neuralogic.nn.loss import CrossEntropy
from neuralogic.optim import Adam

settings = Settings(
    optimizer=Adam(), epochs=2000, initializer=Glorot(), 
    error_function=CrossEntropy(with_logits=False)
)

neuralogic_evaluator = get_evaluator(template, settings)
built_dataset = neuralogic_evaluator.build_dataset(logic_dataset)

for epoch, (total_loss, seen_instances) \ 
    in enumerate(neuralogic_evaluator.train(built_dataset)):

    print(f"Epoch {epoch}, total loss: {total_loss}, 
            average loss {total_loss / seen_instances}")

Преобразование нейронных моделей в SQL

Кроме того, с помощью всего нескольких строк кода модель, которую мы только что построили и обучили, можно превратить в (Postgres) код SQL. Таким образом, вы сможете оценить модель на дополнительных данных непосредственно на сервере вашей базы данных, не устанавливая NeuraLogic или даже Python. Подойдет и простой PostgreSQL!

Все, что нам нужно сделать, это создать преобразователь, который использует нашу модель, «сопоставления таблиц» и настройки. Сопоставления таблиц аналогичны «DBSource», описанному ранее, для сопоставления между отношениями и таблицами:

from neuralogic.db import PostgresConverter, TableMapping


convertor = PostgresConverter(
    neuralogic_evaluator.model,
    [
        TableMapping("_bond", "bond", ["atom1_id", "atom2_id", "type"]),
        TableMapping("atom", "atom", ["atom_id", "molecule_id"], 
                      value_column="charge")
    ],
    settings,
)

После первоначальной настройки (см. документацию) вы можете установить свою актуальную модель в виде кода SQL, который можно получить, просто вызвав to_sql:

sql = convertor.to_sql()

Теперь вы настроены и готовы оценить свою обученную модель непосредственно в базе данных, не покидая ее. Для каждого обучающего представления будет соответствующая функция в «нейрологическом» пространстве имен. Допустим, мы хотели бы оценить нашу модель на молекуле с идентификатором «d150» — теперь это так же просто, как сделать один оператор SELECT:

SELECT * FROM neuralogic.mutagenic('d150');

Точно так же мы можем запросить все возможные замены и их значения, используя «NULL» в качестве заполнителя, например. запрашивая все предсказания молекулы здесь:

SELECT * FROM neuralogic.mutagenic(NULL);

И точно так же мы можем проверять даже внутренние представления модели! Например, мы можем запросить значение химического вещества атом с идентификатором"d15_11" из первого слоя:

SELECT * FROM neuralogic.layer1('d15_11');

Заключение

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

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

Просто экстраполируя пример GNN, ничто не мешает вам расширить отношения с более высокой арностью, различные шаблоны распространения, объединяющие большее количество таблиц, и объединять их в программы иерархической логики (SQL) новыми способами. Таким образом, не нужно ждать, пока NeurIPS в следующем году представит новый раунд новых идей глубокого гиперграфа, глубокого метаграфа, глубокого рассуждения, глубокой логики и других идей глубокого реляционного обучения — вы уже можете начать просто объявлять их самостоятельно в PyNeuraLogic прямо сейчас.

Просто $pip install neuralogic начните воплощать эти идеи в жизнь или свяжитесь с нами, если вам это интересно!

в этой статье мы не делаем особых различий между векторным и тензорным представлениями, поскольку вы всегда можете перевести одно в другое, зная размерности, которые всегда известны/фиксированы в стандартных моделях глубокого обучения.
конечно, обход графов с помощью рекурсивных самосоединений в реляционной базе данных не самый эффективный способ обработки этих структур (например, для этого существуют специализированные базы данных графов). Тем не менее, NeuraLogic использует специальный, высокоэффективный механизм реляционного (логического) вывода на основе CSP, который очень подходит для сложных структурированных запросов к сильно взаимосвязанным структурам.
эта матричная форма, возможно, тоже очень элегантна, но это применимо только к базовым моделям GCN. Переходя к более выразительным моделям GNN, использующим, например, графовые (под)структуры и более продвинутые схемы распространения, матрично-алгебраический формализм очень быстро запутывается, в то время как формализм реляционной логики остается точно таким же.

Автор благодарен Лукасу Заграднику за корректуру этих постов, создание туториала и разработку PyNeuraLogic.

На пути к глубокому обучению для реляционных баз данных

к Глубокому реляционному обучению