10 сбоев релизов CI/CD в кастомных языковых моделях — и какая стадия конвейера ловит каждый из них

Заметки из релиз-цикла — Часть II

Первый пост этой серии прошёл по четырёхэтапному релизному конвейеру, который мы выпускаем — Register → Gate → Roll → Observe. Этот пост — расписки: десять конкретных режимов отказа, которые мы теперь ловим этим конвейером, как каждый из них выглядел на практике и какая стадия конвейера остановила его до того, как он добрался до продакшна.

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

Конвейер, который ловит все десять, — это не список фич. Это небольшое число архитектурных решений, принятых последовательно. Каждый сбой ниже называет, какое решение к нему относится.

Как читать этот список

Каждый сбой помечен стадией, которая его ловит:

• ① REGISTER — слой манифеста. Останавливает сбои, в которых нельзя было сказать, какое изменение сломало продакшн, потому что состояние было размазано по системам.
• ② GATE — покатегорийный Spearman против калиброванного по человеку судьи. Останавливает сбои, которые прячутся внутри агрегированных оценок.
• ③ ROLL — canary с шагами 5% → 25% → 100% и монитором качества на каждой контрольной точке. Останавливает сбои, которые проявляются только на масштабе.
• ④ OBSERVE — непрерывный replay трасс через кандидата, оценённый тем же судьёй гейта. Останавливает тихие просадки качества, которые латентность и 5xx никогда не замечают.

Каждый раздел заканчивается фиксом — точная конфигурация, которую мы выпускаем в Divinci, плюс что собирать самим, если вы не используете нас.

Стадия ① — Register

1. Совместная выкатка модели + промпта + маршрутизации одним пакетом и неспособность понять, что именно сломало релиз

Что случилось. Мы поменяли три вещи в одном релизе: подняли базовую модель с Gemma 4 E2B до Gemma 4 26B-A4B, отредактировали system-промпт правового домена, добавив инструкцию «процитируй статут», и подкрутили правило маршрутизации, которое решает, какой класс трафика попадает на какую модель. Точность на составлении договоров упала на 7 пунктов. Ни одно из трёх изменений не тестировалось независимо. Чтобы это отладить, пришлось откатывать по одной переменной за раз в течение двух дней.

Почему конвейер теперь это ловит. Релиз Divinci — это неизменяемый манифест, объединяющий model_ref, prompt_template_ref, маршрутизацию и dataset_version в один артефакт, адресуемый по SHA-256. Конвейер отказывается деплоить манифест, в котором собрано больше одного изменения, если только SHA предыдущего релиза не указан как опорная база сравнения. Если вы хотите выкатить три изменения разом, вы должны явно подтвердить это в манифесте, и путь атрибуции отказа остаётся чистым, потому что следующий релиз вынужденно возвращается к режиму одной переменной за раз.

Фикс. Не позволяйте людям собирать релизы руками. Релизный манифест должен генерироваться конвейером, который не способен собрать пакет тихо. См. Стадия 1 — Register — там API.

2. Правка system-промпта в дашборде и его выкатка без код-ревью

Что случилось. Кто-то подкрутил system-промпт в админ-UI, чтобы «сделать модель менее многословной». Это выглядело как правка на одно слово. Получившийся промпт стал на 38 символов короче, что опустило его ниже порога длины, который downstream-переписыватель промпта использовал, чтобы решать, добавлять ли safety-шаблон. Через два часа модель отвечала на вопросы, на которые должна была отказывать.

Почему конвейер теперь это ловит. Промпты — часть зарегистрированного манифеста. Правка одного из них в дашборде означает выпуск нового манифеста, что означает генерацию нового SHA, что означает, что гейт прогонится против изменения. Промпты в дашборде по-прежнему можно править. Просто их нельзя выкатывать, минуя гейт.

Фикс. Относитесь к промптам как к коду: версионируйте их по контент-хешу, регистрируйте как часть релиза, гейтите по scored-QA-набору. Разбор Тяньпаня «The Semver Lie»^[1] описывает ровно этот режим отказа в дикой природе — изменение промпта, которое «прошло код-ревью, выкатилось без eval-гейтов, попало в продакшн без покозырьного A/B и не вызвало никакого автоматического отката».

3. Расхождение препроцессинга между обучением и обслуживанием

