Native coref component

[svlandeg]

Work-in-progress

Description

Creating a native coref component in spaCy

Types of change

enhancement

Checklist

• I have submitted the spaCy Contributor Agreement.
• I ran the tests, and all new and existing tests passed.
• My changes don't require a change to the documentation, or if they do, I've added all required information.

[svlandeg]

Status March 1:

• Wrote preliminary v3-compatible framework to facilitate experimentation with different coref models
• Currently assuming two different pipeline components:
  • coref_er / CorefEntityRecognizer is a rule-based mention detection algorithm: uses noun chunks, POS tags and named entities
  • coref / CoreferenceResolver assembles the provided mentions into clusters (dummy implementation)
• Using doc.spans to store the information:
  • doc.spans[coref_mentions] for storing all relevant coref mentions (nouns, pronouns, names, ...)
  • doc.spans[coref_clusters_i] for different clusters, indexed with i
• Coref.v0 needs to be implemented and changed to Coref.v1
• Scorer.score_clusters method that currently uses a too simple scoring mechanism (binary relations between mentions), should be refined with actual coref scoring algorithm

While all of this is mostly dummy framework, it already helped discover some bugs & required functionality, cf PRs #7197, #7209 and #7225.

Going forward, having this bare framework should facilitate working on this functionality with different people in parallel, filling in different parts...

TODO

• Implement proper coref ML model
• Proper mention detection algorithm, rule-based, ML-based, something like the SpanCategorizer, ...
• Meaningful evaluation script
• Tune & benchmark
• Rewrite errors to use spacy.errors

Open questions / current issues

• While we talked about keeping doc.spans a relatively simple dictionary of strings mapping to lists of spans, we might consider having a more formal way of defining clusters that belong together - currently this is done by matching a prefix in the spans key, which is obviously not ideal

• The design with the rule-based coref_er is again awkward, because this component won't run during nlp.update, meaning that the coref model could only train on gold mentions, which is not a good idea in terms of generalizability and robustness of the ML model.

[svlandeg]

I'll just merge this into the new WIP feature/coref branch on explosion, so we can continue the discussion there.