Facilitating Knowledge Sharing from Domain Experts to Data Scientists for Building NLP Models

Recently the data science domain has spurred great research interest in the HCI community. Besides developing numerous tools to support specific data science tasks (e.g. [4, 34, 35, 86]), an emerging area of research has focused on studying the practices of data scientists in model development work. Many have recognized the collaborative nature of data science projects, with both intra- (among data scientists) [43] and multi-disciplinary (with domain experts) collaboration [59, 84]. In particular, data scientists rely heavily on domain experts during core modeling building stages, such as data access and feature extraction. Domain experts also feature prominently in latter stages of data science projects such as model evaluation and communication of results [59]. However, data scientists’ work faces significant challenges as such collaborative activities are currently not well supported [50, 57], and they are often left with no choice but to rely on “an intuitive sense of their data and processes” [53].

Computational notebooks are positioned as a potential solution to both support collaborative coding and communicating results to stakeholders [78]. However, a recent study reported reluctance for data scientists to directly communicate the in-progress model work in notebooks [65]. While there are tools emerging to address the technology gaps to support collaborative data science practices, to our knowledge they tend to focus on supporting teams of data scientists and place domain experts with limited elicitation. In this work, we explore the approach of providing interfaces in which domain experts can create a knowledge repository for a sophisticated domain, so that it could be consumed by data scientists asynchronously and flexibly when the availability of domain experts is limited.

There has been a long-standing desire to increase the involvement of domain experts in model building in both the ML and HCI communities. For example, tasks like text annotation, image annotation involve massive input from domain experts to provide domain-related feedback. Ziva interface is inspired by NLP text annotation tools [54, 60]. We take this design further to acquire domain knowledge for model development and data scientists. Recognizing the challenge of having domain experts label a large quantity of data, many ML works have explored more efficient learning algorithms to reduce the workload [68, 73], or utilize domain experts input as rules [45], constraints [19, 56], prior information [11, 70], or feedback to re-weigh features [24, 61]. Given the prominence of label-hungry ML algorithms, weak supervision has become a popular approach to bootstrap labels based on feedback from domain experts [23, 63, 64].

The HCI community is further concerned with the isolation of domain experts from the model development process, requiring thus data scientists to go through lengthy and asynchronous iterations to get their input [9, 58]. To tackle the problem, the sub-field of interactive machine learning (iML) is motivated to enable domain experts or end-users to directly drive model behaviors [9, 36, 80]. Since domain experts might not have training in ML or programming, iML systems elicit their input through intuitive and interactive interfaces (e.g., visualization [39], graphic user interfaces [9], conversational interfaces [18]), and a tight feedback loop for them to adjust their input. A variety of user input have been explored in prior work for different tasks in model development, including unseen training data to help correct the model's mistakes [18, 25], provide new feature-level input [44] or adjustment to feature weights [68], assessment of model performance [10, 26], error preferences [41], parameter choices [52], model ensemble [75], etc.

Research on iML has been especially fruitful for NLP modeling tasks, partly because text data and features (e.g., bag of words) are often comprehensible to people, increasing the likelihood of obtaining effective feedback from domain experts or end-users [46]. For example, the tools solicit feedback for learned features [69] or support features ideation by the users [14]. Interactive topic modeling is another well-explored area to incorporate domain experts’ input [21, 37, 38, 71], for example, by moving documents around or adding words, to refine clusters of topics.

Our work is informed by prior work on iML but takes a complementary approach by facilitating knowledge sharing from domain experts to data scientists. iML is not a panacea to effectively leverage domain experts’ input. There are known issues with letting ML novices directly adjust models [72], such as lacking generalization or over-fitting [81]. In practice it is not always feasible to set up an iML system for domain experts to work with. Currently most ML projects still rely on data scientists to write code and set up the pipelines [59]. Moreover, having data scientists mediate the knowledge input offers the flexibility to apply it to different kinds of ML algorithms, and allow domain experts to provide reusable knowledge not constrained by a particular modeling task.

