Skip to content
This repository has been archived by the owner on Jul 15, 2022. It is now read-only.

[head] Relation extraction + NER multitask head #371

Open
dvsrepo opened this issue Sep 25, 2020 · 0 comments
Open

[head] Relation extraction + NER multitask head #371

dvsrepo opened this issue Sep 25, 2020 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@dvsrepo
Copy link
Member

dvsrepo commented Sep 25, 2020

Is your feature request related to a problem? Please describe.
In order to better support information extraction use cases, joint models performing relation extraction + NER typically perform better and simplify extraction problems.

Describe the solution you'd like
The solution will be to create a joint task head performing NER -> Relation Extraction (Classification). This can be done combining our current TokenClassification and RelationClassification heads.

I include a working implementation draft (https://gist.github.com/dvsrepo/a33bcd1c4e7074fbf15aefdccca5b46f) with several caveats:

  • We need to extend our current vocabulary handling to support heads to have custom label namespaces (now its fixed in vocabulary.LABEL_NAMESPACE. When you start combining heads with different label domains (e.g., labels for a classifier and tags for a token classifier) they will basically overwrite each other, leading to indexing issues. Ideally, the label namespace could be set in the head (although I would no recommend to request this to the user in the init or configuration).

  • Loss could be calculated with different coefficients, e.g. loss_classiffier + 0.5*loss_ner. This is a hyperparam which could be optimized with HPO so it should go to the head config.

  • We need to think about the TaskOutput and metrics report (see the implementation for a rough idea).

  • This is the first implementation of a multitask head so we should set the basis for other multitask models (e.g., classification + lm loss term)

  • Backbone forward pass is done twice (or N times if we had N heads).

  • There are some issues with default_mapping functionality when we have several optional params (entities and labels in our case) see data creation in gist

@dvsrepo dvsrepo added the enhancement New feature or request label Sep 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants