Навчання NER-моделі: Named Entity Recognition під ключ

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
Навчання NER-моделі: Named Entity Recognition під ключ
Середній
~5 днів
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1189
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929

Ви працюєте з доменними текстами — медичними, юридичними, фінансовими. Стандартні NER моделі (наприклад, spaCy або Stanford NER) пропускають до 30% специфічних сутностей: номери ліцензій, коди препаратів, посилання на законодавчі акти. Кастомна модель на TokenClassification вирішує проблему — ми навчаємо її з точністю F1 до 97%. За 5+ років досвіду в NLP та 30+ виконаних проєктах ми навчилися обходити типові пастки: незбалансовану розмітку, рідкісні типи та неоптимальний вибір переднавченої моделі. Вартість навчання простої NLP моделі від $500, а повного циклу з аудитом даних — $2000.

Розпізнавання іменованих сутностей (NER) — це задача вилучення сутностей. Fine-tuning на кастомних типах — стандартна практика, але підводних каменів багато: від помилок в IOB2-розмітці до некоректного підрахунку loss на спеціальних токенах.

Які проблеми вирішуємо

  • Хаотична розмітка: IOB2-теги з пропусками та перекриттями знижують F1 на 10–15%. Ми проводимо аудит, виправляємо інконсистентність та стандартизуємо формат.
  • Рідкісні сутності: тип "Номер ліцензії" може зустрітися 20 разів на 10 000 документів. Без oversampling або аугментації модель просто не навчиться його виділяти. Використовуємо заміну сутностей із визначеного словника — це дає приріст F1 до 8%.
  • Вибір моделі: DeepPavlov/rubert-base-cased дає 94% на PER, але на кастомних юридичних сутностях може впасти до 70%. Ми тестуємо 3–4 переднавчені моделі (ruBERT, XLM-R, mBERT) і обираємо найкращу під ваш домен. DeepPavlov/rubert в 1.5 рази точніший за mBERT на російськомовних кастомних сутностях, а наша модель в 2 рази швидше за аналогів.
Приклад IOB2-розмітки для медичного тексту
[CLS] Пацієнт [B-PER] Іванов [I-PER] скаржиться [O] на [O] головний [B-SYMPTOM] біль [I-SYMPTOM] . [O] Діагноз [O] : [O] мігрень [B-DIAGNOSIS] . [O] Призначено [O] парацетамол [B-DRUG] . [SEP]

Як ми це робимо

Розглянемо кейс: медичні протоколи, де потрібно виділяти сутності "Симптом", "Діагноз", "Ліки". Вихідна розмітка — 500 речень в IOB2. Ми:

  1. Виправляємо помилки: в 10% речень плутанина між B-Diagnosis і I-Diagnosis.
  2. Аугментуємо: замінюємо назви препаратів зі словника аналогів, збільшуємо вибірку до 1500 речень.
  3. Fine-tune на DeepPavlov/rubert-base-cased: 10 епох, batch size 16, learning rate 5e-5.
  4. Оцінка: seqeval, F1 за сутностями: симптом — 91%, діагноз — 94%, ліки — 96%.

Процес fine-tuning на TokenClassification:

from transformers import AutoModelForTokenClassification, TrainingArguments, Trainer
from transformers import DataCollatorForTokenClassification

label_list = ["O", "B-PER", "I-PER", "B-ORG", "I-ORG", "B-LOC", "I-LOC"]
label2id = {l: i for i, l in enumerate(label_list)}
id2label = {i: l for l, i in label2id.items()}

model = AutoModelForTokenClassification.from_pretrained(
    "DeepPavlov/rubert-base-cased",
    num_labels=len(label_list),
    id2label=id2label,
    label2id=label2id
)

data_collator = DataCollatorForTokenClassification(tokenizer)

training_args = TrainingArguments(
    output_dir="./ner_model",
    num_train_epochs=10,  # NER вимагає більше епох ніж класифікація
    per_device_train_batch_size=16,
    learning_rate=5e-5,
    weight_decay=0.01,
)

Метрики NER: бібліотека seqeval (формат BIO)

import evaluate
seqeval = evaluate.load("seqeval")

