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