Relation Extraction rel_model backprop problem with duplicate entities

[jefhil]

The backprop function in the Relation Extraction example seems to use the pooled vectors as an index back to the entities.
Won't that be problematic if the same entity appears more than once in the input doc??

(P.S. Thanks again for all your excellent software and advice!)

[svlandeg]

Hi, thanks for your question!

Won't that be problematic if the same entity appears more than once in the input doc??

By "the same entity", do you mean the same string, being tagged as an entity, as in "In Paris, I fell in love with Paris"?
Because in spaCy's terminology (and in the code), an "entity" is character-bound. That means that the first "Paris" will be a different entity as the second, and their ent.start and ent.end properties will be different.

If you look at the backprop implementation in rel_model.py, you'll see that the backpropped information from the pooling layer (d_ents) is propagated to each individual, character-bound entity:

d_tokvec[ent.start : ent.end] += d_ents[ent_index]

So we don't go by the string - we go by the offsets in the text to avoid issues. Does that answer your question?

[jefhil]

Thanks for the response. It's not that the entities aren't distinct -- its the way the rel_mode backprop function finds them.
The backprop code maps from the pooled entity representation back to the entities like this:
d_pooled = model.ops.reshape2f(d_relations, d_relations.shape[0] * 2, -1)
d_ents = bp_pooled(d_pooled).data
In a sentence like, "joan lived in Paris and Jack visited Paris" , the two "Paris" entities will have the same pooled representation, so it seems random(?) which "Paris" entity will be used but the 2 "Paris" entities are in distinct relations:
(lives Joan Paris-1)=1 (visits Jack Paris-1)=0
(lives Joan Paris-2)=0 (visits Jack Paris-2)=1

[svlandeg]

d_ents is mapped back to the correct instance by looking at the all_instances variable, which maps to Span objects, which are character-bound. It's not doing any kind of string matching or such.

You're right thought that ideally you need a tok2vec component that produces context-dependent embeddings (like a transformer).

[jefhil]

I'm going to try the approach in:
https://github.com/uf-hobi-informatics-lab/ClinicalTransformerRelationExtraction

thanks for your responses!