Introducing VULCAN : A Visualization Tool for Understanding Our Models and Data by Example (2023)

Abstract: Examples are a powerful tool that help us understand complex concepts and connections. In computational linguistics research, looking at example system output and example corpus entries can offer a wealth of insights that are not otherwise accessible. This paper describes the open-source software VULCAN, a visualization tool for strings, graphs, trees, alignments, attention and more. VULCAN’s unique ability to visualize both linguistic structures and properties of neural models make it particularly relevant for neuro-symbolic models. Neuro-symbolic models, combining neural networks with often linguistically grounded structures, offer a promise of increased interpretability in an age of purely neural black-box end-to-end models. VULCAN aims to facilitate this interpretability in practice. VULCAN is designed to be both easy to use and powerful in its capabilities.

## introduction humans effortlessly abstract patterns and complex generalizations from even small sets of examples (posner and keele, 1968; gick and holyoak, 1983; brown and kane, 1988). this ability is particularly useful for researchers in the field of nlp: looking at entries in a corpus helps us understand what kinds of structures and phenomena occur in the corpus, and looking at example model outputs helps us understand the abilities and limitations of the model. this empowers us to form a more precise notion of how much we can (or cannot) trust the model to be correct, and it often provides us with ideas for how the model can be improved. here we introduce vulcan: visualizations for understanding language corpora and model pre-dictions. vulcan is a flexible, user-friendly tool for visualizing linguistic structures and nlp model predicions. for example, fig. 1 shows vulcan * work done in part at the university of edinburgh visualizing an entry from the little prince abstract meaning representation (amr; banarescu et al., 2013) corpus. @xcite it shows both the gold amr annotation (left) and an amr predicted by a semantic parser (right). beyond visualizing linguistics structures like strings, trees and graphs, vulcan can also display information such as alternative model predictions, attention (including transformer's multi-head attention; vaswani et al., 2017) and alignments. thus, vulcan is particularly useful for interpreting neuro-symbolic models, which combine neural networks with explicit (often linguistically grounded) reasoning and structures. one selling point of neuro-symbolic models is their interpretability. vulcan, with its unique ability to display both linguistic structures and properties of neural models, makes that interpretability accessible in practice. vulcan also includes an advanced search functionality to find examples relevant to a certain research question or problem statement. the software is designed to be easy to use, and to be applicable to a wide range of corpora and models. vulcan is available open source. @xcite 2 related work many nlp visualization tools exist. however, they tend to be limited to a smaller range of linguistic objects they can display, are often tied to a specific framework, and don't always allow displaying model properties such as attention. we provide a selection of examples here: in sum, vulcan fills a gap by visualizing both linguistic structures and (neural) model properties, a crucial combination for interpreting neurosymbolic systems. there are also more general visualization tools available. this includes l a t e x packages like tikz, @xcite and e.g. the graph plotting software graphviz. @xcite their broad functionality, that usually goes far beyond nlp, can be a hurdle for learning how to use them effectively and can make them cumbersome to use even for experts. by contrast, vulcan is designed to require little specialized knowledge and comparatively little effort to use. further, these general tools tend to be non-interactive, and often have long compile times. ## the core design of vulcan the core functionality of vulcan is to visualize entries in a corpus, as well as model predictions on that corpus. advanced functionality includes the display of further information such as alternative predictions and their likelihood. a full description of features follows in section 4. fig. 1 shows an example, where vulcan visualizes an entry from the little prince amr corpus. 1 this is the third sentence in the corpus, displayed together with the annotated amr from the corpus (left) and a predicted amr (right; this amr was predicted by the parser of groschwitz et al., 2018). throughout this paper, we will make a distinction between the host, who runs vulcan and provides the data, and the viewer, who looks at the visualizations. in practice, host and viewer can be the same person: take for example a researcher who uses vulcan to visualize her model's predictions on the development set, in order to analyze errors and find the best next step for improving the model. this researcher is then both the host and the viewer. but if, say, vulcan is used to host a visualization of a corpus on the web, to showcase the corpus to the public, then host and viewer are different people. following this principle of host and viewer, vulcan uses a server/client design. the server side is operated by the host; the viewer interacts with the client side, which runs in the browser. thus, the viewer simply sees an intuitive browser interface like the one in fig. 1 . during setup by the host, vulcan takes as input a file in a dictionary format (see section 6), containing all (and only) the information required for the visualization. all model predictions, attention etc. that are to be visualized must be included in this input file, which uses a simple, generic format -this allows vulcan to be agnostic about the model's implementation framework. the dictionary can be presented as a pickle or json file (generating json is particularly widely supported across programming languages). inside the dictionary, structures like graphs and trees can be included in a variety of formats: vulcan supports a range of input codecs (section 6) that can be further extended (section 7). the visualization can then be accessed from a browser as long as the server program runs. viewers can browse the corpus, and access further information through e.g. mouseover interaction (sections 4, 6.2). ## features this section describes the visualization capabilites of vulcan in detail. throughout this section, we will use three examples: ud visualizes the pud test set of the japanese universal dependency treebank (fig. 2 ; mc-donald et al., 2013). this is an example of visualizing only a corpus and no model predictions. this also highlights vulcan's ability to render characters outside the latin alphabet. leamr visualizes the alignments predicted by leamr (blodgett and schneider, 2021) on the little prince amr dataset. 1 leamr aligns nodes of the amr semantic graphs to tokens, using a combination of heuristics and machine learning. ## case study to illustrate the kinds of insights vulcan makes available, let us take a closer look at the am-parser example from section 4. specifically, we will investigate the sentence once when i was six years old i saw a magnificent picture in a book, called true stories of nature, about the primeval forest. the vulcan visualization is shown in fig. 10 . in this case study, we will gain insights into the probability distributions that the parser predicts in practice and find the reasons why the parser makes a specific error. based on these insights, we develop concrete ideas for a statistical analysis to confirm the found issues, and possible model changes to address them. but before we jump into the analysis, let us look at the am parsing model in more detail (see groschwitz et al., 2018 for a full description). recall that the am parser predicts a so-called am tree, consisting of dependency edges and supertags, that then evaluates to an amr graph. given a sentence, the parser computes for each token, let us say here the token at position i, three types of scores: a symbolic decoding algorithm then finds the best am tree based on these scores and the type constraints of the am algebra. this am tree then evaluates deterministically to the graph. in the visualization in fig. 10 , the heads and supertags of that best am tree are shown above each token, and the dependency edge labels (app_s etc.) are shown directly on the edge. note that some tokens in the graph do not have a supertag assigned to them, and are not part of the dependency trees. these tokens do not contribute directly to the final graph, and the parser has decided to ignore them. for a token to be ignored this way, three things must happen: (1) it must have the dummy supertag represented here with an underscore "_", (2) its head must be a ficticious token at position -1, and (3) the label of the incoming edge must be ignore (note that ignore edges are omitted in the visualization here). that is, the supertag, head and edge icalized supertags and separate lexical labels. this detail is however not relevant for the analysis here, and we bundle the scores into one. label scores all contribute to a token being ignored (they do not have to all say that ignoring the token is most likely, but in total must make ignoring the token the most likely choice for the decoding algorithm). this case study focuses on the token was, the fourth token in the sentence. it should be ignored -it does not directly contribute information that is represented in the gold amr -, but it is not. here we want to find out why. figures 11-13 show the top five supertags, heads and incoming-edge-labels, respectively, for the token was. each possible prediction is given with its score ω as a probability. we can make a first observation immediately: the scores differ wildly in how confident the model is. the scores for the supertag (fig. 11 ) have medium confidence, with the dummy supertag "_" having the highest score by quite a margin, but the other options also having a significant amount of probability mass among them. by contrast, the score distribution for the head (fig. 12 ) is very flat. the option of choosing saw as the head, (wrongly) predicted as most likely, has just barely a higher score than the (correct) choice of the dummy token at position -1, which is fourth most likely. by contrast in the other direction, the distribution for the edge label is extremely peaky, assigning nearly all of the probabily mass to the label mod_mod. the correct edge label ignore is not even in the top five. this explains why the token was is not ignored: while the supertag and head prediction together would indicate ignoring the token, they are not strong enough to overcome the confidently wrong edge label prediction. a first takeaway then is that the score distributions may be unevenly balanced in general. looking at some more examples further supported this hypothesis. a possible next step would be to examine the "peakiness" and "flatness" of the score distributions with corpus-wide metrics, for example by measuring the average entropy of supertag, head, and edge label scores, and see if the pattern holds: that the head scores are consistently overly flat, and edge label scores are consistently too peaky. if so, countermeasures such as hyperparameters to balance out the scores during decoding would be a promising avenue to improve parser performance. a second takeaway is to look more closely at the edge label predictions. why are they so confidently wrong? the answer lies in the following design decision of the am parser. to save computation time, not all edge label scores ω(l|@xmath0. instead, for each token position i, edge label scores are only computed for the most likely head k max , and then this distribution is used for all k. that is, for all possible heads k, the score ω(l|@xmath1. in our example, k @xmath2. but the training data taught the parser that ignore edge labels go with the dummy head @xmath3. thus, the score of the ignore label here, which would be the correct prediction, is very low. as a conclusion, this shortcut to save computation time has a cost in terms of accuracy here. revisiting this decision is another promising avenue to improve parsing performance. this concludes the case study. looking at the probability distributions for just a single token generated multiple hypotheses for how the parser could be improved. a good first next step towards confirming these hypotheses would be to look at more examples and see if the pattern holds. then, corpuswide statistical analyses can serve as further confirmation where applicable. finally, implementing model changes, and iterating this pattern of evaluation, interpretation and implementation continue the research loop. the key step in hosting a corpus with vulcan is to create a vulcan visualization file. once such a file exists, running vulcan takes just one line (technical details in the code documentation). technically speaking, a vulcan visualization file is simply a dictionary in a specific format, which can be provided as a json or pickle file. however, vulcan contains python functions that allow building a vulcan visualization file in an intuitive way, without having to worry about the concrete dictionary format. the general idea is that each entry in the corpus has a fixed set of structures that we want to visualize. for example, in fig. 1 , there are structures named the 'gold graph', 'predicted graph' and 'sentence'. to build a vulcan visualization file, one first specifies this fixed list of structures that each corpus entry consists of. then one adds the corpus entries one by one. more technically speaking, the first step is to create a vulcanfilebuilder object, whose constructor takes as only parameter a dictionary like this (again, for the example in fig. 1 ): alignments, attention scores and alternative label predictions can be added similarly, using the following format. in vulcan, each element within a structure (a token in a string, a cell in a table, a node in a graph, etc.) has a unique identifier in that structure, the element name. for example, a token's name is its position in the sentence. alignments and attention are specified as dictionaries that map pairs of element names to a score (for alignments, the scores are 1 or 0). alternative label predictions are also encoded as a dictionary, mapping an element's name to a list of its alternative labels (and their scores). these generic formats make it easy to create input for vulcan from any source. a vulcan visualization file can also be built by hand, e.g. if the host prefers building it in a programming language other than python. the full dictionary file format is described in appendix a. ## extensibility vulcan is modular, built with extensibility in mind. in particular, it is straightforward to add new input codecs, and to add new search patterns. this way, the host can customize vulcan to their needs. future work could also add functionality to visualize completely new objects, such as images, or the ability to play sound files. ## conclusion we have displayed the capabilities of vulcan, a visualization tool for linguistic structures, neural models, and their interactions. among the features showcased in this paper are the visualization of strings, trees, graphs and complex supertags, as well as alternative predictions with their likelihoods and multi-head attention. this combination of features makes vul-can particularly suited to facilitate the interpretation of neuro-symbolic models in practice. vul-can also features a powerful search functionality and has broad compatibility due to its flexible input format. we built vulcan to make it easier to gain insights into corpora and models by looking at examples. we hope that vulcan will play a part in making neural models in natural language processing and generation more interpretable and tangible.