Bayesian networks (BN) are particularly well suited to capturing vague and uncertain knowledge. However, the capture of this knowledge and associated reasoning from human domain experts often requires specialized knowledge engineers and computational modelers responsible for creating BN-based models. Through our experiences in applying BN modeling techniques across application domains, we have analyzed how these models are constructed, refined, and validated with domain experts. From this analysis, we have identified potential simplifying assumptions and used these to guide the design of computational and user interface methods that support the rapid creation and validation of BN models.
A Bayesian network (BN)
However, the expression of a model (i.e., creating a “view of that model”) by either a knowledge engineer or a domain expert using most current tools is relatively cumbersome, since the full representation of Bayesian network computation is beyond the mathematical sophistication of many domain experts and some knowledge engineers (who, in some cases, may have backgrounds in Cognitive Science and Psychology, rather than Mathematics or Computer Science). Even with an effort to reduce the complexity and power of a BN representation, there is still the problem of constructing conditional probability tables (CPTs). Since the number of distributions that must be expressed in a CPT grows exponentially in the number of parents and the number of states per parent, a knowledge engineer or domain expert can end up responsible for expressing a vast number of what may end up to be meaningless separate distributions (e.g., a child with 3 states and 7 parents that have 4 states each would require the entry of 49,152 probabilities!). Clearly, this exponential explosion, combined with the underlying sophistication of the representation, presents a challenge.
To some degree, the problem has been recognized by the
research community and the subsequent development of
“canonical models” that reduce the number of parameters
needed to specify a CPT. A canonical model
A review of Bayesian network literature indicates a clear bias towards mathematical techniques for representation, inference, and learning instead of techniques for eliciting Bayesian networks from experts. The research that does exist related to Bayesian network elicitation focuses on obtaining the structure (random variables, their states, and the causal connections between them) of the Bayesian network, the conditional probability distribution parameters that quantify the network, or both.
The Weighted Sum Algorithm (WSA)
Our goal across projects has been to identify and study the users and experts and their approaches to decision-making in different application domains, with the express purpose of aiding in that decision making with techniques such as BN modeling. To accomplish this goal in each project, we use a particular set of analytic methods generally referred to as Cognitive Systems Engineering (CSE). The CSE community emerged as experience with the introduction of new technology demonstrated that increased computerization does not guarantee improved human-computer system performance (Woods & Dekker, 2000; Roth, Malin, & Schreckenghost, 1997; Woods, Sarter, & Billings, 1997). Poor use of technology can result in systems that are difficult to learn or use, can create additional workload for system users, or in the extreme, can result in systems that are more likely to lead to catastrophic errors (e.g., confusions that lead to casualties from friendly fire). CSE attempts to prevent these types of failures in the design and development of complex system by addressing design issues through careful analysis of the problem domain, the tasks to be performed by a human-computer system, and the limitations of both the human and the machine.
Figure 3-1: Cognitive Systems Engineering Process
While there are many different approaches to the analysis
components of CSE, such as Cognitive Task Analysis
(Schraagen, Chipman, & Shalin, 2000), Cognitive Work
Analysis (Vicente, 1999), Work Centered Support
Systems (Eggleston, Roth, & Scott, 2003), and Applied
Cognitive Task Analysis (Militello & Hutton, 1998),
these methods share a commitment to analyzing the
cognitive and environmental demands imposed by the
domain of practice and identifying implications for
information, visualization, and decision-support
requirements. CSE methods generally entail a
multiphase, iterative design approach that includes an analysis
phase, a concept development and prototyping phase, and
a user evaluation phase. The cognitive analysis phase
typically employs knowledge elicitation methods such as
interviews of domain practitioners and observations of
work in context. These methods uncover the reasoning
processes involved in making decisions and performing
tasks in the domain and the challenges that arise (Potter,
Roth, Woods and Elm, 2000; Roth and Patterson, 2005).
The analysis phase supports the development of system
requirements that can be used to prototype computational
support tools and user interfaces, including the knowledge
elicitation needed to engineer formalized representations
of user knowledge and expertise. The development of
requirements and capture of expert knowledge is followed
by subjective evaluations of a prototype system. These
subjective evaluations lead to the development of more
robust prototypes, which are then more rigorously
evaluated. The results of the evaluation then aid in the
refinement of the system requirements. This spiral
development process will eventually converge on an
optimal human-computer system (although time/cost
constraints will influence the number of possible
iterations)
In applying this process across numerous projects, we
have spent thousands of hours with hundreds of domain
experts across a wide variety of applications, such as
supporting the analysis of weather impacts
The first and foremost finding is that the power of a computational representation is seemingly proportionate to the ease with which expert knowledge can be both encoded and validated. That is, the ability to quickly create a model with domain experts, then to work through a set of cases within that model allows for a very rapid cycle of elicitation, representation, and validation. Rather than the model being reliant on the knowledge engineer’s ability to ex post facto recall and extrapolate from the statements of the domain expert, the model can be more comprehensively and reliably based on expert knowledge and reasoning. An additional benefit to this ability to rapidly cycle through model development is that time with domain experts is typically constrained, and that multiple sessions would be otherwise required to develop, then refine, then validate a model.
A second finding was that while domain experts may not be conversant in computationally sophisticated technologies, they can be systematically guided to express their own knowledge and reasoning. This systematic guidance can come in the form of a knowledge engineer performing a structured interview, but it may also come in the form of the modeling tool itself. That is, the domain expert could conceivably develop the model herself, if the interface to the model were sufficiently simple (and presuming a knowledge engineer was present to provide some guidance). This concept of supporting domain experts in expressing their own models has additional benefits, in that a domain expert has an external record of their own reasoning, which in turn can be used in a collaborative decision-making process, shared and used as the basis for future reasoning, or independently validated by other experts.
These main findings were accompanied by more specific results about the actual construction of Bayesian networks by both our knowledge engineers and the domain experts with whom we work: (1) The exponential growth of CPTs with the number of parents and parent states was cited most frequently as a cause for frustration. Few domain experts or knowledge engineers were willing to tackle the entry of extremely large CPTs. Domain experts facing this challenge often resorted to saying, “they’d just be making it up” at that level of detail to avoid the task. (2) The lack of ability with many BN software packages to develop a network and immediately update beliefs (as a function of new nodes, states, CPTs, or causal links) slowed model development. (3) “Evidence” and “belief” were commonly confused when shown simultaneously. These terms were also commonly confused in discussions about what a BN was representing. (4) The expression of vague or uncertain knowledge or reasoning varied significantly between users. A great deal of speculation was used in the creation of the CPTs (more so than the relationships among variables) (5) The selection of variables was a primary challenge.
We discovered that expression could be guided towards primarily Boolean and/or Ordinal ranges, although in some cases, Categorical variables were used to simplify the network (“Categorical” refers to non-Boolean, non-Ordinal groups such as {apples, oranges, jet skis}). It was possible to create networks that represented identical reasoning, but that used a different selection of variables and variable types. (6) Many networks were constructed with the assumption that parents were independent, or when parents had dependent influences, variable names and states could be relatively easily re-defined to preserve parental independence. Working towards networks with parental independence may also have helped to more explicitly represent un-stated or assumed influences among variables. (7) In some cases, variables were selected such that they caused wholesale disregard for other variables (e.g., “if A, then I don’t care about anything else, the answer is True”.) (8) The underlying reasoning, while mathematically correct, could be opaque and non-intuitive (particularly when certain non-linearities were exposed). This led to issues of trust in the model and the modeling technique.
These findings are the result of our analysis and experience, not a comprehensive, empirical set of evaluations. However, we would assert that they are highly valuable observations to be used as part of an effort to build better BN-based modeling tools and will, as part of our iterative approach to development, be subjected to more formal evaluation to test the limits of their application in BN modeling.
The results of this analysis were used in the development of Charles River Analytics’ BNet™ suite of products (note: other BN tools (e.g., Elvira, GeNIe) may also perform a subset of features we developed – our goal in this paper is not to perform a product comparison, but simply to show how an analysis of common problems should systematically lead to user interface design elements). Each of the findings has resulted in a particular feature or set of features. For example, our finding that users typically wanted to see updates to beliefs whenever any type of change was made to the network led to the development of a “no-compile” or “mode-less” user interface (see (2) above). Other user interface methods were used to simplify, where possible, the completion of CPTs (e.g., supporting entry of multiple rows simultaneously, supporting cut and paste from spreadsheet applications (see (7) above)). However, while these improvements to BN modeling clearly improve the user experience for an experienced knowledge engineer, they fail to address the broader goal of making BN model construction a more interactive process with domain experts to whom the subtleties of BN representations are not as immediately important as the construction and validation of the model.
Therefore, we focused on two key components of a BN modeling tool that would support a more rapid model creation and validation cycle with domain experts and knowledge engineers, with the greater goal of working towards methods that would allow domain experts to comfortably and intuitively externalize their knowledge and reasoning. The first component consists of an underlying mathematical representation (Causal Influence Models, or CIMs) that is based entirely on BNs, but uses simplifying assumptions much like the canonical models described in Section 1. Compared to these canonical models, these simplifications are based primarily on the desire to support improvements to the user interface, rather than computational efficiency. The second component of our effort was to develop user interface methods that leveraged the results of our analysis and the power of the simplified computational model. Both of these components are described in more detail below.
One of the key findings from our analysis was that experts
tend to express the degree to which certain factors
influence the likelihood of other factors independently
(and, where they do not consider these factors
independently, the act of explicitly expressing these
interdependencies leads to a model where new factors are
created to represent the dependency) (see (6) above).
Therefore, we started with the simplifying assumptions
that each parent node influences the child node (causes it
to be more or less likely) and these parents act
independently. These assumptions, along with a
procedure for combining parent influences into a full
CPT, lead to the Causal Influence Model (described in
full detail in
In our CIM, the user first specifies a baseline probability distribution over the states of the child node. These baseline probabilities represent the a priori likelihood of the child states, without the effects of any of its parents. Next, the user specifies the influence that each parent state has on each child state. This influence is a number in the range [-1, +1] and represents the amount that the parent state increases or decreases the baseline probability of the child state.
Once the user specifies the baseline probabilities and influences, they are used to calculate all of the probabilities in the CPT. For each row and child state in the CPT, we combine the influence of each parent state in that row on the child state into the overall parent influence. While many combination functions are possible, we typically use the mean of the parent influences since it is a linear function causing positive and negative influences to balance each other out and therefore produces CPTs that represent linear relations (see (8) above). This overall parent influence is then used to either increase or decrease the baseline probability of the child state, and this result is used as the conditional probability of the child state given the parent states in that row.
The CIM requires a number of parameters that is only
linear in the number of parents, as opposed to exponential
for a CPT (addressing (1) above). The baseline
probabilities and influences are also easily specified by
domain experts since they do not involve the joint effects
of numerous parent states. In our experience, a domain
expert is much more likely to accurately specify a small
number of simple parameters. This is the primary benefit
of using the CIM instead of a full CPT. Of course, the
user can always further refine the actual CPT later, by
hand or with data, meaning that the full representational
capabilities of the BN model are accessible as needed.
While the IN canonical model
For each parent, the user must specify a number of influences equal to the product of the number of parent states and child states for the CIM. While this is certainly better than the CPT, it can still result in too many parameters for a user to specify. We simplify the CIM even further by making assumptions about the types of the parent and child nodes and the type of influence that the parent has on the child. These assumptions allow us to completely specify the CIM using only a single parameter for edges between Boolean and Ordinal nodes, and for edges connected to a Categorical node only a single parameter for each state of the Categorical node is needed. For example, in a network with only Ordinal or Boolean variables, a child with 7 parents would require the entry of only 7 values. In a full BN representation, the user would need to specify a minimum (assuming only 2 states per variable) of 128 values.
The CIM, and the underpinning assumptions that it uses, is based on the goal of improving interfaces to BN models to the level where they can be dynamically and interactively created with or by domain experts. This goal has led to the development of a number of specific user interface methods that have been incorporated into our BNet™ product suite for further evaluation and refinement. These methods are described in more detail below.
First, we addressed the need to allow for dynamic updating of the model as new links, variables, states, and evidence are created (see (1) above). This is supported by the underlying computation, but results in a network that actively animates as it changes. For example, a user adjusting an evidence slider will see all of the beliefs in the networks move to indicate the change. This animation, in particular, supports current efforts to understand how best to visualize causality (Ware, 2000). We have also developed methods to help draw attention to changes in a network, so that many variables may be simultaneously monitored for change (e.g., through “snapshots” of the beliefs in the network compared to the network after evidence has been posted), although others have developed similar user interface designs to achieve this capability (e.g., Elvira: http://www.ia.uned.es/~elvira) Next, we addressed the need to develop methods that render nodes differently as a function of the type of variable they represent (see (5) above). The following figures show the prototype node renderers for Boolean (Figure 5-1 and Figure 5-2), Ordinal (Figure 5-3 and Figure 5-4), and Categorical (Figure 5-5 and Figure 5-6) node types: We attempted to address the confusion about “beliefs” versus “evidence” that we observed with many of our domain experts by visually separating these two elements (belief being represented by the vertical bar, evidence via the horizontal slider) (see (3) above) and only expanding the node to show the evidence slider(s) when the user hovers the mouse over the node. This also provided additional affordances (or lack thereof) to show that evidence is something that could be entered by the user. The expanded nodes in Figure 5-2, Figure 5-4, and Figure 5-6 show an evidence knob above the slider track and also a baseline knob below the track. The baseline knob can be removed to simplify the user interface, if necessary. The Boolean node simply displays the belief for the true state in a vertical bar and provides a slider that allows the user to (optionally) set the evidence between true and false. The Ordinal node (shown with 4 states to represent the intermediate steps from “none” to “full”) necessarily breaks the vertical belief bar into segments to represent the distribution across the states. A straightforward defuzzification of these results has also been developed to represent this belief as a non-segmented bar. The user can (optionally) set the evidence using a single slider that is fuzzified into values for each state. The Categorical node displays the belief for each state in its own vertical bar and provides a separate evidence slider for each state. We are continuing to prototype additional visualization and user interface methods for all of these nodes. We have also developed methods for expressing probability ranges and baseline probabilities in an attempt to address (4) above (Figure 5-7), although we believe these methods may add a level of complexity that may inhibit usability and have developed versions of the interface that omit these methods. Given that experts may struggle to express in any numerical form their uncertainty about evidence, we developed an interface that allows the user to “grow” a confidence interval around any evidence that is posted. Similarly, we provided a “dual slider” interface where the baseline probability can be expressed. We believe these two additional capabilities (expressing a confidence interval and a baseline) may represent a higher level of complexity in the user interface that may be too sophisticated for some very rapid model development environments, but may be used in the refinement of initial models developed with an interface permitting more limited expressivity. In addition to using our experience with how experts may tend to express their knowledge and reasoning to guide the design of node visualization and user interface methods, we also developed methods for exploiting the CIM’s ability to more rapidly quantify causal relations. Because the CIM allows the influence between Boolean and Ordinal nodes to be expressed as a single number, we developed the interface shown in Figure 5-8.
Figure 5-8: Interface for manipulating the strength of a causal relationship between variables In this case, the user has moused-over the link between the two nodes, and buttons have appeared allowing the user to change the excitatory or inhibitory nature of the link. By adjusting this to various ends of a discrete range (or a continuous range using a slider rather than the two buttons shown) for each parent, the user completely specifies the CPT for the child. In the cases where a child or parent variable is Categorical, additional buttons appear for each state. This interface becomes clumsy for Categorical-to-Categorical variable relationships, as the relationship between each child state and each parent state must be specified. In practice, however, we have found that experts are able to reformulate their reasoning in a form that uses primarily Ordinal or Boolean types. In addition, we have also developed prototype methods for collapsing certain structures of Boolean nodes into Categorical structures (and vice versa).
Although the CIM allows parent influences to be specified in the range [-1, 1], our experience has suggested ±5 steps to be a reasonable level of granularity so we actually elicit an integer in the range [-5, 5] for each parent’s influence on the child (but note that establishing the optimal level of granularity with empirical evaluation remains a goal of future work). In Figure 5-6, we show these levels of link strength and that we adjust the link’s hue, saturation, and width to indicate its influence (providing multiple, redundant visual cues). Alternatively, we could allow the user to adjust a continuous value between [-1, 1] with a slider and continuously vary the link’s visual parameters. By providing this additional visualization, we allow the user to see, at a glance, not only the relationships among the variables in the network, but also the proportional strength of those relationships. This imparts, to a degree, the sensitivity of the variables to each other, meaning that differences in sensitivities can be rapidly adjusted to match domain expert expectations (e.g., “I realized I made this a much bigger influence than I should have when I looked at all of these other variables”). We have discovered potentially challenging interactions between the names of variables and the implications of the red and green hues used in the visualization. There may be some natural mappings of the color to what the variable is intended to represent (“Happy” is more green than red, and “Being Happy” has an inhibitory influence on “Moping”, but the red link may be perceived as causing something to be “less happy”). Similarly, the semantics of the variable names can interact with the visualization of causal links (e.g., “Not Happy” has an excitatory influence on “Moping”). We have, in cases where the variable semantics can be more structured, provided mechanisms for “flipping” the terminology and associated link colors.
An additional challenge faced in a network where experts can easily express their own reasoning is the need for tools to support validation. In the application of these methods across domains, we have discovered that invalid causal chains may be formed simply because it was easy to do so. As a result, we have developed methods that do relatively simple translation of the causal paths in the network into text (e.g., variable A with a +5 link to variable B would result in “A has a strong positive influence on B”). This method appears to be effective for simple models or models with relatively short causal pathways (or for models that follow particular structural patterns). 6.
All of the above interfaces have been implemented and developed as part of a future release of our BNet™ product suite, and as part of many of the custom applications we develop for our clients. As a result, we have used these interfaces and will assert that domain experts without a significant understanding of the underlying computational representation can rapidly externalize and validate their own reasoning more easily than with current off-the-shelf BN modeling packages. We have observed experts, particularly working collaboratively, use our prototype user interface to develop sophisticated models with very little intervention from either knowledge engineers or computational modelers. While this empowers the domain experts to create their own models, it also introduces an opportunity for representational errors that would not otherwise occur with an experienced knowledge engineer “in the loop” along the lines suggested by (Tabachneck-Schijf et al., 2006).
With these encouraging experiences, but without any comprehensive empirical evaluation, we hope to pursue additional efforts to resolve some of the user interface and computational challenges that have arisen from this effort (e.g., semantic issues with node names and the natural mappings of certain colors to certain meanings). We also hope to pursue experimental efforts to more formally test the simplifying assumptions in the CIM, and other observation- and analysis-based design choices. In addition, the user interface designs presented, while capturing the desired functionality, will still require additional refinement to ensure consistency across variable types (and, ideally, additional customizability). Finally, we are also in the process of developing methods for using the simplified interface to aid in the expression of cases that can be used within existing BN learning algorithms.
We would like to express our appreciation for the invaluable testing and feedback provided by Karen Harper, Chen Ling, Sam Mahoney, Sean Guarino, and Eric Carlson. In addition, we would extend our deepest gratitude to Greg Zacharias for his continued funding and support of our work with Bayesian networks. Tabachneck-Schijf, H. & Greenen, P. (2006). Preventing Knowledge Transfer Errors: Probabilistic Decision Support Systems Through The Users' Eyes. In Proceedings of 4th Annual Bayesian Modeling Applications Workshop at Uncertainty in AI '06.
Cambridge, MA.
Ware, C. (2000). Information Visualization: Perception for Design. New York: Morgan-Kauffman.
Wiegmann, D. A. (2005). Developing a Methodology for Eliciting Subjective Probability Estimates During Expert Evaluations of Safety Interventions: Application for Bayesian Belief Networks. (Rep. No. AHFD-05-13/NASA-05-4). Aviation Human Factors Division Institute of Aviation, University of Illinois.