NER for Business: From Entities to a Working Process

I worked on NER services for business use cases in 2022–2023. This revision separates what an off-the-shelf model can do from the engineering that has to surround it.

Named Entity Recognition extracts defined entities such as people, organisations, and locations from unstructured text. It becomes useful when an email, support request, or document has to feed structured data into the next step of a process.

NER does not identify user intent

In Russian, «мне нужен перевод» can mean “I need a money transfer” or “I need a translation”: the word «перевод» covers both. Establishing the purpose of the request is primarily an intent-classification problem, not an entity-recognition problem.

A practical text-processing system often combines several components:

• NER identifies people, organisations, and locations;
• deterministic extractors parse amounts, phone numbers, tax IDs, and dates;
• an intent classifier determines what the user wants;
• validation rules decide whether the process has enough data to continue.

Calling all of this “NER” may simplify a slide, but it makes the system harder to design and evaluate.

What ru_core_news_sm provides

spaCy’s ru_core_news_sm pipeline is trained on Russian news and media text. The checked 3.8.0 model metadata lists three NER labels:

• PER for a person;
• ORG for an organisation;
• LOC for a location.

There is no built-in MONEY label in this Russian pipeline. It is not expected to return 50 000 рублей as one monetary entity.

Install spaCy and the model with:

pip install spacy
python -m spacy download ru_core_news_sm

Then run a small baseline:

import spacy

nlp = spacy.load("ru_core_news_sm")
text = "Алексей Петров приехал в Москву и встретился с командой Яндекса."
doc = nlp(text)

for entity in doc.ents:
    print(entity.text, entity.label_)

The code runs the trained pipeline and prints whatever it detects. Exact spans can change between model versions, so the example deliberately avoids presenting a hard-coded comment as a guaranteed result.

Extracting amounts separately

Structured formats benefit from a transparent rule-based layer. This educational example validates an already selected candidate span containing a non-negative ruble amount. fullmatch checks the entire span, so 1.234 рублей cannot silently turn into 234 рублей. Selecting candidates from a request is a separate stage:

import re
from decimal import Decimal

amount_pattern = re.compile(
    r"(?P<amount>(?:[0-9]{1,3}(?:[ \u00A0][0-9]{3})+|[0-9]+)"
    r"(?:[.,][0-9]{1,2})?)[ \u00A0]*"
    r"(?P<currency>₽|руб(?:ль|ля|лей|\.)?)",
    re.IGNORECASE,
)

candidate = "50 000 рублей"
match = amount_pattern.fullmatch(candidate.strip())
if not match:
    raise ValueError("Unsupported amount format")

raw_value = match.group("amount").replace(" ", "").replace("\u00a0", "")
value = Decimal(raw_value.replace(",", "."))
print(value, match.group("currency"))

The pattern accepts ordinary or non-breaking spaces between three-digit groups and one or two fractional digits after a comma or dot. It rejects signs, malformed grouping and excess decimal places. It neither extracts a span from arbitrary prose nor understands written-out numbers, slang, ranges or an implied currency. A real service needs a test corpus, explicit normalisation rules, and defined behaviour for ambiguous input.

When a hybrid design makes sense

I start with the output schema rather than a model name. For every field, the team should answer:

1. What counts as an entity, and where are its boundaries?
2. Which cases are reliable enough for deterministic rules?
3. Which cases require a model, and do we have labelled examples?
4. What happens when confidence is low or components disagree?

A useful pipeline often contains:

1. text normalisation while preserving the original input;
2. deterministic extraction for stable formats;
3. an NER model for contextual entities;
4. separate intent rules or a classifier;
5. merging, validation, and mapping into the business schema;
6. human review where the cost of an error is high.

The pre-trained model is a baseline. If the domain differs from news text, evaluate it on domain-specific labels before deciding whether to fine-tune the model, add rules, or do both.

Measuring the system

Overall accuracy hides too much. At minimum, I look at:

• precision, recall, and F1 for each entity type;
• exact span quality, not just the predicted class;
• separate slices for typos, lowercase input, and mixed languages;
• the share of requests completed without human correction;
• latency and technical failure rates.

Campaigns, new products, and document templates shift the input distribution. A labelled regression set, versioned artefacts, and post-release monitoring are therefore part of the product, not optional research work.

Production concerns

• Do not send sensitive text to an external API unless the data-processing model explicitly allows it.
• Record the model, rule-set, and input-schema versions with each result.
• Avoid logging raw text by default; it may contain personal data.
• Keep enough provenance to reprocess data after a pipeline update.
• When a human must confirm the result, show both the source span and the normalised value.

NER has no business value in isolation. It matters when extracted data enters a process safely and the system can admit that a fragment was not understood.

The official spaCy documentation describes the available Russian pipelines and their training domain.

Where reliable annotation comes from

Data annotation is a distinct part of the ML process. If two annotators disagree on an organisation name’s boundaries, the model receives a conflicting task. Start with guidelines, ambiguous examples, and a way to resolve disagreements before scaling the work.

For a pilot, I would give a small shared sample to several annotators and review the differences. Agreement is useful, but so are the causes: unclear instructions, conflicting business definitions, or poor source text. Decisions become a new guideline version, and affected examples are reviewed again.

In my enterprise work, an ML data-annotation platform belonged to the Big Data application-services area alongside NER, graph, and geo platforms. As IT Lead, I organised the area’s work and delivery process. That responsibility is distinct from training an individual model.

Acceptance example: extracting details from a request

Take an illustrative request: “Send the agreement to North LLC; the contact is Anna.” We need an organisation and a contact, but these are not automatically verified business records. The organisation still needs matching to a directory, and a first name does not identify a person.

Extracted result	Next step	When to stop
Organisation name	Match it to a directory and show candidates	Several companies match
Contact name	Request or match an authorised identifier	The information does not identify one person
Amount from a rule	Validate currency, range, and field meaning	The amount belongs to another document or period

This separates recognition from business action. A high F1 score does not prove that an agreement reaches the right recipient. A leader also needs the proportion of correctly completed workflows and the cost of reviewing difficult cases.

See my applied AI / ML work for NER and other implementations.

---

Original article: NER Services in Business on Habr

Yours, DPUPP