Azure's custom NER schema-design guidance states that you should avoid 'complex entities' — entity types that bundle together multiple distinct kinds of information with different surface patterns — because such entities are difficult for the model to pick out precisely from text, leading to boundary confusion and false positives. The documented remedy is to break the complex entity into multiple, more specific entity types so each has a narrower, more consistent pattern that requires fewer labels to learn accurately (the official example replaces a single 'Address' entity with 'Street Name,' 'PO Box,' 'City,' 'State,' and 'Zip'). In this project, ContactInfo mixes phone numbers, email addresses, and social media handles — three very different textual patterns — under one label, which is exactly the kind of complex/ambiguous entity design that causes low precision and nearby-text false positives. Replacing ContactInfo with separate Phone, Email, and SocialMedia entities and relabeling the corresponding spans in the training data addresses the root schema issue before retraining, whereas adjusting the confidence threshold, running auto-labeling, or simply adding more training data with the same flawed schema would not resolve the underlying ambiguity.
Community Discussion