GPLinker: Joint Event Extraction Based on GlobalPointer

Task Introduction

Event extraction is a comprehensive task. A standard event extraction sample is as follows:

Each event has an event type and a corresponding trigger word, and is equipped with arguments of different roles. Event types and argument roles are selected from a predefined finite set (schema), while trigger words and arguments are generally fragments of the input sentence. In a few cases, they are also enumerable classification objects (as seen in Baidu’s DuEE-fin). In principle, the design of an event extraction model depends on the evaluation metrics. In LIC2020, the reason we could transform event extraction into an NER problem was that the evaluation metrics at that time only examined the triples composed of (event type, argument role, argument). Therefore, we could combine (event type, argument role) into a single large category, which then corresponded to NER.

Of course, this is just a clever trick for that specific metric. For real-world event extraction scenarios, we naturally hope to extract events in a standard format, which means designing a model that is as complete as possible. Below, we will introduce the GPLinker model used for event extraction, which basically meets the requirements of being simple and complete.

Unified Arguments

We have mentioned the word "complete" several times. What does it mean? Specifically, we hope that the final model design can, at least in theory, be applied to as many event extraction scenarios as possible. Traditional event extraction models are generally divided into four subtasks: "trigger detection," "event/trigger type identification," "event argument detection," and "argument role identification." This means the trigger word must be detected first, and then further processing is done based on the trigger word. Therefore, if the training set does not label the trigger words, it cannot function. This shows that the traditional approach is not complete enough.

To unify scenarios with and without trigger words, we treat the trigger word as just another argument role of the event. In this way, the presence or absence of a trigger word is simply the addition or subtraction of an argument. Thus, the main focus remains on argument identification and event partitioning. For argument identification, we still combine (event type, argument role) into a large category and transform it into an NER problem. However, it should be noted that different entities may be nested, so the previous CRF-based NER is insufficient. Here, we use GlobalPointer, which can identify nested entities, to complete this.

As mentioned earlier, tasks like DuEE-fin also feature classification-style argument types, where the argument is not a fragment of the input text but is selected from a finite set. Considering that there are not many such argument types, we also transform them into extractive arguments. Taking DuEE-fin as an example, for the "Stage" argument of the "Company Listing" event type, the four candidate values are Preparing for Listing, Suspension of Listing, Official Listing, and Termination of Listing. Instead of treating "Stage" as an argument type, we treat Preparing for Listing, Suspension of Listing, Official Listing, and Termination of Listing as four distinct argument types, and the corresponding entity is the trigger word. In this way, the argument we extract is not the classification-style (Company Listing, Stage, XX Listing), but the extractive (Company Listing, XX Listing, Trigger). Finally, we convert them back during the model’s post-processing stage.

Complete Subgraphs

As for event partitioning, a natural idea is to directly aggregate all arguments with the same event type into one event. However, this is also not complete enough because a single input may contain multiple events of the same type. What if we add trigger words? Still not enough. Multiple events of the same type might share the same trigger word. For example, a sample in DuEE is: "Main members Cheng Jie and Wang Shaowei were sentenced by the court of first instance to 22 years and 20 years in prison respectively." There are two events: "Cheng Jie sentenced to 22 years in prison" and "Wang Shaowei sentenced to 20 years in prison." The trigger word for both is "prison sentence," and the event type for both is "Incarceration."

Therefore, we need to design an additional module for event partitioning. We believe that the various arguments of the same event are connected, and this connection can be described by an undirected graph. That is, we treat each argument as a node on the graph, and any two argument nodes of the same event can be connected by an edge to become adjacent nodes. If two arguments never appear in the same event, the corresponding nodes have no edge (are not adjacent). Consequently, any two nodes of the same event are adjacent, which we call a "Complete Graph" or a "Clique." Event partitioning is thus transformed into a search for complete subgraphs on the graph.

So, how do we construct this undirected graph? We follow the approach of TPLinker. If two argument entities are related, their (head, head) and (tail, tail) can be matched. Like the GPLinker for relation extraction, we can use GlobalPointer to predict their matching relationship. Specifically, since we only need to construct an undirected graph, we can mask the lower triangular part, and all edges are described using only the upper triangular part.

