Попросите сделать ИИ-ассистента — и в ответ получите спецификацию того, что он умеет. Отвечать на вопросы. Принимать записи. Готовить черновики ответов. Искать информацию.
Важна другая спецификация — та, где описано, когда он останавливается.
Каждую ИИ-систему, которую мы выпустили и готовы защищать, определяют скорее её выходы, чем её возможности. Не потому, что модели слабые, — они не слабые, — а потому, что у системы, которая может действовать от вашего имени и не имеет продуманного способа остановиться, худший день ничем не ограничен. А именно худший день и решает, оставите вы её или нет.
Это ещё и та часть, которую замечают клиенты. Никто не обижается, что бот не смог ответить. Обижаются все, когда бот не пускает дальше.
Выход — это продуктовое решение, а не запасной вариант
Проблема в самих словах «запасной вариант». Они подают передачу человеку как то, что происходит, когда настоящая функция не сработала, — и она оказывается последней в дизайне и последней в бюджете.
Переверните это. Передача человеку — та функция, благодаря которой всё остальное безопасно запускать. Именно она позволяет поставить языковую модель перед клиентами, не ставя отношения с ними на кон её худшего ответа.
Опишите её первой — и остальную систему станет легче очертить, потому что теперь понятно, в чём машина должна быть права, а что ей достаточно лишь распознать.
Шесть схем и где каждая уместна
Это передачи разговора человеку в системах, которые у нас реально работают. Это разные механизмы для разных рисков, и в большинстве настоящих внедрений используется сразу несколько.
1. По запросу — сразу и без уговоров
Самая простая и самая не подлежащая обсуждению. Человек просит человека — и получает его. Никаких петель удержания, никаких «давайте я попробую ещё раз», никакого спрятанного запасного выхода.
Бот поддержки Bronjoy передаёт разговор по запросу, и команда для этого самая обычная. Соблазн усложнить этот путь — ровно тот соблазн, из которого вырастает поддержка, которую все ненавидят, и обычно его создаёт метрика доли разгрузки — метрика, которая не отличает клиента, получившего решение, от клиента, который сдался. Подробно мы разбираем это в статье «Арифметика разгрузки поддержки».
2. После повторных неудач
Тот же бот передаёт разговор человеку после нескольких бесполезных ответов подряд и при ошибке.
Это важно, потому что клиенты не всегда просят человека. Многие трижды переформулируют один и тот же вопрос, а потом уходят, и этот тихий уход в ваших метриках не виден. Если считать нерешённые реплики подряд и передавать разговор на третьей, тихая потеря превращается в обработанный случай.
3. По категории — ещё до начала разговора
На некоторые темы нельзя отвечать автономно, как бы ни была уверена модель.
В том же боте ответы про оплату и аккаунт ждут одобрения человека. Не потому, что модель в них чаще ошибается, а потому, что ошибка здесь стоит дорого и её трудно отыграть назад. Удерживать ответы по категориям дёшево в реализации, и это убирает целый класс рисков, не затрагивая остальной опыт.
4. Всё, что обязывает деньгами, — всегда
Nomadeo — ИИ-агент по продажам, который общается на русском, узбекском и казахском в WhatsApp и Telegram, — работает по самой строгой версии этого правила: всё, что обязывает бизнес деньгами, ценой, скидкой или сроком, останавливается и ждёт подтверждения человека.
Он же показывает, как выглядит окружающая механика, когда ставки реальны. На каждом черновике перед отправкой срабатывают девять защитных механизмов: опора на факты, полномочия на скидку, запрещённые утверждения, промпт-инъекции, персональные данные, устаревшие факты, ночной режим, лимиты частоты и бюджет. Заблокированный черновик пересобирается или передаётся человеку. Факты, извлечённые из разговора, распределяются по уровням риска и сверяются: малорисковые подтверждаются автоматически, высокорисковые уходят в очередь решений с возможностью отмены.
На отмену стоит обратить внимание. Передача человеку — это не только остановка перед действием, но и возможность действие отменить.
5. Пауза посреди выполнения ради одобрения — и продолжение
Более тонкая схема и самая полезная для внутренних инструментов.
В Knigopoisk есть ИИ-ассистент в админке с инструментами для заказов, товаров, контента, медиафайлов, пользователей и статистики. Когда модель предлагает действие, требующее согласования, выполнение ставится на паузу, предложение записывается, и агент продолжает работу только после того, как администратор его одобрит или отклонит, — остаётся журнал аудита.
Это лучше обеих крайностей. Полная автономия небезопасна для ассистента, который может менять заказы. Полностью ручной режим значит, что человек всё равно делает всю работу сам. Пауза значит, что машина думает и собирает, а человек решает, и всё это записано.
6. Признать, что доказательств недостаточно
Самая дисциплинированная схема и та, которую большинство систем пропускает.
Testify проверяет записи звонков на соответствие регуляторным требованиям. Требование считается выполненным, только если есть дословная цитата с таймкодом. Если доказательства нет, результат — не догадка с низкой оценкой уверенности, а «недостаточно доказательств», и такой случай уходит на проверку человеку.
Тот же принцип проходит ещё через две вещи, которые мы сделали. Legible, который адаптирует документы для доступности, оставляет нечитаемые значения пустыми и помечает их, прямо обосновывая это тем, что уверенное неправильное значение хуже, чем никакого. RecipeReel оставляет количество пустым, а не угадывает, если его не произносят и не показывают на экране.
«Я не знаю» — это тоже передача человеку. Системы, которые не умеют этого сказать, скажут вместо этого что-то другое — и объяснять это «что-то» клиенту будете вы.
Страж утверждений: как поймать передачу, которой не было
Есть сценарий сбоя, который не ловит ни одна из шести схем, и именно он беспокоил нас больше всего, когда мы делали голосового агента.
Модель может сказать, что сделала то, чего не делала. Она может сообщить клиенту, что запись подтверждена, когда инструмент записи вернул ошибку. Все защитные механизмы выше управляют действиями; ни один не управляет предложениями.
Поэтому у ИИ-администратора Bronjoy есть страж утверждений: каждое предложение, где заявлено о записи, отмене или переносе, сверяется с вызовами инструментов, которые действительно прошли успешно. Утверждения без подтверждения превращаются в уточняющий вопрос и записываются в лог.
Вся архитектура вокруг построена на том же недоверии. Ни один инструмент не принимает цену. hold_slot возвращает токен брони, без которого не работает book_appointment, так что к подтверждённой записи нет пути в обход резервирования.
И честные ограничения — такие утверждения должны идти вместе с ними: этот администратор полностью работает только как демо в браузере. В продакшене он стоит за флагом VOICE_ENABLED, который выключен, телефонной части нет, номера телефона нет. Демо ограничено 30 репликами или 10 минутами на сессию и 20 сессиями с одного IP в час.
Что описать до начала разработки
Возьмите этот список на обсуждение объёма работ. Каждая строка — решение, которое кто-то должен принять, а поздно принятые решения и порождают инциденты.
- Что эта система может делать без человека? Явный список, а не граница, описанная прилагательными.
- Чего она не может делать никогда? Деньги, юридические обязательства, всё необратимое, всё, что касается аккаунта конкретного человека.
- Что запускает передачу человеку? Запрос, повторные неудачи, категория, недостаток доказательств, блокировка защитным механизмом, ошибка.
- Куда уходит передача и кто за этим следит? Очередь, которую никто не открывает, — это не путь эскалации.
- Что видит клиент при передаче? Ему нужно прямо сказать об этом и назвать, когда ждать ответа.
- Что получает человек? Весь разговор, что пытались сделать, что не получилось. Передача, которая приходит в виде «клиенту нужна помощь», сводит на нет всю автоматизацию.
- Что записывается в лог? Каждый заблокированный черновик, каждое неподтверждённое утверждение, каждая эскалация. Так вы узнаёте, что чинить.
- Что происходит в нерабочее время? У Nomadeo для этого есть защитный механизм ночного режима. Эскалации в 2 часа ночи, когда её некому принять, нужен другой ответ, чем эскалации в 2 часа дня.
Чаще всего проваливают пункт 6. Ценность передачи человеку — в контексте, который приходит вместе с ней.
Почему это делает систему сильнее, а не слабее
Есть опасение, что продуманные выходы дают робкого ассистента, который постоянно всё передаёт людям.
Происходит обратное. Система с чётко определёнными выходами может быть более способной внутри своих границ, потому что последствия ошибки ограничены. Это системы без выходов приходится держать расплывчатыми и осторожными везде, потому что любая ошибка может обернуться чем угодно.
Nomadeo — самая наглядная демонстрация: девять защитных механизмов, очередь решений, обязательное подтверждение всего, что касается денег, — и в этих пределах он ведёт переговоры, отрабатывает возражения и закрывает сделки, показывая менеджеру по продажам выбранную тактику, использованные источники и пройденные проверки. Именно ограничения делают такой уровень автономии защитимым.
Наши работы по внедрению ИИ и автоматизации стоят от $299 и занимают от одной до трёх недель, а передача разговора человеку прямо указана в результатах работы, а не подразумевается. Это первое, что мы описываем, а не последнее.
Расскажите, что вам нужно. В ответ вы получите фиксированную цену и дату сдачи — бесплатно и без обязательств продолжать.
Частые вопросы
Не подрывает ли автоматизацию заметная кнопка «Связаться с человеком»?
Нет, а данные, которые она даёт, ценны: то, как часто на неё нажимают, точно показывает, где система не справляется. Подрывает автоматизацию как раз спрятанная кнопка, потому что клиенты, которых вы заперли, не становятся довольными — они становятся бывшими.
Что, если у нас нет сотрудников, чтобы принимать эскалации?
Тогда ограничьте автоматизацию тем, что она может довести до конца сама, а запасным вариантом сделайте форму или сообщение с обещанием ответить в названный срок. Это честно. Нечестно — ассистент, который намекает, что человек на связи, когда никого нет.
Как не дать ему передавать людям всё подряд?
Измеряйте причины, а не только частоту. Если эскалации скапливаются вокруг одного типа запросов, для него нужен лучший исходный материал — обычно документация, а не более мощная модель. Логи эскалаций — самая ценная обратная связь, которую даёт внедрение ИИ, и большинство команд их никогда не читают.
Достаточно ли оценки уверенности, чтобы решать, когда передавать разговор?
Сама по себе — нет. Уверенность, о которой модель сообщает сама, слабо связана с правильностью ответа и ухудшается как раз в тех ситуациях, которые вам важны. Отдавайте предпочтение структурным сигналам: прошёл ли вызов инструмента, есть ли дословная цитата в подтверждение утверждения, входит ли эта категория в список удерживаемых. «Недостаточно доказательств» в Testify — структурная проверка, а не числовая, и именно поэтому ей можно доверять.
Должен ли клиент знать, что разговаривает с машиной?
Да, и скажите об этом в самом начале, а не ждите, пока он догадается сам. Так вы правильно выставляете ожидания, избегаете острой обиды, которая наступает, когда человек обнаруживает обман, а во всё большем числе юрисдикций это становится требованием, а не вежливостью.
