What a three-entry company list adds to an AI text extractor

An AI system can correctly label BQE as an organisation and still leave a business with a basic problem: which organisation? In a small test using invented meeting notes, we gave the text-processing library spaCy three dictionary entries. They joined an abbreviation to a full company name, repaired two recognition errors and exposed a new mistake when we added an ambiguous alias.

The exercise offers a useful starting point for extracting familiar suppliers, customers or projects from documents. spaCy can combine a trained named-entity recogniser with an EntityRuler, a component that applies explicit matching rules. A rule can supply both an entity label and an identifier shared by several names. That makes a small, controlled vocabulary useful without retraining the recogniser.[1]

Start with an identity, then add the names

Our miniature company register contained two businesses. Bracken Quay Energy and BQE both pointed to company:001; Willowbridge Labs pointed to company:002. Each entry carried the ORG label, the term used by this model for an organisation. The identifiers were simply labels we assigned to our fictional register.

We loaded the trained English pipeline, then placed EntityRuler after its named-entity recogniser. The setting phrase_matcher_attr=LOWER made phrase matching insensitive to capitalisation. Setting overwrite_ents=True allowed a dictionary match to replace an overlapping model prediction; the default would preserve that prediction. We also enabled pattern validation. These choices are available in spaCy’s documented API.[2]

That order made the division of labour visible. The model processed each sentence first. Our register then supplied a fixed answer for phrases it contained. No model weights changed during the test.

Recognition, classification and identity are separate decisions

A named-entity recogniser predicts which span of text represents an entity and assigns a category. spaCy describes its recogniser in those terms; its separate EntityLinker addresses linking recognised names to identifiers in a knowledge base. Our alias list performed only a tightly specified mapping of known phrases to our own records.[3][4]

The before-and-after outputs show why these distinctions matter:

• Bracken Quay Energy and BQE were already recognised as organisations in their respective sentences. Neither had an entity ID. Our rules attached company:001 to both, giving them a common record key.
• In the lowercase sentence, the base model labelled only the word quay as a geopolitical entity. The rule replaced that fragment with the complete phrase bracken quay energy, labelled ORG and linked to company:001.
• Willowbridge Labs was initially labelled PERSON. The register changed its label to ORG and attached company:002.
• Bracken Quay, a shortened form we deliberately left out of the register, remained labelled PERSON. Adding the full name did not teach the rule to infer every possible abbreviation.

The output also retained the start and end character positions of each extracted span. For the lowercase company name, those were 31 and 50 in our test sentence, counting from zero and excluding the end position. Keeping the original text alongside those positions makes the correction inspectable: a reviewer can see exactly which words produced a record, instead of receiving an unexplained company name.

A nickname can turn a tree into a company

For a second pass, we added Willow as an alias for Willowbridge Labs. This was an intentionally ambiguous rule. It successfully attached company:002 to Willow in the sentence “Willow will review the sensor results.” It attached the same identifier to Willow in “Willow grew beside the river.” Before that extra rule, neither sentence contained a recognised entity.

The failure followed directly from the instruction we supplied. Our phrase rule said that this spelling denoted a company wherever it appeared. It contained no condition about the sentence’s meaning. Lowercase matching also meant that changing the initial capital would not repair that instruction.

For this small register, the sensible next edit would be to remove the ambiguous alias or require context that distinguishes company usage. spaCy supports token patterns as well as phrase patterns, allowing rules to describe more than a bare name. Any more elaborate condition would need its own positive and negative examples; it was not tested in this exercise.[1]

Build a register you can inspect

A useful first version therefore contains more than names. Keep the canonical company ID, its approved aliases and a sentence showing each intended use. Add examples that must remain unmatched, particularly for short names and ordinary words. Run the original and adapted pipelines over the same notes, preserving the text, labels, identifiers and character positions so each change is visible.

In our seven sentences, three entries were enough to join two names and correct two labelling errors. One additional entry was enough to introduce a false company match. That makes the register an operational part of the extraction system: a small piece of business knowledge whose contents deserve the same attention as the model’s output.

Report an error or suggest a correction