Золотой путь ML: почему регистрация модели идёт после quality gate

Пайплайн модели в ViVA состоит из семи стадий: validate → train → quality gate → register → build → deploy → promote. Проект подключает один CI-компонент — и получает их все. Но интереснее не список стадий, а несколько решений, которые определяют, как платформа ведёт себя в сложных ситуациях.

Регистрация — после gate, а не до

Во многих командах версия модели попадает в реестр сразу после обучения, а «прошла ли она проверку» — отдельный тег или статус. Через полгода реестр превращается в свалку, из которой невозможно понять, что вообще можно выкатывать.

В ViVA версия регистрируется в MLflow только после quality gate. Это простое правило даёт сильное свойство: любая версия в реестре — по построению та, что прошла проверку. Реестр остаётся источником правды, а не архивом экспериментов.

Сравнение с живым чемпионом

Фиксированный порог качества — ловушка. Если минимально допустимая метрика равна 0,80, а каждый релиз чуть хуже предыдущего, но всё ещё выше 0,80, качество медленно уходит вниз — по одному «приемлемому» релизу за раз.

Quality gate ViVA сравнивает кандидата с моделью, которая сейчас обслуживает трафик — с алиасом @champion в реестре. Параметр regression_tolerance задаёт, насколько кандидат может быть хуже; 0 означает «никогда не хуже». Порог metric_threshold тоже работает — как дополнительное, а не единственное условие.

include:
  - component: $CI_SERVER_FQDN/viva/deploy/ml-path@0.1.0
    inputs:
      model_name: churn-scoring
      primary_metric: f1
      metric_threshold: 0.80
      regression_tolerance: 0
      # кластеры обучения, staging и прода с их адресами подставляет шаблон «Новая ML-модель»
      train_target: viva-dev
      staging_target: viva-dev
      prod_targets: [viva-prod]

Джобы выполняются там, куда деплоят

Обучение и деплой запускаются раннером с Kubernetes-executor внутри кластера платформы, помеченного именем кластера. Секреты — ключи к хранилищу датасетов, доступ к MLflow, токен GitOps — джоба получает из Vault этого кластера по OIDC-токену GitLab. Статических секретов в переменных проекта нет, а раннер с доступом к проду не живёт на общем хосте.

Деплой — это коммит

CI никогда не вызывает kubectl. Стадия deploy записывает желаемое состояние — версию модели, образ, долю canary-трафика — в values.yaml GitOps-репозитория и открывает merge request. Argo CD согласует кластер с репозиторием. On-prem и облако отличаются только целевым каталогом, поэтому гибридная схема остаётся управляемой.

Staging и canary мержатся автоматически. Единственный ручной шаг — promote, который переносит алиас @champion. Всё до него обратимо; этот шаг и есть определение «в проде».

Откат — копия файла

gitops-sync сохраняет рядом с values.yaml его предыдущую версию — values.previous.yaml. Стадия rollback просто восстанавливает её. Никакой археологии по истории git в три часа ночи.

Что это даёт команде

• Версия модели помечена тегами git.sha, ci.pipeline и data.version — всегда понятно, на каком коде и данных обучен чемпион.
• Модель не зашивается в serving-образ: образ собирается один раз на runtime, модель приезжает из реестра.
• Контракт проекта (точка входа, схема, model card, аннотации каталога) проверяется на стадии validate — до первой GPU-минуты.

Если хотите увидеть золотой путь на своих моделях — запросите демо.