Что случилось. Обучающий конвейер нормализовал пробелы и приводил к нижнему регистру одно конкретное поле. Серверный конвейер — нет. Та же модель, тот же промпт, та же маршрутизация — на уровне байтов входы разные. На dev-фикстурах всё проходило. На реальном трафике модель вела себя так, словно её переобучили на более шумных данных, — с её точки зрения её действительно переобучили.

Почему конвейер теперь это ловит. Манифест регистрирует preprocessing_ref рядом с model_ref. Оценка гейта прогоняется через тот же препроцессинг, что использует продакшн-стек обслуживания. Если они расходятся, офлайновые цифры гейта перестают соответствовать продакшну, и покатегорийный Spearman падает измеримым образом ещё до промоушена.

Фикс. Заверните препроцессинг в версионированный артефакт. Сошлитесь на него из манифеста. Откажитесь от деплоя, если гейт считался против версии препроцессинга, отличной от той, что будет в продакшне.

Стадия ② — Gate

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

4. Обвал на лицензировании ИС (регрессия с учётом срезов №1)

Что случилось. QLoRA-файнтюн улучшил точность на правовом Q&A в пяти поддоменах и обвалил лицензирование ИС — составление договоров 0,71, толкование законов 0,74, краткое изложение дел 0,69, регуляторный комплаенс 0,66, юрисдикционный анализ 0,62, лицензирование ИС 0,41. Агрегированный Spearman ρ по всем шести составил 0,64. Порог гейта — 0,65. По единственному агрегированному баллу релиз был на волосок ниже черты. По покатегорийному разрезу один поддомен обвалился на 27 пунктов.

Почему конвейер теперь это ловит. Порог гейта — покатегорийный, а не агрегатный. Любой отдельный срез, опустившийся ниже своего порога, помечает релиз gate_fail независимо от того, как выглядит среднее. Диаграмма порогов гейта в посте №1 — это реальная визуализация, которую конвейер строит для релизов вроде этого.

Фикс. Разрежьте гейт по срезам. Важные срезы — поддомены вашего клиентского сегмента, а не любая таксономия из импортированного eval-фреймворка.

5. Регрессия среза педиатрической онкологии (регрессия с учётом срезов №2)

Что случилось. Медицинскую Q&A-модель дообучили на дополнительных данных по кардиологии для взрослых. Агрегированная медицинская точность выросла на 4 пункта. Точность на педиатрической онкологии упала на 11 пунктов — судя по всему, новые обучающие данные тонко де-приоритизировали корректировку педиатрических дозировок. Агрегатный гейт промоутил бы релиз.

Почему конвейер теперь это ловит. Педиатрическая онкология была одним из срезов, сконфигурированных клиентом при регистрации scored-QA-набора. Оценка Gate-2 дала покатегорийный Spearman ρ, упавший с 0,72 до 0,61, ниже порога педиатрической онкологии 0,68. Помечено как gate_fail. Без деплоя.

Фикс. Срезы определяет клиент, а не платформа. Платформа должна позволять клиенту добавлять срез и покатегорийный порог без написания кода — потому что никто в Divinci не знает границы клиентского домена так, как сам клиент.

6. Дрейф многоязычного подъязыка (регрессия с учётом срезов №3)

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

Почему конвейер теперь это ловит. Локальные варианты — это под-срезы языкового среза. Spearman по под-срезу поймал регрессию на бельгийском варианте до промоушена. Релиз был возвращён либо за (а) более разнообразными обучающими данными, либо (б) под force-override с письменным обоснованием («мы принимаем региональную регрессию, потому что агрегированное улучшение по французскому важнее в этом раскате») — и override уходит в аудит-трейл.

Фикс. Глубина срезов имеет значение. «Французский» — слишком крупно. «Бельгийский французский» — тот уровень, на котором регрессии реально прячутся.

7. Обход гейта без письменного обоснования override

Что случилось. Окно релиза под давлением. Гейт упал по одному срезу — некритичному, по суждению команды. Кто-то потянулся к флагу force-override. В более ранней версии конвейера force-override был одним булевым значением. Флаг переключился, релиз выпустили, и через три недели уже никто не мог восстановить, кто и что решил по поводу какого среза.