In general, it is possible to elicit diverse kinds of knowledge from people, not all of which could be consumed directly by a given ML model. For example, Stumpt et al.  [74] and Ghai et al. [28] explored what kind of feedback people naturally want to give seeing model explanations. Only a small subset of the various forms of feedback is readily consumable by existing ML algorithms. However, as the ML field rapidly advances, many novel usages of domain knowledge are being explored. For example, since ML models might use low-level features that are not human understandable (e.g., pixels of an image), interpretable ML works explored eliciting human-interpretable concepts in the domain (e.g., an object in the image) and use the concepts to explain the model decisions [29, 42]. Elicited domain concepts have also been used to create sub-groups for labeled data to enable “structure labeling”, which could lower the re-labeling burden when a target class changes [47]. We further envision elicited domain concepts could help data scientists head start their model building, as revealed in our preliminary interview. By facilitating knowledge sharing from domain experts, we also hope to inspire novel algorithmic work that could leverage such a knowledge repository.

Ziva is also motivated by prior work on technologies that facilitate knowledge sharing in enterprise and organizations. Knowledge sharing has been long studied in the Computer Supported Collaborative Work (CSCW) community focusing on building collective knowledge repositories and locating related experts [5, 67]. Knowledge repository tools elicit various formal and informal information including manuals, best practices, common questions, and so on. For example, Goldberg et al. studied collaborative tagging and filtering mechanisms for workers to construct a knowledge repository [30]; Answer Garden is a system to build a repository through people asking and answering questions [4]; Terveen et al. designed a memory framework for large-scale software engineering where groups collectively build a shared memory [76]; Nam and Ackerman studied methods for elicitation of informal information into more organized forms [55].

Knowledge sharing in ML projects poses unique challenges [8, 16] to make the knowledge transferrable into ML specifications. The challenges are amplified in sophisticated domains. For example, for a medical ML model, a clinician may have to help data scientists understand complex drug information. We inform the design of Ziva both by prior work on involving domain experts in data science projects and model development, and a preliminary interview study to understand how data scientists learn from domain experts. Meanwhile, studies have warned that knowledge sharing and repository tools often fail in practice [33, 82, 88], if the design fails to take into account the social dynamics, including what benefits and demands these technologies bring for both the knowledge providers and the knowledge consumers [5, 31]. Thereby we evaluate Ziva by involving both the knowledge consumers–data scientists, and the knowledge providers–domain experts.

All of our data scientist interviewees indicated they often need domain experts’ help and feedback. However, domain experts are busy and have little time to spare. One said: “The first issue is getting hold of their time... I think hardly I was getting one day a week, you can say one hour a week, not even an entire day.” So data scientists try to extract as much knowledge as they can in the limited time they have. They have to spend significant time preparing for these discussions. For example, they often manually curated examples such as mis-classified instances and instances that contain the unfamiliar keywords to ground the discussion during the meetings with domain experts. Even though there is no standard way to extract domain knowledge across different domains, but through mutual effort they find what works best for a project. We identified the following approaches to learn domain knowledge from domain experts:

Example-driven conversation: The first field of approaches is domain knowledge sharing based on examples. By inquiring about how and why domain experts would label or make decisions for these examples, data scientists learn rationales of how the model should behave for the instances. There are three tactics mentioned by our interviewees. P2 observed domain experts during labeling to learn the domain experts’ thought process: “They would go line by line in front of me so that I can also see what their brain is looking at classifying them.” P1 initially took P2’s approach, but due to the complexity of the law domain, explaining rationale required extensive background knowledge. Oftentimes, it is unclear to data scientists how to connect the explanations provided by the domain experts to model specifications. P1 used a strategy called instance perturbation – for a given instance, the domain experts were asked to minimally change the instance until the model changes the label and discuss the reasons. With this, data scientists were able to narrow in on the parts of the instance that should be the most important to the model's decision. Instead of aiming to build a perfect model right off the bat, P4 deployed their model first and incrementally improved the model upon domain experts’ request. Whenever domain experts encountered mis-classified results, they shared the instances with data scientists and discussed why they were mis-classified.

