Чому валідація датасету LLM ламається на обсязі
На вибірці з тисячі прикладів розбіжності в розмітці майже не видні: їх вичищають вручну й вважають випадковим шумом.
На обсязі в сотні тисяч картина змінюється — десятки розмітників тлумачать інструкцію по-різному, і те саме питання отримує то розгорнуту відповідь, то однослівну, то відмову.
Різниця в 5-8% розмітки між виконавцями не спливає у звіті, але саме вона задає стелю, вище якої дообучена модель не піднімається.
Другий шар проблеми — дублі та витікання даних. Схожі формулювання одного питання потрапляють в навчальну та контрольну вибірки одночасно, і метрики на перевірці показують зростання, якого немає на реальних запитах.
Поки вибірка дедуплікується за точним збігом, смислові повтори залишаються непоміченими: перефраз у два-три слова проходить фільтр і подвоює вагу теми в навчанні.
Шум у навчальній вибірці та помилки розмітки в датасеті небезпечні тим, що масштабуються моделлю, а не гасяться нею. Команда витрачає тижні на підбір рецептів навчання й правку підказок, хоча вузьке місце підготовки даних лежить раніше — у самій вибірці.
Валідація датасету LLM потрібна не як разове чищення перед запуском, а як регулярний контроль: правила узгодженості розмітки, пороги розбіжності між виконавцями, перевірка перетинів між вибірками.
Розбираємо, як це закривається: які перевірки ставляться на вході, як розмічаються спірні випадки і що показує розбіжність до та після очищення.
Що виправляється перед навчанням: дублі, шум, розмітка, витікання даних
Перед дообученням датасет проходить перевірку за класами дефектів, і кожен із них модель вивчає разом із корисним сигналом. Виправляти це найдешевше на даних: після запуску навчання ціна правки зростає разом з обсягом розмітки. Нижче — що саме ми перевіряємо і чим вимірюємо результат.
- Дублі та майже-дублі. Точні повтори й перефразовані пари шукаємо за перетином n-грам із налаштовуваним порогом близькості. Навчальна частина після чищення коротша на 15–40% без втрати сенсу — модель перестає переоцінювати часті формулювання.
- Шум і сміття. Уривки розпізнавання, службові вставки, биті символи та приклади не за темою відсікаємо правилами й статистикою за довжиною. Частка сміття падає нижче 1%: ємність моделі не витрачається на заучування артефактів.
- Узгодженість розмітки. Один і той самий приклад у різних виконавців отримує різні мітки. Рахуємо частку розбіжностей на контрольній підвибірці, спірні випадки розбираємо й фіксуємо правило в інструкції, а підозрілі мітки ранжує Cleanlab. Розбіжності нижче 5% означають, що межа класів розмічена однаково.
- Витік між вибірками. Схожі приклади потрапляють і в навчання, і в перевірку, через що метрики на відкладеній частині завищені. Групуємо пов’язані приклади за джерелом і документом та ділимо за групами — частка перетинів нульова, оцінка чесна.
- Дисбаланс класів. Рідкісний клас тоне в частому: перераховуємо ваги у функції втрат, відбираємо приклади за шарами замість синтетики. Крива якості на рідкісному класі виходить із шуму.
Режими очищення: правила, розмітка моделлю, ручний розбір
Жоден режим очищення не працює окремо. Правила фільтрації дешеві, відтворювані й передбачувані, але сліпі до сенсу: вони не відрізнять зв’язну відповідь від правдоподібного набору фраз.
Модель-суддя ловить смисловий брак — суперечності, невідповідність інструкції, шкідливі формулювання, — але успадковує зміщення базової моделі й потребує калібрування на еталоні. Вибір режиму задають дві речі: обсяг корпусу й ціна помилки на виході.
Тому порівнюємо підходи за трьома осями: що саме ловить, на якому обсязі окупається, що вимагає від команди. За таблицею нижче вибираємо одиничний режим або збираємо каскад.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила фільтрації | Великі корпуси, грубий брак: дублі, уривки, бита розмітка, заборонені фрагменти | Не бачить смислового сміття й витікання даних; правила треба підтримувати при зміні джерела |
| Модель-суддя | Критерій смисловий: зв’язність, дотримання інструкції, токсичність, тематична відповідність | Зміщення базової моделі, дрейф рубрики; потрібне калібрування й контроль повторюваності |
| Ручний розбір вибірки | Калібрування порога, розмітка еталона, розбір спірних груп прикладів | Не масштабується на весь корпус; потребує інструкції розмітникам і заміру згоди |
| Каскад правил, моделі й ручного розбору | Змішані корпуси з високими вимогами до чистоти | Складніше відтворити: версіонуються правила, рубрика й пороги разом |
Окремо калібруємо поріг відсікання прикладів: він завжди балансує між повнотою і точністю. Занижений залишає шум і суперечності, які модель потім вивчить як норму; завищений вирізає рідкісні, але валідні приклади — довгі діалоги, рідкісну лексику, нестандартні формулювання.
Поріг підбираємо на еталонній вибірці, розміченій вручну, і фіксуємо разом із версією рубрики — інакше повторний прогін дає інший датасет і відтворюваність втрачається.
Етапи аудиту та очищення датасету: від інвентаризації до передачі
Аудит даних — не разове чищення файлу, а послідовність, де кожен крок спирається на результат попереднього. Порядок важливий: без інвентаризації профілювання рахує дублі як різні записи, а без плану очищення фільтрація вирізає рідкісні класи, які модель якраз і має вивчити.
- Інвентаризація джерел. Збираємо всі корпуси та вивантаження, фіксуємо походження, права на використання, дату збору й перетини між джерелами — частина записів зазвичай дублюється у двох-трьох наборах.
- Профілювання вибірки. Рахуємо розподіли: довжина записів, мова, частка порожніх і обрізаних прикладів, розкид міток. Перекіс виявляється тут — до того, як він потрапить у навчання.
- Схема розмітки. Формалізуємо цільові класи, правила анотації та порядок розв’язання розбіжностей між розмітниками, інакше однакові приклади отримають різні мітки.
- План очищення. Описуємо дедуплікацію точну й майже-дублів, відсів сміття, нормалізацію, балансування класів і розбиття на навчальну, валідаційну та відкладену вибірки без витоку даних.
- Фільтрація та перерозмітка. Проганяємо правила, спірні випадки розбираємо вручну, замірюємо узгодженість розмітки до та після.
- Контрольний прогін. Навчаємо на очищеному й на вихідному зрізах, порівнюємо метрики на відкладеній вибірці — так видно, що саме дало очищення, а не відчуття.
- Передача. Віддаємо версіонований датасет, картку даних з описом обмежень і скрипти, що відтворюють збирання зрізів.
Артефакти: схеми розмітки, правила фільтрації, звіти
Валідація датасету LLM закінчується не вердиктом «дані придатні», а комплектом артефактів, за якими команда замовника може повторити очищення на новому зрізі без нас. Нижче — що входить у передачу й навіщо потрібен кожен документ.
- Схема розмітки: поля запису, типи значень, обов’язковість, допустимі мітки й правило розв’язання конфліктів між розмітниками.
- Інструкція для виконавців: як тлумачити пограничні приклади, що вважати браком, як позначати невпевнену розмітку — розбіжності між людьми падають кратно.
- Правила фільтрації даних: дедуплікація за нормалізованим текстом, пороги за довжиною та мовою, відсів шаблонних і машинно-згенерованих фрагментів, обробка персональних даних.
- Звіт про якість даних: розподіл за класами й сегментами, частка розбіжностей між розмітниками, покриття набору перевірками, перелік проблемних зрізів.
- Журнал виключених прикладів: кожен відкинутий фрагмент із причиною та посиланням на правило — рішення можна оспорити й переглянути, а не приймати на віру.
- Конфігурації та скрипти очищення: повторний прогін на новому зрізі дає той самий результат і ті самі звіти.
- Регламент повторної валідації: за якими метриками і як часто перевіряти набір після дообучення.
Комплект передаємо з розбором: показуємо, де правила розходяться з реальними даними і що змінювати першим. Далі цикл валідації команда замовника веде самостійно.
Кейс: дообучення на зашумлених даних до та після
До: що показав аудит
Проєкт — асистент першої лінії підтримки, який відповідає на основі внутрішньої бази знань. Замовник приніс архів звернень і хотів дообучити модель на ньому.
Перед навчанням прогнали аудит: із 240 тисяч пар майже 19% виявилися близькими дублями з різною розміткою, 8% містили суперечливі відповіді, ще 6% втратили контекст під час вивантаження — відповідь була, а питання, до якого вона належить, у парі не залишилося.
Навчання на такому наборі давало нестабільність: два запуски на одній конфігурації розходилися за часткою коректних відповідей на контрольній вибірці на кілька відсотків.
Після: що змінили і що отримали
Дедуплікацію рахували за нормалізованими формулюваннями з порогом близькості, а не за точним збігом, тому у вибірку не потрапили перефразування однієї й тієї самої заявки.
Конфліктні пари виносили на арбітраж, правила розмітки зафіксували письмово й розмітку вели в Label Studio — версії анотацій стали відтворюваними. Обрізані приклади відновили з вихідних діалогів або відкинули.
Частка дублів упала з 19% до 2%, суперечливих прикладів стало менше 1%, обсяг вибірки скоротився приблизно на чверть.
Частка коректних відповідей на контрольній вибірці зросла з 61% до 79%, а розкид між повторними запусками — менше одного відсотка, тобто результат перестав залежати від того, якою була послідовність даних.
Контрольну вибірку зафіксували до початку робіт і в навчанні не використовували. Це дає замовнику можливість порівнювати версії моделі між собою й розуміти, що зростання якості — наслідок даних, а не підгонки під перевірний набір.
Що робити, якщо навчальна вибірка вже зібрана й розмічена?
Повна повторна розмітка — крайній захід, а не перший крок. Повторний прохід подвоює трудовитрати й вносить новий шар шуму: два розмітники тлумачать інструкцію по-різному, і попередня розмітка перестає бути еталоном для порівняння прогонів. Тому спочатку вимірюємо — скільки в наборі справді зламаних прикладів і в яких зрізах вони лежать.
Частковий аудит вибірки будуємо стратифіковано — за джерелами, типами задач і довжиною відповіді. Дивимося частку розбіжностей між розмітниками на перехресних прикладах, частку обрізаних і порожніх відповідей, дублікати, перетин тестової частини з навчальною.
Брак зазвичай зосереджений у двох-трьох зрізах, і перерозмічати решту — витрата без приросту метрик.
Далі — доразмітка спірних сегментів: там, де розмітники розійшлися або відповідь формально правильна, але суперечить інструкції, уточнюємо правило й перерозмічаємо лише цей зріз. Решту масиву не чіпаємо, щоб зберегти зіставність прогонів і бачити внесок саме виправлених даних.
Перевикористання інструкцій закриває основну частину обсягу: уже розмічені відповіді залишаються в наборі, якщо не суперечать оновленим правилам.
Автоматична перевірка на відповідність інструкції витягує на ручну доразмітку лише пограничні випадки — за нашою практикою це одиниці відсотків від масиву.
Набір стає придатним для дообучення без повної перерозмітки, а рішення щодо кожного зрізу зафіксовано в правилах, щоб наступний збір даних не повторював тих самих помилок.
Обмеження та часті сумніви щодо якості даних
Очищення спирається на статистику: правила пишуться під масові випадки — дублікати, уривки розмітки, шаблонні відповіді.
На рідкісних класах ті самі фільтри дають хибні спрацювання й вирізають саме те, заради чого модель дообучають: вузьку термінологію, нетипові формулювання, поодинокі сценарії відмови.
Видалення без карантину — найдорожчий вид помилки: дефект у датасеті не видно, а потрібний сигнал уже не повернути.
Ефект очищення на шумній метриці вимірюємо не одним числом. Рахуємо на стратифікованій відкладеній вибірці, рідкісні класи дивимося окремими зрізами, повторюємо прогін на тому самому наборі й порівнюємо розкид. Поруч тримаємо частку збережених рідкісних прикладів і обсяг відбракованого.
Чи не втратимо рідкісні приклади за жорстких правил?
Видаляємо лише очевидне сміття, спірні записи йдуть у карантин із причиною відбракування й розбираються вручну. Перед прогоном фіксуємо частку рідкісних класів за зрізами, після очищення звіряємо — просідання вище обговореного зупиняє процес.
Як зрозуміти, що очищення дало ефект, якщо метрика шумить?
Фіксуємо відкладену вибірку, порядок прикладів і умови прогону. Дивимося не на загальний бал, а на зміну за зрізами: там, де правило спрацювало точково, зсув видно на малих числах. Різниця в межах розкиду повторних прогонів ефектом не вважається.
Обговоримо задачу: з чого починається робота
Перш ніж брати весь масив, потрібно зрозуміти, як він улаштований. Для оцінки достатньо опису вибірки, чинних інструкцій розмітки й набору спірних прикладів — цього вистачає, щоб побачити класи помилок і назвати терміни.
- Обсяг і склад: мови, тематики, як збиралися дані й яка частка отримана генерацією, а яка — із реальних звернень.
- Інструкції розмітки й гайд для анотаторів, включно з місцями, де практика розійшлася з текстом.
- 30–50 фрагментів, де розмітники не зійшлися між собою або відповідь виглядає сумнівною: за ними видно, де ламається узгодженість.
- Вимоги продукту: які помилки неприпустимі, що модель не повинна відповідати, які сценарії вважаються цільовими.
- Як вибірка ділиться на навчання й контроль — щоб виключити перетини й витікання даних між частинами.
- Доступи: знеособлене вивантаження або робота на вашому боці, хто підтверджує спірні випадки.
- Критерії приймання й терміни, які для вас критичні.
За цим набором збираємо план робіт з очищення: дедуплікація й нормалізація, фільтри токсичності та персональних даних, повторна розмітка спірних випадків, перезбирання розбиття на навчання й контроль.
Першим кроком іде пробний етап на невеликому зрізі — він показує, чи працює правило на ваших даних, а не в теорії, і де правила чищення конфліктують одне з одним. Після нього оцінка термінів спирається на заміри, а не на середні числа. Обговоримо задачу — повернемося з оцінкою та планом.