Почему конвейер теперь это ловит. Force-override — это двухполевой гейт: forceGateOverride: true И overrideReason: "...". Причина — обязательная свободная строка, записанная в аудит-лог рядом с user ID и результатом покатегорийного гейта, который был перекрыт. Конвейер отказывает в override без причины. Override по-прежнему возможен — просто нельзя выполнить его анонимно.

Фикс. Governance-гейты — не отдельная стадия. Это свойство стадии гейта: каждый override — это подписанная расписка с текстом обоснования.

Стадия ③ — Roll

8. Переход с 0% на 100% трафика за один шаг

Что случилось. Модель чисто прошла гейт. Её сразу выкатили на 100% трафика. На особенности длины разговора новая модель отдавала таймаут на ответах длиннее ~2400 токенов — поведение, которое не всплыло на eval-наборе гейта из 100 вопросов, потому что каждый тестовый промпт был коротким. 15% пользователей получали таймаут в течение 18 минут, прежде чем кто-то откатил релиз вручную.

Почему конвейер теперь это ловит. Стадия Roll удерживает на 5% в течение dwell_5pct_seconds (по умолчанию 240) ИЛИ requests_5pct (по умолчанию 1000), что наступит позже. На 5% трафика таймауты на длинных разговорах всплывают в мониторе 5xx-rate в течение ~3 минут. Конвейер отказывается выходить за 5%, если любой контрольный монитор пробивает свою полосу. Среднее время до halt — 4 минуты; среднее время до полного отката — около 12 секунд после halt.

Фикс. Canary в три шага с quality-монитором, а не только латентность и 5xx. Паттерн «пять процентов за двадцать секунд и готово» — опасный. Паттерн «пять процентов на четыре минуты» — безопасный.

Стадия ④ — Observe

Два сбоя ниже — те, что canary на инфраструктурных метриках промоутил бы. Причина, по которой инфраструктурные метрики их пропускают, тоже структурная — латентность и 5xx могут оставаться идеально чистыми, пока модель тихо хеджирует, отказывается или галлюцинирует.

9. Тихое хеджирование на правовых запросах (тихая просадка качества №1)

Что случилось. Обновление модели с safety-тюнингом сделало ассистента в правовом домене заметно консервативнее. Та же латентность, та же доля 5xx, то же потребление токенов. Но там, где предыдущая версия отвечала «срок исковой давности — X лет», новая версия говорила «вам стоит обратиться к адвокату». Клиенты заметили за часы. Дашборды не сдвинулись.

Почему конвейер теперь это ловит. Наблюдатель Стадии 4 непрерывно реплеит продакшн-трассы через активную модель и оценивает их тем же калиброванным судьёй, который питал Gate-2. Хеджирование всплывает сразу, потому что калиброванный судья — заякоренный на человеческих рейтингах того, как выглядит «хороший» правовой ответ, — штрафует отказ-когда-ожидался-ответ. Монитор output-quality упал ниже своей полосы на три минуты подряд, и конвейер автоматически откатился. Общее время: менее пяти минут.

Фикс. Не мониторьте только латентность и 5xx. Мониторьте quality-оценку, полученную от калиброванного судьи против реальных продакшн-трасс. Deployment guardrails SageMaker^[2] авто-откатываются по алармам CloudWatch — полезно для инфраструктуры, но аларм должен сработать на какой-то метрике, а «модель хеджирует» — не метрика, которую видит CloudWatch.

10. Галлюцинированные даты после файнтюна (тихая просадка качества №2)

Что случилось. Файнтюн ассистента-планировщика начал уверенно вставлять даты, которых не было во входе. «Ваша встреча в четверг 32 марта». Латентность не изменилась. Доля 5xx не изменилась. Галлюцинации прошли safety-фильтр, потому что ничто не пометило «32 марта» как вредное — просто невозможное.

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

Фикс. Судья, откалиброванный по доменной экспертизе. Универсальный LLM-as-judge пропустит «четверг 32 марта» ровно так же, как человек, скользящий взглядом, его пропустит. Домен-калиброванные судьи — заякоренные на рейтингах доменных экспертов — не пропустят.

10 сбоев, наложенных на конвейер

