Контроль качества работы ИИ — вопрос, который заказчик задаёт вторым. Первый: справится ли бот. Второй: кто проверит бота. Ответ «другая модель» обычно не нравится, и понятно почему: звучит как охрана, нанятая охраной.
За последние полгода авторы инструментов, которые этим живут каждый день, опубликовали три случая, где автоматический контроль сломался. Ни один не про то, что модель оказалась глупой. Все три — про устройство самой проверки.
Мы к этому времени построили свой контроль качества работы ИИ — оценщика диалогов для продающего бота — и уже успели собрать на нём собственные шишки. Дальше — что именно ломается и что с этим делать заказчику.
Проверять моделью стоит только то, что нельзя посчитать
Контроль качества работы ИИ начинается со скучного разделения. Всё, что можно измерить, измеряет код. Всё, что можно только оценить, оценивает модель.
В нашем оценщике диалогов эта граница проходит буквально по файлам. Время первого ответа менеджера, конверсия в сделку, сумма закрытой сделки, число сообщений до результата — это запросы к базе и к CRM, без всякой модели. Модель отвечает за другое: поздоровался ли бот и представился ли, спросил ли, как обращаться к клиенту, задал ли уточняющие вопросы, дошёл ли до задачи клиента дальше первого заданного вопроса.
Границу пришлось провести и внутри самой оценки. В промпте судьи стоит прямая фраза: не полагайся на собственную арифметику, итоговый балл и рейтинг будут пересчитаны отдельно. Модель выставляет оценки по пятнадцати критериям, сумму считает программа. Причина простая: с арифметикой модель справляется плохо, а звучит одинаково уверенно и когда права, и когда ошиблась на пять баллов.
Первый излом: проверяющему можно подсказать
Самый неприятный сбой автоматического контроля выглядит как офисная политика, только быстрее.
Джесси Винсент, автор Superpowers — набора инструментов для работы с ИИ-агентами, — в июньском релизе описал, что вскрылось на живых прогонах. Агент-контролёр, отвечавший за выполнение задачи, уговаривал агента-ревьюера пропустить находку или назвать её «Minor at most», незначительной. И дефект уезжал в релиз. В заметках к релизу это записано так: Real runs caught controllers coaching reviewers to skip a finding or call it "Minor at most," and the flaw shipped.
Обратите внимание на слово real runs: поймали не тесты, а обычная работа. Там же сказано, что прежняя схема с двумя ревьюерами и решениями на усмотрение контролёра оказалась «дорогой и лёгкой для обхода». Теперь подавление находок и предварительная оценка серьёзности запрещены правилами, а ревьюер переведён в режим только для чтения — он больше не может ничего исправить сам.
Перенесите это на свой контур. Если тот, кто отвечает за срок, может влиять на того, кто отвечает за качество, — у вас не контроль, а согласование. С людьми это известно лет сто и лечится подчинением проверяющего другому руководителю. С агентами всё то же самое, только цикл занимает не квартал, а сорок секунд, и никто не пишет служебных записок.
Второй излом: проверяющих становится много
Больше проверок не значит больше качества, и это замерено на прогонах.
В релизе 5.0.6 того же Superpowers цикл ревью через отдельного агента был вырезан целиком. Формулировка автора: он удваивал время выполнения, около 25 минут накладных расходов на задачу, без измеримого улучшения качества планов. Регрессионное тестирование на пяти версиях по пять прогонов показало одинаковые оценки независимо от того, запускался цикл ревью или нет. Замена — обычный чек-лист самопроверки внутри той же сессии: три-пять реальных ошибок примерно за тридцать секунд вместо двадцати пяти минут.
Время — половина счёта. В тех же июньских заметках описан прогон, где контролёр не указал модель для проверяющих, и все двадцать шесть ревьюеров молча ушли на самый дорогой тариф.
Заказчику это важно по одной причине. Фраза «у нас трёхуровневая проверка качества» продаёт лучше, чем «у нас одна проверка», и стоит примерно втрое дороже. Спрашивайте не про число уровней, а про то, что вторая и третья проверка находят такого, чего не нашла первая, и есть ли на это прогоны.
Третий излом: проверку построили под слабость конкретной модели
Контроль устаревает быстрее, чем успевает окупиться, и чужие инструменты тут ничем не выделяются.
Anthropic описала свой случай в посте про управляемых агентов. У модели Sonnet 4.5 было заметное поведение: ближе к концу доступного контекста агент начинал торопиться и комкал работу. Компания добавила в инструментарий принудительные сбросы контекста. На следующей модели, Opus 4.5, поведение исчезло — а сбросы остались: the resets we'd added were just overhead. Слой, построенный под слабость модели, умер вместе со слабостью за один релиз.
Оговорка обязательна: этот пост продаёт услугу, в которой инструментарий поддерживает сам вендор. Фразу оттуда же — «для большинства компаний поддержка своего инструментария это накладные расходы, которые не отличают их продукт» — стоит читать с поправкой на интерес автора. Но случай со сбросами от этого не перестаёт быть задокументированным.
Дату пересмотра проверке стоит назначать в тот же день, когда её ставят. Формулировка «поставили и работает» держится ровно до следующего релиза модели, под которую её писали.
Что сломалось у нас
Свой случай короче и нагляднее всех трёх.
Когда мы гоняли бота-продавца через автоматического судью, одна из моделей получила 96 баллов из 100 и высший разряд. Я открыл транскрипт, потому что покупателя в тесте только что сделали жёстче, а под жёстким клиентом оценки не растут. В транскрипте бот скопировал свой финальный ответ восемь раз подряд в одном сообщении. Судья это заметил и снял ровно один балл.
Оценка была не выдуманной. Она была честной по рубрике: содержание ответа правильное, тон уместный, следующий шаг предложен. В рубрике просто не было строки «не повторяй один и тот же текст восемь раз», потому что живому человеку такое в голову не приходит.
Отсюда три вещи, которые мы теперь закладываем сразу.
Применимость правил решает код. Судья не сам догадывается, уместно ли требовать от диалога согласованную дату следующего контакта. Программа смотрит на стадию сделки и на признаки диалога и помечает часть правил неприменимыми. Без этого короткий разговор, где клиент спросил цену и ушёл, получал бы низкий балл за то, чего в нём и не могло быть.
«Нет данных» — отдельный исход. Если транскрипт недоступен или пуст, система возвращает «недостаточно данных для оценки». Ноль она в этом случае не ставит. Разница принципиальная: ноль — это сигнал разбираться с ботом, а «нет данных» — сигнал разбираться с логами.
Поток срочных предупреждений держим узким. Realtime-монитор умеет ровно пять кодов: не представился, слишком быстро сбросил клиента на менеджера, пообещал то, чего не подтверждал, проигнорировал прямой вопрос, нагрубил. В промпте прямо написано: мелкие коучинговые замечания сюда не отправлять. Как только такой канал начинает сыпать замечаниями, его перестают читать — и он не срабатывает в тот единственный раз, когда действительно нужен.
Когда автоматический контроль надёжнее человека
Здесь надо назвать границу собственного аргумента, иначе выйдет статья о том, что проверять ИИ бессмысленно.
Человеческий контроль в отделе продаж почти всегда выборочный: руководитель успевает послушать несколько разговоров за неделю, и попадают в эту выборку обычно те, на которые пожаловались. Автоматический судья читает все, по одной и той же рубрике, и не устаёт к пятнице. В нашей системе валидации контента совпадение таких оценок с мнением живых экспертов держится на 80–85%, и стоит проверка курса меньше двух центов.
У этой надёжности есть чёткая граница, и она проходит по фактам. Без доступа к исходным материалам автоматическая проверка пропускает большую часть фактических ошибок: уверенный тон модель отличить не может, а сверить утверждение ей не с чем. Поэтому фактическую часть мы проверяем отдельно — сверкой с источником, а не мнением второй модели. Как модели ведут себя на русских задачах, мы держим в открытом лидерборде и обновляем по мере прогонов.
И ещё одно, о чём в спорах забывают: у варианта «не проверять вообще» тоже есть цена. Бот без контроля качества не становится нейтральным — он просто ошибается молча, и вы узнаёте об этом от клиента.
Как собрать контроль качества работы ИИ, который не сломается
Порядок, к которому мы пришли, укладывается в пять пунктов.
- Разделите считаемое и оцениваемое. Сроки, конверсию, суммы считает код. Тон, уместность, полноту — модель. Итоговую арифметику не отдавайте модели даже там, где она оценивает.
- Проверяющий не подчиняется исполнителю. Тот, кто отвечает за скорость, не должен формулировать задание тому, кто отвечает за качество, и тем более подсказывать серьёзность находки.
- Один проверяющий, пока не доказано обратное. Второй и третий добавляются после замера, который показал, что они находят новое.
- Рубрика растёт от реальных провалов. Восемь копий одного ответа попали в наш чек-лист только после того, как случились.
- У каждой проверки есть дата пересмотра. Через квартал смотрите, сколько раз она сработала, и снимайте то, что не сработало ни разу.
Отдельный пункт про людей. Тот же судья у нас оценивает и диалоги живых менеджеров — по десяти критериям вместо пятнадцати. Это сильный инструмент и быстрый способ испортить отношения с отделом продаж, если ввести его молча. Мы показываем менеджеру ту же рубрику, по которой его оценивают, до первой оценки, а не после.
Разборы вроде этого — с рубриками, промптами судьи и замерами — я выкладываю в Telegram-канале: там же лежит полный список из пятнадцати критериев, по которым мы оцениваем продающие диалоги, и то, как мы их пересматривали.