Human-in-the-loop Schema Induction (2023)

Abstract: Schema induction builds a graph representation explaining how events unfold in a scenario. Existing approaches have been based on information retrieval (IR) and information extraction (IE), often with limited human curation. We demonstrate a human-in-the-loop schema induction system powered by GPT-3. We first describe the different modules of our system, including prompting to generate schematic elements, manual edit of those elements, and conversion of those into a schema graph. By qualitatively comparing our system to previous ones, we show that our system not only transfers to new domains more easily than previous approaches, but also reduces efforts of human curation thanks to our interactive interface.

## introduction event-centric natural language understanding (nlu) has been increasingly popular in recent years. systems built from an event-centric perspective have resulted in impressive improvements in numerous tasks, including open-domain question answering @xcite , intent prediction @xcite , timeline construction @xcite , text summarization, @xcite and misinformation detection @xcite . at the heart of event-centric nlu lie event schemas, an abstract representation of how complex events typically unfold. the study for such a representation dates back to the 70s, where scripts were proposed as a series of sequential actions @xcite . back then, the schemas were limited to linear and temporal ones. a more recent formulation of event schemas is a graph where the vertices are event flows and the edges are temporal or hierarchical relations between those events @xcite . for example, as shown in figure 1 , the event schema for a "cyber attack" could include subevents such as "gain access", "control system", "exfiltrate files", "modify system logs", etc. the schema would also include the relationships between these sub-events. for instance, the event "gain access" would take place before the event "modify system logs" since a person needs access to a system before modifying it. for the same reason, "exfiltrate data" would only take place after "gain access". event schemas like this encode highlevel knowledge about the world and allow artificial intelligence systems to reason about unseen events @xcite . the darpa knowledge-directed artificial intelligence reasoning over schemas (kairos) program foot_1 aims at developing schema-based ai systems that can identify, comprehend, and forecast complex events in a diverse set of domains. to enable such a system, scalable generation of highquality event schemas is very crucial. on one hand, fully-manual schema creation at a large scale can be inefficient, since people have diverse views about a certain concept, leading to inconsistent schema results. on the other hand, fully automated systems are scalable, but not with high-quality. in fact, the majority of existing approaches under the kairos program are fully-automated ir and ie systems over large collections of news articles @xcite . only some of limited human post-processing on schemas @xcite have been explored. further discussion of the advantages and limitations of existing systems can be found in related work. instead of focusing on fully-automated schema induction systems, we propose a human-in-theloop schema induction pipeline system. rather than using ir and ie over a large document collection, our system relies on pre-trained large language models (llms) and human intervention to jointly produce schemas. our main motivation is that human-verified schemas are of higher quality. that is because human curation can filter out failure cases such as incompletness, instability, or poor domain transfer results in previous systems @xcite . with human curation, schemas are more reliable and accountable when applied to downstream tasks such as event prediction. this is significant if the downstream tasks involve safety-critical applications like epidemic prevention, where the quality of the schema matters beyond task performance numbers. a more comprehensive description of the implementation and functionalities of our interface can be found in section 4. a case study is given in section 5. it walks through each step in our pipeline system under an example scenario, cyber attack. also, in section 5, we provide a qualitative evaluation of five example scenarios. the summary and discussion of our system are included in section 6. ## terminology and problem definition our work focuses on efficiently building a schema graph of a scenario using both llms and human input. following the workflow of our system (see the workflow in figure 2 ), a scenario is a general event type that an interested party will build the schema for, e.g. a 'disease outbreak'. steps are a list of sub-events generated by gpt-3 according to a prompt in the step generation stage. each step can be a phrase or a short sentence, such as 'spread to other areas', etc. nodes or tuples are subjectverb-object pairs extracted from steps at the node extraction stage, such as '(disease, spread, to other area)'. graphs are a visualization of the schema, whose edges joining the nodes represente temporal and hierarchical relations. wikidata 3 ). the flexible interface system allows users to either go through the entire process to create a schema from scratch or directly start at any stage to edit the model's prediction. in addition, the back-end gpt-3 models can be replaced by other user pre-trained models if deployed locally. ## evaluation 5.1 a case study in this section, we walk through the whole process of creating a toy schema with our interface which is much simpler than a fully developed schema. we assume the scenario is 'cyber attack'. in the step generation stage, users can form a prompt from templates such as "list the steps involved in a cyber attack" with 'cyber attack' as the name and sub-event as the prompt type. then, gpt-3 will generate 5 steps. for example, "1. a cyber attacker gains initial access to a system" and "5. the attacker exfiltrates data from the compromised system." users can modify the content and choose steps to save. for example, one may change the first step to "1. a cyber attacker access a system." and save the step. see a screenshot of five steps for reference in figure 3 . next, in the node extraction stage, gpt-3 will be prompted to extract nodes from the selected steps. for example, gpt-3 will output {cyber attacker, access, system} for the first step. the user can change the outputs to correct any mistakes. in this sample, we extract 4 nodes, they are: {cyber attacker, access, system}, {attacker, enumerate, system information and user account}, {attacker, escalates, privileges}, {attacker, exfiltrate, data}. and we concatenate the {subject, verb, object} into a piece of text as a node for the next stage. thereafter, in the graph construction stage, we prompt gpt-3 to automatically build linear temporal edges on the above four nodes that users can modify. we manually add a scenario node 'cyber attack' and link with the other four existing nodes through hierarchical edges. see a screenshot of the graph in figure 4 . finally, we can optionally ground our graph node into the xpo ontology. for example, the node "cyber attacker access system" can be mapped to choices of 'access', 'computer monitoring', 'remote communicating' using name similarity grounding. in this case, we don't get any results from name inference grounding. see a screenshot of grounding in figure 5. ## conclusion with the acknowledgements that fully depending on human annotation is expensive and inefficient, while wholly automated generations can be unreliable, we propose a human-in-the-loop schema curation interface with pre-trained large language models (llms) as the backbone. we use llms to generate candidate components of a schema and involve human as the final judge for both the content and structure of the event schema. with empirical evaluations, we show that our system can efficiently produce human-validated event schemas with minori human efforts.