Continuous Integration (CI)

Непрерывная интеграция (CI) — это практика частого объединения изменений каждого разработчика в общую основную ветку, не реже одного раза в день, и автоматической сборки и проверки каждого изменения. Благодаря этому проблемы интеграции выявляются за минуты, а не во время выпуска. Грейди Буч предложил этот термин в 1991 году, Кент Бек сделал его ключевой практикой экстремального программирования в конце 1990-х, а в статье Мартина Фаулера «Непрерывная интеграция» описан рабочий процесс, которому до сих пор следуют большинство команд. В машинном обучении (ML) CI также проверяет данные, код обучения и поведение модели, поскольку изменение может не нарушить ни одного модульного теста, но снизить её точность.

Как работает конвейер CI#

Когда разработчик отправляет ветку или открывает запрос на слияние, служба CI, например GitHub Actions, GitLab CI/CD или Jenkins, запускает новый исполнитель, получает код, устанавливает зависимости и выполняет последовательность заданий конвейера: линтеры и средства проверки типов, модульные и интеграционные тесты, а также сборки пакетов или образов контейнеров. Каждое задание передаёт свой статус в запрос на слияние, а правила защиты ветки могут запретить слияние, пока не пройдут все обязательные проверки. Конвейеры часто повторяют одни и те же тесты для разных операционных систем и версий Python, а после каждого слияния заново запускают весь набор тестов в основной ветке. Скорость — часть этой практики: в экстремальном программировании Бека на сборку всей системы и запуск всех тестов отводилось десять минут, поскольку более медленные сборки запускают реже.

CI для машинного обучения#

В проектах машинного обучения добавляются собственные проверки. Тесты данных подтверждают, что новые обучающие данные соответствуют ожидаемой схеме, все файлы с метками обрабатываются правильно, а одно изображение не попало одновременно в обучающую и валидационную выборки, поскольку это привело бы к утечке данных. Дымовой тест запускает обучение на крошечном наборе данных в течение одной эпохи, чтобы за несколько минут выявить ошибки размерностей и сбои. В тестах, сравнивающих выходы модели, фиксируют случайные начальные значения и допускают небольшие численные погрешности, поскольку GPU-ядра и порядок загрузки данных могут менять результаты вычислений с плавающей точкой при каждом запуске. Контроль качества оценивает модель на фиксированной валидационной выборке и завершает сборку с ошибкой, если метрика, например средняя точность (mAP), опускается ниже порога. Тесты экспорта проверяют, что версии модели для ONNX или TensorRT по-прежнему загружаются и показывают результаты, сопоставимые с исходной моделью. Полное обучение занимает много времени, а исполнители с GPU обходятся дорого. Поэтому команды обычно запускают быстрые проверки при каждом запросе на слияние, а полное переобучение и развёртывание модели оставляют для запланированных запусков или запусков в основной ветке. Инструменты версионирования, например DVC, позволяют каждому заданию получить точную версию набора данных.

Режим бенчмаркинга Ultralytics YOLO работает как такой контрольный этап: если verbose задан числом с плавающей точкой, например 0.216, режим выдаёт ошибку при сбое экспорта или если mAP_50-95 любого экспортированного формата не превышает этот порог. Собственная система CI репозитория Ultralytics использует этот режим для проверки экспорта YOLO26 в Linux, macOS и на исполнителях ARM. Минимальный рабочий процесс GitHub Actions объединяет модульные тесты с таким контрольным этапом:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

При каждом запросе на слияние и каждой отправке изменений в main задание запускается на новом исполнителе Ubuntu. Если модульный тест завершается с ошибкой или модель ONNX показывает результат не выше порога на небольшом наборе данных COCO8, проверка завершится ошибкой до слияния изменений.

CI, CD, MLOps и непрерывное обучение#

• Непрерывная доставка (CD): Берёт сборки, прошедшие CI, и поддерживает их готовность к выпуску, часто автоматически развёртывая их в тестовой среде. Непрерывное развёртывание идёт на шаг дальше и отправляет каждое прошедшее проверку изменение в рабочую среду.
• MLOps: Более широкая дисциплина, объединяющая CI и CD с версионированием данных, развёртыванием моделей, мониторингом и переобучением на протяжении жизненного цикла машинного обучения.
• Непрерывное обучение (CT): Автоматически переобучает и повторно развёртывает модель при поступлении новых данных или обнаружении дрейфа средствами мониторинга. В уровнях зрелости MLOps от Google автоматическое переобучение относится к уровню 1, а автоматизированные CI/CD для самого конвейера обучения — к уровню 2.