Сергей Нотевский
Оценка качества
English version

Контроль качества ИИ

Процесс выкатки, который предотвращает незаметные регрессии модели, промпта и агента.

Прикладной уровень
v0.1
Обновлено 23 мая 2026 г.
Руководители ИИ-платформ
Staff-инженеры
Продуктовые инженеры
проверка-качества
quality-gate
regression
rollout
Хранится только в этом браузере.

Проблема

"Модель вроде отвечает хорошо" - это не процесс качества.

Симптомы

  • Изменения модели выкатываются без датасетов сценария.
  • Правки промпта не проходят регрессионные тесты.
  • Оценки LLM-as-a-judge есть, но провалам никто не доверяет.
  • Обратная связь из production не обновляет датасет.

Ментальная модель

Контроль качества перед релизом - это не одна оценка. Это цикл, который не даёт платформе деградировать незаметно.

Архитектура

Датасет -> набор проверок -> таксономия ошибок -> изменение промпта или модели -> регрессия -> канареечная выкатка -> обратная связь из production -> обновление датасета.

Evals в миграции self-hosted

При миграции сценария проверки качества не заменяют первичный discovery. Сначала команда находит модель, на которой сценарий вообще может работать. Потом платформа поднимает черновую self-hosted версию и проверяет, что успех воспроизводим локально. Только после этого проверки качества становятся release gate: сравнение качества, задержки, стоимости и регрессий против текущего маршрута.

Иначе команда рискует покупать или арендовать GPU ради curiosity, а не ради доказанного fit сценария.

Метрики

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

Компромиссы

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

Меньшая модель требует больше инженерии

При переходе с frontier MaaS-модели на open-source или self-hosted модель инференс может дешеветь, но доводка сценария часто дорожает. Часть работы, которую раньше тянула большая модель, переезжает в промпт, контекст, валидацию, обработку результата и проверки качества.

Что обычно приходится усиливать:

  • промпт-инженерию;
  • контекст-инженерию;
  • упрощение сценария;
  • обработку результата;
  • валидацию;
  • подбор модели и квантизации;
  • датасеты для проверки качества;
  • иногда дообучение.

Главный риск

Экономия на модели часто превращается в работу команды.

Long-context и router evals

Для длинного контекста проверяйте не только retrieval, но и reasoning в шуме: конфликтующие фрагменты, устаревшие версии, distractors, несколько релевантных документов и необходимость синтеза.

Для Semantic Router качество - это не только качество ответа. Это ещё и правильность выбранного пути: direct_small не должен отвечать там, где нужен агент, а agentic не должен запускаться для простого rewrite или summary.

Router eval metrics

direct

false_direct_rate

Router выбрал слишком простой путь.

agentic

false_agentic_rate

Router зря запустил агентный цикл.

cost

cost_saved_without_quality_loss

Экономия без деградации качества.

Анти-паттерны

  • Эталонные датасеты, которые никогда не получают реальные провалы из production.
  • Одна агрегированная оценка, скрывающая критичные категории.
  • Judge-промпты без версионирования.
  • Канареечная выкатка без критериев остановки.

Чеклист

  • Датасет сценария существует и имеет владельцев.
  • Критичные провалы отделены от косметических проблем.
  • Версии промпта, модели и judge отслеживаются.
  • Канареечная выкатка имеет критерии остановки и путь отката.
  • Перед self-hosted миграцией есть baseline качества на текущем маршруте.
  • Черновой локальный candidate сравнивается с baseline до canary.
  • Semantic Router проверен на false_direct и false_agentic.
  • Long-context сценарии проверены на distractors, conflicting facts и устаревший контекст.
  • Обратная связь из production обновляет датасет.

Пример

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

Шаблон решения

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

Связанные главы

On this page