Я занимался такими вещами в свободное время довольно долго.Я думаю, что сейчас у меня третья или четвертая версия этой же проблемы.На самом деле я готовлюсь к выпуску еще одной версии Fathom (https://github.com/davidrichards/fathom/wiki) с включенными динамическими байесовскими моделями и другим уровнем персистентности.
Поскольку я пытался прояснить свой ответ, он стал довольно длинным.извиняюсь за это. Вот как я атаковал проблему, которая, кажется, отвечает на некоторые ваши вопросы (несколько косвенно):
Я начал с распада убеждений Иудеи Перл в Байесовской сети.это график с предыдущими коэффициентами (причинная поддержка), исходящими от родителей, и вероятностями (диагностическая поддержка), исходящими от детей. Таким образом, базовый класс - это просто BeliefNode, очень похожий на то, что вы описали с дополнительным узлом между BeliefNodes,LinkMatrix. Таким образом, я явно выбираю тип вероятности, который я использую, по типу LinkMatrix, который я использую. Это облегчает объяснение того, что сеть убеждений делает впоследствии, а также упрощает вычисления.
Любые подклассы или изменения, которые я внесу в базуc BeliefNode предназначен для связывания непрерывных переменных, а не для изменения правил распространения или ассоциаций узлов.
Я решил сохранить все данные внутри BeliefNode и только фиксированные данные в LinkedMatrix.Это связано с тем, что я поддерживаю чистые обновления убеждений при минимальной сетевой активности.Это означает, что мой BeliefNode хранит:
- массив дочерних ссылок вместе с отфильтрованными вероятностями, приходящимися от каждого дочернего элемента, и матрицу ссылок, которая выполняет фильтрацию для этого дочернего элемента
- anмассив родительских ссылок, а также отфильтрованные предыдущие шансы, исходящие от каждого родителя, и матрица ссылок, которая выполняет фильтрацию для этого родителя
- объединенная вероятность узла
- объединенные предыдущие коэффициентыузел
- вычисленное убеждение или апостериорная вероятность
- упорядоченный список атрибутов, которым все предшествующие шансы и вероятности придерживаются
LinkMatrix может быть создан с помощьюКоличество различных алгоритмов, в зависимости от характера отношений между узлами.Все модели, которые вы описываете, будут просто разными классами, которые вы будете использовать.Вероятно, проще всего сделать по умолчанию значение or-gate, а затем выбрать другие способы обработки LinkMatrix, если у нас есть особые отношения между узлами.
Я использую MongoDB для сохранения и кэширования.Я получаю доступ к этим данным внутри четной модели для скорости и асинхронного доступа.Это делает сеть достаточно производительной, а также имеет возможность быть очень большой, если это необходимо.Кроме того, поскольку я использую Mongo таким образом, я могу легко создать новый контекст для той же базы знаний.Так, например, если у меня есть диагностическое дерево, некоторая диагностическая поддержка для диагностики будет исходить от симптомов и тестов пациента.Что я делаю, так это создаю контекст для этого пациента, а затем распространяю свои убеждения, основываясь на доказательствах этого конкретного пациента.Аналогичным образом, если врач сказал, что пациент, вероятно, испытывает две или более болезней, то я мог бы изменить некоторые из моих матриц ссылок, чтобы по-разному распространять обновления убеждений.
Если вы не хотите использовать что-то вроде Mongoдля вашей системы, но вы планируете, чтобы над базой знаний работало более одного потребителя, вам нужно будет внедрить некую систему кэширования, чтобы постоянно работать с недавно обновленными узлами.
Моя работа с открытым исходным кодом, поэтому вы можете следить за ней, если хотите. Это все Ruby, поэтому он будет похож на ваш Python, но не обязательно будет заменой. Одна вещь, которая мне нравится в моем дизайне, это то, что вся информация, необходимая людям для интерпретации результатов, может быть найдена в самих узлах, а не в коде. Это можно сделать в качественных описаниях или в структуре сети.
Итак, вот некоторые важные отличия, которые у меня есть с вашим дизайном:
- Я не вычисляю модель вероятности внутри класса, а скорее между узлами внутри матрицы ссылок. Таким образом, у меня нет проблемы объединения нескольких функций правдоподобия в одном классе. У меня также нет проблемы одной модели против другой, я могу просто использовать два разных контекста для одной и той же базы знаний и сравнивать результаты.
- Я добавляю большую прозрачность, делая очевидными человеческие решения. То есть, если я решу использовать стандартный или-gate между двумя узлами, я знаю, когда я добавил это, и это было просто решение по умолчанию. Если я вернусь позже и изменю матрицу ссылок и пересчитаю базу знаний, у меня будет заметка о том, почему я это сделал, а не просто приложение, которое выбрало один метод вместо другого. Вы могли бы попросить своих потребителей делать заметки о подобных вещах. Тем не менее, если вы решите это, то, вероятно, будет хорошей идеей получить от аналитика пошаговый диалог о том, почему они настраивают все так или иначе.
- Я могу быть более точным в отношении предыдущих шансов и вероятностей. Я точно не знаю, я просто видел, что вы использовали разные модели для изменения вероятностных чисел. Многое из того, что я говорю, может быть совершенно неактуально, если ваша модель вычисления апостериорных убеждений не сломается таким образом У меня есть преимущество в том, что я могу сделать три асинхронных шага, которые можно вызывать в любом порядке: передать измененные вероятности вверх по сети, передать измененные предыдущие шансы вниз по сети и пересчитать объединенное убеждение (апостериорную вероятность) самого узла .
Одно большое предостережение: кое-что из того, о чем я говорю, еще не выпущено. Я работал над вещами, о которых говорю, до двух часов утра, так что это определенно актуально и определенно привлекает мое внимание, но пока еще не все доступно для публики. Поскольку это моя страсть, я буду рад ответить на любые вопросы или поработать вместе над проектом, если хотите.