Содержание
- Инструкции
- Шаги и данные
- Сигналы
- База знаний
- Каталог
- Напоминания
- Передача оператору и владение диалогом
- Изменения и тестирование
Здесь собраны типичные ошибки настройки агента — что именно идёт не так, почему это ломает поведение и как сделать правильно. Многие из этих ошибок незаметны «на бумаге» и проявляются только в работе, поэтому каждое изменение стоит проверять в тестовом чате (см. «Тестирование и отладка»).
Инструкции
Слабо прописанный основной промпт. Описать агента парой строк вроде «Ты помощник, помогай клиентам» и ждать осмысленного поведения. Без чёткой основы агент не понимает, кто он, что должен делать и где его границы, — и начинает додумывать. В основном промпте обычно стоит прописать: идентичность и роль агента; основную задачу и цели работы; общие правила общения и поведения; ключевые обязанности; ограничения и требования безопасности; краткое описание предметной области (компании, бизнеса); правила использования базы знаний и других источников. Подробно — «Основной промпт».
Перегруженный основной промпт. Складывать в один промпт всё подряд — правила, ветвления, частные случаи — и надеяться, что агент всё удержит. Чем длиннее и противоречивее инструкция, тем хуже агент ей следует. Держите основной промпт коротким: о том, кто такой агент и какие у него задачи, — а логику выносите в шаги, условия и сигналы.
Ветвящаяся логика словами вместо механизмов. Описывать в промпте «если клиент такой — сделай одно, иначе другое» вместо того, чтобы собрать это шагами и условиями. Текстовые «если-иначе» агент выполняет ненадёжно. Ветвление — через шаги и переходы с условиями, сбор данных — через поля шага.
Конфликтующие правила в разных слотах. Один слот велит одно, другой — обратное, и агент мечется между ними. Следите, чтобы слоты дополняли друг друга, а не спорили; противоречие обычно сразу видно в тестовом чате по «мыслям» агента. Подробно про слоты — «Инструкции».
Изменчивые данные прямо в промпте. Цены, сроки, условия доставки, вписанные в инструкцию, приходится править в промпте, и их легко забыть обновить. Такие данные — в базу знаний: агент достанет их по запросу, и менять их можно в одном месте.
Не следить за накопленным контекстом. Сохранённый контекст сценария и инструкции, которые шаги добавляют агенту, копятся в его задачах — невыполненные инструкции не исчезают сами по себе — и сильно влияют на его решения. Если их не чистить — наваливать всё новые указания и не убирать устаревшие, — агент тонет в противоречивых инструкциях и теряет фокус. Особенно коварно это при отключённой автоматической очистке контекста при закрытии диалога (см. «Настройки агента»): тогда устаревшие данные и установки переезжают в следующий диалог того же чата и продолжают влиять на агента там, где они уже не нужны. Сохраняйте в контекст только действительно важное, вовремя обновляйте и снимайте устаревшее.
Шаги и данные
Слишком много полей в одном шаге. Шаг, который пытается собрать сразу десяток значений, заставляет агента путаться, что и когда спрашивать. Дробите на несколько шагов по смыслу.
Всё подряд обязательное. Если пометить обязательными поля, без которых на деле можно продолжить, шаг не завершится и агент застрянет. Обязательными делайте только то, без чего шаг действительно не имеет смысла.
Невнятные названия и описания. Поля и шаги с размытыми или неотличимыми названиями — агент не понимает, что куда собирать и когда шаг уместен. Давайте понятные, различимые названия; описание добавляйте только там, где оно несёт реальный смысл, а не дублирует название. Подробно — «Шаги сценария».
Шаг всегда доступен, но непонятно зачем. Шаг виден агенту постоянно, без условий и без понятной инструкции, когда им пользоваться, — и агент вызывает его невпопад. Ограничивайте доступность видимостью и условиями либо давайте чёткую инструкцию, в каком случае шаг применять.
Скрытый ключевой шаг, к которому нельзя вернуться. Обратная крайность: важный структурный шаг или развилку сценария прячут сразу после прохождения. Пока клиент идёт строго вперёд, всё хорошо, но стоит ему передумать — поменять выбор, исправить ответ, сменить намерение — и агент не может вернуться к нужному шагу, потому что тот уже недоступен. Правило простое: ключевые шаги и развилки оставляйте открытыми и после прохождения, чтобы агент мог к ним вернуться; скрывайте промежуточные шаги и переходы между ветками — те, что нужны лишь по разу, — чтобы не захламлять доступный агенту набор действий. Подробно про видимость — «Шаги сценария».
Сигналы
Сигналы «на всякий случай». Каждый сигнал — это отдельная работа системы и дополнительные расходы, а лишние ещё и зашумляют картину. Заводите только те сигналы, на которые действительно завязаны шаги или условия.
Размытое описание сигнала. Сигнал с расплывчатым описанием срабатывает невпопад. Описание должно быть чёткой инструкцией, по которой однозначно понятно, когда сигнал считается установленным.
Не учли переоценку сигнала на каждом сообщении. Сигналы переоцениваются на каждое новое сообщение клиента, и шаг по сигналу может срабатывать снова при каждой новой установке значения. Если повторная оценка не нужна, так и напишите в описании сигнала: переоценивать не требуется, значение устанавливается один раз, а сбросит его закрытие диалога. Если же сигнал, наоборот, должен быть «живым» и отслеживать изменение контекста, это тоже стоит указать в описании: когда ситуация изменилась и сигнал больше не актуален, его можно снять. Подробно — «Сигналы».
База знаний
Сваливать всё в один документ. Один огромный документ «обо всём» плохо ищется: на запрос клиента система возвращает агенту документ целиком, и вместе с нужным абзацем приходит куча постороннего текста, который размывает релевантность и сбивает агента. К тому же у такого документа одно общее описание, по которому трудно понять, что внутри. Разбивайте материал на отдельные документы по темам, давайте понятные названия и описания, раскладывайте по секциям.
Не проверять, что распозналось из загруженного файла. Файлы и ссылки система превращает в текст, и на сложных документах — особенно PDF с таблицами, колонками или сканами — распознавание может исказить содержимое или потерять часть. Если этот текст не проверить, агент будет отвечать по испорченному источнику. После обработки откройте документ, посмотрите, какой текст из него извлёкся, и поправьте ошибки распознавания вручную.
Забывать закрывать неотвеченные вопросы. Когда включено пополнение базы из неотвеченных вопросов, агент складывает вопросы, на которые не нашёл ответа, как документы «вопрос-ответ» в статусе «на модерации» — агенту они пока недоступны, потому что ответа в них ещё нет. Если их не просматривать и не дописывать ответы, база не растёт, а агент раз за разом спотыкается на одних и тех же вопросах. Регулярно разбирайте вопросы на модерации и закрывайте их ответами. Подробно — «База знаний».
Каталог
Рассчитывать, что агент вытянет плохой каталог. Подбор товаров не может быть лучше самого каталога. Если структура запутанная, у товаров мало описаний или нет характеристик, по которым клиенты на самом деле выбирают (размер, цвет, назначение, совместимость), агенту просто не на что опереться — он будет предлагать не то или не находить ничего. Инструкциями это до конца не компенсировать. Готовьте каталог под подбор: понятные категории, заполненные описания и ключевые характеристики товаров; а особенности структуры и наиболее надёжные поля дополнительно поясняйте агенту в инструкциях по работе с каталогом. Подробно — «Подагент для работы с каталогом».
Напоминания
Создавать без плана отмены. Если ставить напоминания и не продумывать, когда они снимутся, клиента легко завалить сообщениями — вплоть до жалоб и блокировки номера. Сразу закладывайте условия отмены (клиент ответил, разговор ушёл по другой ветке, цепочка закончилась).
Дублировать системное напоминание своим. Включить и системное «ожидание ответа», и собственное напоминание на ту же роль — клиент получит два. Выберите что-то одно.
Сразу строить агрессивную цепочку. Длинная последовательность напоминаний, выстроенная с ходу, чаще раздражает, чем возвращает клиента. Начинайте с одного-двух и наращивайте, глядя на реакцию. Подробно — «Отложенные действия».
Передача оператору и владение диалогом
Не учитывать, на ком сейчас диалог. Настраивать события так, будто диалог всегда на боте. Пока диалог ведёт менеджер, агент в переписку не вмешивается — и шаги, рассчитанные на ответ клиенту, просто не сработают так, как вы ждёте. Учитывайте ответственного за диалог и режимы запуска агента (см. «События чатов»).
Событийный шаг пишет клиенту поверх менеджера. Шаг по таймеру или событию отправляет сообщение, хотя диалог уже забрал человек, — агент влезает в живой разговор оператора. Проверяйте владение диалогом, прежде чем отправлять сообщение по событию.
Не учли порядок событий в начале диалога. Когда клиент пишет впервые, события приходят не по одному, а связкой, и шаги, настроенные на них, отрабатывают в таком порядке: сначала «Сообщение от клиента» — ещё до того, как диалог назначен на агента; затем «Назначение диалога» — диалог переходит к агенту и агент запускается; и только дальше каждое следующее сообщение приходит снова как «Сообщение от клиента», но уже с диалогом на агенте. Это важно при настройке обработки через шаги по событиям: то же самое событие «Сообщение от клиента» в первый раз срабатывает без назначенного диалога, а потом — с назначенным. Если шаг на этом событии рассчитан на уже работающего агента, на первом сообщении он поведёт себя не так, как вы ждёте. Подробно — «События чатов».
Изменения и тестирование
Править запущенную версию вживую. Менять поведение прямо в работающей версии рискованно: ошибку сразу увидят реальные клиенты. Изменения, затрагивающие логику, проводите через новую версию (см. «Версии и статусы агента»).
Проверить один раз и выпустить. Агент недетерминирован: один удачный ответ ещё не значит, что он будет так отвечать всегда. Важные сценарии прогоняйте по несколько раз, прежде чем доверять агенту реальный трафик (см. «Тестирование и отладка»).