Архитектура ИИ-агента: почему одной умной модели мало

Марат Тимерзянов, собираю ИИ-агентов для продаж

Умная модель — ещё не агент. Представьте нового менеджера в первый рабочий день. Он сообразительный и хочет помочь. Дайте ему только телефон, и он начнёт отвечать клиентам из головы. Назовёт цену, которую где-то слышал. ИИ-агент устроен так же. Модель — это умный новичок. Всё остальное вы ему выдаёте: прайс, правила, схему передачи заявок. Без этого он угадывает. А слабая модель не справляется даже с самими действиями.

Что выдают новичку в первый день

Языковая модель сама умеет только говорить. Она не откроет таблицу, не создаст в CRM карточку и не позвонит. Выпускник с красным дипломом, у которого нет ни рук, ни глаз. Знает много, а сделать ничего не может.

Агент добавляет к модели три вещи. Мозг: инструкцию, по которой модель себя ведёт. Память: историю разговора и базу знаний. Инструменты: функции, которыми агент читает таблицы и создаёт карточки. Работает он по кругу: увидел вопрос, подумал, сделал, проверил результат. О том, чем ИИ-агент отличается от чат-бота, у меня есть отдельная статья.

Эту схему знают все. Я разбираю её с другой стороны. Меня интересует, кто принимает решение. От этого зависит, можно ли агенту верить. В отделе продаж на каждый вопрос клиента кто-то отвечает. Агент устроен так же.

Посмотрите на таблицу. Из шести ответов модель сама подбирает слова только в последнем. В остальных она лишь озвучивает то, что решено без неё.

Слабая модель падает на первом же действии

Начну с неприятного для экономных: на модели нужно не жалеть денег там, где агент действует.

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

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

Для клиента всё выглядит гладко. Агент вежливо ответил. А карточка в CRM не появилась, и утром менеджер может не увидеть заявку. Как новичок, который кивнул «конечно, занесу» и забыл.

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

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

Вывод простой. Модель отвечает за то, сможет ли агент действовать. А можно ли ему верить, определяет всё остальное.

Что мы отнимаем у модели

Чтобы новичок не фантазировал, ему выдают справочник и правила. С агентом то же самое.

Факты лежат в таблицах. Цены и наличие агент читает в момент вопроса. Сняли тариф с продажи, и агент сразу перестаёт его предлагать. Так работает агент для онлайн-школы на GetCourse. Живой менеджер мог не заметить, что тариф сняли вчера. Таблица не пропустит.

Правила закладываются заранее. Возьмём санаторий. Категория «Комфорт» рассчитана на двоих. Гости пишут: нас четверо, берём «Комфорт». Новичок ответил бы «конечно, бронируем». Агент знает про вместимость и предлагает «Люкс» или два номера. Если цены в таблице нет, «примерно» он не подставляет. Так и говорит, что цены нет. Подробности в статье про санаторий.

Как понять, куда положить правило? Я решаю так:

• Что проверяется цифрой, идёт в таблицу. Цена, вместимость, наличие.
• Что зависит от хода разговора, идёт в инструкцию. Как ответить на «вы бот?». Когда позвать менеджера.
• Чего нельзя ни при каких условиях, идёт в запрет. Не называть цену, которой нет в таблице. Не создавать бронь самому.

Ошибки в таблице и в инструкции исправляются по-разному. Таблицу обновляют, инструкцию правят.

Администратор у входа: два уровня вместо одного

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

Уровней два. Нижний — консультант объекта. Он знает планировки и инфраструктуру одного жилого комплекса. Верхний — диспетчер на главном сайте. Он определяет город и объект и передаёт клиента нужному консультанту. Это как администратор на входе. Сам он на всё не отвечает, зато знает, к кому вести.

Зачем так? Логика простая. Чем меньше материалов в одной базе, тем меньше шансов, что агент перепутает планировку или цену. Но это логика, а не результат. Как схема поведёт себя на потоке заявок, пока неизвестно. Демо этого не покажет.

Что видит менеджер утром

Менеджер получает не голый номер телефона. В карточке лежит весь разговор: имя, состав гостей, бюджет, сроки, способ оплаты. Карточку агент создаёт в AmoCRM, Bitrix24 или Planfix. Для онлайн-школ сделка сразу появляется в GetCourse, и отдельная база не нужна.

Память работает и дальше. В email-цепочке агент держит контекст письма. Клиент вернулся через несколько дней, и начинать заново ему не нужно.

Теперь о том, чего агент не делает. Бронь в санатории он не создаёт. Данные Travelline он только читает, а закрывает бронь менеджер. Это сознательное ограничение. Лишнего агент в систему не запишет. Двойной брони не будет. Медицинских рекомендаций он тоже не даёт.

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

Частые вопросы