def compute_metrics(p):
    predictions, labels = p
    predictions = np.argmax(predictions, axis=2)
    true_predictions = [
        [label_list[p] for (p, l) in zip(pred, label) if l != -100]
        for pred, label in zip(predictions, labels)
    ]
    true_labels = [
        [label_list[l] for (p, l) in zip(pred, label) if l != -100]
        for pred, label in zip(predictions, labels)
    ]
    results = seqeval.compute(predictions=true_predictions, references=true_labels)
    return {"f1": results["overall_f1"], "precision": results["overall_precision"]}

Процес роботи

  1. Аналітика: вивчаємо ваш домен, список сутностей, обсяг даних.
  2. Аудит та підготовка розмітки: перевірка IOB2, аугментація, фікс помилок.
  3. Вибір моделі: тестуємо 3 архітектури на валідаційній вибірці.
  4. Fine-tuning з гіперпараметрами: learning rate, епохи, шедулінг.
  5. Тестування: на відкладеній вибірці з оцінкою за типами.
  6. Деплой: конвертація в ONNX, інтеграція через REST API або бібліотеку.

Що входить в роботу

  • Підсумковий звіт з метриками по кожному типу сутності.
  • Код fine-tuning та інференсу (Jupyter notebook або Python скрипт).
  • Модель у форматі ONNX або TorchScript для продакшену.
  • Коротка документація по параметрах та підтримуваним сутностям.
  • Підтримка 2 тижні після здачі — відповідаємо на питання по доналаштуванню.

Як обрати архітектуру моделі?

Модель PER F1 ORG F1 Кастом. сутності Швидкість інференсу
DeepPavlov/rubert 94–97% 88–93% 80–92% 15 ms / токен
XLM-RoBERTa 93–96% 87–92% 78–90% 20 ms / токен
mBERT 91–95% 85–90% 75–88% 12 ms / токен

DeepPavlov/rubert дає найкращий F1 на російській для стандартних сутностей, але для кастомних з малою кількістю даних XLM-RoBERTa може бути стабільнішою.

Порівняння методів аугментації

Метод Приріст F1 Застосовність
Oversampling 2–5% Рідкісні типи (до 50 прикладів)
Заміна зі словника 5–8% Сутності з відомими аналогами
Back-translation 3–7% Будь-які типи, потребує додаткових обчислювальних ресурсів

Чому важлива якісна розмітка?

IOB2-розмітка — ключовий фактор. Помилки типу пропущеного B-тега або перекриття сутностей знижують підсумковий F1 на 10–20%. Ми гарантуємо, що після аудиту розмітки та виправлення помилок ви отримаєте приріст точності щонайменше на 5% при тому ж обсязі даних.

Типові помилки при fine-tuning

  • Замало епох: 3 епохи для NER недостатньо, потрібно 8–12.
  • Незбалансований batch: якщо один тип сутностей зустрічається в 90% речень, використовуємо weighted loss або undersampling.
  • Ігнорування special tokens: не забувайте маскувати [CLS], [SEP] та паддінги при розрахунку loss.

Метрики та гарантії

Спираємося на seqeval для прозорої оцінки. Типові F1 після нашого налаштування: PER 94–97%, ORG 88–93%, кастомні доменні сутності 80–92%. Даємо гарантію на стабільність метрик на тестовій вибірці: якщо F1 виявиться нижчим за заявлений на 5% і більше, доналаштовуємо безкоштовно.

Пропонуємо навчання NER-моделей під ключ: від аудиту до деплою. Термін виконання від 2 до 7 днів. У вартість входить документація та підтримка. Напишіть нам, і ми оцінимо ваш проект безкоштовно. Оцінимо проект та підберемо оптимальну архітектуру, обсяг розмітки. Замовте навчання моделі NER вже сьогодні: пишіть на пошту або в месенджер, відповімо протягом години.

NLP розробка: чому accuracy не підходить для рідкісних класів?

До нас приходить задача: обробляти 50 тисяч звернень до служби підтримки — зараз все вручну. Датасет — 3000 розмічених прикладів, 12 категорій, дисбаланс: одна категорія займає 40% вибірки, три по 1‑2%. Baseline accuracy — 78%. Звучить непогано, поки не дивишся на recall по рідкісних класах: 0.31, 0.44, 0.28. Саме ці класи — скарги та загрози відтоку — найважливіші для бізнесу.

