贝叶斯网络python实现_特定应用的贝叶斯网络的pythonic实现

我在业余时间一直在做这种事。我想我现在也在研究这个问题的第三或第四个版本。我正在准备发布另一个Fathom版本(https://github.com/davidrichards/Fathom/wiki)，其中包含动态贝叶斯模型和不同的持久层。

当我试图把我的答案说清楚的时候，它变得很长。我为此道歉。以下是我如何解决这个问题，它似乎回答了你的一些问题(有些间接)：

我先从朱迪亚·珀尔(JudeaPearl)在贝叶斯网络中的信念传播崩溃说起。也就是说，这是一个图表，其中有来自父母的先验概率(因果支持)和来自孩子的可能性(诊断支持)。这样，基本类就只是一个BeliefNode，很像您描述的BeliefNode之间有一个额外的节点，一个LinkMatrix。通过这种方式，我显式地根据我使用的LinkMatrix类型选择我正在使用的可能性类型。它使人们更容易解释信念网络在事后的行为，同时也使计算变得更简单。

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

我决定将所有数据保存在BeliefNode中，而只在LinkedMatrix中固定数据。这与确保我用最少的网络活动保持干净的信念更新有关。这意味着我的BeliefNode存储：子引用的数组，以及来自每个子引用的筛选的likelihood和为该子引用进行筛选的链接矩阵

父引用的数组，以及来自每个父引用的已筛选优先赔率和正在为该父引用进行筛选的链接矩阵

节点的组合似然

节点的综合先验概率

后验概率，后验概率

所有先前的几率和可能性都遵循的属性的有序列表

根据节点之间关系的性质，可以使用许多不同的算法来构造链接矩阵。您描述的所有模型都是您将使用的不同类。可能最简单的事情是默认使用or门，然后如果节点之间有特殊关系，则选择其他方法来处理链接矩阵。

我使用MongoDB进行持久性和缓存。我在事件模型中访问这些数据，以实现速度和异步访问。这使得网络性能相当好，同时如果需要的话，也有机会变得非常庞大。另外，由于我正以这种方式使用Mongo，我可以轻松地为相同的知识库创建一个新的上下文。例如，如果我有一个诊断树，那么诊断的一些诊断支持将来自患者的症状和测试。我所做的是为那个病人创造一个环境，然后根据那个病人的证据传播我的信仰。同样，如果医生说一个病人可能患有两种或两种以上的疾病，那么我可以改变一些链接矩阵来传播不同的信念更新。

如果您不想在系统中使用Mongo之类的东西，但您计划让多个使用者使用知识库，则需要采用某种缓存系统，以确保您始终在使用最新更新的节点。

我的工作是开源的，如果你愿意的话你可以跟着做。这都是Ruby，所以它与Python类似，但不一定是一个替换品。关于我的设计，我喜欢的一点是，人类解释结果所需的所有信息都可以在节点本身找到，而不是在代码中。这可以在qualitat中完成或在网络结构中。

所以，我对你的设计有一些重要的不同：我不计算类内的似然模型，而是计算链接矩阵内节点之间的似然模型。这样，我就不需要在同一个类中组合几个似然函数。我也没有一个模型和另一个模型的问题，我可以使用两个不同的上下文来获取相同的知识库并比较结果。

我通过让人类的决定变得明显来增加透明度。一、 例如，如果我决定在两个节点之间使用默认值或门，那么我知道何时添加该值，这只是一个默认的决定。如果我稍后回来更改链接矩阵并重新计算知识库，我会记下为什么要这样做，而不仅仅是一个选择一种方法而不是另一种方法的应用程序。你可以让你的消费者记录下这类事情。不管你怎么解决这个问题，从分析员那里得到一个逐步的对话可能是个好主意，告诉他们为什么要把事情设置成一种方式而不是另一种方式。

我可能对先前的几率和可能性更为明确。我不确定，我只是看到你用不同的模型来改变你的可能性数字。如果你计算后验信念的模型没有以这种方式崩溃的话，我说的很多东西可能是完全不相关的。我的好处是可以按任意顺序调用三个异步步骤：向上传递更改后的可能性，向下传递更改前的概率，并重新计算节点本身的组合置信度(后验概率)。

一个重要的警告是：我所说的一些还没有公布。今天凌晨2点左右，我一直在做我正在谈论的事情，所以这绝对是最新的，肯定会得到我的定期关注，但目前还不能全部公之于众。因为这是我的一个激情，如果你愿意的话，我很乐意回答任何问题或者一起做一个项目。