GPU для досліджень ML · Оплата криптою без KYC
IteraGPU
Метод / Якість і діагностика

Перетворити оцінку на перевірювані рішення.

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

01 /

Зберігати виходи до їх узагальнення

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

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

Технічні джерела: scikit-learn 1.9 — тримати тест осторонь від вибору моделі

02 /

Читати матрицю плутанини разом з її чисельністю

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

Наступний приклад вигаданий і суто арифметичний. Сто звернень розподілено між Рахунком, Доступом і Видаленням. Діагональ містить 54 + 24 + 5 = 83 правильні відповіді, тобто 83 %. Цей підсумок маскує клас Видалення: розпізнано лише 5 із 10 очікуваних звернень. Жодна модель чи GPU не створили ці цифри.

Ілюстративний приклад — рядки: еталон; стовпці: прогноз; одиниця: звернення
ЕталонПрогноз РахунокПрогноз ДоступПрогноз ВидаленняФактичний підсумок
Рахунок545160
Доступ424230
Видалення41510
Прогнозований підсумок62308100

Технічні джерела: scikit-learn 1.9 — визначення матриці плутанини

03 /

Пов'язати точність, повноту та практичний наслідок

Для Видалення точність дорівнює 5/8 = 62,5 %: серед звернень, надісланих до цієї категорії, п'ять є правильними. Повнота дорівнює 5/10 = 50 %: половину звернень цієї категорії знайдено. F1 дорівнює 2 × 5 / (2 × 5 + 3 + 5), тобто приблизно 55,56 %. Три хибнопозитивні та п'ять хибнонегативних описують різні проблеми.

F1 класів Рахунок, Доступ і Видалення становлять відповідно 88,52 %, 80 % і 55,56 %. Їхнє незважене середнє, macro-F1, дорівнює приблизно 74,69 %. Воно доповнює 83 % правильних відповідей, але не замінює чисельності. Якщо клас відсутній в еталонах чи прогнозах, деякі метрики можуть бути невизначеними: оголошуйте використану конвенцію, а не ховайте випадок у середньому.

Точність = істинно позитивні / позитивні прогнози; повнота = істинно позитивні / позитивні еталони. Macro-F1 = середнє F1, обчислених окремо для кожного класу.

Технічні джерела: scikit-learn 1.9 — точність, повнота, F1, середні та ділення на нуль

04 /

Побудувати коротку таксономію, пов'язану з діями

Категорія помилок має допомагати вирішити, що саме переглядати. Почніть із кількох категорій, визначення та репрезентативного прикладу. Додайте основну мітку, щоб рахувати випадки без подвійного підрахунку, а потім додаткові мітки, якщо співіснують кілька явищ. Залиште категорію «потребує перегляду» замість того, щоб примусово давати пояснення.

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

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

Для вилучення рахуйте поля та документи

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

Ось другий ілюстративний розрахунок, незалежний від таблиці класифікації. П'ятдесят документів мають по три очікувані поля, тобто 150 значень. Припустімо, 38 документів повністю правильні, шість — із двома правильними полями та шість — з одним. Це дає 38 × 3 + 6 × 2 + 6 × 1 = 132 правильні значення, тобто 88 %. Однак лише 38/50 = 76 % документів повністю прийнятні, якщо всі три поля обов'язкові.

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

Фіктивне вилучення — три обов'язкові поля в кожному з 50 документів
Тип документаДокументиПравильні поля на документПравильних полів загалом
Повністю правильно383114
Одна помилка6212
Дві помилки616
Усього50—132 із 150
06 /

Виберіть виправлення, перш ніж перезапускати кампанію

Визначайте пріоритет за наслідком і охопленим обсягом, а не лише за кількістю рядків. У фіктивній матриці п'ять помилок «Видалення» можуть заслуговувати на перегляд раніше за шість помилок «Рахунок», якщо проєкт визначив цю категорію як критичну. Цей пріоритет належить до контракту проєкту; таблиця не дає змоги вигадати бізнесову важливість.

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

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

Перевіряйте приріст, не затираючи регресії

Парний розрахунок показує те, що приховує чистий показник. На сотні фіктивних тікетів уявімо дев'ять виправлених помилок, але чотири колишні успіхи, що стали хибними. Підсумок змінюється з 83 до 83 + 9 − 4 = 88 правильних відповідей. Приріст становить п'ять пунктів, із чотирма регресіями для перегляду. Це не означає, що дев'ять виправлень було отримано без жодної протилежної дії.

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

08 /

Обмежити висновок тим, що було розглянуто

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

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

Практичні питання

Чи достатньо підвищення загальної оцінки, щоб прийняти варіант?

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

Чи маю я виправляти еталон, коли модель йому суперечить?

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

Чи можу я додавати категорії своєї таксономії?

Лише якщо кожен випадок має одну основну ексклюзивну категорію для цього підрахунку. Другорядні мітки можуть перекриватися; тоді їхня сума рахує входження міток, а не окремі помилки.