Relation, Event, and Temporal Extraction › Document-Level Effects

Some of the examples require information beyond one sentence. The following effects help determine which document context an application needs.

Document-level effects are not a single problem. Several examples below require information beyond the sentence containing the target mention. For these cases, the missing information can be in a previous sentence, a previous paragraph, or document metadata. A system recovering those outputs must make that information available to its prediction stage.

A sentence-local extractor can miss the identity of an argument expressed through a pronoun or description. In the examples here, "it" and "the company" can refer to entities, while "the deal" can refer to an event. Resolving a reference means identifying what it refers to. In these examples, an earlier mention supplies the antecedent. A description can serve as the antecedent. In “The buyer signed. It later paid,” “the buyer” supplies the antecedent of “it.”

When an argument is expressed through a pronoun or another referring expression, extraction may need coreference to identify its entity. An explicit subject and object can instead support a sentence-level relation without a separate coreference step. Relation information can also provide evidence for resolving mentions. Iterative and joint models can represent this interaction; Coreference Resolution develops the task.

The dependency can be handled in stages. A first pass can resolve easy cases, such as pronouns with a single compatible antecedent in the previous sentence. A second pass can use the extracted relations to disambiguate harder cases, and then a third pass can re-run extraction with the improved coreference. This is an iterative design option. Each pass needs evaluation: an incorrect antecedent can propagate into the next extraction pass.

Two textually different mentions may refer to the same entity: "Acme", "Acme Corp", "ACM", "the Ohio-based manufacturer". Coreference or entity resolution groups references to the same entity; entity linking maps a mention to a knowledge-base identifier. Linking to a shared identifier supports cross-document aggregation, while unresolved aliases may remain separate.

Changing the prediction unit also changes what gets counted. At the mention level, "Acme Corp acquired Bolt Systems" and "Acme acquired Bolt" are separate predictions. Once the mentions have been resolved to the same entities, the two passages can provide evidence for one entity-level prediction. The next chapter covers this in detail.

Entity linking is especially important for aggregation. If the system extracts (Acme, acquire, Bolt) from one document and (Acme Corp, acquire, Bolt Systems) from another, those are two different triples unless the mentions are linked. If aggregation treats these unresolved aliases as distinct identifiers, it can create duplicate nodes or edges and leave a query over one alias incomplete. Entity linking is one way to reconcile the references; an input that already supplies canonical identifiers does not require a separate linking step.

Long documents introduce two practical constraints.

• First, context length. In multi-document QA and key-value retrieval experiments, Liu et al. (2024; preprint 2023) observed sensitivity to where relevant information appeared in long inputs. That result motivates checking evidence position in an extraction evaluation; it does not establish the same degradation for every extraction model. Chunking with overlap and subsequent aggregation is one design option.
• Second, the combinatorial blow-up. If a 10,000-token document contains 100 entity mentions, enumerating ordered pairs of distinct mentions gives 9,900 candidates. Possible filters include entity-type compatibility, sentence distance, and selected keywords. They reduce the candidates scored only by excluding pairs; compare retained-relation recall and runtime against exhaustive or batched scoring.

Chunking with overlap introduces its own problems. An entity mention that falls on a chunk boundary may be split, and a relation whose arguments are in different chunks may be missed. Overlap can put a boundary-spanning mention or pair into a chunk, but it can also produce duplicate extractions that need a merge decision. Design the merge rule together with the chunking strategy, and evaluate the combined output.

An extracted record can retain provenance, including its source sentence, character offsets, and trigger. Those references let an auditor inspect the supporting text and help distinguish an extraction error from a later normalization or aggregation error.

The JSON below shows the spans and offsets for the acquisition candidate attributed to Acme. The worked record that follows also keeps the status and attribution fields, which this projection leaves out.

{
  "head": "Acme Corp",
  "head_span": [0, 9],
  "relation": "acquire",
  "tail": "Bolt Systems",
  "tail_span": [57, 69],
  "evidence": "Acme Corp announced on 3 March 2019 that it had acquired Bolt Systems",
  "evidence_span": [0, 69]
}

Each quoted source span must match the document at its stated character offsets. A mismatch can indicate an incorrect offset, altered surface text, or a fabricated span; it does not by itself identify the cause. A substring check tests whether selected field strings occur somewhere in the document. A strict offset check additionally tests the exact location. The implementation below demonstrates the substring check, which does not establish that the source entails the extracted relation.

Evaluate the tuple and its cited evidence separately. An otherwise correct candidate for Acme’s reported acquisition could cite the paragraph’s chief-executive sentence, which does not support that report. Retaining the evidence span makes this mismatch available for review.