贝叶斯网络python代码,python实现贝叶斯网络的特定应用程序

我在空闲的时间里一直在做这种事。我想我现在是我的第三个或第四个版本的这个相同的问题。我实际上准备发布另一个版本的Fathom(https://github.com/davidrichards/fathom/wiki)包括动态贝叶斯模型和不同的持久层。

正如我试图让我的答案清楚，它已经相当长。我为此道歉。这里是我一直在攻击的问题，这似乎回答了你的一些问题(有点间接)：

我开始与犹太珍珠的信念传播在贝叶斯网络的故障。也就是说，它是来自父母的先前赔率(因果支持)和来自儿童的可能性(诊断支持)的图表。这样，基本类只是一个BeliefNode，很像你所描述的BeliefNodes之间的一个额外的节点，一个LinkMatrix。这样，我明确选择我使用的类型的可能性我使用的LinkMatrix类型。这使得更容易解释信任网络后来做什么以及使计算更简单。

任何子类化或我将对基本BeliefNode的更改将用于分级连续变量，而不是更改传播规则或节点关联。

我决定将所有数据保存在BeliefNode中，并且只有LinkedMatrix中的固定数据。这与确保我保持干净的信任更新与最少的网络活动。这意味着我的BeliefNode存储：

>一个孩子引用数组，以及来自每个孩子的过滤的可能性以及为该孩子进行过滤的链接矩阵

>父引用数组，以及来自每个父的过滤的先验概率和为该父进行过滤的链接矩阵

>节点的组合可能性

>节点的组合的先前赔率

>计算的置信度或后验概率

>所有先前赔率和可能性遵守的属性的有序列表

根据节点之间的关系的性质，可以用许多不同的算法来构造LinkMatrix。你描述的所有模型都将是你将采用的不同类。可能最简单的事情是默认为一个或门，然后选择其他方式来处理LinkMatrix如果我们在节点之间有一个特殊的关系。

我使用MongoDB持久性和缓存。我访问这个数据在一个事件模型内的速度和异步访问。这使得网络性能相当高，而且如果需要的话也有机会非常大。此外，由于我以这种方式使用Mongo，我可以轻松地为同一个知识库创建一个新的上下文。因此，例如，如果我有诊断树，诊断的一些诊断支持将来自患者的症状和测试。我做的是为该患者创建一个上下文，然后基于该特定患者的证据传播我的信念。同样，如果医生说一个病人可能经历两种或更多种疾病，那么我可以改变一些我的链接矩阵，以不同的方式传播信念更新。

如果你不想为你的系统使用Mongo，但是你计划让多个消费者在知识库上工作，你将需要采用某种缓存系统，以确保你正在新鲜工作更新节点。

我的工作是开源的，所以你可以跟随，如果你想。它是所有的Ruby，所以它会类似于你的Python，但不一定是一个drop-in的替换。我喜欢我的设计的一件事是，人类解释结果所需的所有信息可以在节点本身，而不是在代码中找到。这可以在定性描述中或在网络的结构中完成。

所以，这里有一些重要的区别，我有你的设计：

>我不计算类内的似然模型，而是在链路矩阵内的节点之间。这样，我没有在同一个类中组合几个似然函数的问题。我也没有一个模型与另一个模型的问题，我可以只使用两个不同的上下文为相同的知识库和比较结果。

>我通过使人类的决策显而易见，增加了很多透明度。也就是说，如果我决定在两个节点之间使用默认或门，我知道当我添加它，并且它只是一个默认的决定。如果我以后回来更改链接矩阵并重新计算知识库，我有一个注释，为什么我这样做，而不只是一个应用程序选择一种方法。你可以让你的消费者记录这种事情。然而，你解决这个问题，从分析师那里得到一个逐步的对话框，它可能是一个好主意，为什么他们设置的方式比另一个。

>我可能更清楚先前的赔率和可能性。我不知道肯定的，我只是看到，你使用不同的模型来改变你的似然数。如果你的计算后验信念的模型没有以这种方式破坏，我所说的大部分可能是完全不相关的。我有能力做出三个异步步骤的好处，可以按任何顺序调用：将改变的可能性上传到网络，通过改变先前的赔率下降网络，并重新计算节点本身的组合信念(后验概率) 。

一个大的警告：我所说的一些还没有发布。我工作的东西，我说的，直到今天早上约2:00，所以它绝对是目前的，绝对得到我的定期关注，但还不是所有的公开。因为这是我的激情，如果你愿意，我乐意回答任何问题或在一个项目上一起工作。