Розрізняйте кампанію, конфігурацію та виконання
Кампанія несе питання, наприклад порівняти базовий варіант з адаптацією. Конфігурація описує технічні вибори. Запуск — це спроба виконати цю конфігурацію, із зерном (seed), початком, кінцем і статусом. Отже, дві ідентичні спроби зберігають два ідентифікатори, навіть якщо друга замінює перервану спробу.
Додайте ідентифікатор оцінювання, коли той самий артефакт оцінюється на кількох наборах або з новою метрикою. Це запобігає плутанині між новою моделлю та новим прочитанням наявної моделі. Пов'яжіть спробу відновлення з тією, що їй передувала, і із завантаженим checkpoint.
MLflow також організовує відстеження навколо запусків, параметрів, метрик і артефактів. Це розрізнення корисне навіть у простій теці з файлами. Ви можете застосувати його зі своїм звичним інструментом; жодна конкретна платформа відстеження не потрібна, щоб почати.
Технічні джерела: MLflow — запуски, параметри, метрики та артефакти
Записуйте маніфест, який справді виконувався
Зберігайте розв'язані параметри після застосування значень за замовчуванням і аргументів запуску. Початковий файл конфігурації може опускати batch за замовчуванням або опцію, змінену під час виконання. Записуйте те, що фактично використовувалося, разом із копією коду або незмінною ревізією та станом незафіксованих змін.
Маніфест також пов'язує версії моделі й токенізатора, програмне середовище, фактично використаний GPU, точність, дані, seeds і визначення метрик. Він описує спробу, не перетворюючись на посібник зі встановлення. Зазначайте одиниці: секунди, байти, токени, бали або частку від 0 до 1 залежно від вимірювання.
На старті статус — у процесі; наприкінці він стає завершеним, невдалим або перерваним залежно від того, що ви спостерігали. Не доповнюйте заднім числом забуту версію тією, що наразі встановлена. Позначайте невідому інформацію та обмежуйте висновок, який від неї залежить.
| Блок | Елементи для збереження | Питання, на яке відповідає |
|---|---|---|
| Ідентичність | campaign_id, config_id, run_id, за потреби parent_run_id | Яка спроба дає цей результат? |
| Код і модель | Точні ревізії, локальні зміни, базова модель і токенізатор | Яке обчислення справді було запущене? |
| Дані | Версія, split, попередня обробка, ідентифікатори та відповідний порядок | На яких вхідних даних? |
| Параметри | Чинні значення, зерна (seeds) та одиниці | З якими налаштуваннями? |
| Оцінювання | Оцінений артефакт, метрика/версія, поріг і сукупність | Що означає оцінка? |
| Закриття | Статус, помилка, створені файли та рішення | Чи придатна спроба до використання? |
Ідентифікуйте дані поза назвою теки
Шлях, як-от donnees/final, не позначає стабільну версію. Зберігайте інвентар файлів або прикладів, splits і процедуру перетворення. Якщо ви виправляєте мітки чи фільтруєте рядки, створіть нову версію та збережіть зв'язок із попередньою. Стара оцінка має й надалі вказувати на свої старі дані.
Hugging Face Datasets зіставляє fingerprints зі станом набору та його перетвореннями для керування кешем. Цей механізм корисний, але потрібно також зберігати походження даних і попередню обробку. Зокрема, не хешоване перетворення може призвести до випадкового fingerprint: ідентифікатор кешу сам по собі не замінює вашу теку походження.
Для зафіксованих артефактів додавайте розмір і відбиток файлу. Дайджест SHA-256, обчислений до і після копіювання, дозволяє перевірити, що байти відповідають збереженому зразку. Він не доводить ні якості міток, ні прав на використання, ні відсутності витоку між splits.
Технічні джерела: Hugging Face Datasets — fingerprints і перетворення · Python 3.14 — відбитки файлів за допомогою hashlib
Пов'язуйте метрики, прогнози та артефакти
Рядок метрики має ідентифікувати запуск, оцінюваний артефакт, набір для оцінювання, версію метрики та її межі. Уточніть, чи стосується значення проміжного контрольного знімка (checkpoint), фінальної моделі або підгрупи. Кривої недостатньо, якщо вже не зрозуміло, який файл відповідає вибраному значенню.
Зберігайте передбачення разом з їхнім ідентифікатором входу, статусом та інформацією, потрібною для оцінювання. Очікувані еталонні відповіді можуть залишатися в окремому файлі під контролем версій. Для структурованого виводу розрізняйте сирий результат, розібраний результат і вердикт: виправлення парсингу не повинно перезаписувати початковий вивід.
MLflow дає змогу пов’язати метрики з моделями та даними. З файлами застосовуйте той самий принцип через явні ідентифікатори. Тримайте читабельний перелік артефактів: ваги або адаптер, параметри генерації, виводи, звіт про оцінювання та запису про рішення. Не припускайте, що знімок екрана замінює ці файли.
Технічні джерела: MLflow — пов’язуємо метрики, моделі та набори даних
Приклад: шість запусків і дублікат, що приховує прогалину
Розгляньмо приклад класифікації з двома конфігураціями та трьома зернами (graines). Він дає шість запланованих запусків. Кожен має передбачити ті самі 300 ідентифікаторів для оцінювання: повна тека, отже, потребує 6 × 300 = 1 800 унікальних пар (run_id, input_id). Це обчислення описує очікуваний перелік, а не реально виконаний експеримент.
Припустімо, що файл містить 300 рядків, але ідентифікатор doc-042 присутній двічі, а doc-117 відсутній. Загальна кількість рядків виглядає правильною; однак унікальних ідентифікаторів лише 299. Цей запуск не проходить перевірку покриття, доки аномалію не буде пояснено й виправлено.
Якщо кожен запуск потім оцінюють на повному корпусі та на його підгрупі довгих текстів, ви отримаєте дванадцять рядків метрики для однієї заданої метрики. Це все одно шість запусків, а не дванадцять незалежних тренувань. Ключ оцінювання має включати межі (périmètre), щоб зберегти цю відмінність.
| Перевірка | Очікувано | Ілюстративна аномалія |
|---|---|---|
| Запуски | 2 конфігурації × 3 зерна = 6 | Повторний запуск отримує новий ідентифікатор |
| Передбачення на запуск | Очікується 300 унікальних ID | 300 рядків, але лише 299 унікальних ID |
| Пари запуск/вхід | 6 × 300 = 1 800 | Лише загальний підрахунок не виявляє всіх дублікатів |
| Оцінювання | 6 запусків × 2 межі = 12 | Дванадцять оцінок не створюють дванадцять запусків |
Закриваємо справу зрозумілим рішенням
Перш ніж оголосити запуск завершеним, перевірте наявність і відкриття файлів, відповідність ідентифікаторів, можливість перерахувати метрики та статус кожної помилки. Технічно завершена спроба може залишатися відхиленою через недостатню якість. Тримайте ці два стани окремо.
Запису про рішення збирає питання, порівнювані варіанти, оголошений критерій, залишені результати та причини виключення. Посилайтеся на run_id та шляхи до артефактів, а не на «останню модель». Додайте обмеження: мало повторень, недостатня підгрупа, версію не знайдено або порівняння стало неможливим.
Подальше виправлення має залишити слід: нове оцінювання, новий звіт і причину зміни. Зберігайте попередній висновок як ідентифіковану історичну версію, не дозволяючи йому виглядати як поточне рішення. Насамкінець перевірте, що експортована копія відкривається зі своєї теки призначення.
Уникаємо зайвого збору даних і обіцянок відтворення
Збирайте поля, потрібні для доказу, а не всі змінні середовища чи історію термінала. Конфігурація або URL можуть містити токен; підготуйте версію для поширення без секретів, а дані, що мають залишатися приватними, тримайте в дозволеному місці. Технічні ідентифікатори тестів не повинні містити імені людини.
Повна тека покращує можливість повторити й зрозуміти експеримент. Вона не гарантує числової тотожності між платформами чи версіями: PyTorch документує ці межі відтворюваності. Розрізняйте відновлення протоколу, перезавантаження артефакту та точне відтворення чисел.
Журнал IteraGPU може зберігати ваші цілі, параметри та рішення разом з корисними посиланнями. Він не запускає запуски й не збирає автоматично файли чи телеметрію. Використовуйте його як покажчик ваших міркувань, а теку артефактів тримайте у власних резервних копіях.
Технічні джерела: PyTorch 2.14 — межі відтворюваності між середовищами
Практичні питання
Чи достатньо коміту Git, щоб відтворити експеримент?
Коміт ідентифікує версію коду, але не обов'язково дані, ваги, фактичні параметри чи незафіксовані зміни. Поєднайте його з маніфестом і створеними артефактами. Без цих зв'язків два запуски одного коміту можуть відповідати різним експериментам.
Чи потрібно зберігати всі прогнози?
Зберігайте виходи, необхідні для перевірки висновків і перерахунку оцінювання, у межах ваших прав і обмежень щодо зберігання. Для обмеженого порівняльного корпусу ідентифікатори та повні прогнози роблять помилки доступними для аудиту. Простий агрегований бал зазвичай не дозволяє відновити пропущені приклади.
Чи має повторний запуск використовувати той самий run_id?
Запропонована схема надає новий ідентифікатор кожній спробі та пов'язує повторний запуск із попереднім запуском і завантаженим checkpoint. Ви можете об'єднати ці спроби в один логічний експеримент. Таке розділення робить видимими переривання, витрати та файли, фактично створені на кожному етапі.