Entity linker returns NIL if no aliases are defined

[fcggamou]

How to reproduce the behaviour

I was trying to train a NEL and was getting NIL for every token every time. I tried the examples from https://spacy.io/usage/examples and it worked fine. I realized the difference is that I don't have any aliases defined in my KB. I then proceeded to test the same examples "Creating a Knowledge Base for Named Entity Linking" and then "Training spaCy’s Named Entity Linker" but removing this line:

kb.add_alias(
        alias="Russ Cochran",
        entities=["Q2146908", "Q7381115"],
        probabilities=[0.24, 0.7],  # the sum of these probabilities should not exceed 1
     )

Without this line I reproduce the issue on these simple examples, getting this as a result:

Entities [('Russ Cochran', 'PERSON', 'NIL')]
Tokens [('Russ', 'PERSON', 'NIL'), ('Cochran', 'PERSON', 'NIL')]

Entities [('Russ Cochran', 'PERSON', 'NIL')]
Tokens [('Russ', 'PERSON', 'NIL'), ('Cochran', 'PERSON', 'NIL')]

Entities [('Russ Cochran', 'PERSON', 'NIL')]
Tokens [('Russ', 'PERSON', 'NIL'), ('Cochran', 'PERSON', 'NIL')]

Entities [('Russ Cochran', 'PERSON', 'NIL')]
Tokens [('Russ', 'PERSON', 'NIL'), ('Cochran', 'PERSON', 'NIL')]

I guess I'm probably misunderstanding something, but I thought aliases were optional, sort of a way to define synonyms or something. Do I need to add aliases for every entry in my KB?

Your Environment

• spaCy version: 2.2.4
• Platform: Linux-4.19.104+-x86_64-with-Ubuntu-18.04-bionic
• Python version: 3.6.9
• Models: en, es

[svlandeg]

I guess I'm probably misunderstanding something, but I thought aliases were optional, sort of a way to define synonyms or something. Do I need to add aliases for every entry in my KB?

Aliases are definitely required as input. The KB does not know anything else about the entities other than their unique ID, so it's not able to produce sensible candidates if there are no aliases.

[fcggamou]

Thanks a lot for the answer, I thought the EL would learn to produce the candidates through the training examples.

[svlandeg]

That does seem like a reasonable approach, but internally it would mean quite some changes. Right now there are two steps: First, the KB generates the candidates. Then, the EL scores each candidate. Currently, only the latter step is trained; the candidate generation itself isn't. You can ofcourse use your training data to define the aliases and their prior probabilities, but you'd do this only once, and the KB would remain the same throughout further training of the EL algorithm.

[svlandeg]

I'm thinking about this some more, and it would definitely be less efficient to adjust the aliases / prior probabilities on the fly.

Basically when encountering the combination entity X triggered by alias a in the training data, you'd need to find all other entities that may have a as alias and do something about all of these prior probabilities. I'm sure it could be done, and there may be use-cases for it, but if you have a large corpus, I think it makes more sense to do this up-front.

[fcggamou]

Thanks a lot for your answer. Indeed your explanation makes a lot of sense.

Actually my use-case is a little bit different, and maybe not the actual intended use case of EL; I'm trying to disambiguate medical terms (similar to scispaCy), and I ideally I would like the model to learn to identify medical terms even if I had not added an alias for it in the exact same words.
Sort of how a NER model would know that something is a person even if it has not seen this particular name before, I would need a model that learns that "high blood pressure", "arterial hypertension", "increased blood tension" are all the same medical term with some ID, and then correctly identify e.g. "high blood tension" even if it has not seen it before (and so on for all of the possible terms in my dictionary). If I understand correctly this is not currently possible with the current implementation of EL, right?

[fcggamou]

After a little bit of digging it seems this is something that has been discussed before, #4981, #4572, #4988. Do you think we may get official support for this kind of thing in the near future? Thanks

[svlandeg]

Yep your use-case sounds a lot like what @kabirkhan was working on. I'll close this issue and let's continue our discussion at Issue #4981 and the related PR #4988 to keep the discussion in one place :-)

And yes, we do want to support this in the near future. We probably want to get a stable release of v.3 out first, then focus on additional features like this. The ongoing work on v.3 has been holding up that PR, but it would be good to get back to that soonish.