Розробка та впровадження системи машинного перекладу тексту

При перекладі юридичних документів через DeepL ми отримали 30% помилок у термінології. Клієнту потрібна була система, що зберігає контекст контрактів і забезпечує конфіденційність даних. Ми розробили рішення на базі fine-tuned MarianMT. Постобробка за термінологічним словником забезпечила точність до 97%. Нерідко готові сервіси не справляються з галузевою лексикою: юридичні, медичні або технічні тексти втрачають до 30% точності ключових термінів. Для компаній, що обробляють великі обсяги документів, це обертається ризиками та додатковими витратами на вичитку. Ми вирішуємо цю проблему за допомогою кастомізованих моделей машинного перекладу, які адаптуються під предметну область і вимоги конфіденційності.

Машинний переклад пройшов шлях від статистичних моделей (Moses) через нейронні (seq2seq+attention) до сучасних трансформерів. Сьогодні для більшості мовних пар доступні готові моделі високої якості. Завдання зводиться до вибору правильної моделі та інтеграції в продукт. Наші інженери мають 5+ років досвіду в NLP і виконали 50+ проектів з машинного перекладу для різних галузей. Гарантуємо точність перекладу не нижче BLEU ≥35 для доменних моделей (детальніше про метрику BLEU).

Як вибрати модель для машинного перекладу?

Готові API (найкраща якість, простота):

• Google Cloud Translation API: 500K символів/місяць безплатно, >100 мов, плата за обсяг
• DeepL API: перевершує Google для європейських мов, щомісячна підписка
• OpenAI GPT-4o: для контекстно-залежного перекладу (маркетинг, література)

Open-source моделі (приватність, on-premise, нема витрат на API):

• MarianMT (Helsinki-NLP): компактні моделі для 1000+ мовних пар, Hugging Face
• NLLB-200 (Meta): 200 мов включаючи рідкісні, якість близька до Google для багатьох пар
• SeamlessM4T (Meta): мультимодальна — текст і мова, 100+ мов
• Opus-MT: велика колекція навчених моделей MarianMT

Чому fine-tuning необхідний для галузевих текстів?

Готові моделі погано справляються з галузевою термінологією. Для юридичних, медичних або технічних текстів fine-tuning на 10–100 тис. паралельних речень підвищує BLEU на 3–8 пунктів. Це в 2–3 рази більше, ніж приріст від простого термінологічного словника. Ми реалізували такий проект для клієнта з промисловості: донавчили MarianMT на 50 тис. пар речень — BLEU зріс з 30 до 37, а витрати на постобробку скоротилися на 80%.

Стратегії покращення перекладу:

• Термінологічні словники: пост-обробка перекладу із заміною на затверджені терміни. Бібліотека sacremoses для детокенізації, потім regex-заміна.
• Fine-tuning на доменних даних: 10K–100K паралельних речень з вашої області. MarianMT навчається на одному GPU за кілька годин. Якість зростає на 3–8 BLEU для спеціалізованих текстів.
• Промпт-інжиніринг для LLM: GPT-4o з інструкцією «перекладай медичні тексти, зберігай латинські терміни» без fine-tuning.

Як ми це робимо: стек і процес

Процес впровадження включає наступні етапи:

1. Аналіз вимог і специфікація мовних пар, обсягів, privacy constraints.
2. Вибір моделі (API або open-source) і збір паралельних даних.
3. Fine-tuning на доменних даних (якщо потрібно).
4. Інтеграція через REST API або gRPC.
5. Тестування якості (BLEU, COMET, A/B-тест на реальних користувачах).
6. Деплой у production і моніторинг латентності та якості.

Приклад інтеграції з використанням MarianMT:

from transformers import MarianMTModel, MarianTokenizer

model_name = "Helsinki-NLP/opus-mt-ru-en"
tokenizer = MarianTokenizer.from_pretrained(model_name)
model = MarianMTModel.from_pretrained(model_name)

def translate(texts: list[str]) -> list[str]:
    inputs = tokenizer(texts, return_tensors="pt", padding=True, truncation=True)
    translated = model.generate(**inputs)
    return tokenizer.batch_decode(translated, skip_special_tokens=True)

Для довгих документів (більше 512 токенів) використовуємо чанкінг з перекриттям: розбиваємо на речення через nltk.sent_tokenize, перекладаємо по одному, потім збираємо з урахуванням форматування. Для GPT-4o — чанкінг по абзацах з останнім реченням попереднього чанка для збереження контексту.

Оцінка якості: BLEU, COMET (модель Unbabel/wmt22-comet-da) та chrF. У production запускаємо A/B-тест на реальних користувачах — порівнюємо time-on-page та явні оцінки.

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

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

• Аналіз поточного пайплайну перекладу та вимог
• Підбір моделі: API або open-source з кастомізацією
• Fine-tuning та навчання на ваших даних
• Інтеграція через REST API або gRPC
• Автоматична оцінка якості (BLEU, COMET)
• Документація та навчання команди
• Підтримка після впровадження: 1 місяць

Типові помилки при впровадженні

Строки та вартість

Проект реалізуємо від 2 тижнів до 2 місяців залежно від складності та необхідності fine-tuning. Вартість розраховується індивідуально — вона залежить від обсягів, обраного підходу та вимог до конфіденційності. Наприклад, для проекту з перекладом 500 тис. слів на місяць економія від впровадження може скласти до $10 000/міс. Зв'яжіться з нами для безплатної консультації — ми підберемо оптимальне рішення під ваші завдання та обсяги. Замовте пілотний переклад на ваших даних і оцініть результат. Працюємо під ключ за 2 тижні для типових інтеграцій — пишіть, оцінимо проект безкоштовно. Наші фахівці мають 5+ років досвіду в NLP та виконали 50+ проектів машинного перекладу для різних галузей, що підтверджує надійність.

Нейромережевий переклад — це сучасний підхід, який забезпечує високу якість навіть для складних мовних пар.

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 дні.