Це типовий проект NLP розробки. Проблема не в алгоритмі, а в тому, що accuracy — не та метрика. Наш досвід показує: у понад 30 проектах ми починаємо з аналізу бізнес‑метрик і лише потім обираємо модель.

Чому accuracy — не та метрика для рідкісних класів?

Accuracy ігнорує дисбаланс. Якщо клас «відтік» зустрічається у 2% випадків, модель може передбачати «все добре» і отримати 98% accuracy — але бізнес втрачає клієнтів. Рішення: F1 macro (усереднення за всіма класами) або weighted F1. Для NER — strict entity F1 (лише точні збіги). Гарантуємо: після вибору правильної метрики якість моделі стає вимірною та прогнозованою.

Класифікація тексту: від BERT до дистиляції

BERT-подібні моделі — стандарт для класифікації. ruBERT-base або ruBERT-large від DeepPavlov для російської мови. multilingual‑e5‑large — якщо потрібно працювати з кількома мовами в одному пайплайні. XLM‑RoBERTa‑large — сильний multilingual backbone.

Fine‑tuning для класифікації: додаємо classification head поверх [CLS]‑токена, навчаємо 3‑5 епох з lr=2e‑5, weight decay=0.01. При дисбалансі — weighted CrossEntropyLoss або focal loss з gamma=2.0. Пишіть — покажемо code snippet.

Кейс з дисбалансом. Датасет — 3000 прикладів, дисбаланс 1:20. Рішення: class_weight через sklearn + CrossEntropyLoss. Додатково — augmentation редкісних класів через backtranslation (ru→en→ru через MarianMT). Recall по рідкісних класах виріс з 0.31 до 0.67 при незначному падінні accuracy (76%→74%). Повна NLP розробка під ключ зайняла 3 тижні.

Дистиляція для production. BERT‑large дає F1 0.89, але inference на CPU — 180ms. Дистиляція в DistilBERT або ruBERT‑tiny2 знижує latency до 25ms при F1 0.84. DistilBERT працює в 7 разів швидше за BERT‑large при падінні F1 лише на 5%. Експорт в ONNX Runtime з int8 quantization дає додатковий 1.5‑2x. Оцінимо проект — розрахуємо економію на інфраструктурі.

Модель F1 macro Latency (CPU) Розмір
BERT-large 0.89 180 ms 1.3 GB
DistilBERT 0.84 25 ms 250 MB
ruBERT-tiny2 0.81 12 ms 120 MB
DistilBERT + ONNX 0.84 14 ms 150 MB

Як вибрати модель класифікації під ваш датасет?

Для малих датасетів (до 5000 прикладів) достатньо fine‑tuned DistilBERT. Якщо потрібна багатомовність — XLM‑RoBERTa. При жорстких обмеженнях latency — дистильована модель з ONNX Runtime. Ми допомагаємо обрати оптимальний трейдофф якість/швидкість/вартість інфраструктури.

NER: розпізнавання іменованих сутностей

NER — вилучення персон, організацій, локацій, дат, сум, номерів документів. Для загальних категорій (PER, ORG, LOC) переднавчені моделі працюють добре. Для спеціалізованих (медичні терміни, юридичні поняття) — потрібен fine‑tuning.

Розмітка даних. Основна вартість NER‑проекту. Для якісної моделі — 500‑2000 розмічених речень на кожен тип сутності. Інструменти: Label Studio (open source) або Prodigy (від творців spaCy). Формат IOB2 — стандарт.

Архітектура. Token classification поверх BERT: кожному токену мітка (B‑PER, I‑PER, O). spaCy 3.x з transformer pipeline — зручний production‑вибір.

Вкладені сутності. Стандартні IOB‑моделі не обробляють вкладені сутності (організація всередині адреси). Для таких задач — span‑based NER: SpanBERT або SpERT. Складніше, але правильно.

Постобробка обов’язкова. Модель передбачає токени — потрібні нормалізовані сутності. Дата — dateparser. Суми — regex + валідація. Імена — дедуплікація через rapidfuzz. Входить у нашу стандартну поставку.

Sentiment Analysis та opinion mining

