Чому очищення даних LLM ламається на масштабі
На демонстраційній вибірці в пару тисяч прикладів корпус виглядає чистим, а на повному обсязі донавчання поводиться непередбачувано: валідаційна метрика зростає, а в роботі модель повторює формулювання з інструкцій і втрачає формат відповіді.
Причина майже завжди не в архітектурі, а в тому, як виконано очищення даних — дефекти навчального корпусу не видно під час вибіркового перегляду очима.
Дублікати у вибірці — перший і найдорожчий дефект. Точні копії ловляться нормалізацією та хешуванням, але майже-дублікати залишаються: одна інструкція з різними вступними, передруки з того самого джерела.
Модель бачить той самий приклад десятки разів, перенавчається на нього, а рідкісні, але важливі випадки тонуть у повторах. Поруч — шум у розмітці: уривки службових тегів, непарні лапки, поля, що залишилися від автоматичного збору, відповіді не на те питання.
Окрема категорія — приховані шаблони. Якщо дев’ять із десяти відповідей починаються однаковою вступною фразою або містять маркер джерела, модель вивчає шаблон замість розв’язання задачі й упевнено відтворює його на користувацьких запитах.
Витік еталонних прикладів б’є по довірі до метрик: поки контрольна вибірка перетинається з навчальною, заміри показують якість, якої в роботі немає.
Падіння якості донавчання спливає вже після викатки, коли перенавчати найдорожче, — розбираємо, як очищення даних LLM закриває це до старту навчання.
Що дає контрольована якість корпусу для донавчання
Контроль якості даних починається не з чистки, а з вимірюваності: поки частка відбракованих прикладів не рахується за кожним класом дефектів, неможливо відрізнити поліпшення корпусу від випадкового коливання.
Профіль дефектів ведемо як звіт за кожним прогоном — скільки дублікатів, шаблонних вставок, битих кодувань, обрізаних діалогів і перетинів з оцінювальними наборами пішло у відбракування і за яким правилом.
Профіль дефектів показує, які правила працюють, а які вирізають зайве.
Поріг на повтори й мовний фільтр налаштовуються за доменом: там, де рідкісні конструкції цінні для цільового сценарію, правило пом’якшується, а не вимикається — інакше рідкісний клас просто зникає з корпусу, і модель втрачає на ньому стійкість.
Відтворюваність навчання тримається на версіонуванні: набір отримує маніфест із контрольними сумами, складом фільтрів і розбиттям на частини.
Прогін повторюється через місяць із тим самим результатом, а порівняння двох навчань зводиться до різниці в правилах, а не до шуму в даних. Для дедуплікації та фільтрації на великих обсягах беремо NeMo Curator, а метрики рахуємо своїми скриптами.
Стійкість моделі на рідкісних сценаріях — прямий наслідок акуратного очищення: надмірна фільтрація прибирає саме довгий хвіст, а метрики на загальному наборі при цьому зростають. Тому частку рідкісних класів до і після фільтрації звіряємо і тримаємо не нижче початкової.
Потік чи разове вивантаження: чим відрізняються підходи
Режим підготовки корпусу впливає не лише на терміни першого прогону, а й на те, як корпус живе далі: разове вивантаження корпусу дає хороший знімок на дату, регулярна пакетна переробка тримає його в актуальному стані, безперервний потік ловить свіжі дані майже одразу.
Різниця проявляється пізніше — у вартості нагляду, відтворюваності версій і в тому, наскільки боляче відкочувати зіпсований прогін.
| Варіант | Коли підходить | Обмеження режиму |
|---|---|---|
| Разове вивантаження корпусу | Перший прогін, перевірка гіпотези, джерело з рідкісними змінами | Знімок застаріває; відтворюваність тримається лише на архіві версії |
| Регулярна пакетна переробка | Дані змінюються передбачувано: раз на добу, тиждень, місяць | Потрібен регламент оновлення даних і звірка лише нових фрагментів, інакше дублікати |
| Безперервна потокова обробка | Живий потік подій або зворотного зв’язку від користувачів | Складніший відкат, дублікати на межах вікон, вищі вимоги до нагляду |
На практиці частіше беруть комбінацію: потік валідує записи і складає їх у буфер, а пакетна переробка раз на узгоджений інтервал перезбирає цілісну версію корпусу — з повторною дедуплікацією, нормалізацією та розміткою персональних даних.
Регламент оновлення даних фіксує, що вважається новою версією, який мінімум чистих записів потрібен для перезбирання і за яким правилом відкочуються невдалі прогони.
Так потокова обробка не перетворюється на неконтрольоване зростання, а кожна версія корпусу залишається простежуваною до джерела.
Як будується очищення корпусу: етапи інженерних робіт
Очищення корпусу будується не навколо готової бібліотеки, а навколо конкретних даних і задачі моделі. Спочатку домовляємося, що вважаємо шумом саме тут: биті кодування, вставки зі сторонніх джерел, шаблонні блоки, машинний переклад, однакові інструкції з різною розміткою. Далі робота йде етапами, і кожен залишає перевірюваний артефакт — звіт, правило або тест.
- Аудит корпусу — стратифікована вибірка за джерелами й мовами, ручна розмітка класів шуму та їхніх часток. Це задає порядок робіт: першим прибираємо те, що дає основну масу сміття.
- Правила фільтрації — кожне правило записуємо як перевірювану умову: частка службових символів, довжина в токенах, збіг із шаблонами. Пороги підбираємо за розміткою і версіонуємо набір за індивідуальним розрахункомДедуплікація прикладів — порівняння за сигнатурами близькості, а не за точним збігом: так ловляться перефразування й склейки. Окремо проходимо пари «інструкція — відповідь»: дубль питання з різними відповідями шкідливіший за повний повтор.
- Складання конвеєра — кроки оформлюємо як відтворюваний ланцюг із логуванням: скільки прикладів відсіяв кожен фільтр. Змінюємо поріг і одразу бачимо наслідки, а не перезапускаємо наосліп.
- Контрольна вибірка — прогін на відкладеному наборі, який не брав участі в підборі правил: частка хибних вилучень, залишковий шум, збереженість рідкісних, але цінних прикладів.
- Передача конвеєра — конфігурації, тести, звіти за метриками та інструкція із запуску. Команда замовника проганяє очищення сама на новому зрізі даних.
Конфігурації, схеми та регламенти підготовки корпусу
Кожен крок підготовки корпусу фіксується в артефактах, які залишаються у вашому контурі, а не в листуванні з виконавцем.
За ними новий інженер відтворює складання з нуля, аудитор бачить походження кожного запису, а повторний запуск дає той самий результат на тих самих вхідних даних.
- Схема проходження даних — шлях запису від джерела до фінального корпусу: вузли обробки, точки розгалуження, карантин відбракованого, перевірки на кожному переході.
- Налаштування конвеєра — декларативні файли конфігурації: правила нормалізації, пороги фільтрів за мовою та дублями, вікна дедуплікації, обмеження на довжину й кодування запису.
- Версіонування корпусу — знімки датасету з контрольними сумами й журналом змін: видно, яке складання пішло в донавчання і на яку версію відкотитися.
- Політики доступу до корпусу — ролі й рівні чутливості, маскування персональних полів, журнал звернень до даних, порядок надання й відкликання доступу.
- Регламент переробки — що відбувається із відбракованими записами: карантин, повторна розмітка, термін зберігання, порядок видалення на запит власника даних.
- Документація щодо даних — паспорт корпусу: склад і частка мов, обсяг, джерела та права на використання, звіт за метриками чистоти.
- Чек-лист приймання — відтворювані перевірки: контрольний прогін на фіксованій вибірці й пороги, за яких складання вважається придатним.
Пакет передаємо разом із запуском на вашій інфраструктурі: інженери замовника правлять конфігурацію самостійно, а конвеєр залишається керованим без нас.
Кейс: як скоротили частку браку в навчальному корпусі
Що надійшло на вхід
Замовник — продуктова команда, яка донавчає асистента підтримки: корпус на 4,2 млн документів збирали зі звернень, листувань і внутрішньої бази знань.
Заміри перед роботою показали 34% майже однакових записів, 11% обривків — фрагментів, обрізаних за лімітом поля, — і різнобій у службовій розмітці.
Донавчання через це перезапускали по 5–6 разів: модель з однаковою впевненістю відтворювала і робочі відповіді операторів, і сміттєві заготовки.
Що змінили
Зібрали конвеєр підготовки корпусу: нормалізація тексту й переносів, зняття службової розмітки, дедуплікація за нечітким збігом шинглів — розрахунок розподілений, на Apache Spark.
Далі фільтри якості: відсів коротких і обривкових фрагментів, перевірка мови, відсів шаблонних привітань, маскування персональних даних. Метрики рахували на контрольних наборах після кожного кроку — так видно внесок окремого фільтра, а не загальний результат.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Частка дублів | 34% | 6% |
| Обривки й биті фрагменти | 11% | 1,4% |
| Обсяг навчальної вибірки | 4,2 млн документів | 2,6 млн |
| Повторні прогони донавчання | 5–6 | 1–2 |
Конвеєр залишився в команди як регулярний прогін: нові вивантаження проходять ті самі перевірки, звіт за якістю корпусу збирається автоматично, частка дублів тримається на рівні 6% і не зростає разом з обсягом.
Повторні прогони донавчання скоротилися з 5–6 до 1–2 — правки в даних тепер видно до запуску навчання, а не після.
Що робити, якщо корпус уже зібрано й частково розмічено?
Перший крок — інвентаризація готового корпусу: рахуємо частку прикладів із розміткою, чинну схему міток, скільки прикладів розмічали кілька людей і де розходження вищі за поріг узгодженості.
Перевикористовується зазвичай більше, ніж очікує замовник: якщо схема міток не змінювалася, розмічене ядро йде в донавчання як є, а спірні приклади передаються в арбітраж, а не на перерозмітку з нуля.
Часткова розмітка не заважає роботі. Розмічена частина працює як посів: на ній калібруємо автоматичну розмітку, перевіряємо її на відкладеній вибірці й дорозмічуємо вручну лише те, де впевненість низька. Так корпус зростає без пропорційного зростання ручної праці.
Перерозмітка прикладів потрібна там, де змінювалася схема міток або правило віднесення до класу.
Будуємо таблицю відповідності старих міток новим, проганяємо міграцію розмітки й перевіряємо результат на контрольній вибірці: частка прикладів, що втратили мітку, має бути видна до старту донавчання.
Попередню розмітку не видаляємо — вона залишається окремою ревізією, до якої можна повернутися під час відкату.
Історія змін даних — обов’язкова частина, а не надбудова. Кожну зміну прикладу фіксуємо з автором, причиною та версією, а корпус тримаємо ревізіями, щоб донавчання на будь-якій із них відтворювалося.
Це дає змогу порівняти метрики до і після правок і не запускати навчання наосліп після масової перерозмітки.
Технічні сумніви щодо якості корпусу
Придатність корпусу ми перевіряємо не на око, а за набором вимірюваних ознак: частка точних дублів і майже-дублів, розкид довжини документів, частка фрагментів іншою мовою, щільність службової розмітки й битого тексту, покриття цільових тематичних кластерів.
Пороги фіксуємо до старту робіт — тоді приймання перетворюється на звірку з числами, а не на суперечку про смаки.
Якщо після фільтрації залишається 60–70% початкового обсягу і він покриває всі потрібні теми, корпус придатний; якщо менше — перезбираємо джерела, а не посилюємо правила.
Чи не втратимо рідкісні приклади під час жорсткого очищення?
Втратимо, якщо фільтри застосовуються однією хвилею. Тому рідкісні класи не видаляємо, а позначаємо й відводимо в окремий набір: дедуплікація за ними йде зі зниженим порогом, а під час навчання їхня вага підвищується.
Контроль — за частотним розподілом міток: жоден клас не повинен зникнути після очищення, навіть якщо його частка — частки відсотка.
Як вимірювати якість, якщо еталонної розмітки немає?
Збираємо «золоту сотню»: невелику вибірку, розмічену вручну за інструкцією, і калібруємо на ній усі автоматичні правила.
Решту корпусу оцінюємо опосередковано — узгодженістю двох незалежних розмітників на контрольних фрагментах і поведінкою моделі на утриманому наборі до і після донавчання. Якщо якість відповідей не зростає, проблема частіше в правилах відбору, ніж в обсязі.
Наскільки складна розмітка і скільки часу займає підготовка?
Основний час іде не на фільтрацію — вона займає дні, — а на розмітку й розбір спірних випадків: вона триває тижнями і потребує письмової інструкції з прикладами граничних ситуацій.
Плюс закладаємо одну-дві ітерації: після першої перевірки на утриманому наборі правила майже завжди доводиться уточнювати. Ці терміни ми називаємо до початку робіт, а не за фактом.
Обговоримо задачу: що потрібно для оцінки корпусу
Оцінка обсягу робіт з очищення корпусу залежить від того, що вже є на вході, тому обговорення задачі починаємо з вхідних даних, а не із загальних обіцянок. Нижче — те, що найбільше впливає на розрахунок термінів і склад етапів.
- Цілі донавчання: який клас відповідей має видавати модель і на яких прикладах перевіряється коректність.
- Джерела корпусу: звідки взяті тексти, у якому вигляді вони лежать зараз, приблизний обсяг у документах і діалогах.
- Розмітка й еталони: чи є вручну перевірені приклади, хто і за якими правилами їх відбирав.
- Відомий шум: повтори, обривки, змішування мов, службові вставки, сліди автогенерації.
- Обмеження щодо даних: персональні відомості, комерційна таємниця, вимоги до зберігання й доступу.
- Критерії приймання: за якими метриками ви зрозумієте, що корпус готовий до навчання.
- Режим роботи: разове очищення чи регулярний потік з оновленнями й повторною перевіркою.
Опишіть задачу своїми словами — повернемося з оцінкою обсягу, планом робіт і розподілом ролей за етапами. Якщо частину вхідних даних ще не зібрано, почнемо з їх уточнення: це надійніше, ніж перерозмічувати корпус після того, як модель уже навчена.
