GeneralitiesWhat is the relationship between OpenDial and MDP/POMDP approaches?As in existing statistical frameworks, OpenDial represents the dialogue state as a Bayesian network that is regularly updated with new observations and employed to calculate the utility of possible system actions. The key difference between OpenDial and traditional MDP/POMDP approaches is that the domain models (i.e. the transition, reward and observation models) are expressed via probabilistic rules instead of the usual representations for probability distributions and utility functions. The rules are essentially highlevel templates for probabilistic models. They provide an abstraction layer that allows the system designer to capture the domain in a concise and humanreadable form, with a limited number of parameters. In other words, OpenDial can be seen as following a "structured POMDP" approach to dialogue. See Lison (2014) for a more detailed description of the formalism. What exactly are the utility rules? Do they represent rewards, actionvalues, or something else?It depends on the planning horizon that is employed for your domain. In the most common case, the planning horizon is set to 1 (i.e. limited to the present time step). In this setting, the action selected by OpenDial will simply correspond to the one that maximises the total utility in the current dialogue state. It is, however, also possible to use planning horizons larger than 1, in which case online planning is performed to find the action that maximises the accumulated utilities from the present time up to the horizon limit (given a particular discount factor). Online planning is, however, a computational expensive operation due to the combinatorial explosion of the number of possible interaction paths to consider. It also necessitates the specification of a full transition model. For most dialogue domains, we recommend therefore to keep the planning horizon to its default value, and ensure that the (handcrafted or learned) utilities reflect the longterm utilities of the action, and not just its immediate reward. Why is there a distinction between "predictive" variables X^p and normal state variables X in OpenDial?We sometimes want to use probability rules to provide a prior prediction on a future, currently unobserved variable (for instance, to predict the next user dialogue act following a particular system response). The suffix ^p allows OpenDial to distinguish such predictions from actually observed values. Once matched with actual observed values, the prediction acts as a prior for the observation. Technically, this is realised via an "equivalence node" inserted between the prediction and the observation, see Lison (2014), p. 7879 for details. This explicit distinction between prediction and observations is necessary in OpenDial since both the predictions and the observations may be uncertain (and hence expressed as distinct probability distributions). Spoken dialogue systems must indeed frequently integrate observations that represent "soft" evidence, such as the ASR/NLU hypotheses of the user dialogue act. What are the differences between probability and utility rules?Probability rules represent conditional probability models P(YX), where Y and X are arbitrary subsets of the state variables. In other words, probability rules express conditional, probabilistic relations between state variables. Utility rules, on the other hand, express the utility U(A,X) of particular system actions A depending on the state variables X. The utility rules encode the relative "desirability" (from the system's point of view) of executing particular actions depending on the current state. In practice, probability rules are typically used to define the models used in language understanding (to capture e.g. the relation between the user utterances and their corresponding dialogue acts), dialogue state update (to capture the relation between the dialogue acts and other state variables such as the underlying user intentions) and in the prediction of future observations. The utility rules, for their part, are most often used in action selection (to find the next system action to execute) and generation (to find the best realisation of a particular communicative action). Dialogue domainsHow do I get the dialogue system to start first, before the user has uttered anything?This can be done very easily: just add the starting system action in the initial dialogue state for the domain. The calculation of marginal distributions sometimes gives imprecise results. Why?If your domain includes continuous distributions (such as unknown parameter values), OpenDial will rely on sampling algorithms to perform probabilistic inference. Sampling algorithms are approximate algorithms, so the probability value will always be somewhat imprecise  especially when dealing with multivariate continuous distributions, which are more difficult to sample. You can easily modify the number of samples in the Options > Settings GUI window, or in the domain settings. What is this special None value present in some distributions?The None value is employed as a filler value to ensure that all probability distributions sum up to 1.0. For instance, if a user utterance is expressed as an Nbest list with 2 elements, one "move left" with probability 0.6 and one "mow the left" with probability 0.2, the distribution over possible user utterance will have a None value with probability 0.2, corresponding to an empty utterance. For system actions, the None value represents the void action (i.e. do nothing). How can I keep track of the dialogue history?By default, the dialogue state will only contain the most recent value of the user or systemrelated variables such as u_u (user utterance), a_u (user dialogue act), a_m (system action) or u_m (system utterance). However, one can easily record longer dialogue histories by creating new variables that capture previous dialogue acts. For instance, we can create a new variable a_uprev that contains the nexttolast dialogue act from the user, and specify the following rule in the domain model updating the user dialogue act:
The same operation can be of course done for other state variables. Alternatively, if you want to keep track of the complete dialogue history (without limit on the number of elements), you can also define the history as a list, and insert a new element after each update:
For this last approach, you might need to reduce the number of hypotheses in the Nbest lists in order to avoid a combinatorial explosion in the number of values in this history variable.
MiscellaneousHow do I integrate OpenDial as part of another application?

User Guide >