NER-сервисы для бизнеса: от сущностей к рабочему процессу

В 2022–2023 годах я работал с NER-сервисами для бизнес-задач. В этой версии статьи отделяю возможности готовой модели от того, что приходится проектировать вокруг неё.

NER, или Named Entity Recognition, извлекает из текста именованные сущности: людей, организации, локации и другие заранее определённые классы. Это полезно, когда из письма, обращения или документа нужно получить структуру для следующего шага процесса.

NER не определяет намерение пользователя

Фраза «мне нужен перевод» ещё не сообщает, идёт ли речь о переводе денег или текста на другой язык. Разобраться в цели обращения — прежде всего задача классификации интента, а не распознавания сущностей.

В прикладной системе обычно работают несколько компонентов:

• NER находит персону, организацию или локацию;
• детерминированные извлекатели разбирают суммы, телефоны, ИНН и даты;
• классификатор интента определяет цель обращения;
• правила валидации проверяют, достаточно ли данных для продолжения процесса.

Смешивать всё это под названием NER удобно на презентации, но вредно при проектировании и измерении качества.

Что даёт ru_core_news_sm

Русская модель spaCy ru_core_news_sm обучена на новостных и медийных текстах. В проверенной версии 3.8.0 встроенный NER использует три класса:

• PER — персона;
• ORG — организация;
• LOC — локация.

В частности, у этой модели нет встроенной сущности MONEY. Сумму 50 000 рублей она не обязана выделять как единый объект.

Установить spaCy и модель можно так:

pip install spacy
python -m spacy download ru_core_news_sm

Минимальный пример:

import spacy

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

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

Код запускает готовый pipeline и печатает найденные сущности. Точные границы и даже состав результата могут отличаться между версиями статистической модели, поэтому пример намеренно не подменяет тест ожидаемым комментарием.

Суммы лучше выделять отдельно

Для формализованных записей полезен прозрачный rule-based слой. Ниже учебная проверка уже выделенного фрагмента с неотрицательной суммой в рублях. fullmatch проверяет фрагмент целиком: строку 1.234 рублей нельзя молча превратить в 234 рублей. Выделение кандидата из обращения — отдельный этап:

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"))

Паттерн принимает обычные и неразрывные пробелы между группами из трёх цифр, запятую или точку перед одной-двумя цифрами копеек. Он отвергает знаки, неверную группировку и лишние десятичные знаки. Он не извлекает сумму из произвольного предложения и не понимает «пятьдесят тысяч», сленг, диапазоны и валюту из контекста. Для реального сервиса нужны тестовый корпус, правила нормализации и понятное поведение на неоднозначных строках.

Когда нужен гибридный подход

Я начинаю с определения схемы данных, а не с выбора модели. Для каждого поля нужно решить:

1. Что именно считается сущностью и где проходят её границы?
2. Что можно извлечь строгим правилом?
3. Для каких случаев нужна модель и есть ли размеченные примеры?
4. Что делать при низкой уверенности или конфликте результатов?

Практичный pipeline часто выглядит так:

1. нормализация текста без потери исходной строки;
2. детерминированное извлечение стабильных форматов;
3. NER-модель для контекстных сущностей;
4. отдельная модель или правила для интента;
5. объединение, валидация и приведение к бизнес-схеме;
6. ручная проверка там, где цена ошибки высока.

Готовая модель здесь служит baseline. Если домен заметно отличается от новостных текстов, качество нужно измерить на своей разметке, а затем дообучать модель или дополнять её правилами.

Как измерять качество

Одной общей accuracy недостаточно. Я смотрю как минимум на:

• precision, recall и F1 по каждому типу сущности;
• точность границ сущности, а не только совпадение класса;
• отдельные срезы для опечаток, нижнего регистра и смешения языков;
• долю обращений, которые можно обработать без исправления человеком;
• latency и частоту технических ошибок сервиса.

Новая акция, продукт или шаблон документа меняют входные данные. Поэтому контрольная размеченная выборка, версионирование модели и мониторинг качества нужны и после релиза.

Что важно в production

• Не отправлять чувствительные тексты во внешний API без разрешённой модели обработки данных.
• Хранить версию модели, правил и входной схемы вместе с результатом.
• Не логировать исходный текст целиком по умолчанию: в нём могут быть персональные данные.
• Сохранять возможность повторно прогнать данные после обновления pipeline.
• Показывать пользователю исходный фрагмент и распознанное значение, если решение требует подтверждения.

NER приносит пользу не сам по себе. Ценность появляется, когда извлечённые данные корректно встраиваются в процесс и система умеет честно сказать: «этот фрагмент я не понял».

Описание русских моделей и их области применения есть в официальной документации spaCy.

Откуда берётся качественная разметка

Разметка данных — самостоятельная часть ML-процесса. Если два специалиста по-разному выделяют название организации или включают в сущность соседние слова, модель получает противоречивую задачу. Сначала нужны инструкция, примеры спорных случаев и порядок разрешения разногласий. Уже потом — масштабирование работы разметчиков.

Для пилота я бы выделил небольшую общую выборку, дал её нескольким участникам и разобрал расхождения. Важно измерять не только согласие, но и причины: неоднозначная инструкция, разная трактовка бизнеса, плохое качество исходного текста. Договорённости становятся новой версией правил, а затронутые примеры проходят повторную проверку.

В моей корпоративной практике платформа разметки данных для ML входила в направление прикладных сервисов Big Data вместе с NER, графовой и геоплатформами. Моя роль как ИТ-лидера состояла в организации работы направления и производственного процесса. Это отдельная зона ответственности от обучения конкретной модели.

Пример приёмки: реквизиты из обращения

Возьмём учебное обращение: «Отправьте договор в ООО Север, контакт — Анна». Здесь нужно получить организацию и контакт, но не считать их автоматически проверенными реквизитами. Название компании ещё предстоит связать с записью в справочнике, а имя без дополнительных данных не идентифицирует человека.

Результат извлечения	Следующий шаг	Когда остановиться
Найдено название организации	Сверить со справочником и показать совпадения	Найдено несколько подходящих компаний
Найдено имя контакта	Запросить или сопоставить разрешённый идентификатор	Данных недостаточно для однозначного выбора
Найдена сумма правилом	Проверить валюту, диапазон и смысл поля	Сумма относится к другому документу или периоду

Так становится понятна граница между распознаванием текста и бизнес-действием. Даже высокий F1 сам по себе не доказывает, что договор отправится правильному адресату. Для руководителя полезнее видеть долю корректно завершённых сценариев и стоимость ручной проверки сложных случаев.

Прикладные реализации NER и других моделей собраны в разделе AI / ML-проектов.

---

Оригинал статьи: NER-сервисы в бизнесе на Habr

Ваш ДПУПП