Как собрать надёжный CI/CD-пайплайн для проекта с генеративным ИИ

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

Я расскажу, как мы строили CI/CD именно для такого проекта: LLM-бэкенд с частым обновлением моделей и промптов, где регресс мог проявиться не в падении тестов, а в том, что модель начала галлюцинировать факты, менять стиль ответов или неадекватно реагировать на новые домены. Плюс затрону, что делать, когда публичных данных для оценки качества мало, а тестировать надо.

Чем пайплайн для ИИ отличается от обычного

Классический CI/CD понятный: собрал код, прогнал юнит-тесты, прогнал интеграционные, проверил линтеры, деплоишь. С генеративным ИИ добавляется несколько слоёв сложности:

• Выход не детерминирован. Один и тот же запрос может дать разный текст. Нельзя просто сравнить строку с эталоном.
• Качество субъективно. Пользователь решает, хороший ответ или нет. При этом «хорошо» зависит от задачи: фактология для справочного сервиса, тон для поддержки, формальная корректность для юридического бота.
• Много моделей и вариаций. Часто одновременно живут несколько моделей: тяжёлая для продакшена, лёгкая для тестов, отдельные версии под домены или клиентов.
• Активное использование промптов. Промпт — это часть логики, и менять его приходится почти так же часто, как код.
• Ограниченные данные для оценки. Набор кейсов для тестирования небольшой, быстро устаревает, и его постоянно нужно дополнять.

Из-за этого в пайплайне появляются три вещи, которых обычно нет:

• тесты на качество ответов модели на фиксированных примерах;
• автоматическая оценка по метрикам, включая деградацию на старых кейсах;
• обязательный этап ручного ревью для критичных актуализаций промптов или при смене модели.

Как обычно устроен пайплайн

На высоком уровне пайплайн состоит из нескольких шагов:

1. Build: собрали образ, зависимости, прогрели модель, если кэшируете.
2. Тесты: юнит-тесты, интеграционные тесты на API, минимальные смоук-тесты на модель.
3. Quality-gate: автоматическая проверка качества ответов модели на тестовом наборе кейсов.
4. Канриевый деплой: выкатываем на изолированную среду, гоняем дополнительные проверки.
5. Продакшен: финальный деплой, с автоматическим откатом по метрикам качеств.

Что обязательно включить в пайплайн

1. Версионирование всего, что влияет на результат

Промпты, описания моделей, наборы тестовых примеров, конфиги параметров генерации (temperature, top_p и т. п.) — всё это должно жёстко версионироваться.

Если ты просто меняешь промпт в базе или параметры через UI, через день не вспомнишь, что привело к ухудшению качества, и что откатывать. Удобно, когда:

• промпт хранится в репозитории рядом с кодом;
• тестовые примеры — в отдельном файле с историей изменений;
• сборка связывает конкретный коммит промпта и конкретную версию модели.

2. Чёткий набор критичных кейсов

Для ИИ минимум — иметь фиксированный «золотой набор» запросов и эталонных ответов (или критериев качества). Он не заменит полноценный QA, но защитит от совсем грубых багов.

Такой набор стоит разбить на группы:

• Фактология: вопросы, где ответ объективно правильный/неправильный.
• Поведение на отказ: что модель делает, когда не знает ответа.
• Критичные сценарии: то, что напрямую бьёт по пользователю (конфиденциальность, токсичность, безопасность).
• Типовые пользовательские сценарии: самые частые задачи.

Важно: этот набор должен обновляться, иначе через месяц модель начнёт «дрейфовать», а тесты этого не заметят.

3. Уровни проверок

Хорошо показывает себя трёхуровневая проверка:

• Быстрые смоук-тесты: проверка, что API вообще отвечает и возвращает корректный формат.
• Автоматическая оценка по метрикам: запускаем модель на фиксированных примерах, считаем качество и сравниваем с предыдущей версией.
• Человеческий ревью: проверка части ответов людьми, особенно после смены модели или серьёзной переработки промптов.

4. Отслеживание деградации

Качество ИИ-продукта умеет портиться незаметно: сегодня чуть хуже отвечает на русском с опечатками, завтра начала путать термины. Поэтому важно хранить историю метрик и настраивать алерты по их просадке.

Под это удобно завести отдельный «метрик-стор»: каждая сборка сохраняет свои результаты, и при новом релизе мы видим:

• упали ли объективные метрики (например, точность, фактология);
• ухудшились ли показатели на старых кейсах;
• изменился ли тон или длина ответов.

Что автоматизировать, а что оставить на людях

Этап	Что можно автоматизировать	Что лучше делать вручную
Сборка и деплой	Сборка образов, прогрев моделей, деплой в staging и prod	Решение о выкатке в prod после серьёзных изменений модели/промпта
Проверки качества	Метрики на фиксированных кейсах, проверка на отказоустойчивость и безопасность	Проверка крайних случаев, субъективное качество ответов на сложных запросах
Обновление тестовой базы	Автоматический сбор новых запросов из продакшена (по согласованию с командой)	Валидация того, что новые примеры действительно осмысленные и покрывают важные сценарии
Анализ инцидентов	Поиск последних изменений по метрикам, автоматический откат, если сильное падение качества	Принятие решения об откате при «размытом» ухудшении без конкретного виновника

