12 возможностей QA и управления релизами, которые должна поставлять любая платформа кастомных LLM

Заметки из цикла релизов — часть III

Год назад, прежде чем начать строить собственный конвейер релизов, мы сели и перечислили все возможности QA и управления релизами, которые, по нашему мнению, должна поставлять серьёзная платформа LLM. Затем мы оценили двенадцать других платформ по этому списку — LangSmith, MLflow, Weights & Biases, Braintrust, Humanloop, Patronus, Arize, Phoenix, Confident, Deepchecks, SageMaker Deployment Guardrails, KServe, BentoCloud, Vertex AI Endpoints, Seldon Core. Ни у кого не оказалось всех двенадцати. Те комбинации, которые были реализованы, группировались в три лагеря, которые не соприкасались друг с другом.

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

Три лагеря (чтобы вы понимали, на что смотрите)

Перед самим контрольным списком — форма рынка в 2026 году:

• Лагерь Eval-CI — Braintrust, Humanloop, Patronus. Запускают автоматические оценщики при слиянии PR. Блокируют плохие слияния. Никогда не касаются живого трафика. Сильны в возможностях 4–6; отсутствуют в 7–12.
• Лагерь канареечного развёртывания — SageMaker Deployment Guardrails, KServe, Vertex AI Endpoints, BentoCloud, Seldon Core. Делят трафик, отслеживают инфраструктурные метрики, делают автооткат по тревогам в стиле CloudWatch. Сильны в 1, 7, 9; отсутствуют на стороне качества в 8 и 10–12.
• Лагерь наблюдаемости — Arize Phoenix, Confident AI, Deepchecks. Наблюдают за продакшеном, оповещают людей, эскалируют. Сильны в 10 (мониторинг), но они ничего не принуждают к исполнению — оповещение не есть автооткат.

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

Недостающий шов: гейт качества по срезам → атомарный откат, управляемый качеством вывода, а не инфра-метриками.

Этап ① — Register

Возможность 1. Неизменяемый манифест релиза с контентно-адресуемым SHA

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

Почему это важно: без этого «какое изменение сломало продакшен?» не имеет ответа, когда состояние разнесено по трём системам. Сбой Atlassian в апреле 2022 года^[1] занял по двенадцать часов на сайт именно потому, что состояние жило в независимо версионируемых системах, которые приходилось обратно приводить к согласию.

Кто поставляет: лагерь канареечного развёртывания — частично (модель + маршрутизация); реестры моделей (MLflow, W&B Models^[2]) — частично (только артефакт модели). Почти никто не упаковывает шаблон промпта в SHA, а это именно то поле, которое меняется чаще всего.

Возможность 2. Атомарный контроль версий по всем компонентам релиза

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

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

Кто поставляет: никто полностью. Лагерь канареечного развёртывания атомарно переключает образ модели; промпт и маршрутизация обычно живут где-то ещё. Переключение, управляемое манифестом, — это то, откуда происходит заявление Divinci об атомарном откате^[5].

Возможность 3. Паритет окружений обучения и обслуживания

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

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

Кто поставляет: фреймворки контейнеризации (BentoML, KServe) получают частичный зачёт за то, что располагают препроцессинг рядом с обслуживанием. Никто из них не привязывает препроцессинг к входу гейта оценки.

Этап ② — Gate

Возможность 4. Гейт качества по срезу / по домену

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

Почему это важно: агрегированные оценки размывают локализованные регрессии. Разбор Semver Lie у Tianpan^[3] называет это доминирующим режимом отказа релиза LLM в 2026 году: модель, улучшающаяся в среднем, но при этом тихо проседающая на одном классе пользовательских сценариев.

Кто поставляет: никто другой в 2026 году. Инструменты Eval-CI — Braintrust, Humanloop, Patronus — оценивают относительно единой глобальной рубрики или плоского списка задач. Они не предоставляют ни порога по срезу, ни обхода без учёта среза. Это первое место, где лагеря не пересекаются.

Возможность 5. Калиброванный судья с привязкой к человеку (Спирмен ρ к человеческим оценкам)

Что это: судья — не обобщённый LLM-as-judge. Это LLM-судья, чей Спирмен ρ относительно панели доменных экспертов измерен и сконфигурирован по каждому срезу. Судья выбирается потому, что его ранги совпадают с человеческими, а не потому, что у него сильная репутация.

Почему это важно: MT-Bench^[6] показывает, что GPT-4-в-роли-судьи согласуется с людьми >80% в целом, с дисперсией по категориям от программирования (86%) до письма (36–44%). «Общее согласие» скрывает срезы, где судья ненадёжен. Калибровка судьи по срезам — единственный честный способ сделать автоматизированное оценивание заслуживающим доверия.