Столбцы, окрашенные в красный, — это сбои, которые мы находили по ходу выпуска этого конвейера; именно из-за них мы в итоге целенаправленно строили гейт с учётом срезов и наблюдатель по replay трасс, а не выпускали типовой canary на инфра-метриках, как все остальные.

Чем CI/CD для LLM отличается от CI/CD для софта?

Коротко: релиз LLM — не детерминированный артефакт. Один и тот же промпт даёт разные выходы между запусками. Один и тот же eval-набор даёт разные оценки между железками. Одна и та же модель может пройти агрегированную проверку качества, тихо проваливая срез, который вы не включили в eval. Большинство допущений, на которых строился традиционный CI/CD, не выживают при контакте с вероятностной системой.

Три конкретных следствия:

1. Нельзя писать утверждения вида expect(output).toEqual(X). Нужна оценка, осознающая распределение, потребляющая ранговую корреляцию против заякоренного на человеке оценщика, а не равенство против фикстуры.
2. Модель, «прошедшая CI», может выкатить сломанное поведение. Прохождение CI означает, что код работает. Это не означает, что модель права. Релизный конвейер должен навязывать quality-гейт поверх correctness-гейта, который даёт CI.
3. Откат не опциональный и не медленный. Поскольку режимы отказа вероятностные — и поскольку некоторые из них тихие на уровне инфраструктуры, — путь отката должен быть первичной инфраструктурой, а не запасным планом. Релизный манифест существует именно для того, чтобы откат был атомарным.

Первый пост этой серии описывает четырёхэтапную архитектуру, которая отвечает на эти следствия. Этот пост описывает сбои, которые она ловит.

Как построить устойчивый к сбоям CI/CD-конвейер для кастомных LM?

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

Если вы не используете Divinci и хотите собрать что-то эквивалентное, несущие элементы такие:

• Неизменяемый релизный манифест, объединяющий модель + промпт + маршрутизацию + датасет + препроцессинг в один SHA. Это то, что делает 1, 2 и 3 ловимыми. (Стадия 1)
• Покатегорийный гейт с порогами, которые задают владельцы доменов, а не платформа. Это то, что делает 4, 5, 6 ловимыми. (Стадия 2)
• Canary с мониторингом качества на каждой контрольной точке, а не только латентностью и 5xx. Это то, что делает 8 ловимым и что делает 9 и 10 переживаемыми, как только они попадут в продакшн. (Стадия 3)
• Непрерывный наблюдатель, который оценивает реальные продакшн-трассы через активную модель тем же калиброванным судьёй, который питал гейт. Это то, что делает 9 и 10 ловимыми. (Стадия 4)
• Подписанная аудит-расписка по каждому решению. Хеш-связанная, внешне якорьируемая. Для моделей с открытыми весами расписка встраивает vindex-аттестацию весов, доказывающую, что активные веса — те самые, что зарегистрировал манифест. Для бэкендов с закрытым API расписка покрывает цепочку решений, но не может претендовать на провенанс весов — и аудит-трейл это явно говорит.

Сами по себе элементы не новы. У каждой MLOps-платформы есть один-два из них. Комбинация — гейт с учётом срезов + наблюдатель по продакшн-трассам + атомарный откат + проверяемая расписка — это то, что в 2026 году не выпускает никто другой.

Куда дальше

• Парный пост — Как построить CI/CD-конвейер для LLM с Divinci AI — покрывает архитектуру и API.
• Страница compliance документирует формат vindex-расписки, которая стоит за каждым релизным решением, и как она ложится на EU AI Act, GDPR Article 17, HIPAA и NIST AI RMF.
• Страница продукта AutoRAG покрывает снижение галлюцинаций на стороне RAG, которое естественно сочетается с калиброванным судьёй, питающим Gate-2 и наблюдатель Стадии 4.
• Справочник API — каждая команда, упомянутая в этой серии, — реальный endpoint.

FAQ

Какой самый частый сбой CI/CD для кастомных языковых моделей?

По всем релизам, которые мы выпустили, самый разрушительный одиночный сбой — это регрессия с учётом срезов, которая проходит агрегированный гейт: модель, которая улучшается в среднем, тихо обваливаясь на конкретном поддомене (сбои 4, 5 и 6 выше). Это случается чаще, чем отсутствующий откат, чаще, чем дрейф промпта, и обнаружить это сложнее, чем оба. Фикс структурный, а не подбор параметров: гейтите по срезу, а не по среднему.

