Сложный процесс агенту отдают не одним большим промптом, а цепочкой коротких шагов с проверкой после каждого. Причина арифметическая: надёжность шагов перемножается. Семь шагов, каждый из которых срабатывает правильно в 95 % случаев, дают на выходе 0,95 в седьмой степени — около 70 %. То есть каждая третья заявка выйдет из цепочки с дефектом, хотя ни один отдельный шаг не выглядит ненадёжным.
Это самое частое расхождение между ощущением и результатом в проектах с агентами. На демонстрации всё работает: показывают один шаг, он отрабатывает безупречно. В эксплуатации выясняется, что «почти всегда» семь раз подряд — это уже «в двух случаях из трёх». Дальше начинается правка инструкции, хотя формулировки тут ни при чём: проблема не в тексте, а в конструкции.
Ниже — арифметика надёжности с таблицей по числу шагов, разбор приёма заявки на семь шагов с точками проверки, расчёт в рублях, устройство хранения состояния, сравнение двух схем сборки, состав журнала шагов для отладки и признак, по которому сценарий пора укорачивать. Сквозной пример прежний для раздела: оптовая компания с интернет-магазином, 1 500 обращений в месяц, из них 420 — заявки, идущие через сценарий целиком. Ставки модельные: инженер подрядчика 3 000 ₽/час, методист или старший оператор 900 ₽/час, оператор 700 ₽/час.
Арифметика надёжности: почему длинная цепочка проседает
Считается это в одно действие: надёжность шага возводится в степень числа шагов. Таблица ниже показывает, почему разговор «наш агент почти не ошибается» бессмысленен без указания длины цепочки.
| Шагов в цепочке | Шаг срабатывает в 90 % | Шаг срабатывает в 95 % | Шаг срабатывает в 99 % |
|---|---|---|---|
| 3 | 73 % | 86 % | 97 % |
| 5 | 59 % | 77 % | 95 % |
| 7 | 48 % | 70 % | 93 % |
| 10 | 35 % | 60 % | 90 % |
Из таблицы следуют два практических вывода. Первый: длину цепочки нужно считать до начала работ, а не после. Семишаговый сценарий на модели с надёжностью шага 90 % не имеет смысла — он даёт меньше половины успешных проходов, и никакая правка формулировок это не исправит. Второй: разница между 95 % и 99 % на одном шаге кажется косметической, а на семи превращается в 70 % против 93 %. Именно за эти четыре процентных пункта на шаге и платят, когда ставят проверки.
Условие, которое выполняется кодом, а не моделью, и определяет, можно ли идти дальше. Сравнение с данными учётной системы, проверка формата, наличие обязательного поля, явный вопрос человеку. Проверка не «спрашивает у модели, уверена ли она» — самооценка модели такой же результат её работы, как и сам ответ, и ошибается вместе с ним.
Механика подъёма надёжности простая. Если шаг ошибается в 5 случаях из 100, а проверка ловит 4 из этих 5, эффективная надёжность шага становится 99 %: пойманная ошибка не проходит дальше, а превращается в уточняющий вопрос или в передачу человеку. Ловится не всё — оставшийся 1 % проходит, и с этим приходится жить. Что именно делать с непойманными случаями, разбиралось в материале про человека в контуре принятия решений.
График с тремя нисходящими кривыми. По горизонтали — число шагов от 1 до 10, по вертикали — доля успешных проходов от 0 до 100 %. Верхняя кривая подписана «шаг 99 %» и проходит через точки 97, 95, 93, 90. Средняя «шаг 95 %» — через 86, 77, 70, 60. Нижняя «шаг 90 %» — через 73, 59, 48, 35. Вертикальная штриховая линия на отметке 7 шагов, точки пересечения подписаны значениями 93 %, 70 %, 48 %. Оси и подписи по-русски.
Приём заявки: семь шагов и семь проверок
Разберём типовой сценарий целиком. Клиент пишет в чат свободным текстом: «Добрый день, нужно 20 доводчиков на входные двери и 4 упора, когда сможете отгрузить». На выходе должна получиться заявка в CRM с позициями, количествами, суммой и сроком. Между этими двумя точками — семь шагов.
- 1Шаг 1. Это заявка или вопрос
Классификация сообщения. Проверка: если модель не уверенно относит сообщение к заявке, агент не догадывается, а задаёт один вопрос — «оформляем заказ или пока уточняем наличие?». Ошибка на этом шаге дороже всех остальных: она запускает шесть лишних шагов на человеке, который просто спросил цену.
- 2Шаг 2. Кто клиент
Поиск в CRM по телефону, почте или названию компании. Проверка кодом, а не моделью: ровно один кандидат — принимаем; ноль или больше одного — уточняющий вопрос. Именно здесь чаще всего появляются дубли клиентов в CRM, если проверку заменить фразой «найди наиболее похожего».
- 3Шаг 3. Разобрать состав
Из свободного текста вынимаются пары «что» и «сколько». Проверка формальная: у каждой позиции обязано быть количество. «Нужны доводчики» без числа — не позиция, а вопрос; агент спрашивает количество, а не подставляет единицу.
- 4Шаг 4. Сопоставить с номенклатурой
«Доводчик» превращается в конкретную позицию прайса. Проверка: принимается только точное совпадение по коду или подтверждение клиента выбором из списка. Как собирается словарь соответствий между словами клиента и номенклатурой, разобрано в материале про язык компании в инструкции агента.
- 5Шаг 5. Наличие и срок
Запрос в учётную систему. Проверка простая и жёсткая: ответ берётся из системы, и только из неё. Если система не ответила за отведённое время, шаг не выполняется — агент не называет срок «примерно», а сообщает, что уточнит. Это то место, где отсутствие проверки даёт самые дорогие обещания.
- 6Шаг 6. Собрать черновик и посчитать сумму
Проверка: сумма считается кодом, а не моделью. Умножение количества на цену и применение условий — арифметика, и отдавать её языковой модели незачем: она делает это медленнее, дороже и иногда неверно. Модель здесь формирует текст подтверждения, а не число.
- 7Шаг 7. Записать в CRM и подтвердить клиенту
Проверка на повтор: запись создаётся с ключом, по которому повторная отправка не порождает вторую заявку. Механика описана в материале про идемпотентность простыми словами, и она обязательна: пользователь нажмёт кнопку дважды, а сеть моргнёт трижды.
Обратите внимание, что из семи проверок только две касаются языка. Остальные пять — это сравнение с данными системы, формальные условия и арифметика. Это общее свойство работающих сценариев: чем длиннее цепочка, тем меньшую её часть выполняет модель. Модель разбирает свободный текст на входе и формирует текст на выходе; середина держится на коде и данных. Граница между тем и другим разобрана в опорной статье про то, что должно жить в промпте, а что в коде.
Горизонтальная схема из семи прямоугольных блоков со стрелками, подписи: «1. Заявка или вопрос», «2. Кто клиент», «3. Состав и количества», «4. Сопоставление с номенклатурой», «5. Наличие и срок из учётной системы», «6. Черновик и сумма кодом», «7. Запись в CRM с ключом повтора». После каждого блока ромб проверки; от ромбов 1, 2 и 3 вниз отходят ветки в блок «уточняющий вопрос клиенту», от ромба 5 — ветка в блок «передача сотруднику». Над блоками 1, 3 и 7 пометка «работает модель», над остальными — «работает код». Справа итоговая плашка «93 % проходов без вмешательства». Чертёжный стиль, подписи по-русски.
Что даёт проверка после каждого шага: расчёт
Считаем на сквозном примере. Через семишаговый сценарий проходят 420 заявок в месяц. Без проверок надёжность цепочки — 70 %, с проверками — 93 %. Разбор одной кривой заявки занимает у оператора 12 минут: найти диалог, понять, что не так, переспросить клиента, поправить запись.
Строка про невернувшихся клиентов — самая спорная и самая крупная, поэтому про неё стоит сказать отдельно. Двенадцать из ста двадцати шести — это примерно каждый десятый, и это осторожная оценка: заявка, оформленная неверно и исправленная через два дня, чаще всего доживает до отгрузки. Если у вас есть своя статистика по отвалу, подставьте её — арифметика не изменится, изменится только вторая строка. Как считать такие эффекты, чтобы им можно было верить, разобрано в материале про то, что считать экономией от автоматизации.
Двадцать один час на семь проверок — это по три часа на каждую, и большая часть времени уходит не на сложную логику, а на выяснение, что считать нормой: сколько ждать ответа учётной системы, что делать при двух кандидатах в CRM, какой срок считать подтверждённым. Технически большинство проверок — это несколько строк условий. Дорого стоит решение, а не код.
Где живёт состояние диалога
Многошаговый сценарий обязательно прерывается: человек уходит обедать, отвечает через два часа, закрывает вкладку, пишет с другого устройства. Если единственное место, где хранится собранное, — это сама переписка, то любой обрыв означает начать сначала, а любое переполнение контекста — потерю начала диалога.
Правильное устройство — отдельная запись состояния с шестью полями, живущая независимо от переписки.
- 1Идентификатор сессии. Привязан к клиенту и каналу, а не к сообщению. По нему диалог, продолженный через два часа, находит собранные ранее данные.
- 2Номер последнего подтверждённого шага. Именно подтверждённого, а не начатого: возврат после обрыва идёт к нему, а не к тому месту, где всё оборвалось.
- 3Собранные поля. Клиент, позиции, количества, срок — в структурированном виде, а не пересказом. Пересказ на пятой реплике теряет детали, структура не теряет.
- 4Версия сценария. Если во время диалога вышла новая редакция, вы должны знать, по какой шёл этот конкретный разговор, иначе разбор жалобы становится гаданием.
- 5Время последнего действия и срок жизни. Разумный срок для заявки — 24 часа. После него сессия закрывается, но собранные поля не выбрасываются: они пригодятся, когда человек вернётся через неделю.
- 6Ключ повторной отправки. Одно значение, по которому система понимает, что эта заявка уже создана. Без него двойное нажатие даёт две заявки, и разбирать их будет бухгалтерия.
Самая частая ошибка сборки: считать, что модель «помнит» разговор. Она не помнит — ей каждый раз передают историю переписки, и эта история конечна. На длинном диалоге начало вытесняется, и агент забывает клиента, которого сам же определил на втором шаге. Ограничение объясняется устройством контекстного окна модели и не лечится ни формулировками, ни просьбой «помни, что клиент — ООО Ромашка».
Две схемы: цепочка и диспетчер
Собрать многошаговый сценарий можно двумя способами, и выбор между ними — это решение про деньги и отладку, а не про технологию.
| Линейная цепочка | Диспетчер | |
|---|---|---|
| Как устроено | Шаги идут в фиксированном порядке, ветвление задано условиями | Отдельный шаг решает, какой шаг следующий, на основании состояния |
| Предсказуемость | Полная: путь известен заранее и повторяем | Частичная: путь зависит от решения модели |
| Сборка семи шагов | 20–30 часов инженера | 35–60 часов инженера |
| Отладка | Простая: сбой всегда на конкретном шаге | Сложная: сбой может быть в выборе шага, а не в самом шаге |
| Расход на модель | Один запрос на шаг, где нужна модель | Плюс один запрос на каждое решение диспетчера |
| Когда брать | Процесс с известным порядком: заявка, запись, возврат, согласование | Порядок заранее неизвестен: разбор входящего письма, подбор из десятка типов операций |
На практике для процессов, которые описываются регламентом, почти всегда выигрывает цепочка. Регламент — это и есть готовый фиксированный порядок; отдавать выбор следующего шага модели, когда порядок уже определён приказом, означает платить за случайность. Диспетчер оправдан там, где вход разнородный и заранее неизвестно, что вообще пришло, — например, при разборе почты, где в одном письме может быть и заявка, и претензия, и запрос документов.
Есть и третий вариант, который часто оказывается правильным ответом: половина цепочки собирается вообще без модели. Шаги 2, 5, 6 и 7 из разбора выше — это обычная интеграция, и на них модель не нужна ни в каком виде. Такой гибрид дороже в сборке на старте и дешевле в эксплуатации; подробнее подход разобран в материале про гибридную архитектуру: правила плюс модель.
Сравнение в две колонки. Слева «Линейная цепочка»: семь блоков в ряд со стрелками по порядку, снизу подписи «20–30 часов сборки», «сбой всегда на конкретном шаге», «запрос к модели только там, где нужен разбор текста». Справа «Диспетчер»: центральный блок «диспетчер» с расходящимися к шести блокам-шагам стрелками в обе стороны, снизу подписи «35–60 часов сборки», «сбой может быть в выборе шага», «дополнительный запрос на каждое решение». Внизу общая полоса: «регламент = готовый порядок, платить за случайность незачем». Чертёжный стиль, подписи по-русски.
Отладка: журнал шагов и повтор с любой точки
Длинный сценарий невозможно отлаживать по переписке: в ней виден только вход и выход, а сломалось где-то посередине. Нужен журнал, в котором каждый шаг оставляет строку. Шесть полей достаточно.
| Поле | Что записывается | Зачем |
|---|---|---|
| Идентификатор сессии и время | Одно значение на весь диалог, отметка времени шага | Собрать все строки одного случая в порядке |
| Номер и название шага | «4. Сопоставление с номенклатурой» | Понять, где именно оборвалось |
| Вход шага | Что пришло на шаг после предыдущего | Воспроизвести шаг отдельно, не проходя всю цепочку |
| Выход шага | Что шаг вернул | Сравнить с ожидаемым |
| Результат проверки | Прошла, не прошла, ушёл вопрос клиенту | Отличить ошибку шага от срабатывания защиты |
| Версия сценария и модели | Номер редакции и идентификатор версии модели | Отличить свою правку от обновления у провайдера |
Последняя строка — та, из-за отсутствия которой разборы затягиваются на недели. Без записи версии модели невозможно понять, стал ли шаг ошибаться после вашей правки или после обновления у провайдера; подробно этот класс инцидентов разобран в материале про то, что делать, когда агент стал отвечать хуже после правки.
Второе требование к отладке — возможность повторить сценарий с любого шага, подставив сохранённый вход. Без неё воспроизведение одного сбоя на четвёртом шаге означает вручную проходить три предыдущих, и разбор десяти случаев превращается в день работы вместо часа. Технически это несколько часов при сборке и десятки сэкономленных часов за первый же квартал эксплуатации.
Нарисованный бланк журнала (не скриншот продукта) с заголовком «Журнал шагов, сессия 4412-08». Таблица на шесть колонок: «время», «шаг», «вход», «выход», «проверка», «версия сценария и модели». Семь строк по числу шагов; четвёртая строка выделена рамкой, в колонке «проверка» стоит «не прошла: два кандидата в номенклатуре», в колонке «выход» — две позиции прайса. Под таблицей кнопка-плашка «повторить с шага 4». Чертёжный стиль, подписи по-русски.
Когда сценарий пора упрощать
Каждый лишний шаг стоит дважды: в расходе на модель и в вероятности сбоя. Поэтому длину цепочки регулярно сокращают, и признаков для этого три.
- Три шага, которые всегда идут вместе. Если за месяц наблюдений шаги 3, 4 и 5 ни разу не разошлись — то есть после третьего всегда шёл четвёртый, а после четвёртого пятый, без ветвлений, — это один шаг, разрезанный из аккуратности. Слияние убирает два перехода и два запроса к модели.
- Шаг, проверка которого ни разу не срабатывала. Проверка, не поймавшая ни одной ошибки за 400 проходов, либо лишняя, либо написана так, что не ловит ничего. Разбираться стоит в обоих случаях: первый вариант экономит время, второй означает, что защиты у вас нет.
- Шаг, который всегда заканчивается вопросом человеку. Если на пятом шаге агент в 80 % случаев передаёт диалог сотруднику, шага фактически нет — есть точка выхода. Честнее сократить сценарий до четырёх шагов и передавать раньше, чем изображать семь.
Длина сценария — это не показатель зрелости системы, а статья расходов. Семь шагов должны быть обоснованы семью разными решениями, а не желанием показать, что агент умеет много.
Когда многошаговый сценарий не нужен
Сборка семишаговой цепочки с проверками, журналом и хранением состояния — это 40–70 часов инженера, то есть 120 000–210 000 ₽ по модельной ставке. Есть четыре ситуации, в которых эти деньги не окупаются, и мы говорим об этом до начала работ.
- Поток меньше 100 операций в месяц. При 420 заявках проверки окупаются за 1,2 месяца, при 80 — за шесть с лишним, и это при условии, что процесс за полгода не изменится. Ниже сотни операций дешевле оставить человека и автоматизировать подготовку, а не решение.
- Процесс ещё меняется. Сценарий из семи шагов фиксирует порядок. Если порядок пересматривается каждый месяц, каждая переработка стоит 10–20 часов, и вы платите за фиксацию того, что не устоялось. Признаки неготовности процесса собраны в материале про то, когда автоматизировать рано.
- Половина шагов — обычная интеграция. Если разбор свободного текста нужен только на входе, а остальные шесть шагов — это запросы в системы, вам нужна не цепочка агента, а интеграция с одним умным шагом. Это дешевле в сборке и надёжнее в эксплуатации.
- Цена одной ошибки высока и не восстанавливается. Списание со счёта, отгрузка без оплаты, отправка документа контрагенту. Здесь 93 % — недопустимая надёжность, и вопрос не в числе шагов: такие операции подтверждает человек, а агент только готовит. Что агент делает сам, а что только готовит, разобрано отдельно в материале про границу самостоятельности агента.
И честный итог. Многошаговый сценарий — это не «более умный бот», а инженерная конструкция со своей арифметикой надёжности, своим хранением состояния и своей отладкой. Она окупается на потоке и на повторяемости. Там, где нет ни того, ни другого, семь шагов дают только семь мест, где что-то может пойти не так.
