NER-сервисы в бизнесе: от теории к практике

«Переведите мне менеджера»

Простое предложение. Шесть слов. И NER-система должна понять: это «переведите деньги» или «переключите на менеджера»? «Менеджер» — это имя, должность или тип операции? Контекст решает. Но контекст — это именно то, что машине даётся хуже всего.

Клиент пишет в чат банка: «Здравствуйте, меня зовут Алексей Петров, хочу перевести 50 000 рублей на счёт жены». Четыре сущности для обработки: имя, сумма, валюта, тип операции. Оператор call-центра извлекает их интуитивно. Но оператор обрабатывает один запрос за раз, устаёт, ошибается, уходит на обед. При тысячах обращений в час ручная обработка не масштабируется.

Named Entity Recognition — автоматическое извлечение структурированных сущностей из неструктурированного текста. В банковском контексте это не академическое упражнение. Это разница между операторами, которые вбивают данные руками, и системой, которая предзаполняет карточку обращения за миллисекунды.

Почему это сложнее, чем кажется

На первый взгляд — задача для регулярного выражения. На второй — нет.

Имена. «Алексей Петров» — просто. «А. Петров» — уже сложнее. «Передайте Петрову» — нужна лемматизация. «Мне Лёша звонил по поводу перевода» — нужно понять, что «Лёша» — имя. «петров алексей» в нижнем регистре без пунктуации — регулярка сдаётся.

Суммы. «50 000 рублей» — очевидно. «Пятьдесят тысяч» — конвертация числительных. «Полтинник» — сленг. «50к» — интернет-формат. «Пятьдесят тысяч рэ» — комбинация. Каждый вариант — отдельный паттерн, и их бесконечно много.

Валюты. «Рублей», «руб.», «рэ», «деревянных» — один и тот же рубль. Плюс мультивалютность в одном предложении.

Интенты. «Хочу перевести», «скиньте на карту», «закинуть на счёт» — transfer. «Переведите мне менеджера» — routing. Без контекста не отличишь.

Три подхода: сравнение

Критерий	Rule-based	ML-модели	Гибридный
Precision	Высокая (на известных паттернах)	Средняя-высокая	Высокая
Recall	Низкий (только явные паттерны)	Высокий	Высокий
Время разработки	Дни	Недели-месяцы	Недели
Нужны размеченные данные	Нет	Да, много	Частично
Поддержка	Правила растут, конфликтуют	Переобучение модели	Правила + переобучение
Отладка	Прозрачная	Чёрный ящик	Частично прозрачная
Устойчивость к новым форматам	Низкая	Высокая	Средняя-высокая

Rule-based: быстрый старт, медленная смерть

Пишешь правила, регулярки, словари. Для каждого типа сущности — набор паттернов. Когда правило сработало неправильно — ты точно знаешь почему и можешь исправить. Для извлечения ИНН, номера телефона, стандартного формата суммы — это идеальный инструмент.

Но через полгода система правил превращается в монстра. Новый формат ввода — новое правило. Правила конфликтуют. Изменение одного ломает три других. У нас был набор из нескольких сотен правил для извлечения сумм — и каждый новый edge case добавлял хрупкости.

ML: мощно, но дорого

Обучаешь модель на размеченных данных: вот текст, вот сущности. Модель обобщает — справляется с вариантами, которых не было в обучающей выборке. Устойчивость к опечаткам, нестандартным формулировкам, сленгу.

Проблемы: нужны размеченные данные, и много. В банке это означает работу с персональными данными — compliance-ад. Модель — чёрный ящик: когда она ошибается, понять причину и объяснить бизнесу «почему» — задача нетривиальная. И нужна инфраструктура для обучения и inference.

Гибридный: то, что работает в продакшене

Правила обрабатывают очевидные случаи с высокой точностью. ML подхватывает остальное. Pipeline: текст проходит rule-based модуль, извлекает сущности с высокой confidence. Нераспознанное уходит в ML-модель. На выходе — объединённый результат с приоритизацией по confidence score.

