Генерація синтетичних даних для донавчання LLM під ключ

Синтетичні дані для донавчання LLM: де ламається якість

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

Ручна розмітка буксує: експерти тижнями узгоджують формулювання, а донавчання на малій вибірці дає перенавчання — модель впевнено відтворює фрази з навчального набору й не переносить логіку на нові випадки. Перша спокуса — догенерувати вибірку моделлю, і тут починається деградація якості.

Коли генератором виступає споріднена модель, вона тиражує власні зміщення: шаблонні вступи, однотипну структуру міркування, однакові відповіді. Різноманітність згортається — тисячі прикладів описують один випадок.

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

Друга пастка — контроль. Якщо перевірка йде на тій самій згенерованій вибірці, метрики зростають, але про поведінку на реальних запитах не говорять нічого. Плюс витік: приклади з одних документів-джерел потрапляють і в навчання, і в перевірку — модель завчає відповіді. На живому трафіку збірка розсипається на першому нетиповому запиті.

Синтетичні дані для LLM працюють, коли генерація керована: задано схему прикладу й розподіл тем, частка згенерованого обмежена, кожен приклад проходить фільтр на дублі та відповідність фактам, а частину вибірки перевіряє людина. Розбираємо, як це закривається.

Що дає керована генерація навчальних вибірок

Рідкісні класи випадають із вибірки першими: живих прикладів на них одиниці, і модель згортає їх у мажоритарний.

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

Ручна розмітка змінює роль: людина перевіряє не кожен приклад, а стратифіковану вибірку та граничні випадки. Чорновий шар робить генератор — дедуплікація за ембедингами, перевірка несуперечливості пар «запит — відповідь», відсів шаблонних формулювань.

Обсяг ручної роботи скорочується в рази, а вивільнений час іде на спірні приклади, де рішення людини справді змінює поведінку моделі.

Контроль якості прикладів тримаємо окремим шаром розмітки, а не всередині скрипта: Argilla дає чергу на перевірку, версіонування правок і облік розбіжностей між перевіряльниками.

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

Відтворюваність навчання тримається на фіксації версії набору, версії промптів і зерна генерації: той самий набір даних дає той самий результат, а розбіжність метрик між прогонами вказує на зміну даних, а не на випадковість.

Це дає змогу порівнювати експерименти між собою та відкочувати вибірку до попередньої версії, якщо якість впала.

Підходи до формування вибірок: генерація, доповнення, перенесення

Вибірку майже ніколи не збирають одним способом: чистий синтез закриває обсяг і баланс класів, реальні приклади утримують розподіл близьким до робочого. Режим вибирають за тим, скільки даних уже розмічено й наскільки жорсткі вимоги до стилю відповідей.

Загальне обмеження синтезу — дрейф розподілу: чим вища його частка у вибірці, тим більший ризик, що модель вивчить особливості генератора, а не предметну область. Тому частку реальних даних фіксують, ведуть дедуплікацію та оцінюють результат на відкладеній реальній вибірці.

Ми підбираємо режим під ваш домен: спочатку розбираємо, на яких прикладах модель помиляється зараз, і лише потім вирішуємо, що генерувати, що доповнювати й де достатньо перенесення стилю.

Етапи роботи над вибіркою: від аудиту до передачі

Без зафіксованого порядку робіт вибірка для донавчання перетворюється на набір прикладів, про якість яких сперечаються на смак.

Ми йдемо від аудиту даних до перевірки на прикладах, яких генератор не бачив: критерії приймання вибірки відомі до старту, а не обговорюються після першого прогону.

Що фіксуємо на кожному кроці

1. Аудит даних. Рахуємо обсяг, дублі, якість розмітки, розподіл за темами, довжиною та складністю. На виході — карта прогалин: які сценарії не покриті й що доведеться синтезувати.

2. Схема генерації. Вибираємо опору — ваш корпус або набір правил, задаємо цільовий розподіл за класами та рівень складності. Окремо фіксуємо, що робить модель, а що пише людина: інакше набір виходить одноманітним.

3. Правила фільтрації. Точна та смислова дедуплікація, відсів прикладів, що перетинаються з контрольним набором, перевірка на персональні дані, балансування класів. Правила лежать у конфігу — їх можна переграти.

4. Валідація прикладів. Автоперевірка формату й структури плюс вибіркова ручна оцінка: рахуємо частку збігів з еталоном, окремо розбираємо граничні випадки.

5. Перевірка на відкладеній вибірці. Метрики на даних, які не брали участі в генерації, порівняння з базовою моделлю та з вашим поточним набором. Приріст не підтвердився — повертаємося до схеми генерації.

6. Передача. Віддаємо датасет у узгодженому форматі, конфігурації генерації та фільтрації, звіт за метриками й регламент відтворення. Учимо вашу команду доповнювати вибірку, не змішуючи її з контрольною.

Що залишається у вас: вибірка, генератор, документація

Ми передаємо не архів із файлами, а робочий процес: набір з історією походження кожного прикладу, генератор, який запускається на вашому боці, і документи, за якими команда відтворює результат без нас.

Приймання йде не за описом, а прогоном — генерація запускається у вашому контурі, і її вихід звіряється з контрольними наборами.

• Набір даних із паспортом походження: частка реальних і синтетичних прикладів, розподіл за темами, які перевірки пройшов кожен блок.
• Генератор у вашому контурі: параметри запуску, шаблони запитів, правила фільтрації та відсіву, скрипти повторного прогону.
• Правила відбору прикладів: як відсікаються дублікати й близькі формулювання, за якими критеріями приклад іде в навчання, а за якими — у брак.
• Документація вибірки: схема полів, статистика за довжиною та темами, відомі обмеження й сліпі зони набору.
• Контрольні набори: відкладена частина й еталонні відповіді, за якими порівнюються версії моделі до та після донавчання.
• Регламент оновлення: періодичність добору прикладів, хто запускає генерацію, які пороги якості вважаються прийманням.
• Інструкція для команди: покроковий запуск, розбір типових збоїв, на що дивитися в логах і коли звертатися до нас.

