Проверить, что правка инструкции не сломала то, что работало, можно единственным способом: прогнать агента по заранее собранному набору контрольных диалогов и сравнить ответы с эталоном. Всё остальное — «мы посмотрели, вроде отвечает нормально» — не проверка, а надежда. Набор из 30 диалогов собирается за 22 часа, прогоняется за полчаса и ловит именно тот класс поломок, который иначе обнаруживает клиент.
Типичная последовательность событий без набора выглядит так. Руководитель поддержки пишет подрядчику в мессенджер: «сделай ответы покороче, клиенты жалуются на простыни». Подрядчик правит одну строку инструкции и выкатывает. Через три дня приходит клиент с вопросом «а почему мне не сказали про предоплату», ещё через неделю выясняется, что агент перестал предлагать передачу оператору по жалобам. Связать это с правкой недельной давности уже трудно: инструкцию с тех пор трогали ещё дважды, и какая именно правка что сломала, никто не скажет.
Ниже — как этот контур выглядит в рабочем виде: где должна лежать действующая редакция инструкции, из чего собирается контрольный набор, в каком порядке выкатывается правка, какие три метрики достаточно снимать и сколько часов в месяц это занимает у компании, в которой нет ни тестировщика, ни промпт-инженера. Все расчёты — модельные, по ставкам: инженер подрядчика 3 000 ₽/час, методист или старший оператор внутри компании 900 ₽/час, руководитель направления 2 000 ₽/час.
Промпт — это код, даже если он написан по-русски
Инструкция агента обладает всеми тремя свойствами кода. Она определяет поведение системы, которая разговаривает с вашими клиентами от лица компании. Она ломается от правок, причём в местах, не связанных с правкой очевидным образом. И к ней иногда нужно вернуться назад — быстро, посреди рабочего дня, не разбираясь в причинах. Из этих трёх свойств следует единственное требование: у инструкции должны быть версии, и предыдущая должна быть под рукой.
На практике версий обычно нет. Инструкция живёт в переписке с подрядчиком, в файле на облачном диске, который правят все, или в поле административной панели, где сохраняется только последнее состояние. Разница между этими вариантами измеряется двумя вещами: можно ли узнать, что именно изменилось, и сколько занимает откат.
| Где лежит действующая редакция | Видно ли, что менялось | Время отката | Чем это кончается |
|---|---|---|---|
| Переписка с подрядчиком в мессенджере | Нет: правки разбросаны по репликам, часть — голосовыми | От часа до суток, если подрядчик на связи | При смене подрядчика инструкция собирается заново с нуля |
| Файл на облачном диске, правят несколько человек | Частично: история есть, но без причин правок | 10–20 минут, если помнить, какая версия работала | Две редакции расходятся, в проде оказывается не та |
| Поле в административной панели без истории | Нет: хранится только текущее состояние | Отката нет — только написать заново по памяти | После неудачной правки восстанавливают формулировки на слух |
| Система версий рядом с кодом агента | Да: что, зачем, кто утвердил, какой прогон прошёл | 1–2 минуты, откат на предыдущий номер | Разбор инцидента занимает 15 минут вместо дня |
Не дата изменения файла, а запись из пяти полей: номер редакции, что изменилось по существу, зачем — со ссылкой на конкретную жалобу или требование, кто утвердил правку, результат прогона контрольного набора и дата выката. Без этих полей номер версии не помогает: вы знаете, что редакций было двенадцать, но не знаете, в какой из них появилась проблема.
Простой и достаточный вариант для компании без своего программиста — держать инструкцию в том же репозитории, где живёт код агента, а править её через подрядчика по короткой форме заявки. Право утверждать правку остаётся у вас, право выкатывать — у инженера, и в любой момент видно, кто и что менял. Что именно должно быть записано в договоре, чтобы доступ к действующей редакции остался у вас при расставании с подрядчиком, разобрано в материале о том, что должно быть в договоре на разработку.
Сравнение в две колонки. Слева «Инструкция в переписке»: строки «Что менялось — неизвестно», «Кто утвердил — неизвестно», «Откат — от часа до суток», «При смене подрядчика — собирается заново». Справа «Инструкция в системе версий»: «Что менялось — запись из пяти полей», «Кто утвердил — фамилия», «Откат — 1–2 минуты», «При смене подрядчика — остаётся у вас». Внизу общая подпись: «Разбор инцидента: день против 15 минут». Чертёжный стиль, подписи по-русски.
Что именно ломается: механика побочного эффекта
Правила внутри инструкции не изолированы друг от друга. Модель получает весь текст одним куском вместе с сообщением клиента и составляет ответ, взвешивая все требования сразу. Поэтому новое правило конкурирует со старыми, а не добавляется к ним. Особенно опасны правки, которые формулируются как общее ограничение: «короче», «мягче», «без лишних деталей», «не повторяйся». Они действуют на все ответы, включая те, где деталь была обязательной.
Модельный пример из практики поддержки оптовой компании: поток 1 500 обращений в месяц, инструкция на полторы страницы, контрольный набор из 30 диалогов, который до правки проходил полностью — 30 из 30. Правка одна: «Отвечай короче, не длиннее трёх предложений». Прогон после правки — 26 из 30. Отвалилось четыре диалога, и ни один из них не про длину ответа.
- 1Заказ с доставкой в регион: агент перестал называть срок доставки, потому что срок был четвёртым предложением ответа. Клиент получает вежливый короткий ответ без единственной цифры, ради которой писал.
- 2Первый заказ нового покупателя: пропала оговорка про предоплату на первую поставку. Правило в инструкции осталось, но не поместилось в три предложения.
- 3Жалоба на брак: агент ответил по существу и не предложил передать диалог оператору. Предложение эскалации всегда стояло последней фразой — она и ушла под нож.
- 4Вопрос про остаток на складе: агент перестал добавлять оговорку «остаток меняется в течение дня, уточните перед отгрузкой». Формально ответ верный, фактически — обещание, которого компания не давала.
Все четыре поломки объединяет одно: сломалось то, что стояло в конце ответа. Это типовая механика — общее ограничение срезает хвост, а в хвосте у большинства инструкций живут оговорки, сроки и эскалация, то есть ровно те элементы, из-за которых потом возникают споры с клиентом. Заметить это без набора невозможно: правку проверяют на том сценарии, ради которого её делали, и там она работает идеально.
Проверка «попросили короче — стало короче» всегда даёт положительный результат и потому не является проверкой. Смысл контрольного набора в том, что в нём есть 29 диалогов, к которым правка не имеет отношения. Если после правки они продолжают проходить — правка безопасна. Если четыре из них перестали — вы узнали об этом за полчаса и бесплатно, а не через неделю и от клиента.
Столбчатая диаграмма из трёх столбцов по шкале от 0 до 30. Столбцы: «До правки — 30 из 30», «После правки „отвечай короче“ — 26 из 30», «После доводки — 30 из 30». У среднего столбца выноска с перечнем отвалившихся сценариев: срок доставки, оговорка про предоплату, предложение оператора, оговорка про остаток. Ось Y подписана «диалогов из набора пройдено», ось X — «редакция инструкции».
Контрольный набор: 30 диалогов и что считать эталоном
Контрольный набор — это список реальных обращений с описанным правильным ответом на каждое. Не идеальный ответ дословно, а перечень того, что в ответе обязано быть, чего в нём быть не должно, и какое действие агент обязан совершить. Дословный эталон не работает: две правильные формулировки одной мысли отличаются словами, и сравнение по тексту даст ложную тревогу на каждом прогоне.
- 1Шаг 1. Выгрузить обращения за квартал
Берём переписку и расшифровки за последние три месяца — в модельном примере это около 4 500 обращений при потоке 1 500 в месяц. Персональные данные из выгрузки убираем сразу: для набора важен вопрос, а не фамилия клиента. Выгрузка обезличивается один раз и дальше живёт как рабочий материал.
- 2Шаг 2. Отобрать 30 штук по трём корзинам
Пятнадцать частотных — то, что спрашивают каждый день, они держат основную нагрузку. Десять рискованных — деньги, сроки, возврат, жалоба, персональные данные: здесь ошибка стоит дороже всего. Пять редких, но дорогих — нестандартные случаи, из-за которых однажды был скандал. Корзины важнее числа: набор из 30 частотных вопросов проверяет один и тот же кусок инструкции тридцать раз.
- 3Шаг 3. Описать эталон к каждому диалогу
Три поля. Обязательные элементы: срок, цена, оговорка, ссылка на документ. Запрещённые элементы: обещание скидки, точная дата без оговорки, упоминание конкурента, любой факт не из базы знаний. Требуемое действие: ответить самому, найти в базе знаний, передать оператору, создать заявку. Эталон пишет тот, кто знает процесс, а не тот, кто пишет промпт.
- 4Шаг 4. Оформить набор в прогоняемый вид
Набор должен запускаться одной командой и выдавать таблицу «диалог — пройден или нет — какой элемент отсутствует». Пока это делается вручную копированием в чат, прогон занимает не 30 минут, а полдня, и после третьей правки его перестают делать. Автоматизация прогона — единственная строка набора, требующая инженера.
Схема из пяти блоков со стрелками слева направо. Первый блок — «Вопрос клиента» с примером «когда приедет заказ в Казань». Второй, третий и четвёртый идут вертикальной колонкой и подписаны «Обязательные элементы: срок доставки, оговорка про остаток», «Запрещённые элементы: точная дата без оговорки, обещание скидки», «Требуемое действие: ответ из базы знаний, без эскалации». От них стрелки в пятый блок — «Вердикт: пройден или не пройден, с указанием отсутствующего элемента». Сбоку пометка: «набор из 30 таких карточек, прогон 30–40 минут».
Почему именно 30. Десять диалогов не покрывают даже частотную часть и создают ложное спокойствие: набор проходит, а поломка живёт в сценарии, который в набор не попал. Двести диалогов собираются полторы недели, а прогон и разбор расхождений после каждой правки съедает день — через месяц набор перестают запускать, и он превращается в мёртвый артефакт. Тридцать — это компромисс: три корзины покрыты, сборка укладывается в три рабочих дня, прогон и разбор помещаются в один вечер. Набор дорастает до 45–60 диалогов сам, по одному новому за каждый разобранный инцидент.
Порядок выката: четыре ступени
Прогон набора отсекает грубые поломки, но не все. Часть проблем видна только на живом потоке: клиенты формулируют вопросы иначе, чем в наборе, и попадают в сценарии, которых в нём нет. Поэтому правка выкатывается ступенями, и на каждой есть условие перехода дальше и условие отката.
- 1Ступень 1. Прогон на контрольном наборе
30–40 минут. Условие перехода — набор пройден полностью или расхождения разобраны и признаны допустимыми осознанно, с записью в версии. Если провалено больше двух диалогов, правка возвращается на переформулировку, а не идёт дальше «с оговоркой».
- 2Ступень 2. Теневой режим, 3–5 дней
Агент получает реальные обращения и формирует ответы, но клиенту их не отправляет — отвечает человек. Ответы агента складываются в журнал, старший оператор просматривает их выборочно, 20–30 штук в день. Это единственная ступень, на которой ошибка вообще ничего не стоит, поэтому её пропускают чаще всего и зря.
- 3Ступень 3. Двадцать процентов трафика, неделя
Новая редакция отвечает каждому пятому обращению, остальные идут на предыдущую. Сравниваются три метрики из следующего раздела на двух потоках сразу — это единственный честный способ увидеть эффект правки, а не сезонное колебание. При потоке 1 500 обращений в месяц двадцать процентов за неделю — это около 75 диалогов, достаточно для грубого сравнения.
- 4Ступень 4. Полный переход
Вся нагрузка на новую редакцию, предыдущая остаётся в системе версий помеченной как «откатная». Первые двое суток кто-то из команды смотрит очередь эскалаций утром и вечером. Через неделю без инцидентов редакция считается принятой, и её эталоны попадают в набор.
| Ступень | Длительность | Что смотрим | Условие отката |
|---|---|---|---|
| Прогон на наборе | 30–40 минут | Сколько диалогов из 30 пройдено | Провалено больше 2 диалогов |
| Теневой режим | 3–5 дней | Выборка 20–30 ответов в день глазами оператора | Найдено фактическое враньё или нарушенное стоп-правило |
| 20 % трафика | Неделя, около 75 диалогов | Эскалации и повторные обращения на двух потоках | Доля эскалаций выросла больше чем в полтора раза |
| Полный переход | Наблюдение 7 дней | Очередь эскалаций утром и вечером | Любой инцидент с деньгами или персональными данными |
Ценность ступеней не в осторожности, а в скорости отката. Когда предыдущая редакция помечена номером и лежит рядом, возврат занимает пару минут: откатились, разобрались, выкатили заново. Когда её нет, каждый выкат становится решением, которое страшно принимать, и правки копятся месяцами, пока не выкатываются пачкой — а пачку уже не разобрать по причинам. Этот сюжет мы разбирали в материале про жизнь системы после запуска.
Горизонтальная лента времени примерно на две недели с четырьмя ступенями: «Прогон на наборе — 30–40 минут», «Теневой режим — 3–5 дней», «20 % трафика — неделя, около 75 диалогов», «Полный переход — наблюдение 7 дней». Под каждой ступенью подписано условие перехода дальше, над каждой — условие отката. Слева от ленты вертикальная отметка «предыдущая редакция помечена как откатная, возврат 1–2 минуты». Чертёжный стиль, подписи по-русски.
Три метрики, которые снимаются без аналитической системы
Для контроля качества ответов не нужна отдельная аналитика — нужны три числа, которые считаются по журналу диалогов и по выгрузке из CRM. Их достаточно, чтобы поймать деградацию за неделю, а не за квартал.
| Метрика | Как считается | Рабочий порог | О чём говорит выход за порог |
|---|---|---|---|
| Доля прохождения контрольного набора | Пройдено диалогов ÷ 30, после каждой правки | 30 из 30, допустимо 29 | Правка задела сценарии, которых не касалась |
| Доля эскалаций на человека | Диалогов, переданных оператору ÷ все диалоги за неделю | Стабильна в пределах ±20 % от своего обычного уровня | Рост — агент потерял знание или осторожничает; падение — берётся за то, что должен отдавать |
| Доля повторных обращений по той же теме | Клиентов, написавших повторно по тому же вопросу в течение 7 дней ÷ все клиенты недели | До 15 % | Ответы формально верные, но задачу клиента не закрывают |
Третья метрика — самая полезная и самая недооценённая. Первые две показывают, что агент ведёт себя как задумано, а повторные обращения показывают, помогло ли это клиенту. Агент может проходить набор на 30 из 30, почти не эскалировать и при этом гонять людей по кругу: ответ есть, задача не решена. Падение доли повторных обращений — единственный из трёх показателей, который прямо переводится в снятую нагрузку с людей. Как считать эффект автоматизации в деньгах, у нас есть отдельный разбор в материале про измерение эффекта.
Чего не стоит делать — считать главной метрикой оценку «понравился ли ответ». Её ставят 3–7 % клиентов с перекосом в сторону недовольных: на потоке 1 500 обращений это 45–100 оценок в месяц, половина которых относится не к агенту, а к цене. Как сигнал она полезна, как основание для правки инструкции — нет. Контроль сроков ответа и просрочек тоже лучше отдать отдельному контуру: это задача контроля SLA, а не набора тестов.
Кто проверяет ответы, если в компании нет тестировщика
Тестировщик для этой работы не нужен и, честно говоря, не подходит. Нужен человек, который знает, каким ответ должен быть по существу: старший оператор поддержки, методист, руководитель группы продаж. Проверка контрольного набора — это не поиск технических ошибок, а сверка ответа с тем, что компания на самом деле обещает клиенту. Инженер здесь отвечает только за прогон, выкат и откат.
Из девяти часов семь с половиной — внутренние, и это принципиально. Отдать разбор расхождений подрядчику технически можно, но тогда решение «правильный ли это ответ» принимает человек, который не знает ни ваших договорённостей с постоянными клиентами, ни того, что на прошлой неделе сменился срок поставки. Подрядчик отвечает за то, чтобы правка доехала до прода и откатилась при необходимости; за содержание отвечает компания. Как эти роли раскладываются по людям и три рабочие схемы распределения ответственности разобраны в материале о том, кто в компании ведёт промпты.
Отдельно про частоту. Здоровый ритм — один плановый прогон в неделю плюс прогон после каждой правки. Если правок больше четырёх в месяц и после каждой набор падает, дело уже не в формулировках: агенту не хватает данных, доступа к системе или задача требует расчёта, а не текста. Признаки этого состояния и порядок действий разобраны отдельно в материале о том, когда промпт уже не спасает.
Когда набор тестов заводить рано
Регресс-тесты — не универсальная гигиена, а инструмент с ценой. Есть три ситуации, в которых 22 часа на сборку набора не окупаются, и мы честно говорим об этом до начала работ.
- Пилот на две-четыре недели. У пилота задача — понять, справляется ли агент в принципе, и инструкция за это время переписывается целиком по три раза. Набор, собранный на первой неделе, к третьей описывает несуществующее поведение. Правильный порядок — сначала стабилизировать требования, потом фиксировать их набором.
- Меньше 200 обращений в месяц через агента. Тридцать контрольных диалогов при таком потоке покрывают почти все реальные обращения, и роль набора выполняет обычная выборочная проверка: старший оператор просматривает все ответы за день за 20 минут. Заводить набор имеет смысл начиная примерно с 400–500 обращений в месяц.
- Агент только читает и не отвечает наружу. Если модель классифицирует обращения, извлекает поля из счёта или составляет резюме звонка для менеджера, ошибка видна человеку до того, как что-то произойдёт. Здесь работает выборочный контроль качества распознавания, а не набор диалогов.
И обратная сторона того же правила. Если агент отвечает клиентам самостоятельно, называет цены и сроки и умеет что-то записывать в учётную систему, набор нужен с первого дня эксплуатации — не потому, что модель ненадёжна, а потому, что инструкцию будут править, и править будут люди, которые не помнят, какие ещё сценарии зависели от каждой строки. Набор здесь работает не как контроль качества модели, а как память команды.
Спросите у подрядчика две вещи: сколько диалогов в контрольном наборе вашего агента и когда набор прогонялся последний раз. Если ответ на первый вопрос — «мы проверяем вручную», а на второй — «после каждой правки смотрим», значит, набора нет, и каждая правка выкатывается на ваших клиентах. Это не повод для скандала, но повод внести сборку набора в план работ ближайшего месяца.
Набор из 30 диалогов — это не контроль качества модели. Это память команды о том, почему каждая строка инструкции однажды там появилась.