Насколько быстро нужно уметь откатывать плохой релиз LLM?

На порядок — секунды, а не минуты. Среднее время отката на конвейере Divinci — около 12 секунд; это слив запросов в полёте на сервисе с ~100 репликами, а не сам своп манифеста, который занимает меньше секунды. Архитектурное решение, делающее это возможным, — собранный релизный манифест: поскольку каждый компонент (веса, промпт, маршрутизация, датасет) ссылается из одного SHA, откат — это один атомарный re-point. Сравните с публичными постмортемами: инцидент Cloudflare в июне 2022^[3] занял 44 минуты на откат, потому что инженеры наступали друг другу на откаты; авария Atlassian в апреле 2022^[4] занимала 12 часов на сайт, потому что состояние было размазано по нескольким системам.

Почему изменения промпта вызывают столько продакшн-аварий?

Потому что промпты регулярно правятся вне CI/CD-конвейера — в дашбордах, в админ-UI, иногда людьми без инженерного ревью. К ним относятся как к конфигурации, но ведут они себя как код. Правка system-промпта на 38 символов может изменить downstream-поведение модели сильнее, чем переобучение модели. Фикс — регистрировать промпты как часть релизного манифеста и требовать, чтобы они проходили тот же гейт, что и модель.

Как обнаруживать тихую деградацию качества в выходах LLM?

Не инфраструктурными метриками. Латентность, доля 5xx и потребление токенов не поймают хеджирование, отказ-когда-ожидался-ответ или галлюцинированные даты. Сигнал обнаружения должен идти от quality-оценки, вычисляемой калиброванным судьёй против реальных продакшн-трасс. Наблюдатель Стадии 4 в конвейере Divinci реплеит скользящую выборку продакшн-трасс через активную модель, оценивает их тем же заякоренным на человеке Spearman-судьёй, который питал Gate-2, и запускает автоматический откат, когда quality-оценка падает ниже порога на три минуты подряд.

Какие требования к аудит-трейлу применимы к деплою AI-моделей?

EU AI Act, GDPR Article 17 (право на стирание), HIPAA и NIST AI Risk Management Framework — все требуют от организаций вести записи о версиях моделей, результатах оценки, решениях об одобрении и раскатках. Невысказанное требование под всеми четырьмя — записи должны быть проверяемыми: «auditable» означает больше, чем «у нас есть лог». Vindex-расписки Divinci хеш-связаны и внешне якорьируемы, что означает, что аудитор может проверить цепочку, не доверяя нашим логам. Для бэкендов с открытыми весами расписка также встраивает аттестацию весов; для бэкендов с закрытым API расписка явно отмечает, что провенанс весов не заявляется.

Ссылки

1. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026). Прямо называет режим отказа с правкой промпта в дашборде. Парная статья: LLM postmortem template — fields SRE missed.
2. AWS SageMaker — Use canary traffic shifting. Стандартный авто-откат, управляемый инфраструктурными метриками. Полезное сравнение с тем, что делает иначе наблюдатель Стадии 4 (quality-оценка, а не алармы CloudWatch).
3. Cloudflare — Cloudflare outage on June 21, 2022. 44-минутный откат, потому что инженеры наступали друг другу на откаты. Цитируется как якорь «откат — это собственный инцидент».
4. Atlassian — Post-Incident Review: April 2022 Outage. 12 часов на восстановление одного сайта. Режим отказа «состояние размазано по системам» в его худшем виде.
5. DORA — Software delivery performance metrics. Порог «времени восстановления после неудачного деплоя» для элитных перформеров задокументирован как менее одного часа. Полезная рамка для «насколько быстро — достаточно быстро» по откату.
6. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv:2306.05685, 2023). Ссылка на то, почему LLM-as-judge может соответствовать рейтингам людей в целом, но широко варьироваться по категориям — ровно тот паттерн, что делает покатегорийный гейтинг необходимым.

Следующее в серии: Валидация и выпуск кастомных LM в регулируемых областях. Конвейер выше — это архитектура. Compliance-путь — это практика его применения. EU AI Act, GDPR Article 17, HIPAA и NIST AI RMF — что каждый из них требует от релизного процесса и какие поля vindex-расписки покрывают какое требование.