Именно этот подход мы использовали. Начали с правил — получили быстрый результат и базовую точность. По мере накопления размеченных данных подключили ML.

Python-стек для русского NER

Экосистема NER-инструментов для русского языка зрелая. Вот что мы использовали.

spaCy — фреймворк для NLP. Токенизация, лемматизация, POS-tagging, базовый NER из коробки. Модель ru_core_news_sm — отправная точка, но для банковской специфики нужна дообучка.

import spacy

nlp = spacy.load("ru_core_news_sm")
doc = nlp("Алексей Петров хочет перевести 50000 рублей")

for ent in doc.ents:
    print(f"{ent.text} -> {ent.label_}")
# Алексей Петров -> PER
# 50000 рублей -> MONEY

Базовый пример работает. Но «Лёша хочет скинуть полтинник» — уже нет. Тут нужна дообучка или гибридный подход.

pymystem3 — обёртка для Mystem от Яндекса. Лучший морфологический анализатор для русского языка по моему опыту. Когда нужно понять, что «Петрову» — дательный падеж от «Петров»:

from pymystem3 import Mystem

m = Mystem()
lemmas = m.lemmatize("Передайте Петрову документы")
# ['передавать', ' ', 'петров', ' ', 'документ', '\n']

pymorphy2 — морфологический анализатор для нормализации словоформ. Приведение к начальной форме, определение рода, числа, падежа. Работает в связке со spaCy.

Наш production pipeline: текст токенизируется spaCy, морфология обогащается через pymystem3, rule-based модуль извлекает жёсткие паттерны (ИНН, телефоны, стандартные суммы), ML-модель обрабатывает всё остальное.

Кейсы из продакшена

Извлечение ФИО

Одна из самых сложных задач для русского языка. Имя может быть в любом падеже, в любом порядке (ФИО, Имя-Фамилия, только Имя), с сокращениями или без.

Наш подход: словарь русских имён и фамилий (порядка трёхсот тысяч записей) в сочетании с морфологическим анализом. Pymystem3 определяет существительное с признаками имени собственного. Правила проверяют контекст: «меня зовут» или «я» перед словом — вероятность имени выше.

Суммы и валюты

Мы написали конвертер числительных, обрабатывающий десятки вариантов: от «пятьсот двадцать три рубля сорок копеек» до «523.40 руб.» и «523р40к». Отдельная задача — разделители тысяч: «50 000» vs «50,000» vs «50000».

Словарь валют — более ста вариантов написания для двадцати основных валют, включая сленг.

Случай с «менеджером»

Определение intent — не только сущности, но и понимание, что клиент хочет. «Хочу перевести» — transfer. «Покажите баланс» — balance_inquiry. «Заблокируйте карту» — card_block.

Rule-based подход тут работает на удивление хорошо — набор операций банка конечен. Мы создали таксономию из примерно пятидесяти intent-типов и для каждого — набор триггерных фраз. ML добавляет обработку нестандартных формулировок.

Инцидент, который нас научил

Март 2023-го. Мониторинг показывает падение precision NER-сервиса с 94% до 78% за неделю. Recall при этом не изменился. Что произошло?

Оказалось, маркетинг запустил акцию для клиентов. В обращениях массово появились фразы вроде «хочу оформить Мультикарту Плюс с кэшбеком 5%». NER начал классифицировать «Мультикарту Плюс» как ФИО — «Мультикарта» попадала под паттерн имени собственного с заглавной буквы, «Плюс» — под фамилию.

Правила, которые полгода работали безупречно, сломались на новом контексте. Мы добавили словарь продуктов банка в исключения rule-based модуля. На это ушёл день. Но сам факт — NER-система, которую ты не кормишь актуальным контекстом, деградирует молча. Мониторинг метрик — не опция, а необходимость.

Метрики и реальность

Лабораторные цифры: precision 94%, recall 91%. Продакшен — ниже, потому что реальные клиенты пишут с опечатками, без знаков препинания, на смеси русского и английского. И запускают акции с продуктами, названия которых NER-система принимает за имена.

