NLP: Класифікація Тексту, NER, Embedding'и та Видобування Інформації
Приходить задача: "класифікувати звернення в службу підтримки — їх близько 50 тисяч на місяць, зараз все вручну". Датасет — 3000 розміченних прикладів, 12 категорій, дисбаланс: одна категорія займає 40% вибірки, три — по 1-2%. Baseline accuracy — 78%. Здається непогано, поки не подивишся на recall для редких класів: 0.31, 0.44, 0.28. Саме ці класи — скарги та загрози оттоку — важливіші за все бізнесу.
Це типовий NLP-проект. Проблема не в алгоритмі, а в тому, що accuracy — не та метрика.
Класифікація Тексту: Від BERT до Дистиляції
BERT-подібні моделі — стандарт для класифікації. ruBERT-base або ruBERT-large від DeepPavlov для російської. multilingual-e5-large — якщо потрібно працювати з кількома мовами в одному pipeline. XLM-RoBERTa-large — сильний multilingual backbone із хорошою якістю на ru/uk/de/fr.
Fine-tuning для класифікації: додаємо classification head поверх [CLS]-токена, учимо 3-5 епох з lr=2e-5, weight_decay=0.01. При дисбалансі класів: weighted CrossEntropyLoss або focal loss з gamma=2.0.
Кейс з дисбалансом. Датасет з прикладу вище: 3000 прикладів, дисбаланс 1:20 на редких класах. Рішення: class_weight через sklearn compute_class_weight('balanced', ...) + подаємо в CrossEntropyLoss. Додатково — augmentation редких класів через backtranslation (uk → en → uk через Google Translate API або MarianMT) або перефразування через LLM. Результат: recall по редких класах виріс з 0.31 до 0.67 при незначному падінні accuracy (76% → 74%).
Дистиляція для production. BERT-large дає F1 0.89, але inference на CPU — 180ms. Дистиляція в DistilBERT або ruBERT-tiny2 (DeepPavlov) знижує latency до 25ms при F1 0.84. Для більшості задач класифікації — приємний трейдофф. Якщо 25ms все ще багато — експорт в ONNX Runtime дає додатковий 1.5-2x.
NER: Розпізнавання Іменованих Сутностей
NER — видобування з тексту сутностей: персон, організацій, локацій, дат, сум, номерів документів. Для загальних категорій (PER, ORG, LOC) претренировані моделі працюють добре. Для спеціалізованих (медичні терміни, юридичні поняття, інженерні назви) — потрібен fine-tuning.
Розмітка даних. Основна вартість NER-проекту. Для якісної моделі потрібно 500-2000 розміченних речень на кожен тип сутності. Інструменти: Label Studio (open source), Prodigy (платний, від творців spaCy, відмінний UX). IOB2 формат — стандарт.
Архітектура. Token classification поверх BERT: кожному токену присвоюється мітка (B-PER, I-PER, O тощо). spaCy 3.x з transformer pipeline — хороший production-вибір: зручний API, вбудований serving, підтримка кастомних компонентів.
Вкладені сутності. Стандартні IOB-моделі не обробляють вкладені сутності (організація всередині адреси). Для таких — span-based NER: SpanBERT або моделі з семейства SpERT. Складніше в реалізації, але правильно розв'язує задачу.
Postprocessing — обов'язковий. Модель передбачає токени, але потрібні нормалізовані сутності. Для дат — нормалізація через dateparser. Для сум — regex + валідація. Для імен — дедупліка через нечітке совпадіння (rapidfuzz).
Sentiment Analysis та Opinion Mining
Бінарна класифікація позитив/негатив працює з BERT з коробки. Справжня складність — аспектна тональність (ABSA, Aspect-Based Sentiment Analysis): "у ресторані гарна кухня, але жахливий сервіс".
Для ABSA: задача розпадається на aspect extraction (NER) + sentiment класифікація по кожному аспекту. Або joint моделі типу BERT-for-ABSA, навчені end-to-end. Якість на українських даних нижче, ніж на англійських — менше розміченних датасетів. RuSentiment, SentiRuEval — основні ресурси для російської.
Для production з простим позитив/негатив/нейтраль: distil-моделей достатньо. Три класи, збалансований датасет, 2000+ прикладів — F1 macro 0.82-0.87 досяжне за 1-2 дні.
Резюмування Тексту
Екстрактивне резюмування (вибираємо речення з тексту) — через TextRank або BM25-based scoring без навчання. Швидко, передбачувано, не галюцинує. Гарно для довгих документів, де потрібна швидка вижимка.
Абстрактивне резюмування (генерує новий текст) — seq2seq моделі. mT5, mBART для multilingual. FRED-T5 та ruT5-large — спеціалізовані російські моделі для резюмування. Для production deployment через LLM API (GPT-4, Claude) — часто найкращий трейдофф стоимість/якість/швидкість.
Embedding'и: Векторні Представлення Тексту
Embedding'и — основа для семантичного пошуку, дедупліцирення, кластеризації, RAG. Якість embedding'ів критично впливає на downstream задачі.
Моделі. E5-large-v2, BGE-M3, multilingual-e5-large — сильні multilingual embedders. sentence-transformers/paraphrase-multilingual-mpnet-base-v2 — швидкий варіант з меншою якістю. Для української: ru-en-RoSBERTa (Skoltech) дає гарні результати на semantic textual similarity.
Оцінка якості embedding'ів. MTEB benchmark — стандарт для порівняння. Дивимося Retrieval, STS, Clustering subtasks. Важливо: топові результати на MTEB не завжди означають кращі результати на вашому доменному датасеті. Обов'язково будуємо домен-специфічний eval.
Fine-tuning embedding'ів. Якщо стандартні моделі дають недостатню якість — contrastive learning на доменних парах (позитивні та негативні). sentence-transformers підтримує MultipleNegativesRankingLoss. 500-2000 пар, 1-3 епохи — часто дають 5-15% прирост Recall@k на доменних даних.
Розмірність та зберігання. E5-large: 1024 dim, float32 — 4KB на вектор. При 10M документів — 40GB індексу. Квантизація в int8 знижує до 10GB з незначною втратою якості. FAISS IVF_PQ ще компактніше, але з трейдофф'ами по recall.
Видобування Інформації та Парсинг Документів
Структуроване видобування з неструктурованого тексту — одна з найчастіших задач. Приклади: видобути ключові умови контракту, розпарсити технічні характеристики з описання товару, витащити дати та суми зі счетів.
Підхід 1: regex + rule-based. Для типових полів з передбачуваним форматом (ІПН, ЕГРП, суми, дати) — надійніше нейросіті. Не потребує даних, передбачуваний.
Підхід 2: NER + post-processing. Для сутностей з варіативним форматом.
Підхід 3: LLM з structured output. GPT-4 / Claude з JSON schema — для складних неструктурованих документів, де rule-based не справляється. Вартість: ~$0.001-0.01 на документ залежно від обсягу та моделі. Для 10k+ документів/день — потрібно рахувати економіку.
Production зазвичай гібрид: regex/NER для типових полів + LLM для edge cases та складних структур.
Етапи Роботи
Аналіз даних та базові метрики. Дивимося розподіл класів, довжину текстів, якість розмітки, мовний склад. Визначаємо правильні метрики: F1 macro для дисбалансу, Precision@k для ранжування, Recall@k для пошуку.
Baseline. TF-IDF + LogReg або CatBoost на bag-of-words — за день отримуємо baseline. Розрив між baseline та BERT-fine-tuning показує, наскільки важливий семантичний контекст.
Навчання та валідація. k-fold cross-validation (k=5), ранню зупинку по F1 на валідації. Аналіз ошибочних передсказань руками — дає ідеї для вдосконалення.
Деплой. ONNX Runtime для CPU-інференса. FastAPI + uvicorn — стандарт для REST API. Батчинг запитів, якщо потрібна пропускна спроможність.
Прототип на існуючих даних — 1-3 тижні. Production-система з CI/CD та моніторингом — 1.5-2.5 місяці.