Как сделать пайплайн устойчивым к типичным проблемам

Если говорить не в целом, а про конкретные узкие места, то есть несколько вещей, которые сильно спасают на практике.

1. Не держать всё в голове

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

2. Закладывать время на обновление тестовой базы

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

3. Использовать канареечный деплой

Особенно важно, когда у вас:

• высокий трафик и ошибка в промпте/модели сразу бьёт по многим пользователям;
• много доменов или сценариев, и единого «эталона» качества нет.

Канареный деплой позволяет выкатить кандидата на 5–10% трафика и сначала посмотреть на метрики качества, а не полагаться исключительно на тестовый стенд.

4. Не смешивать типы тестов

Если у вас один стенд и для тестов качества модели, и для нагрузочного тестирования, и для ручного ревью — быстро начнётся ад. Лучше разделить:

• «быстрый» стенд для метрик, связанных с качеством;
• стенд для нагрузочного тестирования;
• стенд для демонстраций и ручной проверки дизайнерам/аналитикам/Product Owner’ам.

Частые ошибки при проектировании пайплайна

Если ты собираешь пайплайн впервые, очень легко скатиться в крайности: либо закомитьсяся в перфекционизм и никогда не выкатить изменения, либо сделать всё «на коленке» и потом ловить проблемы в продакшене. Важно держаться золотой середины.

Вот самые частые промахи, которые я видел:

• Отсутствие фиксированной тестовой базы.
  Только субъективные проверки типа «ну вроде нормально» и разовые демо-сессии.
• Игнорирование деградации на старых кейсах.
  Модель научилась хорошо отвечать на новые вопросы, но разучилась на старых сценариях.
• Проверка только фактологии.
  Кажется, что фактология — самое важное, и про тон, безопасность и поведение на отказах забывают, хотя они могут влиять на опыт пользователей ничуть не меньше.
• Запуск проверок качества только локально.
  Команда тестирует у себя, а на CI проверки вообще не запускаются.
• Замена метрик на самоощущение.
  Вроде показалось, что модель работает хорошо, хотя по метрикам качество на грани деградации.

Как подступиться, если бюджет ограничен

Если у вас небольшой проект и вы не можете сразу построить сложную систему с тяжёлыми метриками, начните с минимума, но делайте его честно.

Минимальный, но осмысленный пайплайн:

1. Фиксируете 10–20 критичных пользовательских запросов. Этого достаточно, чтобы увидеть грубую деградацию.
2. Собираете их в простую таблицу: запрос, ожидаемый результат, критерии ошибки (факты, стиль, безопасность), частота возникновения у пользователей.
3. Прогоняете их на каждую сборку и хотя бы глазами проверяете, не пропали ли ключевые пункты в ответе, не появилась ли откровенная чушь или токсичность.
4. Закладываете квартальный пересмотр этого набора и добавляете новые примеры по мере развития продукта.

Такой пайплайн не защитит от всего, но даёт ощущение, что вы контролируете ситуацию, а не просто надеетесь на удачу.

Когда имеет смысл внедрять серьёзные инструменты тестирования ИИ

Если вы замечаетешь хотя бы один из этих признаков, стоит задуматься о более формализованном инструментарии и, возможно, привлечь специализированные фреймворки для оценки генеративных моделей:

• более 20% глюков качества ловится уже после выкатки;
• пользователи жалуются на «дрейф» стиля или фактологии;
• у вас десятки и сотни тестовых сценариев, удерживать их в голове и в локальных скриптах уже не получается;
• вы активно экспериментируете с промптами и моделями, и изменения влияют на метрики продукта сильнее, чем хотелось бы.

Что выбрать под свою ситуацию

Не существует одного идеального пайплайна. Всё зависит от масштаба, зрелости команды и критичности продукта. Если совсем коротко:

• У вас MVP и мало ресурсов:
  Возьмите фиксированный набор кейсов, простую проверку качества на каждую сборку и human review для ключевых изменений.
• Сервис растёт и пользователи уже замечают изменения:
  Добавьте метрики деградации, канареечный деплой и систему алертов.
• Продукт уже крупный и критичный:
  Внедряйте полноценную платформу для оценки, A/B-тестов, мониторинга дрифта и быстрого отката.

Итог

Надёжный CI/CD-пайплайн для генеративного ИИ — это не про «настроить GitHub Actions по гайду». Это про то, чтобы закрыть три главных риска:

• сломать качество уже существующих сценариев;
• скатиться в неконтролируемый дрифт модели;
• разучиться объяснять пользователю, почему модель вела себя не так, как раньше.

Если вы:

1. версионируете всё, что влияет на результат;
2. держите фиксированный, но постоянно обновляемый набор кейсов;
3. сочетаете автоматические метрики с человеческим ревью;

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

Хороший первый шаг — не писать сразу десятки плагинов и сложных дашбордов, а выбрать 5–10 самых критичных запросов, прогонять их при каждой сборке и сделать обязательным ревью ответов кем-то из команды. Это простое действие уже сильно снижает риски и даёт возможность постепенно наращивать пайплайн дальше.