Автоматичне визначення мови тексту: інструменти та реалізація

Клієнт приходить із завданням: потрібно обробляти тексти російською, англійською та німецькою. Але як зрозуміти, який пайплайн запускати? Без швидкого визначення мови мультимовний пайплайн перетворюється на кашу. Ми вирішили цю проблему, впровадивши детектор мови на базі fasttext lid.176 — він працює за долі секунди та покриває 176 мов. За час нашої практики ми реалізували 30+ проєктів із впровадження NLP-пайплайнів, включаючи детекцію мови для міжнародних чат-ботів із навантаженням 10 000 запитів/сек. Економія часу на обробку становить до 40%, а помилки класифікації знижуються на 30%.

Які задачі вирішує автоматичне визначення мови?

Визначення мови — перший крок у будь-якому мультимовному NLP-пайплайні. Перш ніж застосовувати мовно-специфічні моделі (стеммінг, NER, синтаксис), потрібно точно знати мову тексту. Помилка на цьому етапі призводить до некоректної обробки всього документа. Наприклад, якщо запустити стеммер російської мови на англійському тексті, результат буде марним. Правильне визначення мови безпосередньо впливає на якість downstream-задач: машинний переклад, тональність, вилучення сутностей.

Чому fasttext — стандарт для визначення мови?

Facebook AI Research (FAIR) випустила fasttext lid.176.bin, який став промисловим стандартом. Модель розпізнає 176 мов, розмір — лише 1,8 МБ (бінаризована версія). Latency — менше 1 мс на тексті до 200 символів. Точність — 97%+ для текстів довших за 20 слів. Приклад коду:

import fasttext
model = fasttext.load_model("lid.176.bin")
predictions = model.predict("Привіт, як справи?", k=3)
# (('__label__uk', '__label__ru', '__label__bg'), array([0.99, 0.003, 0.002]))

Інші інструменти поступаються в швидкості або точності. Порівняємо їх у таблиці:

fasttext працює в 10 разів швидше за langdetect при точності на 7% вищій на довгих текстах. FastText — відкрита бібліотека, доступна для інтеграції.

Як ми обробляємо складні випадки?

На практиці часто трапляються кейси, де стандартний детектор дає збої:

• Змішаний текст (code-switching): «Зустрічаємось о 5pm на zoom call» — технічно українська, але з англійськими вставками. Ми залишаємо домінуючу мову, не намагаючись сегментувати короткі фрази. Для довгих текстів застосовуємо ансамбль: fasttext + langid.
• Короткі тексти (до 5 слів): У чат-ботах часто приходять короткі повідомлення на кшталт «Ok» або «Так». Точність fasttext падає до 60-70%. Вихід — використовувати lingua-py, яка навчена на n-грамах і дає 85-90% на коротких фрагментах.
• Близькоспоріднені мови: українська/російська, іспанська/португальська — джерело основних помилок. Ми донавчаємо модель на корпусі цих пар, підвищуючи точність до 98%.

Як впливає визначення мови на економіку проєкту?

Коректне визначення мови знижує кількість помилково оброблених запитів на 30%, що економить до 40% часу на наступні етапи (переклад, вилучення даних). У грошовому вираженні це може становити від 30 000 до 60 000 гривень щомісяця для чат-бота з навантаженням 10 000 запитів/сек. Вартість інтеграції детектора мови зазвичай варіюється від 80 000 до 150 000 гривень залежно від складності. Окупність — 2–3 місяці.

Покрокова інструкція впровадження детектора мови

1. Збір корпусу: зберіть representative sample текстів кожною цільовою мовою (не менше 1000 документів на мову).
2. Тестування моделей: запустіть fasttext, lingua-py та langdetect на тестовій вибірці, заміряйте точність і latency. Для коротких текстів віддайте пріоритет lingua-py.
3. Вибір стратегії: визначтеся з ансамблем — наприклад, fasttext для довгих текстів, lingua-py для коротких, з порогом довжини в 20 слів.
4. Оптимізація: застосуйте кешування (Redis) — для повторюваних повідомлень latency знижується до сотень мікросекунд.
5. Моніторинг: поставте метрики accuracy на rolling window та p99 latency. При просіданні точності автоматично перемикайтеся на резервну модель.

Що входить у роботу з реалізації?

Ми пропонуємо впровадження детектора мови під ключ. До складу робіт входить:

• Вибір та тестування моделі (fasttext, lingua-py або ансамбль) під ваш сценарій
• Інтеграція в мультимовний пайплайн (REST API або gRPC)
• Кешування результатів (Redis, Memcached) для зниження навантаження
• Моніторинг метрик: latency p99, accuracy на тестовій вибірці, FLOPS
• Документація та навчання команди

Етапи впровадження:

Строки — від 2 до 4 тижнів залежно від складності інтеграції. Вартість розраховується індивідуально після оцінки обсягу даних.

Чому варто обрати нас?

За час нашої практики ми реалізували 30+ проєктів із впровадження NLP-пайплайнів, включаючи детекцію мови для міжнародних чат-ботів із навантаженням 10 000 запитів/сек. Гарантуємо точність 97%+ та підтримку на всіх етапах. Зв'яжіться з нами для консультації — ми оцінимо навантаження, підберемо оптимальну модель і вбудуємо детекцію мови у ваш пайплайн. Замовте впровадження детектора мови — отримайте точність 97%+ та latency менше 1 мс.

Вікіпедія: Ідентифікація мови — загальна концепція ідентифікації мов.

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. Оцінимо проект — розрахуємо економію на інфраструктурі.

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

Для малих датасетів (до 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 проектів.

Етапи роботи

Прототип на існуючих даних — 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 дні.