Дообучення T5, BART, ruT5 для доменної сумаризації текстів

Моделі загального призначення як GPT-4o чудово справляються з анотаціями новин, але на юридичному контракті пропускають ключові умови — форс-мажор або термін повідомлення. Ми знаємо це з практики: доменна адаптація кардинально змінює якість. Fine-tuning на предметних даних вчить модель виділяти важливе саме у вашому контексті — чи то медичні карти, судові рішення або технічна документація. Наші інженери адаптують архітектури під специфіку задачі: стиль, термінологію, структуру. Результат — сумаризація, якій можна довіряти. Економія на інференсі порівняно з комерційними LLM досягає 10 разів. Наприклад, дообучення ruT5 на 3000 парах обійдеться в 150 000–200 000 ₴, а економія на інференсі може становити 100 000 ₴ на місяць. Оцінимо вартість вашого проєкту безкоштовно — зв'яжіться для консультації.

Які проблеми вирішує дообучення

Невідповідність стилю. Генеративні моделі схильні до розмовних зворотів. Для ділового звіту потрібна формальна лексика, для новини — стислість, для медицини — точна термінологія. Fine-tuning підлаштовує стиль під домен. Медична сумаризація потребує особливої точності термінів, новинна — лаконічності.

Галюцинації фактів. Модель може додати неіснуючі цифри або імена. Це критично в юридичних і фінансових текстах. Дообучення на доменних даних знижує відсоток галюцинацій на 30–50%. Дослідження Google показує, що адаптовані моделі дають на 20% менше вигаданих деталей.

Довгий контекст. Деякі документи (наприклад, судові рішення) перевищують 8K токенів. Не всі моделі вміють з ними працювати. T5 і BART з вікном 1024 токени потребують чанкінгу — ми використовуємо стратегію sliding window з перекриттям.

Як ми адаптуємо модель: кейс з юридичними документами

Наш клієнт — юридичний департамент великої компанії. Потрібно було сумаризувати договори поставки. Стандартні моделі (GPT-4o) видавали переказ, а не витяжку — пропускали дати, суми та умови розірвання.

Зазначимо: що зробили:

• Зібрали 2000 пар «договір → сумарі» з архіву за 5 років.
• Використали ruT5-base з LoRA — ранг 16, target modules = q_proj, v_proj.
• Навчали на одному A100 80GB, 3 епохи, batch size 8, gradient accumulation 2. Loss зійшовся за 2 години.
• Після дообучення ROUGE-1 виріс з 0.32 до 0.48, BERTScore — з 0.78 до 0.89.
• Human evaluation: accuracy 4.2/5, completeness 4.5/5.

Результат: модель стабільно виділяє всі суттєві умови. Галюцинації — менше 2%.

Порівняння архітектур для сумаризації

Для російськомовних доменів ми рекомендуємо ruT5 або ruBART — вони компактні й дають результат з 2000+ прикладів. Після дообучення такі моделі в середньому в 1.5 рази краще утримують структуру документа порівняно з багатомовними аналогами. Завдяки правильному вибору архітектури ви економите до 40% бюджету.

Чому важливо дообучати модель на доменних даних?

Навчання на загальному корпусі (наприклад, Common Crawl) не вчить модель специфіці вашого бізнесу. Терміни, структура документа, важливість полів — все це потрібно доналаштувати. Fine-tuning вирішує задачу domain adaptation: модель починає розуміти, що в контракті «суттєві умови» — це не те саме, що в новині про погоду. На практиці адаптована модель дає ROUGE-L на 15–20 пунктів вище базової.

Скільки даних потрібно для якісного дообучення?

Досвід показує: 1000–5000 пар достатньо, щоб отримати приріст 15–20 пунктів ROUGE. Якщо даних менше, використовуємо аугментацію: зворотний переклад, синонімізацію, рекурсивне сумаризування через GPT-4o. Але синтетичні дані не замінюють реальні — обов'язково змішуйте їх у пропорції 1:3. Для оцінки якості застосовуємо BERTScore разом з ROUGE. domain adaptation NLP — ключова техніка для перенесення знань у новий домен.

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

1. Аналіз домену та вимог — збираємо репрезентативну вибірку документів, визначаємо стиль і обсяг підсумкової сумарі.
2. Підготовка даних — чистка, розмітка (якщо немає пар), чанкінг для довгих документів. Використовуємо конкатенацію з роздільником і sliding window.
3. Вибір архітектури та тонке налаштування — експериментуємо з T5, BART, іноді з mT5. Підбираємо гіперпараметри: learning rate (1e-4…5e-5), batch size, кількість епох. Використовуємо EarlyStopping з бібліотеки Hugging Face.
4. Оцінка — ROUGE + BERTScore + human evaluation. Якщо якість нижче порогу, повертаємося до даних або архітектури.
5. Деплой — розгортаємо на Triton Inference Server або через FastAPI. Оптимізуємо latency p99 до 500 мс. Використовуємо quantization INT8 для прискорення на GPU.

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

• Аналіз ваших даних і домену з підбором архітектури.
• Підготовка та аугментація тренувального набору.
• Fine-tuning моделі з оптимізацією гіперпараметрів.
• Оцінка за ROUGE, BERTScore та людське тестування.
• Деплой моделі (Triton, FastAPI) з документацією.
• Навчання вашої команди роботі з моделлю.
• Гарантія стабільності — додаткові епохи при необхідності.