Провайдер обновляет модель без вашего участия, и в большинстве случаев без внятного предупреждения. В понедельник агент отвечает так же вежливо и так же по делу — но вместо заполненных полей карточки отдаёт связный текст с пояснением, и запись в CRM уезжает с мусором. Ни одной ошибки в логах при этом нет: с точки зрения кода всё отработало штатно.
Ломается почти никогда не смысл. Ломается форма: формат вывода, длина и тон, поведение при вызове функций и трактовка правил из инструкции. Две недели такого расхождения на потоке 200 обращений в день обходятся в 93 090 ₽, а контур, который ловит его за ночь, стоит 7 086 ₽ в месяц.
Дальше — четыре типа поломок и как каждая выглядит с вашей стороны; почему это принципиально не ловится вручную; устройство и смета сторожевого прогона; можно ли вообще зафиксировать версию у провайдера и что писать в договоре с подрядчиком; и порядок перехода на новую версию, когда старую выводят из эксплуатации.
Что ломается на самом деле
Новая версия модели — это не «та же модель, только лучше». Это другая модель с тем же названием: у неё иначе устроены предпочтения по формату, иначе расставлены акценты в длине, иначе интерпретируются формулировки инструкции. На девяноста четырёх ответах из ста разницу не заметит никто, включая вас. Проблемы приходят с оставшихся шести.
| Что изменилось | Как это выглядит у вас | Что ломается дальше |
|---|---|---|
| Формат вывода | вместо заполненных полей — связный текст с пояснением перед ними | запись в CRM или 1С уходит с мусором либо не уходит вовсе |
| Длина и тон ответа | ответы стали короче и суше, исчезли обязательные оговорки | клиент не предупреждён о предоплате или сроке — спор и претензия |
| Поведение при вызове функций | модель зовёт другую функцию или подставляет параметр не того типа | в учётной системе создаётся не то действие или не создаётся ничего |
| Трактовка правил инструкции | запрет обсуждать скидки стал пониматься мягче | стоп-темы перестают срабатывать, агент говорит лишнее |
Сравнение в две колонки под общим вопросом сверху: «Клиент: заказ 4471, когда отгрузка и на каких условиях». Левая колонка «До обновления»: аккуратный блок из подписанных полей — «номер заказа», «дата отгрузки», «условия оплаты», «источник», под ним пометка «карточка заполнена, 4 поля из 4». Правая колонка «После обновления»: тот же ответ, но в виде сплошного абзаца текста с вводной фразой, поля не выделены; под ним пометка «карточка пустая, разбирает менеджер, 12 минут». Обе колонки помечены одинаковой галочкой «смысл верный». Внизу общая подпись «6 % ответов из 2 800 за две недели — 168 карточек». Чертёжный стиль, все подписи по-русски.
Первая строка таблицы — самая частая и самая дорогая. Просьба «отвечай в заданном формате» держится на добросовестности модели, и новая версия трактует эту просьбу иначе. Именно поэтому формат фиксируется не текстом инструкции, а проверкой по схеме на стороне кода: такая проверка переживает любое обновление, потому что живёт не в модели.
Почему вручную это не ловится
Соблазн понятный: посмотреть десяток диалогов, убедиться, что всё хорошо, и закрыть вопрос. Так и делают — и не находят ничего, потому что искать надо не там и не так.
- Расхождение точечное. Меняются проценты ответов, а не все. Чтобы наткнуться на сломанный сценарий вручную, нужно случайно взять именно тот диалог, где он проявился.
- Ломается редкое. Сценарий, который встречается три раза в неделю, — как раз тот, что не попадает в выборочный просмотр. А обходится он дороже частого, потому что его никто не проверяет.
- Ответ выглядит нормально. Это не ошибка и не сбой, а просто другой ответ. Оценка «стало хуже» — суждение, и без заранее записанного эталона его не с чем сравнить.
- Разброс есть всегда. Модель и без всякого обновления отвечает на один вопрос по-разному; почему это нормально и где проходит граница дефекта, разобрано отдельно. На фоне обычного разброса точечное изменение поведения теряется полностью.
- Вас не предупредили. Уведомление о смене версии приходит не всегда и не всем, а иногда приходит после факта. Полагаться на него как на единственный сигнал нельзя.
В типовом сценарии расхождение обнаруживается на второй-третьей неделе — по жалобе клиента или по вопросу менеджера «почему карточки пустые». К этому моменту через систему прошли тысячи обращений, и разбирать приходится не одну поломку, а её последствия, разъехавшиеся по учётной системе. Это же одна из пяти причин, по которым агент со временем начинает отвечать хуже.
Сторожевой прогон: 30 примеров каждую ночь
Идея простая: раз изменение точечное, надо каждую ночь задавать системе один и тот же небольшой набор вопросов и сравнивать ответы с эталоном. Не с прошлым ответом — с эталоном, записанным один раз. Тридцати примеров достаточно, если они выбраны не случайно, а по цене ошибки.
Схема потока данных слева направо. Блок «Расписание: каждую ночь» → блок «30 контрольных примеров» → блок «Агент на боевой конфигурации» → блок «Сравнение с эталоном: формат, обязательные оговорки, вызванные функции, числа» → ромб «есть расхождения?». Ветка «нет» подписана «846 ₽ в месяц, никто ничего не делает» и уходит короткой петлёй в блок «Запись в журнал». Ветка «да» ведёт в блок «Уведомление инженеру и стоп-флаг на выкладку» → блок «Полный регресс, 180 примеров, 3 240 ₽» → развилка на два блока: «Откат на предыдущую конфигурацию» и «План перехода на новую версию». Сбоку отдельная пунктирная стрелка от блока «Уведомление провайдера об обновлении» к блоку «Полный регресс» с подписью «второй сигнал, приходит не всегда». Чертёжный стиль, все подписи по-русски.
В набор кладут то, что дорого сломать: пять примеров со строгим форматом вывода, пять с обязательными оговорками про деньги и сроки, пять с вызовом функций в учётной системе, пять на стоп-темы, пять уже чинившихся ошибок и пять вопросов, ответа на которые в базе нет. Из тридцати проверок примерно две трети автоматические — наличие поля, обязательная фраза, имя вызванной функции, число в ответе; остальные требуют взгляда человека, но только когда сработал сигнал.
Тринадцать месяцев — честный порог, и он же главный аргумент против контура там, где агент не касается денег и не пишет в учётную систему. Если же касается, одного эпизода достаточно: 93 090 ₽ покрывают год наблюдения с запасом. Сам набор из тридцати диалогов — это те же 22 часа и 35 600 ₽, что и при версионировании инструкций агента, и собирается он один раз на обе задачи.
Можно ли зафиксировать версию и что писать в договоре
Иногда можно. Часть провайдеров даёт закреплённый идентификатор конкретной версии — вы обращаетесь именно к ней, и она не меняется под вами. Это первое, что надо спросить у провайдера ещё до выбора: есть ли закреплённые версии, сколько живёт каждая и за сколько дней предупреждают о выводе из эксплуатации.
Любая закреплённая версия рано или поздно выводится из эксплуатации, и переход всё равно понадобится — просто в удобный вам момент, а не внезапно. Хуже другое: закреплённая версия перестаёт получать улучшения, и через год вы платите те же деньги за заметно более слабую модель. Правильная позиция — фиксировать версию и одновременно держать регресс-набор, а не выбирать одно из двух.
- 1Идентификатор версии модели указан в акте и в паспорте системы вместе с датой фиксации и датой планового вывода, если она известна. Формулировка «используется модель провайдера X» не годится: через полгода будет нечего сравнивать.
- 2Обязанность подрядчика прогнать регресс-набор после смены версии у провайдера — за его счёт и в оговорённый срок, обычно два рабочих дня. Это стандартный пункт договора на поддержку, и он там часто отсутствует.
- 3Описано, кто и как узнаёт об обновлении: подписка на уведомления провайдера плюс сторожевой прогон как второй контур. Один только первый способ ненадёжен, один только второй даёт задержку в сутки.
- 4Порядок отката: предыдущая рабочая конфигурация хранится не меньше месяца и включается в течение оговорённого времени. Если откатываться некуда, любая проблема превращается в срочную разработку.
- 5Что считается провалом прогона: падение на деньгах, на вредном запросе или на уже чинившейся ошибке блокирует выкладку целиком. Пороги по остальным корзинам разобраны в материале про регресс-набор.
План перехода на новую версию
Когда переход неизбежен — версию выводят или новая заметно лучше, — он делается ступенями, а не переключателем. Четыре ступени занимают 2–3 недели календарно и 10–14 часов инженера, то есть 30 000–42 000 ₽.
- 1Параллельный прогон регресс-набора — один день, 3 240 ₽
Полный набор из 180 примеров прогоняется на старой и новой версии, результаты кладутся в две колонки рядом. Смотрят не итоговую долю прохождения, а поимённо: какие примеры упали на новой и не падали на старой.
- 2Теневой режим — 3–5 дней
Новая версия отвечает молча на реальный поток параллельно со старой, её ответы никуда не уходят и складываются парами со старыми. Здесь всплывают сценарии, которых в наборе не было, — а их всегда больше, чем кажется.
- 3Десять процентов трафика — неделя
Новая версия начинает отвечать по-настоящему, но только на десятой части обращений. Смотрят три вещи: долю эскалаций на человека, долю повторных обращений по той же теме и число сработавших проверок формата.
- 4Полный переход и хранение отката — месяц
Старая конфигурация остаётся в готовом виде ещё месяц. Всё это время сторожевой прогон продолжает идти каждую ночь: часть расхождений проявляется не сразу, а на редких сценариях через две-три недели.
Горизонтальная лента времени слева направо с четырьмя подписанными этапами и их длительностью: «Параллельный прогон — 1 день, 3 240 ₽», «Теневой режим — 3–5 дней», «10 % трафика — 1 неделя», «Полный переход — далее». Под каждым этапом подпись «что получаем»: «список упавших примеров поимённо», «сценарии, которых не было в наборе», «доля эскалаций и повторных обращений», «старая конфигурация хранится ещё месяц». Под всей лентой сплошная стрелка обратного хода с подписью «откат возможен на любой ступени». Справа итоговая подпись «2–3 недели, 10–14 часов инженера, 30 000–42 000 ₽». Чертёжный стиль, все подписи по-русски.
Эта сумма кажется большой ровно до сравнения с альтернативой. Полная смена провайдера модели — другая работа и другие деньги: 44 часа и 132 000 ₽ при наличии адаптера и вдвое больше без него, как посчитано в разборе того, как сменить модель без переписывания системы. Переход между версиями одного провайдера в три-четыре раза дешевле — но только если регресс-набор уже существует.
Когда всё это лишнее
Сторожевой контур — это 7 086 ₽ в месяц и чья-то ответственность. Есть сценарии, где он не окупится никогда, и там правильнее договориться о простом наблюдении и жить дальше.
- Агент ничего не пишет в учётные системы и не говорит о деньгах. Справочный бот по расписанию работы и адресам может отвечать чуть иначе, и цена этого — ноль. Хватит ежемесячного просмотра двадцати диалогов.
- Поток меньше 1 000 обращений в месяц. При двухстах обращениях в месяц те же 6 % испорченного формата — это 12 карточек, то есть 2 160 ₽. Контур за 7 086 ₽ дороже проблемы, которую он ловит.
- Модель развёрнута в вашем контуре. Собственный узел никто не обновляет без вашего ведома: смена весов — это ваше плановое действие, а не сюрприз. Сторожевой прогон там всё равно полезен, но уже не как охрана от провайдера.
- Регресс-набора нет и делать его пока не на чем. Пока система в пилоте и сценарии переписываются каждую неделю, эталон устаревает быстрее, чем собирается. Сначала стабилизация, потом наблюдение.
- Некому реагировать. Сигнал, который приходит в почту, где его никто не читает, хуже отсутствия сигнала: он создаёт ложное чувство защищённости. Назовите человека и срок реакции до того, как включать прогон.
Зеркальный признак — когда контур нужен обязательно: агент пишет в CRM или 1С, отвечает клиентам про деньги и сроки, поток выше 3 000 обращений в месяц и модель берётся у внешнего провайдера. При таком сочетании 53 600 ₽ на сборку и 7 086 ₽ в месяц закладываются в бюджет сразу, вместе с самим агентом, — а не после первого эпизода, о котором вы узнали от клиента.