Кто поставляет: Braintrust, Humanloop, Patronus запускают оценщики-судьи. Никто из них не требует, не показывает и не сохраняет калибровку Спирмена с привязкой к человеку по каждому срезу. Конвейер калибровки Divinci задокументирован в Калибровка ИИ-судьи.

Возможность 6. Путь обхода с обязательным письменным обоснованием

Что это: принудительный обход отказа гейта разрешён (холодный старт, принятые регрессии и т. п.), но требует двух полей — forceGateOverride: true И overrideReason: "...". Причина попадает в журнал аудита рядом с идентификатором пользователя. Никаких анонимных обходов.

Почему это важно: гейты управления — это не отдельная фича комплаенса; это свойство самого этапа гейта. Журнал аудита должен отвечать не только на «использовался ли обход?», но и на «каково было обоснование на тот момент?» — потому что будущему вам придётся это прочитать.

Кто поставляет: у инструментов Eval-CI есть флаги; никто из них не требует обоснования как структурной части обхода.

Этап ③ — Roll

Возможность 7. Многоконтрольная канарейка с выдержкой

Что это: трафик движется от 0% до продакшена через как минимум три контрольные точки — обычно 5% → 25% → 100% — и удерживается на каждой либо заданное время выдержки, либо заданное число запросов, в зависимости от того, что позже. Никаких мгновенных 0%→100%.

Почему это важно: баги длинного хвоста проявляются на масштабе. Баг, затрагивающий 0,3% диалогов, невидим на оценке из 100 промптов и очевиден при 5% продакшен-трафика. Выдержка — это то, что даёт канарейке время увидеть длинный хвост.

Кто поставляет: лагерь канареечного развёртывания поставляет это. AWS SageMaker Deployment Guardrails^[4] документирует значение по умолчанию TerminationWaitInSeconds 600 (десять минут). KServe, BentoCloud, Seldon и Vertex — все предоставляют похожие конфигурации многошаговой канарейки. Это насыщенная возможность.

Возможность 8. Монитор качества вывода в каждой контрольной точке канарейки

Что это: на каждой контрольной точке конвейер проверяет три монитора перед продвижением — p95 латентности, частоту 5xx и оценку качества вывода, вычисленную тем же калиброванным судьёй из возможности 5. Латентности и 5xx по отдельности недостаточно.

Почему это важно: вот где лагеря снова не сходятся. SageMaker, KServe, Vertex, BentoCloud, Seldon — все следят за латентностью и частотой ошибок. Никто из них не поставляет монитор качества вывода по контрольным точкам — потому что у них нет калиброванного судьи, относительно которого оценивать. У инструментов Eval-CI есть судья, но они не сидят на трафике.

Кто поставляет: никто не завершает этот мост. Инфраструктура канарейки с выдержкой существует в лагере обслуживания; калиброванный судья существует в лагере Eval-CI; мы не видели, чтобы кто-то их соединял.

Возможность 9. Автоматическая остановка при нарушении качества

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

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

Кто поставляет: лагерь канареечного развёртывания останавливается по инфраструктурным метрикам. Остановка по метрике качества — это часть, для которой требуется наличие возможности 8.

Этап ④ — Observe

Возможность 10. Непрерывное воспроизведение продакшен-трасс через кандидата

Что это: после того как канарейка продвинута до 100%, наблюдатель продолжает работу. Он сэмплирует свежие продакшен-трассы, воспроизводит их через кандидат (теперь активный) релиз, оценивает их калиброванным судьёй и выдаёт поминутную оценку качества. Непрерывно, а не периодически.

Почему это важно: тихие просадки качества — модель хеджирует, уверенно галлюцинирует дату, отказывается там, где не должна, — никогда не двигают латентность или 5xx. Единственный сигнал, который вы получаете для них, — клиентский тикет, а это худший из возможных сигналов. Непрерывный монитор качества ловит их за минуты однозначных чисел.

Кто поставляет: никто. Лагерь наблюдаемости (Arize, Phoenix, Confident, Deepchecks^[7]) мониторит продакшен-выход, но не принуждает к исполнению. Лагерь канареечного развёртывания смотрит на инфраструктуру. Лагерь Eval-CI не сидит на трафике. Замкнутая петля — продакшен-трассы → калиброванный судья → принуждение — это и есть недостающий шов.

Возможность 11. Атомарный откат за секунды, а не минуты

Что это: когда наблюдатель срабатывает (скажем, три последовательные минуты ниже порога), откат запускается автоматически. Откат перенаправляет маршрутизацию на previous_release из манифеста. Поскольку предыдущий релиз был полностью упакованным манифестом, все компоненты переключаются атомарно. От начала до конца, включая дренаж запросов в полёте на сервисе из ~100 реплик: около 12 секунд^[5].

