Лучшая практика хранения нейронной сети в базе данных

Это зависит от намерения прогресса в модели.

1. У вас есть зацикленное представление о неизменной структуре сети? Как карта Кохоннена. Или готовая модель.
2. У вас есть несколько структур отношений, которые вам нужно протестировать, чтобы иметь возможность переключаться между различными структурами?
3. Рассматривает ли ваша модель узлы как текучие автоматы, которые могут свободно искать своих соседей? Где каждый автомат вырабатывает уникальные характеристические значения общего набора параметров, и вам нужно проанализировать, как эти значения влияют на их «выбор» соседей.
4. У вас есть фиксированный набор параметров для фиксированного количества типов/классов узлов? Или ожидается, что узел будет развивать уникальный набор атрибутов и отношений?
5. Вам часто требуется доступ к каждому узлу, особенно к тем, которые глубоко встроены в сетевые уровни, для их анализа и сопоставления?
6. Воспринимаема ли ваша сеть как набор конечных автоматов или квантуется?

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

Категория, параметр и атрибут
Можем ли мы классифицировать транспортные средства по количеству колес или тоннажу? Должны ли количество колес или тоннаж быть атрибутами, параметрами или характеристиками категории.

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

• Тип 1: все узлы имеют общий набор параметров, поэтому узел можно смоделировать в виде таблицы с известным количеством столбцов.

• Тип 2: Существуют различные классы узлов. Существует фиксированное количество классов узлов. Каждый класс имеет фиксированный набор параметров. Поэтому для каждого класса узлов существует таблица характеристик.

• Тип 3: нет намерения классифицировать узлы. Каждый узел может свободно развиваться и приобретать свой собственный уникальный набор атрибутов.

• Тип 4: существует фиксированное количество классов узлов. Каждый узел внутри класса может свободно развиваться и приобретать свой собственный уникальный набор атрибутов. Каждый класс имеет ограниченный набор атрибутов, которые может приобретать узел.

Прочитайте о модели EAV, чтобы понять проблему параметры против атрибутов. В таблице EAV узлу нужны только три характеризующих столбца:

• идентификатор узла
• имя атрибута
• значение атрибута

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

• идентификатор узла
• тип атрибута
• имя атрибута
• значение атрибута

Последовательный/связанный доступ по сравнению с хешированным/прямым адресным доступом
Требуется ли вам прямой доступ к отдельным узлам, а не обход структурного дерева, чтобы быстро добраться до узла?

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

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

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

Заключение

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

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

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

SELECT id FROM Nodes a, NumericAttributes b
WHERE a.attributeName = $name
  AND b.value WItHIN $range
  AND a.id = b.id

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

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

Деревья можно хранить в таблице с помощью внешних ключей, ссылающихся на самих себя. Я предполагаю, что нужно сохранить только две вещи: топологию и веса; оба они могут храниться в сглаженной древовидной структуре. Конечно, это может потребовать большого количества рекурсивных операций выбора, которые в зависимости от вашей СУБД могут быть трудными для реализации в исходном виде (таким образом, для выполнения требуется множество SQL-запросов). Я не могу комментировать сравнение, но, надеюсь, это поможет с реляционной точки зрения :)