Fine-tuning LLM: підготовка датасету — формати, дедуплікація та чекліст

Чому датасет для LLM визначає якість донавчання

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

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

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

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

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

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

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

Що дає вивірена вибірка: ефект у вимірюваних метриках

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

Після видалення майже-дублів, приведення розмітки до однієї угоди та розбору спірних прикладів частка правильних відповідей на відкладеній контрольній підбірці зростає на 8–15 пунктів.

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

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

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

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

Курування ведемо в Argilla: версії набору, розмітка кількома анотаторами та історія правок в одному місці — після кожної ітерації видно, яке саме змінення дало приріст.

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

Формати датасета для LLM і режими донавчання: порівняння

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

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

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

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

Етапи підготовки даних: від аудиту джерел до приймання

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

1. Аудит джерел. Інвентаризація: логи звернень, база знань, листування підтримки, внутрішні регламенти. За кожним джерелом — власник, право на використання, обсяг, доменне покриття та частка пошкоджених записів.
2. Схема запису. Домовляємося про поля, єдиний формат зберігання та правила опису відповіді еталонного асистента, щоб розмітники не розходилися в трактуванні.
3. Очищення та дедуплікація. Прибираємо розмітку розмітки (HTML, службові заголовки), нормалізуємо текст, ловимо точні та майже-дублі, вирізаємо персональні дані. Близькі повтори перекошують навчання сильніше, ніж шум.
4. Розмітка та звірка. Кожен запис перевіряє другий фахівець; спірні випадки розбираємо окремо й дописуємо в правила.
5. Розбиття на навчальну та перевіркову частини. Ділимо за джерелами та смисловими кластерами, а не випадково — інакше схожі формулювання потраплять в обидві частини й якість на перевірці виявиться завищеною.
6. Контрольний замір. Прогоняємо донавчену модель на перевірковій частині та порівнюємо з вихідною за сценаріями, які важливі замовнику.
7. Приймання набору. Чекліст за складом, статистика, версія вибірки та опис обмежень — що модель на цих даних освоїти не зможе.

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

Схеми полів, правила розмітки та регламент перезбирання

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

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

Що входить у передаваний набір:

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

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

Кейс: як перезбирання вибірки прибрало потік сміттєвих відповідей

Клієнт — внутрішній асистент із нормативної бази: співробітники запитують про регламенти, модель відповідає з посиланням на пункт. Першу версію донавчили на вивантаженні з тікетів першої лінії — близько п’ятдесяти тисяч пар «запит-відповідь» за рік.

На демонстраціях усе виглядало рівно, а на живих запитах модель посилалася на скасовані накази та склеювала пункти з різних документів.

Що знайшли у вибірці

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

Ще в 7% відповідь була склеєна із сусіднього рядка вивантаження — збій експорту, а не помилка людини. Розмітку вели в Label Studio, але без єдиної інструкції: кожен оператор розумів «відповідай стисло» по-своєму.

Що змінили

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

Вибірка скоротилася з 48 до 29 тисяч прикладів, зате перестала вчити суперечностей. На живих запитах частка відповідей із посиланням на неіснуючий пункт упала з 22% до 3%, а частка чесних відмов «у регламенті не знаходжу» зросла з 4% до 15% — модель перестала вгадувати. Ескалацій до живого юриста стало помітно менше: асистент перестав бути джерелом хибних посилань.

Що робити, якщо дані вже розмічено в іншому форматі?

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

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

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

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

Частина записів у перетворення не вкладається: кілька міток на одному фрагменті, вкладені репліки, мітки, яких у новій схемі просто немає.

Такі випадки не «домалювують» автоматично, а складають у чергу на часткову перерозмітку — зазвичай це 5–15 % обсягу, і саме вони дають основний приріст якості. Перерозмічати вручну решту — заново робити вже зроблену роботу.

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

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

Дедуплікація, ліцензії та приватність: питання інженерів

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

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

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

Що перевіряєте в ліцензіях на навчальні дані?

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

Як персональні дані потрапляють у вибірку і як їх звідти прибрати?

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

Як переконатися, що модель не «вивчила» дані напам’ять?

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

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

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

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

• Перелік вихідних матеріалів: звідки беруться дані — звернення до підтримки, листування, внутрішня база знань, документи — і в якому вигляді вони зберігаються зараз.
• Зріз даних для оцінки: приклади «запит — очікувана відповідь» рівно в тому вигляді, у якому вони виникають у роботі, включно з невдалими та неповними.
• Еталонна розмітка: 20–30 прикладів, розмічених вручну вашим фахівцем, — за ними калібруємо перевірки якості та правила чищення.
• Глосарій: прийняті у вас назви продуктів, терміни, скорочення та варіанти написання, щоб модель не викривляла предметну область.
• Обмеження: теми та формулювання, яких у відповідях бути не повинно, і правила поведінки в спірних або неповних запитах.
• Вимоги до відповіді та критерії приймання: що ви вважаєте коректним результатом, а що — помилкою, яка потребує переробки вибірки.

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