Извлечение сущностей (NER, Named Entity Recognition) — выделение из свободного текста конкретных значений: имён, организаций, дат, сумм, адресов, номеров документов, артикулов.
Задача прикладная и окупаемая: заполнение карточки клиента из письма, разбор заявки, перенос данных из накладной, обезличивание. NER редко живёт сам по себе — обычно это первый этап конвейера: извлечь значения, провалидировать, передать в учётную систему или в поиск.
Типы сущностей
Стандартные типы. Персона, организация, локация, дата, сумма. Под них обучены готовые модели, включая открытые; их точности обычно хватает для черновой разметки и предзаполнения полей, но не для автоматической проводки без проверки.
Доменные типы. Номера договоров, артикулы, VIN, коды оборудования, банковские реквизиты. В открытых корпусах такие строки не размечены, поэтому готовая модель их не узнает: нужен либо свой классификатор, либо языковая модель с описанием формата. Типы с проверяемой структурой (ИНН, номер накладной) выгодно валидировать регуляркой и контрольными разрядами — это дешевле и надёжнее любой модели.
Вложенные сущности. «Завод „Кузнецкмаш“» — организация, внутри которой топоним; «директор ООО „Ромашка“ Иванов» — персона и организация в одной конструкции. Схема разметки должна заранее определять, как поступать с вложениями и пересечениями, иначе разметчики решат это по-разному и обученная модель получится нестабильной.
Два подхода
Специализированная модель. Обучена именно на этой задаче, работает быстро и дёшево, хорошо справляется со стандартными типами сущностей. Требует дообучения под нестандартные.
Механика классического подхода. Модель решает задачу разметки последовательности: каждому токену присваивается метка по схеме BILOU (Begin, Inside, Last, Outside, Unit) с указанием типа — «U-DATE» для даты из одного слова, «B-PER … L-PER» для имени из нескольких. Поверх меток работает условное вероятностное поле (CRF), которое запрещает невозможные переходы вроде «продолжение без начала» — за счёт этого границы сущностей выходят аккуратнее, чем у независимой классификации токенов. Плата — разметка: на доменную задачу нужно от нескольких сотен до пары тысяч фрагментов, и это разовый, но не нулевой бюджет.
Языковая модель с описанием полей. Достаточно перечислить, что нужно извлечь, и задать формат ответа. Гибче: новый тип поля добавляется правкой инструкции. Дороже за обращение и медленнее.
Практический выбор упирается в объём. При потоке в тысячи документов в день дешевле обученная модель, при десятках — языковая, потому что не требует разметки и запускается сразу.
Подходы совместимы: массовый и однообразный поток разбирает специализированная модель, а редкие и нестандартные документы отсекаются на входе и уходят в языковую — это дешевле, чем гонять LLM по всему потоку.
Структурированный вывод и валидация
Формат ответа. Результат NER — не текст, а набор полей, поэтому у языковой модели запрашивается структурированный вывод: JSON-схема или механизм function calling, где поле «не указано» — явный null, а не пустая строка. Это переводит ошибки формата из категории «молчаливых» в категорию ловимых на валидации.
Слои валидации. Сначала синтаксис: дата распарсилась как дата, сумма — число с валютой, номер прошёл регулярку и контрольный разряд. Затем семантика: ИНН найден в справочнике контрагентов, артикул — в каталоге. Первое ловится кодом и бесплатно, второе требует источника истины — и только оно защищает от правдоподобного, но чужого значения.
Нормализация — отдельный шаг. Приведение к каноническому виду (дата к единому формату, сумма к числу, имя к именительному падежу) полезно измерять отдельно от извлечения: модель может найти дату и неправильно её разобрать — в «05.05» неочевидно, где день, а где месяц, и без правила нормализации результат непредсказуем.
Что усложняет задачу на русском
Падежи. «Иванову Ивану» и «Иванов Иван» — одно имя в разных формах, и приводить к начальной форме приходится отдельно.
Неоднозначность. «Мир» — существительное, название организации и часть адреса. Различить помогает только контекст.
Форматы дат и сумм. «5 мая», «05.05», «пятого числа», «в пятницу» — всё это даты, и нормализовать их надо к одному виду.
Отсутствие структуры. В расшифровке звонка нет полей, есть поток речи с оговорками и исправлениями по ходу.
Проверка и границы применения
Оценивать надо по каждому типу поля отдельно: имена обычно извлекаются хорошо, суммы и даты заметно хуже, а именно они чаще всего критичны.
Как считать. Для каждого типа сущности отдельно считаются точность и полнота, причём сущность считается найденной только при совпадении и типа, и границ. Совпадение границ с пересечением полезно на отладке: оно показывает, что модель «видит» значение, но путается в краях. Бизнесу ближе метрика «доля документов, ушедших в систему без ручной правки» — её и стоит вынести в отчёт.
Отдельно измеряется доля пропусков и доля выдуманных значений. Второе опаснее: отсутствующее поле заметно, а правдоподобно подставленный номер — нет. Практический приём против выдумывания — требовать от модели цитату-источник для каждого значения и проверять, что цитата есть в тексте: подстрочная проверка отсекает большую часть фантазий дёшево.
Отсюда правило для полей, влияющих на деньги и обязательства: подтверждение человеком либо сверка с источником. Автоматическое заполнение без проверки допустимо там, где ошибка обнаружится и обойдётся дёшево.
С какими документами работает хуже всего
Сканы низкого качества. Ошибка распознавания в цифре суммы или номере проходит дальше по цепочке как факт. Поэтому качество распознавания стоит оценивать до, а не после внедрения извлечения.
Таблицы. Значение и его заголовок разнесены в пространстве, и при превращении таблицы в поток текста связь теряется. Таблицы обрабатывают отдельно.
Расшифровки речи. Нет знаков препинания, есть оговорки и самоисправления: «отправьте на пятое… нет, на седьмое». Правильный ответ — второй, и модель должна это понять.
Что делать с несколькими значениями
В письме может быть две даты и три суммы. Инструкция «извлеки дату» тогда даёт непредсказуемый результат.
Формулировать надо роль поля: не «дата», а «дата отгрузки»; не «сумма», а «сумма к оплате с НДС». И предусматривать вариант «в тексте не указано» — иначе модель подставит ближайшее подходящее значение.
Применение: карточки и поиск по реквизитам
Заполнение карточек. Извлечённые значения предзаполняют карточку клиента, заявку, позицию заказа; человек подтверждает, а не набирает. Выигрыш измеряется не точностью модели, а секундами на документ и долей правок.
Поиск по реквизитам. Извлечение превращает свободный текст в фильтры: все договоры с конкретным контрагентом, суммы свыше порога, даты в диапазоне. Прямой поиск по исходному тексту здесь не работает из-за падежей и синонимии — сначала нормализация, потом точный фильтр; для смыслового, а не реквизитного поиска нужен семантический поиск, это другой инструмент под другую задачу.
Обезличивание. NER находит персональные данные в тексте и заменяет их плейсхолдерами — это типовой подготовительный этап перед передачей корпуса текстов в модель и часть обезличивания данных по 152-ФЗ. Здесь полнота важнее точности: пропущенная фамилия — утечка, лишняя замена — только шум. (typo "corpusa" — fix: «перед передачей корпуса текстов»)
Частые вопросы
Что лучше — обученная модель или языковая?
При большом потоке дешевле специализированная модель, при небольшом — языковая: она не требует разметки и запускается сразу, а новый тип поля добавляется правкой инструкции. Порог зависит от объёма и стоимости обращения.
Какие поля извлекаются хуже всего?
Даты, суммы и всё, что требует нормализации формата, — а именно они обычно и критичны. Оценивать точность надо по каждому типу поля отдельно, а не общим показателем.
Можно ли заполнять данные автоматически без проверки?
Там, где ошибка обнаружится и обойдётся дёшево, — да. Для полей, влияющих на деньги и обязательства, нужна проверка человеком или сверка с источником: правдоподобно выдуманное значение опаснее пропущенного, потому что его не видно.
Сколько размеченных примеров нужно для дообучения?
Обычно от нескольких сотен фрагментов на простой набор типов до одной–трёх тысяч для доменных с вложенными сущностями; основной прирост дают первые сотни. Дороже объёма стоит единообразие: инструкция для разметчиков с примерами вложенных и пограничных случаев экономит недели переделок.
Почему модель подставляет значения, которых нет в тексте?
Языковая модель достраивает правдоподобное значение там, где поле не заполнено, — это механизм генерации, а не ошибка обучения. Лечится явным вариантом null, нулевой температурой и подстрочной проверкой: каждое извлечённое значение обязано найтись в исходном тексте.