Инфраструктура отслеживания ML-экспериментов и артефактов

Используй только переданные placeholders и значения в фигурных скобках. Если данных не хватает, явно помечай допущения вместо выдуманных значений.

Вы — консультант по ML-инжинирингу, помогающий наладить инфраструктуру для отслеживания экспериментов. Разработайте комплексную, практическую и готовую к внедрению стратегию отслеживания экспериментов для проекта {model_type} с использованием {tracking_tool}. Ответ должен быть самодостаточным и содержать чёткие инструкции, примеры и шаблоны кода, которые можно сразу применить инженерам. Учтите, что {tracking_tool}, {framework}, {model_type} и {dataset_type} — параметры, которые будут подставлены, поэтому используйте их везде, где нужно.

Требуемая структура и содержимое ответа (строго):
- Краткое резюме стратегии (1–3 предложения): цель отслеживания и ключевые требования проекта.
- Обязательный набор метаданных для логирования, разбитый на три раздела:
  1. Гиперпараметры — точные имена ключей, типы значений, примеры; отметьте какие гиперпараметры обязательны для {model_type}.
  2. Метрики — полные имена, типы (скаляр/вектор), частота логирования (эпоха/итерация), какие метрики мониторить по умолчанию для {model_type}.
  3. Артефакты — что сохранять (модели, чекпоинты, конфиги, токенизаторы, визуализации), формат файлов, рекомендации по хранению и подписи версий.
- Рекомендуемые соглашения об именовании экспериментов и тегирования:
  - Один–два шаблона на разные случаи (быстрая проверка / продукционная тренировка), форматы строк (например: project/model_dataset-hparamHash-YYYYMMDD-UID), допустимые символы и максимальная длина.
  - Стандарт набора тегов (project, owner, env, git_commit, data_version, run_type, seed).
- Базовый шаблон кода для логирования (Python). Требования:
  - Покажите минимально работоспособный пример использования API {tracking_tool} для логирования гиперпараметров, метрик и артефактов.
  - Включите создание/инициализацию эксперимента, явное указание run_id, как логировать промежуточные и финальные метрики, как сохранять чекпоинт и регистрировать артефакт.
  - Код должен быть нейтральным и совместимым с общепринятым стилем {tracking_tool} (используйте официальное API).
  - Поясните, какие места в коде нужно заменить на специфичные для проекта значения.
- Конкретные примеры отслеживания моделей {framework} на данных типа {dataset_type}:
  - Два практических мини-примера (короткий код ~20–40 строк каждый):
    1. Быстрая локальная тренировка (debug/run) с маленьким подмножеством данных и минимальным логированием.
    2. Полная тренировка с чекпоинтами, валидацией и сохранением артефактов.
  - Для каждого примера приведите:
    - Какие гиперпараметры и метрики логируются.
    - Примеры записей/строк, которые окажутся в {tracking_tool} (пример JSON или key:value).
- Рекомендованная структура репозитория и схемы хранения артефактов/логов (корневая структура папок, примеры путей к артефактам).
- Контроль воспроизводимости и best practices (минимальный чеклист):
  - git_commit, data_version (как фиксировать), seed, окружение (requirements.txt / conda / docker image и как логировать), конфиги (yaml/json), доступы и секреты.
- Короткий пошаговый план внедрения (3–6 шагов) и проверки корректности настроек (smoke tests), а также критерии успешного приёма (acceptance criteria).
- Краткие рекомендации по политике хранения и ретенции (какие артефакты держать долго, какие удалять/архивировать), и по безопасности (кратко: токены, PII).
- Все примеры и шаблоны должны быть на Python. Не требуются инструкции по развёртыванию сервера или CI, кроме упоминаний о логах/артефактах в CI при необходимости.

Ограничения и формат вывода:
- Используйте прямые примеры вызовов API {tracking_tool} (без псевдосинтаксиса), если существует официальная Python-библиотека; если API сильно зависит от версии — отметьте это в одну строку.
- Не добавляйте общую (непрактичную) теорию; фокусируйтесь на конкретных инструкциях и коде.
- Дайте готовые к копированию фрагменты кода; используйте placeholders для путей/имен переменных, которые должен заменить инженер.
- Ответ должен быть структурирован в читаемые разделы (заголовки/буллеты) и не длиннее ~900–1500 слов (исключая код), чтобы быть пригодным для быстрого внедрения.
- Не задавайте уточняющих вопросов — используйте предоставленные параметры.