Валідація якості датасету для донавчання LLM: аудит і очищення

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

Чому валідація датасету LLM ламається на обсязі

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

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

Різниця в 5-8% розмітки між виконавцями не спливає у звіті, але саме вона задає стелю, вище якої дообучена модель не піднімається.

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

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

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

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

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

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

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

  • Дублі та майже-дублі. Точні повтори й перефразовані пари шукаємо за перетином n-грам із налаштовуваним порогом близькості. Навчальна частина після чищення коротша на 15–40% без втрати сенсу — модель перестає переоцінювати часті формулювання.
  • Шум і сміття. Уривки розпізнавання, службові вставки, биті символи та приклади не за темою відсікаємо правилами й статистикою за довжиною. Частка сміття падає нижче 1%: ємність моделі не витрачається на заучування артефактів.
  • Узгодженість розмітки. Один і той самий приклад у різних виконавців отримує різні мітки. Рахуємо частку розбіжностей на контрольній підвибірці, спірні випадки розбираємо й фіксуємо правило в інструкції, а підозрілі мітки ранжує Cleanlab. Розбіжності нижче 5% означають, що межа класів розмічена однаково.
  • Витік між вибірками. Схожі приклади потрапляють і в навчання, і в перевірку, через що метрики на відкладеній частині завищені. Групуємо пов’язані приклади за джерелом і документом та ділимо за групами — частка перетинів нульова, оцінка чесна.
  • Дисбаланс класів. Рідкісний клас тоне в частому: перераховуємо ваги у функції втрат, відбираємо приклади за шарами замість синтетики. Крива якості на рідкісному класі виходить із шуму.

Режими очищення: правила, розмітка моделлю, ручний розбір

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

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

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

Варіант Коли підходить Обмеження
Правила фільтрації Великі корпуси, грубий брак: дублі, уривки, бита розмітка, заборонені фрагменти Не бачить смислового сміття й витікання даних; правила треба підтримувати при зміні джерела
Модель-суддя Критерій смисловий: зв’язність, дотримання інструкції, токсичність, тематична відповідність Зміщення базової моделі, дрейф рубрики; потрібне калібрування й контроль повторюваності
Ручний розбір вибірки Калібрування порога, розмітка еталона, розбір спірних груп прикладів Не масштабується на весь корпус; потребує інструкції розмітникам і заміру згоди
Каскад правил, моделі й ручного розбору Змішані корпуси з високими вимогами до чистоти Складніше відтворити: версіонуються правила, рубрика й пороги разом

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

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

Етапи аудиту та очищення датасету: від інвентаризації до передачі

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

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

Артефакти: схеми розмітки, правила фільтрації, звіти

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

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

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

Кейс: дообучення на зашумлених даних до та після

До: що показав аудит

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

Перед навчанням прогнали аудит: із 240 тисяч пар майже 19% виявилися близькими дублями з різною розміткою, 8% містили суперечливі відповіді, ще 6% втратили контекст під час вивантаження — відповідь була, а питання, до якого вона належить, у парі не залишилося.

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

Після: що змінили і що отримали

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

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

Частка дублів упала з 19% до 2%, суперечливих прикладів стало менше 1%, обсяг вибірки скоротився приблизно на чверть.

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

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

Що робити, якщо навчальна вибірка вже зібрана й розмічена?

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

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

Брак зазвичай зосереджений у двох-трьох зрізах, і перерозмічати решту — витрата без приросту метрик.

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

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

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

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

Обмеження та часті сумніви щодо якості даних

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

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

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

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

Чи не втратимо рідкісні приклади за жорстких правил?

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

Як зрозуміти, що очищення дало ефект, якщо метрика шумить?

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

Обговоримо задачу: з чого починається робота

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

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

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

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

Напрямки AI-розробки

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1369
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142