Но ключевая бизнес-метрика — не accuracy модели, а снижение нагрузки на операторов. NER-сервис предзаполняет карточку обращения: имя клиента, тип запроса, ключевые параметры. Оператору остаётся подтвердить или скорректировать. Время обработки обращения сократилось ощутимо. А это — метрика, которую бизнес понимает и за которую платит.

Три вещи, которые я усвоил

Начни с правил, масштабируй через ML. Правила дают быстрый результат и базовую точность. ML подключай, когда накопишь размеченных данных. Не наоборот — ML без данных — это деньги в огонь. Мы начали с rule-based и за первые две недели закрыли примерно семьдесят процентов кейсов. Оставшиеся тридцать — нестандартные формулировки, сленг, опечатки — копились три месяца, пока мы не набрали достаточно размеченных примеров для ML-модели. Если бы начали сразу с ML — три месяца сидели бы без рабочего продукта, объясняя бизнесу, почему «модель ещё учится».

Инвестируй в данные, не в модели. Качество размеченного датасета определяет потолок. Простая модель на чистых данных бьёт сложную на грязных. Всегда. Мы потратили месяц на разметку: два аналитика, чёткие гайдлайны, перекрёстная валидация. Скучно? Адски. Но когда подключили ML — модель сразу показала приемлемый результат. У коллег из смежной команды, которые сэкономили на разметке и скормили модели то, что было — precision был на пятнадцать пунктов ниже.

NER — это pipeline, а не модель. Токенизация, нормализация, rule-based extraction, ML extraction, постобработка, валидация. Каждое звено влияет на результат. И каждое может незаметно сломаться, когда маркетинг запустит очередную акцию.

Деплой NER в банке: отдельный вид боли

Написать NER-сервис — полдела. Запустить его в банковской инфраструктуре — вторые полдела, и они сложнее первых.

Первое: всё on-premise. Никаких облаков, никаких внешних API. Это один из кругов ада финтех-разработки, к которому стоит быть готовым. Модель, данные, inference — всё крутится внутри контура. Это значит: ты сам поднимаешь инфраструктуру для обучения, сам настраиваешь GPU-сервера (если они вообще есть), сам следишь за версионированием моделей. В облаке ты нажал кнопку — получил endpoint. В банке ты пишешь служебку на выделение ресурсов, ждёшь две недели, получаешь сервер, на котором стоит не та версия CUDA.

Второе: compliance. Размеченные данные содержат персональные данные клиентов. Каждый датасет — через согласование с ИБ. Каждый доступ к данным — логируется. Нельзя просто скопировать выгрузку на рабочий ноутбук и разметить в удобном инструменте — всё делается на изолированном контуре, в специальной среде, с ограниченным набором инструментов. Мы размечали данные в интерфейсе, который разработали сами, потому что ни один внешний инструмент разметки не прошёл проверку безопасности.

Третье: latency. NER-сервис стоит на критическом пути обработки обращения клиента. Клиент написал в чат — система должна за миллисекунды предзаполнить карточку. Не за секунды — за миллисекунды. А ML-модель, даже лёгкая, на CPU выдаёт десятки миллисекунд. Мы оптимизировали inference через ONNX Runtime, батчили запросы, кешировали результаты для типовых фраз. Каждая миллисекунда — это UX оператора, а UX оператора — это время обработки обращения, а время обработки — это деньги.

Четвёртое: мониторинг деградации. Модель не ломается со звуком. Она тихо начинает ошибаться — и ты узнаёшь об этом, когда операторы начинают жаловаться, что «система опять бред несёт». Мы построили pipeline мониторинга: precision и recall считаются на выборке каждый день, алерты при падении ниже порога, еженедельный отчёт для бизнеса. Автоматизация не заменяет ручную проверку, но хотя бы даёт шанс поймать проблему раньше, чем её поймает клиент.

NER в банке — это не ML-задача. Это инженерная задача, обёрнутая в compliance, latency-требования и реальность, в которой маркетинг запускает акции, не предупредив IT. Кто к этому готов — строит продукт. Кто нет — строит прототип, который никогда не доедет до прода.

---

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

Ваш ДПУПП