Почему это важно: сбой Cloudflare в июне 2022 года^[8] потребовал 44 минут на возврат. Причина была не в самом возврате — она была в том, что инженеры перекрывали откаты друг друга, потому что состояние было разнесено. Откат, управляемый манифестом, — это одна инструкция; у него не может быть такого режима отказа.

Кто поставляет: лагерь канареечного развёртывания поставляет быстрый инфраструктурный откат (по тревоге, blue-green-переключение). Архитектурное отличие в том, является ли триггер только инфраструктурным или учитывает качество (возможность 10).

Возможность 12. Квитанция комплаенса с хэш-цепочкой, привязываемая извне

Что это: каждое решение релиза — register, gate-pass, gate-fail, gate-override, checkpoint-promote, auto-rollback — выдаёт JSON-квитанцию с SHA-256, сцепленную хэшем с предыдущей квитанцией для этого клиента и предыдущей квитанцией для этого релиза. Цепочка привязывается извне по расписанию, которое настраивает клиент.

Оговорка про открытые веса. Когда релиз основан на модели с открытыми весами (Gemma, Qwen, Llama, Mistral, GPT-OSS), квитанция встраивает vindex-аттестацию весов — доказательство того, что активные веса на момент решения — это те веса, которые зарегистрировал манифест. Когда релиз основан на закрытой API-модели (OpenAI, Anthropic, Google через непрозрачные API), квитанция покрывает цепочку решений, но не может претендовать на провенанс весов, потому что поставщик не выставляет веса наружу. Квитанция явно это говорит. Это предел того, что верифицируемо.

Почему это важно: регулируемые отрасли сегодня получают логи. EU AI Act и NIST AI RMF^[9] всё чаще требуют доказательств. Квитанция с хэш-цепочкой — это разница между «у нас есть лог» и «аудитор может проверить цепочку, не доверяя нашему логу».

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

12 возможностей по лагерям платформ

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

Чем QA для кастомных языковых моделей отличается от QA для ПО?

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

• Нельзя писать ассерты expect(output).toEqual(X). Нужна оценка с учётом распределений, которая потребляет ранговую корреляцию относительно человеко-привязанного оценщика, а не равенство относительно фикстуры. Это и есть возможность 5.
• Модель может пройти агрегированную проверку качества, проваливая её на срезе. Поэтому возможность 4 существует отдельно. Если ваша оценка не умеет резать по срезам, она не сможет ловить регрессии по срезам.
• Сбои качества тихи на уровне инфраструктуры. Латентность и 5xx остаются чистыми, пока модель хеджирует или галлюцинирует. Возможности 8 и 10 существуют потому, что никакой инфраструктурный монитор этого не видит.
• Откат необязателен только на словах. Поскольку режимы отказов вероятностны и часть из них тиха, путь отката должен быть основной инфраструктурой, а не запасным планом. Возможность 11 — это то, что делает «12 секунд» достижимыми; возможность 2 — то, что делает их корректными.

Платформа QA и релизов, которая не учитывает эти четыре факта, поставляет детерминированное программное CI/CD с приклеенным сверху логотипом LLM. Рынок делает это часто.

Как журналы аудита поддерживают комплаенс ИИ на практике?

Самый распространённый пробел в комплаенсе, который мы видим, — когда аудитор приходит через шесть месяцев после развёртывания и спрашивает «какая версия модели работала 15 марта и кто одобрил этот релиз?» — это не «у нас нет логов». Это «у нас есть логи в пяти системах, и таймлайны не сходятся».

Квитанция комплаенса (возможность 12) решает это, делая сам журнал переносимым артефактом: с хэш-цепочкой, единым источником, привязываемым извне. Аудитор может проверить цепочку, не доверяя нашей инфраструктуре. Это разница между «у нас есть записи» и «записи доказуемы».

Для основ на моделях с открытыми весами квитанция также включает аттестацию весов — криптографическое доказательство того, что активные веса — это веса, которые зарегистрировал манифест. Это удовлетворяет более жёстким требованиям (право на стирание по статье 17 GDPR, провенанс EU AI Act), потому что вы можете доказать не только то, что было развёрнуто, но и что лежащие в основе веса именно те, за которые они выдаются.

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

Что этот контрольный список не решает

Три честных ограничения:

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

Конкурентный снимок относится к 2026 году и будет сдвигаться. Через полгода часть отметок ✗ выше поменяется — конкуренты прочитают постмортемы и закроют пробелы. Если вы читаете этот пост в 2027 году, проверьте отметки сами, прежде чем им верить.

Некоторые возможности зависят от других. Возможность 8 (монитор качества вывода канарейки) требует возможности 5 (калиброванного судьи). Возможность 10 (замкнутое воспроизведение трасс) требует обеих. Платформа, поставляющая 8 без 5, поставляет плацебо — монитор канарейки существует, но не привязан ни к чему заслуживающему доверия.

