Проверка ИИ-продавца: как замечать ошибки после запуска

Как заметить, что ИИ-продавец стал отвечать хуже, если жалоб пока нет? Раз в неделю возвращайте ему небольшой постоянный набор вопросов и добавляйте спорные разговоры последних дней. Сравнивать нужно ответ, использованные данные и действие после ответа: обещание «передал менеджеру» ещё ничего не говорит о том, получил ли менеджер обращение.

Особенно полезен такой разбор после смены модели, правки инструкции или обновления каталога. Вопрос покупателя может остаться прежним, а причина ошибки — измениться. Если каждый раз смотреть только новые удачные диалоги, это легко пропустить.

Что проверять у ИИ-продавца после запуска?

Проверяйте три вещи: правильно ли помощник понял покупателя, взял ли актуальные сведения и выполнил ли разрешённое действие. Для повторного сравнения сохраняйте вопрос, версию инструкции, снимок исходных данных и наблюдаемый результат. Итогом разбора становится конкретное исправление с ответственным.

Это отличается от первой приёмки. Перед запуском вы выясняете, способен ли продавец вообще пройти нужный путь. После запуска задача другая: сохранить этот путь, когда меняются товары, цены, каналы и настройки. Еженедельный разбор диалогов и доработка слабых мест входят в работу Никиты Сашина с первой линией; ниже порядок, который можно повторить самому.

Разделите вопросы на два списка. В постоянном списке — обычный подбор, отсутствие товара, неполные данные, просьба о скидке и передача человеку. Во втором — новые затруднения из разрешённой переписки. Первому списку нужны устойчивые условия, чтобы сравнение имело смысл. Второй помогает находить то, о чём вы раньше не подумали.

Постоянная проверка хорошо обнаруживает возвращение уже исправленной ошибки. Однако покупатели способны спросить иначе, поэтому рядом с точной исходной фразой полезно держать одну переформулировку. Например: «Есть этот ноутбук?» и «Могу сегодня забрать именно эту модель?» Второй вопрос добавляет срок и проверяет, не превратит ли помощник справочное наличие в обещание выдачи.

Откуда брать разговоры и что оставить в записи

Для разбора подходят диалоги, которые компания вправе использовать внутри своей работы. Уберите имена, телефоны, адреса, номера заказов и другие детали, по которым можно узнать человека. Сохраните сведения, от которых зависит решение: товар, запрошенное действие, относительный срок, источник цены. Если существенную деталь пришлось заменить, отметьте замену в рабочей записи.

Выбирайте разговоры по причине включения. Один показывает обычный путь, другой — отказ источника, третий — непонятную просьбу, четвёртый — жалобу. Выбор только по признаку «длинная переписка» оставляет без внимания короткие ошибки: неверная цена часто помещается в одно предложение.

Для каждого примера запишите:

• вопрос и необходимый предыдущий контекст;
• ожидаемое поведение: какой факт или действие должны появиться;
• откуда берётся факт и на какой момент он действителен;
• что сделал помощник и чем закончилась передача;
• причину ошибки, решение и ответственного.

Сведения о покупках и оплатах берутся из учётной системы. Фразу покупателя «приеду» можно учитывать как намерение посетить магазин, но смешивать её с оплаченной покупкой нельзя. Так журнал качества останется журналом качества, а отчёт о продажах — отчётом о продажах.

Три похожие жалобы — три разных исправления

Вот вымышленный магазин ноутбуков. В его каталоге модель N14 стоит 54 000 ₽. Жалобы в журнале звучат одинаково: «бот подвёл покупателя».

В первом случае бессмысленно обновлять исправный каталог: это ошибка в ответе модели. Во втором новая формулировка промпта оставит старую цену на месте. В третьем красивый ответ маскирует незавершённое действие. Поэтому до правки инструкции стоит открыть именно тот источник и тот результат действия, которые были у помощника во время разговора.

Как сравнивать версии на одних условиях?

Повторите одинаковые сценарии на прежней и новой настройке, сохранив одинаковые входные данные. Записывайте версию инструкции, выбранную модель, версию каталога и состояние интеграции. Если условия различались, сначала объясните это различие; один удачный ответ новой версии ещё не показывает устойчивого улучшения.

В руководстве Anthropic по оценке агентов разделяются история выполнения и конечное состояние системы. Для бизнеса это понятное различие: помощник мог написать правильные слова, но бронь или обращение должны действительно появиться там, где с ними работает команда. Авторы также советуют повторять попытки, поскольку ответы модели могут различаться.

В журнале магазина можно использовать такие отметки:

Таблица показывает, как устроен журнал. Для своего помощника рядом с отметкой сохраните ответ и подтверждение действия: запись «всё хорошо» через неделю уже не поможет восстановить, что именно проверяли.

После исправления верните не только проблемный вопрос, но и соседние. Запрет отвечать без свежего каталога может защитить цену и одновременно остановить ответы о графике магазина. Проверка обычного вопроса рядом с аварийным покажет такую потерю.

Какие ошибки исправлять первыми

Сначала остановите действия, которые могут привести к неверному заказу, раскрытию данных или потере обращения. В зависимости от устройства системы это может быть временная передача конкретного сценария человеку. Остальные ответы продолжают работать, если их путь не затронут.

Следом идут ошибки фактов и выбора: другая модель товара, недействующая цена, неверное условие доставки. Неловкий оборот и лишнее приветствие тоже можно поправить, но они не должны вытеснять разбор пропавшей заявки.

Один общий процент скрывает разницу между такими событиями. Лучше видеть отдельно число проверенных разговоров, ошибки цены, ошибки действия и замечания к формулировкам. Если проверено мало примеров, оставьте их количество рядом с результатом. Набор из нескольких выбранных диалогов описывает эти диалоги; оценить весь поток по нему трудно.

У каждой причины свой владелец. Каталогом занимается тот, кто отвечает за данные; доставкой обращения — ответственный за интеграцию; правилами разговора — человек, который принимает работу первой линии. Тогда дефект перестаёт переезжать между «это бот» и «это CRM».

Что должно остаться после еженедельного разбора

Короткий список решений полезнее пересказа всей переписки. У каждого решения должны быть исходный пример, причина, изменение и условие повторной проверки. Если требуется доступ или информация от другой команды, запишите это как незавершённую задачу с ответственным.

Для передачи в CRM в журнале достаточно ссылки на сценарий проверки и его результата: так не придётся переписывать порядок интеграции в каждом отчёте.

К Никите можно обратиться с задачей разбора действующей первой линии: подготовьте несколько разрешённых обезличенных диалогов, желаемый следующий шаг и описание источника товаров. Актуальное предложение и контакт находятся в профиле Никиты Сашина. Состав сопровождения обсуждается по задаче.

С чего начать сегодня

Возьмите один обычный разговор и один спорный, уберите личные данные и запишите, каким должен быть следующий шаг. Проверьте цену или условие в источнике, затем сравните с ответом и результатом передачи. Уже эта пара покажет, что требуется исправлять первым: данные, поведение помощника или доставку обращения.

После исправления повторите оба разговора и сохраните результат рядом с прежним. На следующем разборе начните с этой пары, а затем добавьте новый затруднительный вопрос. Так журнал постепенно собирается из вашей работы, а не из абстрактного списка проверок.

Что почитать дальше

• Подбор товара из каталога: как ИИ-продавец подбирает товары из каталога магазина.
• Интеграция Авито и amoCRM: как проверить передачу заявки без дублей.