Окремим пунктом іде передача генератора: спільний прогін на ваших даних із розбором налаштувань, щоб шаблони й фільтри ви далі змінювали самі.

Комплект зібрано так, щоб донавчання не залежало від підрядника: розширити тематику або перезапустити генерацію можна силами вашої команди, а ми підключаємося на складних випадках.

Практика: як вибірка закрила дефіцит прикладів у підтримці

Клієнт — сервіс підтримки з потоком звернень кількома мовами: класифікація тікета й генерація чернетки відповіді оператору. Модель навчали на вивантаженні з Zendesk, де рідкісні сценарії — повернення, спірні списання, збої інтеграцій — були представлені одиничними прикладами.

На них асистент відповідав шаблоном або переходив у відмову, а приклади для рідкісних тем фахівці розмічали вручну місяцями.

Що зробили

Розібрали історію звернень, виокремили рідкісні сценарії та згенерували синтетичні дані LLM: пари «запит — еталонна відповідь» з варіаціями формулювань, тональності й мови.

Кожну пару прогнали через автоматичні правила та звірку з регламентом компанії, спірні — через вибіркове ручне приймання; залишили близько двох третин згенерованого обсягу.

Що змінилося

На відкладеній вибірці реальних звернень частка коректних відповідей зросла з 61% до 89%, частка відмов упала з 18% до 4%.

Покриття рідкісних сценаріїв у навчальному наборі зросло з одиниць до сотень прикладів на тему, а обсяг ручної розмітки скоротився приблизно втричі — фахівці перевіряють спірні випадки замість написання прикладів з нуля.

Метрики якості рахуємо на тому самому наборі, що й до донавчання, тому порівняння до та після залишається коректним.

Чим синтетичні дані відрізняються від розмітки реальних логів?

Розмітка реальних логів спирається на факт: це справжні формулювання, живий шум, реальний розподіл класів. Проблема в іншому — рідкісний сценарій рідко потрапляє в логи, а на пограничних прикладах розмітники тлумачать інструкцію по-різному, і узгодженість міток падає. У підсумку клас, заради якого модель донавчають, виявляється представлений десятком прикладів.

Синтетика будується у зворотному порядку: спочатку описуємо таксономію сценаріїв і правила допустимих відповідей, потім генеруємо приклади за схемами та через мовну модель.

Далі — обов’язковий контур перевірок: дедуплікація, відсів шаблонних повторів, перевірка на витік чутливих даних і оцінка моделлю-суддею. Це дає рівне покриття класів, яких у логах майже немає.

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

Пропорцію підбираємо за класами: де фактичних прикладів мало, частка синтетики вища; де достатньо — залишаємо лише розмітку логів.

Контрольний набір при цьому збираємо виключно з реальних логів, інакше метрики вимірюють якість генератора, а не моделі на бойових даних. Такий спліт видно: де синтез справді додав клас, а де просто розбавив вибірку схожими прикладами.

Часті питання про дані, приватність і приймання робіт

Перед стартом генерації виринають одні й ті самі питання: що йде в модель, де межа між реальними документами й синтетикою та що вважається прийманням. Відповідаємо по суті.

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

Чи потрібна ваша розмітка?

Зазвичай ні: мітки синтезуються разом із прикладами й відомі заздалегідь. Ваша розмітка потрібна для контрольної вибірки — невеликої частки реальних прикладів, на яких перевіряємо, що модель не перенавчилася на синтетиці.

Як відбувається приймання робіт?

На вашому наборі перевірок: частка коректних відповідей, стійкість до перефразувань, відсутність деградації на реальних даних. Метрики знімаємо на одному й тому самому наборі до та після донавчання.

Що входить у підтримку після передачі?

Віддаємо конфігурації генератора, скрипти перевірки та документацію — щоб повторне навчання запускалося без нас. Далі супроводжуємо: оновлюємо набір, коли зміщується розподіл реальних даних.

Обговоримо задачу та повернемося з оцінкою й планом

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

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

Ми зі свого боку перевіряємо, чи є в цих прикладах сигнал для генерації: типи сутностей, термінологію, формати виводу, обмеження та заборонені формулювання — без цього синтетичні дані LLM виходять гладкими, але марними для донавчання.

Далі робота йде за кроками, і кожен крок завершується артефактом, який можна перевірити:

• Розбір домену — складаємо перелік сценаріїв, які модель має закривати, і окремо ті, де вона зобов’язана відмовити.
• Схема генерації — фіксуємо, з чого збираються приклади: правила, шаблони, реальні фрагменти, дерево тем і розподіл за складністю.
• Пілотний етап — проганяємо обмежений обсяг, дивимося на частку прикладів, що пройшли перевірку якості, і на приріст за вашими тестовими питаннями.
• Оцінка термінів — обсяг робіт прив’язуємо до метрики приймання, а не до «зробимо красиво»: скільки прикладів, якої якості, з якою перевіркою.
• План робіт — етапи, точки узгодження та те, що потрібно від вас: доступ до прикладів, експерт на 2–3 годинні сесії, відповіді щодо спірних кейсів.
• Передача — сценарії генерації, правила фільтрації, звіт за метриками та регламент, за яким ви зможете нарощувати набір самостійно.

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

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