FAQ

Какая возможность QA важнее всего для релизов кастомных LLM?

Гейт качества по срезам (возможность 4) — то есть решение релиза потребляет оценки Спирмена по доменам относительно человеко-привязанного оценщика, а не одну глобальную агрегацию. Агрегированные оценки размывают локализованные регрессии, а локализованные регрессии — доминирующий режим отказа релиза LLM в 2026 году^[3]. Если вы можете поставить только одну возможность из этого списка, поставляйте 4. Затем поставляйте 5, что и делает 4 заслуживающей доверия.

Как оценить платформу QA для LLM, не запуская её шесть месяцев?

Примените 12-возможностный контрольный список выше к документации вендора с двумя конкретными тестами. Во-первых, попросите вендора показать вам посрезовый вывод гейта для одного из их референсных клиентов — если у них есть только агрегированные оценки, у них нет возможности 4. Во-вторых, спросите, что запускает их автооткат, — если ответ «латентность, частота ошибок и наши тревоги», они в лагере канареечного развёртывания, и возможность 10 отсутствует.

В чём разница между инструментами Eval-CI и инструментами управления релизами?

Инструменты Eval-CI (Braintrust, Humanloop, Patronus) запускают автоматические оценщики при слиянии PR и блокируют плохие слияния. Они никогда не касаются живого трафика. Инструменты управления релизами (эта категория) владеют манифестом релиза, канарейкой, наблюдателем и путём отката. Eval-CI — это часть рабочего процесса управления релизами, но не его замена. Многие команды поставляют что-то одно из двух и обнаруживают пробел, когда регрессия, прошедшая CI, тихо попадает в продакшен.

Насколько быстрым должен быть откат?

Порядок секунд, а не минут. Среднее время отката в конвейере Divinci — около 12 секунд; это дренаж запросов в полёте на сервисе из ~100 реплик, а не сам переключение манифеста, которое субсекундное. Сравните с инцидентом Cloudflare в июне 2022 года^[8], где возврат занял 44 минуты, потому что состояние было разнесено по системам. Архитектурное решение, делающее «секунды-а-не-минуты» возможным, — это упакованный манифест релиза (возможности 1 и 2).

Почему квитанции комплаенса важнее логов комплаенса?

Лог — это то, что вы написали. Квитанция — это то, что аудитор может проверить, не доверяя вам. EU AI Act и NIST AI RMF^[9] всё чаще различают эти две вещи — «задокументировано» не то же самое, что «доказуемо», и регуляторное направление движется ко второму. Квитанция с хэш-цепочкой, привязанная извне, — самая простая доступная технология для пересечения этой линии.

References

1. Atlassian PIR April 2022. Post-Incident Review: April 2022 Outage. "The accelerated Restoration 2 approach took approximately 12 hours to restore a site." Cited for capability 1 — what state-spread-across-systems looks like at scale.
2. W&B Models / MLflow registry. Weights & Biases Registry and MLflow Model Registry. The model-artifact-only side of capability 1. Neither ships prompt-template registration.
3. The Semver Lie. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026). Names the slice-aware regression failure mode as the dominant 2026 pattern. Companion: LLM postmortem template — fields SRE missed. Anchor for capability 4.
4. SageMaker Deployment Guardrails. Use canary traffic shifting and Auto-Rollback Configuration. Default TerminationWaitInSeconds of 600 (ten minutes), maximum 1800 (thirty minutes). The standard infrastructure-metric canary the post contrasts against on capabilities 8 and 10.
5. Internal — atomic routing-flip via release manifest. The ~12-second rollback time is in-flight drain on a ~100-replica service; the manifest swap itself is sub-second. Number is from our own service, not a benchmark. The architecture that makes it possible is the bundled manifest from capability 1.
6. LLM-as-judge per-category variance. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% overall GPT-4-vs-human agreement, with per-category variance from coding (86%) to writing (36–44%). Anchor for capability 5 — why a calibrated judge has to be per-slice.
7. Observability camp comparison. Arize Phoenix, Confident AI's 2026 observability tools comparison. All ship monitoring and alerting; none enforce rollback. Anchor for capability 10's "monitor without enforcement" framing.
8. Cloudflare June 2022 outage. Cloudflare outage on June 21, 2022. "06:58: Root cause found and understood. Work begins to revert the problematic change… 07:42: The last of the reverts has been completed." 44 minutes from "we know what to revert" to revert complete, in part because engineers walked over each other's reverts. Anchor for capability 11.
9. NIST AI Risk Management Framework. NIST AI RMF. Governance, mapping, measurement, management — the four core functions that capability 12 maps onto. Plus the EU AI Act provenance requirements at artificialintelligenceact.eu. Anchor for capability 12.

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