General background knowledge acquisition: Concepts are key units of information for a given domain, such as notions, entities, components or properties. A set of domain concepts can be seen as a taxonomy. Understanding them could help data scientists make sense of the domain. Participants reported approaches to learn concepts in an unfamiliar domain. P2 and P3 said domain experts in one of their projects offered a lecture to explain key concepts their domain. For P2, domain experts gave an overview and touched on the basic concepts of each class. P3  pair-authored [78] with domain experts to bridge concepts and a mathematical formula that encapsulates the information. With this iterative learning process, data scientists were able to kick start model building. P2 said “I think that was very helpful because after that, my dependency reduced a bit. I could myself assess that what category they belong to.”

Summary:. From our interview, we derived several design requirements to design Ziva. We found that the usage of domain knowledge is not only limited to labeling but also other parts in ML development, sometimes open-ended learning. Thus, interfaces of Ziva ought to facilitate domain-knowledge learning of data scientists in general throughout the development workflow. More specifically, we found that the tool should scaffold domain experts to efficiently elicit domain knowledge within short amount of time (R1). Next, a tool should help data scientists to extract basic domain concepts (R2). Lastly, data scientists indicated that they often learn from domain experts’ rationale, especially how they justify a decision or label. Hence, the tool needs to facilitate label justification sharing (R3).

As highlighted in the our formative interview, domain experts have limited time for labeling or sharing domain knowledge (R1). Hence, it is important to ask them to review only a few of instances and the sample can cover most concepts in the domain. Ziva extracts such a representative sample of m instances from a large training set of N text instances by the simple method of transforming the original text into ’tf-idf’ space, clustering the result using an algorithm such as k-means (setting k = m), and, for each cluster, returning the text instance closest to the cluster center. This method is not deterministic, but provides a reasonable set of representative instances, for cases where m < < N.

Creating a taxonomy is an effective way of organizing information [20, 48]. Ziva provides an interface where SMEs can extract domain concepts (R2). Users are asked to categorize each example instance, presented as a card, via a card-sorting activity. Users first group cards by topic (general concepts of the domain such as atmosphere, food, service, price). Cards in each topic are then further divided cards into descriptions referencing specific attributes for a topic (e.g., cool, tasty, kind, high). The interface (Figure 2) was implemented as a drag-and-drop UI using LMDD [2].

Once a domain expert finishes the concept extraction, they review each instance using one of elicitation interfaces, which ask the domain expert to justify an instance's label (this information is then intended for consumption by data scientists (R3)). We used Materialize to implement the justification elicitation conditions.

The justification elicitation interfaces were designed through an iterative process of paper prototyping, starting with initial designs inspired by our preliminary interviews. As we conducted paper prototyping, we examined if (1) the answers from different participants were consistent and (2) the information from participants’ answers were useful to data scientists. We now describe the five different justification elicitation methods that we created and evaluated, and highlight the design rationale where appropriate.

Bag of words. This base condition reflects the most common current approach. Given an instance and a label (e.g., positive, negative), the domain experts are asked to highlight the text snippets that justify the label assignment.

Instance perturbation. Inspired by one of our data scientists in the formative study, this condition asks a domain expert to perturb (edit) a part of the instance such that the assigned label is no longer justifiable by the resulting text. For example, in the restaurant domain, “our server was kind”, can be modified to no longer convey a positive sentiment by either negating an aspect (e.g., “our server was not kind”) or altering it (e.g., “our server was rude”).

This strategy is also inspired by the research area of generating natural language adversarial examples [7]. Such approaches algorithmically alter training examples to create similar adversarial examples that fool well-trained NLP models. In our scenario, the domain expert is seeking to alter training examples in order to point out the most salient characteristics to the data scientist; the latter learns from this information, combining it with syntactic and semantic analysis of the original and perturbed instances.

Instance simplification. This condition asks domain experts to shorten an instance as much as possible, leaving only text that justifies the assigned label of the original instance. For example, “That's right. The red velvet cake... ohhhh.. it was rich and moist”, can be simplified to “The cake was rich and moist”, as the rest of the content does not convey any sentiment, and can therefore be judged irrelevant to the sentiment analysis task.