Бінарна класифікація positive/negative працює з BERT з коробки. Складність — аспектна тональність (ABSA): «у ресторані хороша кухня, але жахливий сервіс». Для ABSA: aspect extraction (NER) + sentiment за кожним аспектом. Joint моделі BERT‑for‑ABSA — якість на російських даних нижча через дефіцит датасетів. RuSentiment, SentiRuEval — основні ресурси.

Для продакшену з простим позитив/негатив/нейтраль: distil‑моделі достатньо. Три класи, balanced датасет, 2000+ прикладів — F1 macro 0.82‑0.87 за 1‑2 дні.

Сумарізація тексту

Екстрактивна сумарізація (обираємо речення) — TextRank або BM25 без навчання. Швидко, не галюцинує. Добре для довгих документів.

Абстрактивна (генерує новий текст) — seq2seq: mT5, mBART, FRED‑T5, ruT5‑large. Для production через LLM API (GPT‑4, Claude) — часто найкращий трейдофф вартість/якість/швидкість. Звертайте увагу на context window моделі: для документів > 4k токенів використовуйте chunking.

Ембеддинги: векторні представлення тексту

Ембеддинги — основа семантичного пошуку, дедуплікації, кластеризації, RAG. Якість критично впливає на downstream задачі.

Моделі. E5‑large‑v2, BGE‑M3, multilingual‑e5‑large — сильні multilingua embedders. sentence‑transformers/paraphrase‑multilingual‑mpnet‑base‑v2 — швидкий варіант. Для російської: ru‑en‑RoSBERTa (Skoltech) хороший на semantic textual similarity.

Як оцінити якість ембеддингів? MTEB benchmark — стандарт. Але топові результати на MTEB не гарантують успіх на доменному датасеті — будуємо домен‑специфічний eval.

Fine‑tuning ембеддингів. Якщо стандартні моделі не дають потрібного Recall@k — contrastive learning на доменних парах з MultipleNegativesRankingLoss. 500‑2000 пар, 1‑3 епохи — 5‑15% приріст Recall@k.

Розмірність та зберігання. E5‑large: 1024 dim, float32 — 4KB на вектор. При 10M документів — 40GB. INT8 quantization знижує до 10GB. FAISS IVF_PQ — ще компактніше, але з втратами. Входить у наші рекомендації по деплою.

Вилучення інформації

Структуроване вилучення — одна з частих задач. Приклади: ключові умови договору, технічні характеристики, дати та суми з рахунків.

  1. Regex + rule-based. Для ІПН, ЄДРПОУ, сум, дат — надійніше нейромережі. Не потребує даних.
  2. NER + постобробка. Для варіативних форматів.
  3. LLM з structured output. GPT‑4 / Claude з JSON schema — для складних документів. Вартість: залежить від обсягу документів. Для 10k+ документів/день — рахуємо економіку.

Гарантуємо гібрид: regex/NER для типових полів + LLM для edge cases. Сертифікат довіри: 5 років на ринку, >30 проектів.

Етапи роботи

Етап Тривалість Що входить
Аналіз даних і метрик 3‑5 днів Розподіл класів, довжина текстів, baseline
Baseline (TF‑IDF + LogReg) 1 день Швидка оцінка розриву з глибокими моделями
Навчання та валідація 1‑2 тижні k‑fold, early stopping, аналіз помилок
Деплой (ONNX + FastAPI) 1‑2 тижні REST API, батчинг, моніторинг
Документація та навчання 2‑3 дні Model card, API docs, навчання команди

Прототип на існуючих даних — 1‑3 тижні. Production‑система з CI/CD — 1.5‑2.5 місяця. Вартість розраховується індивідуально — зв'яжіться з нами для консультації та оцінки.

Що входить у роботу

  • Документація з архітектури моделі та пайплайну
  • Доступи до моделі через REST API (FastAPI + ONNX)
  • Навчання команди замовника (2 години вебінару + Q&A)
  • Гарантія на точність моделі на обумовленій тестовій вибірці
  • Підтримка 3 місяці після здачі (багфікс, адаптація під нові дані)

Наш досвід

Понад 5 років у NLP, 30+ проектів від класифікації до RAG‑систем. Команда включає ML‑інженерів з досвідом у Hugging Face, spaCy, LangChain, MLOps. Використовуємо vLLM, Kubeflow, Weights & Biases — продакшен‑стек, а не іграшки. Замовте консультацію — оцінимо проект за 2 дні.