Как на самом деле работают чат-боты: правила, поиск, LLM, инструменты и передача человеку

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

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

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

Что такое чат-бот?

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

Разговор - это интерфейс, а не базовая технология. Два чат-бота могут выглядеть одинаково, работая совершенно по-разному. Один следует дереву решений. Другой сопоставляет намерение и вызывает вебхук. Третий извлекает документы и просит большую языковую модель написать ответ. Наиболее полезные системы часто сочетают несколько подходов.

Урок от ELIZA, шестьдесят лет спустя

В 1966 году Джозеф Вейценбаум опубликовал ELIZA, программу для естественно-языкового разговора. Его известный сценарий DOCTOR использовал шаблоны и преобразования, чтобы превращать части высказывания пользователя в ответ. Предложение вроде «Я несчастлив» могло быть сопоставлено, переставлено и отражено как вопрос. Обмен мог казаться внимательным, хотя программа имела мало информации о жизни человека и не имела современной языковой модели.

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

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

Три основные архитектуры чат-ботов

Чат-боты легче понять, если разделить три архитектурных семейства. Это не строгие поколения, где каждое новое делает предыдущие устаревшими. Это инструменты с разными сильными сторонами.

1. Правила и разговорные потоки

Чат-бот на правилах следует путям, разработанным заранее. Он может показывать кнопки, сопоставлять ключевые слова, заполнять форму или переходить между состояниями при выполнении условий. Логика может быть явной: если пользователь хочет изменить дату доставки, соберите номер заказа, проверьте, подходит ли посылка, покажите доступные даты и попросите подтверждение.

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

2. Сопоставление намерений и поиск

Система на основе намерений оценивает, что пытается сделать пользователь, затем извлекает полезные детали, называемые сущностями или параметрами. «Отследить заказ 4821» может соответствовать намерению отслеживания заказа и параметру номера заказа. Документация Google Cloud по намерениям Dialogflow описывает этот шаблон как сравнение ввода с обучающими фразами для поиска совпадения .

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

3. Языковые модели, инструменты и гибридные системы

Большая языковая модель может интерпретировать разнообразные формулировки и создавать естественные ответы в гораздо более широком диапазоне вводов. Она может резюмировать, объяснять, переводить, задавать уточняющий вопрос или превращать структурированный вывод инструмента в читаемый язык. Для более глубокого объяснения генерации токенов и ограничений модели см. Что такое ИИ на самом деле?.

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

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

Что происходит во время одного хода чат-бота

Проследите за простым сообщением: «Где заказ 4821?» Реальная реализация может комбинировать или переименовывать шаги, но основные обязанности остаются узнаваемыми.

1. Получить и нормализовать ввод. Канал может предоставлять введённый текст, транскрибированную речь, выбор кнопок, язык или метаданные сеанса.
2. Определить цель. Система определяет, касается ли запрос отслеживания, отмены, оплаты, другой темы или чего-то неподдерживаемого.
3. Извлечь необходимые детали. В данном случае номер заказа - 4821. Если он отсутствует или неоднозначен, бот должен спросить, а не выдумывать.
4. Проверить состояние разговора. Система определяет, что она уже знает, что ей разрешено сохранять и какой шаг активен.
5. Получить знания или вызвать инструмент. Служба отслеживания возвращает текущий статус. Чат-бот не должен создавать этот статус из языковых шаблонов.
6. Составить и проверить ответ. Приложение превращает результат в понятный язык, проверяет обязательные поля и избегает раскрытия внутренних или личных данных.
7. Ответить, восстановиться или передать. Нормальный результат возвращается пользователю. Ошибка, неподдерживаемый случай или запрос человека следуют другим маршрутом.

Google Cloud использует термин fulfillment для части разговорного хода, которая возвращает статический ответ, вызывает вебхук для динамической информации, устанавливает параметры или выполняет действие. Его документация по fulfillment в Dialogflow проводит важное различие: понимание запроса и его выполнение - это отдельные обязанности.

Состояние разговора - это не человеческая память

Чат-боту нужно достаточно состояния, чтобы не начинать заново каждый ход. Состояние сеанса может записывать, что текущая задача - отслеживание посылки, номер заказа - 4821, и пользователь уже подтвердил почтовый индекс. Без состояния «А что насчёт второй посылки?» не имеет полезной ссылки.

Это состояние - инженерные данные, а не человеческое воспоминание. Некоторые системы хранят только текущий сеанс. Другие хранят историю разговора, сводки, предпочтения или информацию об учётной записи. Модель также может получать только часть длинного разговора, потому что её контекст имеет конечную ёмкость или потому что приложение намеренно ограничивает отправляемое.

Пользователи не должны предполагать, что чат-бот забывает, когда окно закрывается, или помнит, потому что говорит так, как будто помнит. Хранение, привязка к учётной записи, использование для обучения и удаление зависят от конкретного сервиса. Прежде чем делиться конфиденциальной информацией, изучите объяснение конфиденциальности сервиса и используйте минимум информации, необходимой для задачи.

Как работает генерация с дополнением поиском

Параметры языковой модели - плохое место для хранения часто меняющейся политики возврата. Генерация с дополнением поиском, обычно сокращаемая до RAG, решает эту проблему, выполняя поиск по внешней коллекции релевантного материала и помещая выбранные отрывки в контекст модели перед написанием ответа.

Оригинальная статья Retrieval-Augmented Generation сочетала предварительно обученный генератор с явной непараметрической памятью, извлекаемой из индекса. Этот общий шаблон теперь появляется во многих ассистентах знаний: сначала поиск, затем генерация.