This condition is inspired by the plethora of methods for sentence simplification used in extractive text summarization [77]. In particular, the domain expert is performing sentence reduction as in [40]. The output can be considered to be a concise summary of the original instance, keeping only that content which is directly relevant to the sentiment analysis task. The result for the data scientist is clean, compact, and fully relevant high quality training examples.

Concept bag of words. This condition incorporates the concept extracted in the prior step. Similar to the Bag of words condition, domain experts are asked to highlight relevant text within each instance to justify the assigned label; however, each highlight must be grouped into one of the concepts. If, during Concept creation, the domain expert copied a card to assign multiple topics and descriptions, then the interface prompts multiple times to highlight relevant text for each one. For example, if they classified the instance, “That's right. The red velvet cake... ohhhh.. it was rich and moist”, into the concept “food is tasty”, they can select rich, moist and cake as being indicative words for that concept.

Concept annotation. This condition is similar to the above Concept bag of words condition. However, when annotating the instance text, domain experts are directed to distinguish between words relevant to the topic and words relevant to the description. Given the above sample instance, the domain expert would need to indicate which part of the sentence applies to food (e.g., cake) and which to tasty (e.g., rich and moist). Both this and the previous concept condition are motivated by the well-established knowledge that a variety of NLP tasks, such as relation extraction, question answering, clustering and text generation can benefit from tapping into the conceptual relationship present in the hierarchies of human knowledge [85]. Learning taxonomies from text corpora is a significant NLP research direction, especially for long-tailed and domain-specific knowledge acquisition [79].

In the rest of the paper, we present a case study to evaluate the utility of the Ziva interface in two parts. In Section 5, we conduct a lab experiment and a crowd experiment in which participants acted as domain experts using Ziva. We choose the domain of restaurant reviews (Yelp Open Dataset[3]) and the NLP task of sentiment analysis, as being extremely familiar and easy enough to understand for most people to qualify as domain experts. In Section 6, we conduct an interview study with data scientists to evaluate the utility of domain knowledge collected in the above experiments. We instruct the data scientists to assume no previous knowledge of the domain, so we could use the elicited knowledge about restaurant reviewing as proxy to understand how Ziva could help them build NLP models.

Study protocol: To avoid noisiness in labeling, we pre-labeled the set of yelp reviews instance so we could focus on comparing the elicitation methods. We created binary labels based on ground-truth ratings: if the number of stars is 1 or 2 for a review, we labeled it as negative, 4 or 5 as positive [87]. We then took a random balanced sample of 10,000 instances. 8,000 were used as a (balanced) ’training set’, from which we extracted ten representative instances to use in the study (see Section 4.1.) We set the other 2,000 (balanced) instances to use as a test set for analyzing the performance of models built from the study output (see Section 6).

We recruited participants (5 female, 7 male), who self-report little or no knowledge in ML via posting on slack channels of an international technology company. Participants are designers, graduate students, researchers, trained professionals, skilled laborers, software engineers and project managers. To compensate their time, we ran a $30 raffle.

Participants were given introduction to the project and a tutorial of the Ziva interface. They were also given a practice task in a different domain, i.e., clothing. For the concept extraction task, all participants used the same interface. For the justification interface, we randomly assigned each participant one treatment from the elicitation methods without concepts (bag of words, label perturbation and simplification), and one from those with concepts (concept bag of words and concept annotation). Thus, each participant experienced two elicitation interfaces and reviewed 5 instances each. After each interface, participants were asked to fill out the NASA TLX form [32] to evaluate their subjective workload and share their feedback. The entire session lasted about for up to one hour.

Task Results: One participant could not complete the second justification interface. We reported the summary of concepts generated by participants, as well as quantitative and qualitative experience using justification methods.

Concept creation. Participants took 879.7 seconds on average (σ=385.4). They created 3.92 topics on average (σ=1.11). Everyone included Food quality and Customer service in their topics. To assess taxonomy from each domain expert, we examined the consistency between domain experts and coverage of the restaurant domain.

• Consistency between domain experts: The union of all topics across all participants includes following 10 topics: ambiance, cuisine, food quality, customer service, additional service, complaint, speciality, reservation, location, and price. For each topic, we rated whether each taxonomy intersects with the topic or not. Thus, the inter-rater reliability (IRR) across all domain experts was 58% using Fleiss’ κ.
  
