Engenheiro da red_mad_robot mostrou como montar um serviço de NER para currículos: da rotulagem à API

На Habr вышел практический материал о том, как решать задачу NER не в теории, а на реальном кейсе с резюме для HR-системы. Автор показывает полный путь: от выбора сущностей и подготовки датасета до обучения модели и запуска API, который можно встроить в рабочий продукт.

От задачи к схеме В основе кейса — довольно прикладная задача:

рекрутерам нужен модуль, который принимает резюме в PDF или DOC, извлекает текст и находит в нём имя, фамилию, email, телефон, навыки и ожидаемую зарплату. Именно под такой сценарий и подбирается NER-подход. Важный момент в статье: автор начинает не с модели, а с уточнения бизнес-требований.

Сначала нужно понять домен, язык документов, формат входа и то, какие поля реально нужны заказчику. Без этого даже хорошая модель будет решать не ту задачу. После формализации требований автор фиксирует конкретные теги: NAME, SURNAME, EMAIL, PHONE, SKILL и SALARY.

Для разметки он выбирает схему BIO, потому что в резюме навыки часто идут подряд, и модели важно понимать, где начинается каждая отдельная сущность. Пример вида "Python SQL Docker" здесь показателен: если разметка выбрана неудачно, система может склеить несколько навыков в один. Это как раз тот случай, когда на первый взгляд мелкое решение на старте потом влияет на качество всей системы.

Где ломается датасет

Самый большой блок статьи посвящён данным, и это логично: именно здесь обычно тратится больше всего времени. Для ручной разметки автор использует Label Studio, но отдельно решает две практические проблемы: сервис не умеет нормально парсить PDF сам по себе и плохо работает с простым импортом TXT. Поэтому перед разметкой он пишет небольшой Python-скрипт, который вытаскивает текст из PDF и переводит документы в JSON-формат, удобный для Label Studio.

«Garbage in — garbage out».

Дальше начинается то, что особенно полезно для прикладных команд. Готового русскоязычного датасета по резюме автор не нашёл ни на Hugging Face, ни на Kaggle, ни на других популярных площадках. Поэтому пришлось комбинировать несколько подходов к подготовке корпуса: ручная разметка реальных или подготовленных резюме в Label Studio перевод англоязычных resume-датасетов на русский язык с дополнительной проверкой генерация синтетических резюме через LLM и фиктивные данные из Faker доразметка EMAIL и PHONE через regex там, где LLM ошибалась В статье хорошо показано, что LLM не снимает проблему качества данных, а только меняет её форму.

При переводе резюме могли коверкаться email, телефоны и названия технологий, а при автоматической разметке модель иногда относила работодателя вроде Oracle к навыкам или, наоборот, пропускала очевидные теги. Ещё один важный вывод: навыки нужно размечать по всему тексту, а не только в блоке "Навыки", иначе модель выучит шаблон секции, а не саму сущность. Для демонстрации автор собрал 114 документов и шесть разных шаблонов резюме, но прямо оговаривает, что для production обычно нужны уже тысячи примеров.

Почему выбрали mBERT Этап моделирования автор строит вокруг семейства **BERT**.

Для эксперимента он сравнивает шесть предобученных моделей, включая mBERT, XLM-RoBERTa, ruBERT и ruRoBERTa-large. Обучение шло на RTX 3090 с 16 ГБ видеопамяти, а длинные документы дополнительно чанковались, чтобы влезть в контекстное окно модели. Для оценки использовалась F1-мера, и формально лучшей оказалась ruRoBERTa-large.

Но на этом автор не останавливается и переходит к вопросу, который в реальных проектах важнее таблички с метриками: сколько стоит каждая лишняя доля качества. Итоговый выбор пал не на лидера бенчмарка, а на bert-base-multilingual-cased. Причина простая: у mBERT 178 млн параметров против 355 млн у ruRoBERTa-large, а разница в F1 составила около 0,01.

Такой размен даёт более быстрый инференс и менее жёсткие требования к железу, что особенно важно, если сервис потом придётся запускать не только на GPU, но и на CPU. Поверх выбранной модели автор собирает FastAPI-сервис с endpoint /predict, который принимает текст резюме и возвращает найденные сущности. То есть статья доводит кейс не до ноутбука с экспериментом, а до минимально жизнеспособного API.

Что это значит

Разбор red_mad_robot ценен тем, что показывает NER как инженерную задачу, а не как академическое упражнение. Главный вывод простой: рабочий результат появляется не из выбора модной модели, а из связки корректной постановки, жёсткой схемы разметки, ручной проверки данных и трезвого компромисса между качеством и стоимостью инференса.