Полезный конвейер RAG имеет как минимум четыре возможности для сбоя. Коллекция источников может быть неполной. Документ может быть устаревшим. Поиск может выбрать нерелевантный отрывок. Генератор может неправильно понять или приукрасить полученное. Цитаты помогают только если они указывают на точный подтверждающий источник и пользователь может его проверить.

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

Ответы и действия требуют разных уровней контроля

Чат-бот, который объясняет политику возврата, - это не то же самое, что чат-бот, который оформляет возврат. Вторая система может изменять внешнее состояние. Она может вызывать сервис учётных записей, календарь, платёжную систему, инструмент обмена сообщениями или управление устройствами. Эта способность иногда описывается как агентность, но практический вопрос проще: что это приложение может делать помимо создания текста?

Безопасный путь действий должен держать важные проверки вне прозы модели:

• Аутентифицировать пользователя и подтвердить, что учётная запись или ресурс принадлежит ему.
• Авторизовать конкретное действие, а не давать чат-боту широкий доступ.
• Проверять аргументы инструмента, суммы, назначения и допустимые диапазоны обычным кодом.
• Требовать явного подтверждения перед необратимыми или дорогостоящими действиями.
• Возвращать проверенный результат инструмента, а не предполагать, что действие удалось.
• Записывать достаточно информации для расследования сбоев, не раскрывая ненужные конфиденциальные данные.

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

Инъекция подсказок: когда контент пытается стать инструкцией

Чат-бот, использующий инструменты или поиск, может читать текст, предоставленный пользователями, веб-сайтами, электронными письмами или документами. Некоторые из этих текстов могут содержать инструкции, нацеленные на модель, например, говорящие ей игнорировать предыдущие правила, раскрывать скрытую информацию или вызывать инструмент непреднамеренным образом. Это инъекция подсказок.

Проект Проект безопасности GenAI OWASP перечисляет инъекцию подсказок как ведущий риск для приложений на языковых моделях. Основная проблема в том, что модели обрабатывают инструкции и обычный контент через один и тот же языковой канал. Недоверенный документ может выглядеть грамматически похожим на инструкцию от приложения.

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

Почему чат-боты дают неправильные или разочаровывающие ответы

Они неправильно понимают запрос

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

Им не хватает необходимой информации

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

Они генерируют уверенную ложь

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

Они теряют состояние или переносят неправильное состояние вперёд

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

У них нет изящного выхода

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

Передача человеку - часть системы, а не признание поражения

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

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

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

Как оценить, хорош ли чат-бот

Убедительную демонстрацию легко поставить. Надёжный чат-бот должен справляться с обычными вариациями и видимыми сбоями. Оценку следует начинать с задачи, которую пользователь пришёл решить.

• Завершение задачи: получил ли пользователь ответ или правильно выполнил действие?
• Обоснованность: соответствовали ли фактические утверждения предоставленному источнику или проверенному результату инструмента?
• Восстановление: приводили ли отсутствие информации, события без совпадения и сбои инструментов к полезному следующему шагу?
• Безопасность: сохранялись ли авторизация, подтверждение, обработка данных и границы инструментов при враждебных вводах?
• Качество передачи: достиг ли разговор нужного человека с достаточным контекстом?
• Язык и доступность: работал ли процесс на поддерживаемых языках, при разных стилях ввода, условиях речи, навигации с клавиатуры и с вспомогательными технологиями?
• Усилия пользователя: сколько ходов, повторений и исправлений потребовалось для завершения задачи?

Тестовые разговоры должны включать не только счастливый путь. Используйте отсутствующие номера заказов, два номера в одном сообщении, орфографические ошибки, неподдерживаемые запросы, устаревшие документы, тайм-ауты инструментов, запросы на смену темы, прямые запросы человека и вредоносные инструкции, скрытые в извлечённом контенте. Google Cloud's agent design guidance аналогично рекомендует итеративный дизайн и тестовые случаи, а не попытку спроектировать каждый путь сразу.

Как использовать чат-бот, не отказываясь от суждения

1. Сформулируйте цель и минимальный релевантный контекст. Точный запрос сокращает ненужные ходы.
2. Не вставляйте пароли, коды аутентификации, платёжные данные, закрытые ключи или конфиденциальные записи, если конкретный доверенный сервис явно не требует и не защищает такой ввод.
3. Отличайте объяснение от живого результата. Спросите, пришёл ли ответ из текущей записи, цитируемого источника или общих знаний модели.
4. Открывайте цитаты и проверяйте важные утверждения. Ссылка на источник может быть нерелевантной, устаревшей или противоречащей ответу.
5. Проверяйте каждое действие перед подтверждением. Проверяйте счёт, сумму, получателя, дату и возможность отмены изменения.
6. Просите человека, когда бот повторяется, не имеет полномочий, неправильно понимает деликатный вопрос или не может показать, откуда взялся ответ.

Ментальная модель, которую стоит сохранить

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

Лучший вопрос - не «Звучит ли этот бот по-человечески?». Спросите, понял ли он задачу, использовал ли правильные доказательства, соблюдал ли свои разрешения, честно ли восстанавливался и оставил ли вам контроль. Естественный язык делает систему более доступной. Надёжная инженерия делает её полезной.

Основные и технические ссылки

• Joseph Weizenbaum, ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
• Google Cloud, Dialogflow CX documentation for intents, fulfillment, agent design, and human handoff.
• OWASP GenAI Security Project, LLM01:2025 Prompt Injection.