• Coverage of the domain: We selected 3 additional instances which were not shown to the participants. We used our curation method to pick another set of representative instances. We then inspected how many instances can be categorized using each taxonomy resulting in a coverage of 69% (25 out of 36 instances).
  

Justification elicitation. The average task completion time in each condition is summarized in Table 2. Since each participant was assigned two out of five justification elicitation, there were only a few data points per elicitation technique (3 to 5 per technique). To further investigate in a larger population, we deployed Ziva on a crowd platform described in the following section.

Most participants found the bag of words condition easy to complete. One participant said: “This was easy because a lot of words were clearly positive or negative, such as ”terrible” or ”delicious””. However, some considered it tricky to identify words that are indicative of the overall sentiment. For example, one participant said, “this can be just descriptive without any positive or negative feelings without the context. So it's difficult to isolate the context out of the words.”

For the simplification task, participants indicated the task was straightforward. Participants said “easy as it had eliminated redundant and unnecessary words” and “quite easy and intuitive, paraphrasing keeping the original intent is what I usually do as part of minutes of meetings”. One participant said sometimes the task became hard because some instances could not be obviously shortened and instead need to be entirely rewritten.

Participants said perturbation is also straightforward but it required them to understand the entire instance thoroughly. One participant commented, “It was kind of hard because I don't know some of the words”. Another participant suggested that if the interface suggested antonyms, it would be easier to finish the task.

With concept bag of words, participants said it allowed subjective and nuanced elicitation, as they could pick words associated with a concept without judging their sentiment. However, it led to more varied results among participants. For example, for the concept Food is tasty, and the instance Ohhhh... The red velvet cake is rich and moist, most participants selected rich and moist. One participant said “Even red velvet cakecould be the indicative words if you personally like the cake”. Others said “maybe ohhhhpart can be included” and “moistdoesn't necessarily mean delicious”.

For the concept annotation task, participants said it is straightforward to choose words directly mapped to each token. On the other hand, it complicated the articulation to have to label in such fine granularity. One participant commented, “slightly tedious as it required me to comprehend on how best to label the words accordingly”.

To assess different justification methods on larger population, we deployed the Ziva interface on a crowd platform.

Study Protocol: Using our representative sampling method, we extracted 10 reviews from the datasets used in the lab study. We pre-populated a taxonomy. In order to provide a representative sampled concept, we recruited 5 volunteers and asked them to extract concepts of the restaurant domain using the concept extraction interface and two of the authors aggregated the taxonomy.

We installed 5 test questions for each condition with ground-truth created by the authors. If a crowd worker did not pass more than half of test questions, they can not continue to the Human Intelligence Task (HIT). Each worker was given one of the five justification elicitation interfaces, and reviewed 10 instances.

We recruited our study participants from Appen [1]. We compensated them with $0.5 per HIT, they are rewarded $2.5 in addition for test questions. From the lab study, we observed each HIT took less than 2 minutes on average, which makes hourly wage of $15. After the tasks, we asked them to fill out the same NASA TLX form to report on their subjective workload. Participants were rewarded additional $3 for the survey. A total of 88 crowd workers completed our study resulting in 857 instances with elicitated data.

Result: We analyzed participants’ survey responses using an one-way Kruskal–Wallis ANOVA as summarized in Table 3. There was marginal difference in self-reported success of task accomplishment and significant difference in stress level across justification elicitation methods.

As a post-hoc analysis, we ran a one-tailed Mann-Whitney U Test. The result revealed that participants completed the tasks using bag of words perceived higher success in accomplishing the tasks than participants with simplification (U=76.5, z=2.31; p=.01) and concept annotation (U=97.5, z=2.02; p=.02). Concept bag of words users also perceived higher success than simplification (U=75.5, z=2.34; p=.009) and concept annotation users (U=103, z=1.85; p=.03).

As for the stress level, bag of words users reported significantly higher stress than perturbation (U=55, z=2.90; p=.002), concept bag of words (U=84.5, z=-2.24; p=.01), and concept annotation users (U=81.5, z=-2.34; p=.01).