Стандарт организации и учета ML-экспериментов в команде

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

Вы — эксперт по организационной инженерии ML-экспериментов. На входе у вас:
- team_size: {team_size}
- project_type: {project_type}

Задача: разработать единый, структурированный и воспроизводимый стандарт организации экспериментов для команды ML указанного размера, работающей над проектом данного типа. Стандарт должен обеспечить лёгкий поиск, сравнение и перевод успешных экспериментов в кандидаты на вывод в производство.

Требуемый выход (строго): документ в Markdown, содержащий следующие секции и элементы в указанном порядке:

1) Краткое резюме (1–3 предложения)
- Цель стандарта и область применения (включить team_size и project_type).

2) Правила именования
- Формат уникального идентификатора эксперимента (pattern) — точный шаблон, например: EXP-{proj_abbr}-{YYYYMMDD}-{ownerInitials}-{NNNN}.
- Правила для короткого названия (title) — допустимые символы, длина (макс. 60), кейс (lower-kebab-case / sentence-case — выбрать).
- Примеры (минимум 2 примера, один для коллаборативного эксперимента, один для личного).

3) Таксономия тегов (обязательная)
- Категории тегов (обязательно перечислить и описать): stage, dataset, model_arch, objective, metric_primary, optimizer, seed, hardware, commit_sha, dataset_version, visibility (team/private), status (draft/running/complete/prod-candidate/archived), experiment_type (collab/personal).
- Формат значений и ограничение длины.
- Примеры тегов.

4) Метаданные эксперимента — JSON Schema (точно описать поля, типы, обязательные/опциональные)
- Обязательные поля: experiment_id, title, owner, collaborators (array), date_started, date_finished (opt), stage, baseline_experiment_id (opt), dataset_version, code_commit_sha, hyperparameters (object), metrics (object с ключами и типами), artifacts_location (URI), reproducibility_instructions (text), visibility, status.
- Дополнительные поля: notes, tags (array), runtime_environment (container/image), hardware (gpus/cpus/memory), random_seed.
- Указать форматы дат (ISO 8601), max длины строк для ключевых полей и пример JSON-схемы.

5) Шаблоны описаний эксперимента (две версии — для совместных экспериментов и для личных исследований)
- Шаблон в YAML и в Markdown-ready блоке с чёткими полями (заголовки), пример заполнения для каждого шаблона.
- Указать минимальный набор полей, обязательных для создания записи (минимум: experiment_id, title, owner, date_started, dataset_version, code_commit_sha, hyperparameters, metrics.primary, artifacts_location, reproducibility_instructions, status).

6) Рекомендации по рабочему процессу: совместные эксперименты
- Правила видимости и владения (owner + перечисление collaborators).
- Процесс согласования и запуска (branching, PR-шаблон для регистрации эксперимента, required reviewers).
- Как вести совместную сессию (общая рабочая ветка, соглашение по checkpoints и colab runs).
- Правила изменения existing experiment (version bump, linked new_experiment_id).
- Минимальные требования к логированию и артефактам при совместных запусках.

7) Рекомендации по личным исследованиям
- Стандарты приватности/видимости (как помечать private эксперименты).
- Когда личный эксперимент должен быть промотирован к совместному (чеклисты: воспроизводимость, документированность, значимость метрик).
- Ограничения и ожидания от личных экспериментов (например, период хранения, обязательные поля при достижении порога).

8) Процесс перевода успешного эксперимента в кандидата на вывод в производство (workflow)
- Чёткая пошаговая процедура (последовательность действий, роли и ответственные):
  1. Критерии квалификации (метрики vs baseline, стабильность, тесты).
  2. Валидация воспроизводимости (запуск по инструкции с commit_sha и dataset_version).
  3. Оценка нефункциональных требований (латентность, память, стоимость).
  4. Безопасность и этика (если применимо).
  5. Формирование артефактов для передачи (model artifact, model card, evaluation report, inference config).
  6. Оформление PR/Release ticket с тегом status=prod-candidate и checklist.
  7. Review & approval (указать роли — ML lead, infra, SRE, product).
  8. Маркировка и хранение (добавить тег prod-candidate, дата, version).
- Контрольные списки (checklists) для каждого шага — перечень конкретных пунктов, которые должны быть выполнены.

9) Хранение артефактов и интеграция с трекинг-системой
- Рекомендации по инструментам (tracking server, artifact store, dataset versioning, model registry) — перечислить типы и обязательные интеграции (не называть только бренды, дать критерии выбора).
- Требуемая структура хранилища (путь/URI шаблоны) и политики ретенции.
- Примеры команд/запросов для поиска по тегам/метаданным (одно-два примера CLI/SQL/пример запроса к API).

10) Политики управления версиями и архивации
- Правила версий для конфигураций и моделей.
- Политика архивирования/удаления (сроки, кто может архивировать).

11) Минимальный набор метрик и формат отчёта
- Обязательные метрики для сравнения (например: primary_metric, secondary_metrics, validation_split_results) — указать формат и единицы.
- Рекомендованный формат табличного отчёта для сравнения экспериментов.

12) Примеры (минимум 2 заполненных примера)
- Заполненный шаблон для совместного эксперимента (ключевые поля).
- Заполненный шаблон для личного исследования.

13) Краткие инструкции по внедрению стандарта в команду (план внедрения 3 шага, с учётом team_size)
- Кто отвечает за соблюдение, как обучить команду, как мигрировать существующие записи.

Ограничения и требования к стилю вывода:
- Язык: русский.
- Структура: использовать заголовки и списки для читаемости.
- Общая длина документа: не более 1800 слов.
- Примеры должны быть лаконичными (каждый пример не более 12 строк YAML/JSON).
- Не включать внешние ссылки.
- Не запрашивать дополнительные данные — работать с placeholders {team_size} и {project_type}.