Разработка системы контроля качества AI-воркфорса

Контроль качества AI-агентов: где ломается процесс

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

Вторая точка — деградация после обновления модели. Изменение весов, контекста или системной инструкции меняет поведение на краевых сценариях, тогда как базовые ответы выглядят прежними. Без зафиксированных эталонов регресс замечают через недели — по накопленной статистике отказов.

Третья — нет воспроизводимых эталонов, и воспроизводимость ответов агента проверить нечем. Разметка эталонных диалогов фиксирует ожидаемые шаги, допустимые вариации формулировок и критерии отказа: разговор «кажется, стало хуже» превращается в проверяемое сравнение. Контроль качества AI-агентов держится на прогоне таких наборов до выкладки, а не на выборочном просмотре журналов.

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

Как измеряем поведение агентов: метрики и эталонные наборы

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

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

Чек-лист, по которому агент допускается в продукт:

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

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

Сравнение режимов проверки агентов: прогоны, разметка, гибрид

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

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

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

Этапы внедрения: от аудита текущих проверок до передачи

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

1. Аудит текущих проверок. Разбираем, что уже работает: ручные разборы, журналы, метрики, спорные случаи. Считаем, какую долю отклонений ловят сейчас и где автопроверка расходится с решением человека.
2. Схема контроля качества. Определяем метрики и раскладку по ним: автоматические проверки, выборочный ручной разбор, эскалация. Фиксируем пороги и правила остановки прогона, чтобы результат не зависел от настроения дежурного.
3. Настройка прогонов. Собираем эталонные наборы, размечаем пограничные случаи, прогоняем на исторических данных и калибруем пороги. На выходе — воспроизводимый прогон: те же входные данные дают тот же вердикт.
4. Пробный прогон. Запускаем в теневом режиме рядом с текущим контролем и сверяем вердикты. Расхождения разбираем: часть закрываем правкой правил, часть — дообучением на спорных примерах.
5. Приёмка системы. Идём по критериям, согласованным заранее: доля пойманных отклонений, уровень ложных срабатываний, время разбора одного случая.
6. Передача документации. Отдаём регламенты, описания метрик, инструкции для дежурных, порядок обновления эталонных наборов и доступы. Дальше сопровождаем в согласованном режиме, пока команда не выйдет на самостоятельный цикл.

Что остаётся у вас: конфигурации, схемы и регламенты проверок

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

• Конфигурации проверок — где заданы пороги, условия остановки выпуска и правила сравнения версий агента. Меняются в одном месте, применяются ко всем потокам сразу.
• Схемы потоков данных — путь от запроса пользователя до вердикта проверяющего: где сохраняются ответы, где эталон, на каком шаге подключается ручной разбор.
• Регламент разметки — что считать верным ответом, как разрешать спорные случаи и сколько проверяющих смотрит одну выборку. Без него доля согласия между разметчиками падает уже на второй неделе.
• Эталонные наборы — фиксированные примеры с согласованными оценками. На них воспроизводимо сравниваются версии: видно, что улучшилось, а что деградировало.
• Документация по метрикам — как считается каждая величина, откуда берутся данные и какое отклонение считается сработкой, а не шумом.
• Инструкции для команды — что делает проверяющий при расхождении, кто имеет право менять правило и куда записывается исключение.
• Журнал инцидентов и порядок разбора — случаи, когда проверка пропустила ошибку, разбираются и превращаются в новое правило или пример в эталонном наборе.
• Порядок выпуска новой версии — прогон на эталонном наборе, допуск по метрикам, порядок отката на предыдущую конфигурацию.

Новый инженер входит в работу по этим документам, а не по памяти предыдущей команды. Это и есть проверка зрелости: если система проверок нельзя передать, она держится на людях, а не на процессе.

Кейс: доля ошибок агентов до и после регрессионных прогонов

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

Что показали замеры до внедрения

Мы разметили поток обращений по классам и увидели, что больше половины расхождений — одна причина: агент подставлял общий срок возврата, игнорируя категорию товара. Вторая группа — обрыв на уточнении: агент не запрашивал номер заказа и уходил в догадку вместо вопроса. Трассы и срезы метрик собирали в Langfuse, чтобы каждое расхождение можно было разобрать до конкретного шага диалога.

Что изменили и что получилось

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

Доля корректных ответов выросла с 78% до 94%, а класс «неверный срок возврата» ушёл полностью — 0 попаданий на 240 сценариев и 0 в потоке обращений за следующий месяц. Покрытие ветвей диалога довели до полного по разметке, обрыв на уточнении перестал воспроизводиться. Регрессионные прогоны не отменяют ошибки навсегда: новая инструкция может сломать соседний сценарий. Но теперь такой откат виден до выкладки, а не в жалобе клиента.

Чем теневой прогон отличается от регрессионного теста?

Это два разных инструмента проверки, и путать их дорого. Теневой прогон запускает новую версию агента рядом с текущей на живом потоке запросов: ответы не уходят пользователю, но фиксируется, как модель ответила бы в реальной ситуации. Регрессионный тест работает на фиксированном наборе сценариев с заранее известными эталонными ответами.

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

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

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

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

Частые технические сомнения перед стартом работ

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

Доступ к инфраструктуре ограничен, стенд закрыт

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

У нас уже развёрнутый контур — не сломаете?

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

Разметки нет — собирать эталоны с нуля?

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

Обсудим вашу задачу и вернёмся с оценкой и планом

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

Чтобы оценка была по делу, а не «по ощущениям», нужен минимальный набор вводных:

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

Дальше собираем план внедрения: пилот на одном сценарии, замер метрик до и после, расширение по результату. Опишите задачу — вернёмся с оценкой и планом, старт работ назначим в удобном для вас темпе.