Search Algorithm

Assuming we already have an undirected graph describing the relationships between arguments, how do we search for all complete subgraphs? It looks similar to graph partitioning, but not exactly the same, because in our scenario, nodes can be reused, meaning the same entity can simultaneously be an argument for multiple different events. For example, in the figure above, the 8 nodes can yield two complete subgraphs, where node D appears in both subgraphs. This means we can partition two events that share a common argument D.

After analysis, I conceived the following recursive search algorithm:

1. Enumerate all node pairs on the graph. If all node pairs are adjacent, then the graph itself is a complete graph; return it directly. If there are non-adjacent node pairs, proceed to step 2.

2. For each pair of non-adjacent nodes, find the sets of all nodes adjacent to each (including the node itself) to form subgraphs, and then execute step 1 for each subgraph set.

Using the figure above as an example, we can find that B and E are a pair of non-adjacent nodes. Then we can find their respective adjacency sets as \{A, B, C, D\} and \{D, E, F, G, H\}. We then continue to look for non-adjacent node pairs in \{A, B, C, D\} and \{D, E, F, G, H\} and find none, so \{A, B, C, D\} and \{D, E, F, G, H\} are both complete subgraphs. Note that this does not depend on the order of non-adjacent node pairs because we perform the same operation for "all" non-adjacent node pairs. For instance, if we find that A and F are a pair of non-adjacent nodes, we would similarly find their adjacency sets \{A, B, C, D\} and \{D, E, F, G, H\} and execute recursively. Therefore, in the whole process, we might get many duplicate results, but we will not miss any results, nor will we be affected by the identification order; we just need to deduplicate at the end.

Furthermore, for each search, we only need to search nodes of the same event type. In most cases, the number of arguments for the same event type is in the single digits, so although the above algorithm seems complex, its actual running speed is very fast.

Experimental Results

Now our design for event extraction has been introduced. In summary, we need a nested entity recognition model to identify arguments, and then we need a "head-head" matching model and a "tail-tail" matching model respectively to construct the relationships between arguments. These modules are surprisingly consistent with the GPLinker model for relation extraction, and they can all be completed using GlobalPointer. Therefore, we still name it "GPLinker." The code is organized at:

GitHub Address: https://github.com/bojone/GPLinker

I conducted simple experiments on DuEE and DuEE-fin and submitted them to the QianYan Leaderboard. The results are as follows:

Looking at these two scores alone, they rank 5th on the leaderboard, which is not particularly outstanding and is still some distance from 1st place. However, this article was not specifically intended for competition, so no further optimization was done for the competition data. The current results are quite commendable. As for the lack of comparison with other event extraction models, it is because I am truly unfamiliar with this field. I briefly looked at a few papers on relation extraction and felt the models inside were exceptionally complex, so I didn’t have the interest to reproduce them.

Finally, the GlobalPointer used in the code is entirely Efficient GlobalPointer. I also compared it with the standard version of GlobalPointer and found that while the standard version converges faster in the early stages, its final performance is worse. This once again confirms the effectiveness of Efficient GlobalPointer.

Model Reflection

Using GPLinker for event extraction pursues simplicity and completeness. In practice, it may not be the most effective solution. One obvious problem is its significant dependence on data; performance may be poor in few-shot scenarios. This is essentially due to GPLinker being sufficiently complete, which means it has a high degree of freedom (it can accommodate many scenarios), and the model has little prior information, thus increasing the learning difficulty.

However, GPLinker indeed has the characteristics of being simple and efficient, and theoretically, there is no Exposure Bias problem. Therefore, in practice, if GPLinker’s performance is suboptimal, one feasible solution is to first use another method that can achieve better results (likely high performance but poor efficiency) to create a model version, and then distill it into GPLinker. This way, both performance and efficiency can be balanced.

Conclusion

This article introduced the idea of using GPLinker for event extraction. It first uses nested entity extraction to extract arguments and then transforms event partitioning into a complete subgraph search problem. The entire model is relatively concise and complete, and theoretically, there is no Exposure Bias problem.

When reprinting, please include the address of this article: https://kexue.fm/archives/8926

For more detailed reprinting matters, please refer to: "Scientific Space FAQ"