Чат-бот

Происхождение и история термина

Один из ранних документированных примеров диалога человека с программой — ELIZA Джозефа Вейценбаума, описанная в научной статье 1966 года. Пользователь печатал реплику, программа искала ключевые слова и перестраивала части сообщения по правилам. Сценарий задавал, какие фрагменты узнавать и как составлять ответ; он хранился отдельно от самой программы. Это позволяло менять характер разговора, не переписывая весь механизм. ^[7]

Такой способ важен для понимания эволюции предмета. Диалоговая форма уже существовала, хотя ответ возникал из обработки текста по правилам, а не из современной большой языковой модели. Вейценбаум показывал разницу между впечатлением осмысленного собеседника и понятными процедурами внутри программы. ELIZA здесь — ранний пример, а не объявленная единственная точка рождения всех чат-ботов или самого слова. ^[7]

Следующий показательный этап — включение таких программ в привычные каналы общения. Telegram открыл Bot API сторонним разработчикам 24 июня 2015 года. API, или программный интерфейс, — набор способов обращения одной программы к другой. В анонсе показаны программно управляемые аккаунты и кнопки: пользователю уже не обязательно писать свободный текст, чтобы запустить нужную операцию. Это веха конкретной платформы, не изобретение диалоговых программ. ^[4]

Развитие способов выбора ответа не отменило сценарии. IBM различает ботов с заданными правилами и ботов с искусственным интеллектом; последние могут использовать большие языковые модели. ^[6] В учебном курсе Google описано, как генерирующая модель продолжает историю диалога новым текстом. ^[8] Поэтому эволюцию удобно видеть как расширение возможностей: от преобразования реплик по правилам к работе в разных каналах и созданию новых ответов. Это не означает, что каждый новый бот обязан использовать все эти возможности.

Суть и механизм

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

В Telegram бот связан с сервером владельца, который обрабатывает обращения; Bot API связывает его с платформой. ^[3] Для пользователя разговор выглядит единым, хотя интерфейс и обработка находятся в разных частях системы.

Microsoft различает событие взаимодействия и ход обработки: бот принимает входящее событие и может отправить ответные события. Возможности каналов различаются, поэтому документация требует проверять функции в каждом используемом канале. ^[1] Простая аналогия — бланк и содержание заявления. Доставка заполненного бланка ещё не означает принятого по нему решения.

Учебный пример: бот районного издания принимает сообщения об ошибках. Читатель пишет: «В статье неверно указано время встречи». Это событие. Бот запрашивает ссылку на публикацию. Теперь разговор находится на шаге ожидания ссылки: это состояние. Когда ссылка получена, программа регистрирует обращение: это действие. Фраза «Сообщение передано редактору» — ответ. Ни один из этих шагов пока не доказывает, что читатель прав или что материал исправлен.

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

В Dialogflow CX состояния разговора представлены страницами, намерение обозначает тип запроса пользователя, а параметры содержат извлечённые значения. Например, намерение может соответствовать сообщению об ошибке, параметр — адресу публикации. Вебхук — обращение к сервису с внешней логикой — позволяет проверять данные и запускать операции. Это устройство конкретной платформы, а не словарь, обязательный для любого бота. ^[2]

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

Виды и классификации

Ниже — авторская классификация по устройству работы, а не перечень официальных видов. Она помогает выбрать предмет обсуждения: какие сообщения принимает система, как выбирает ответ и что вправе делать.

Кнопочный бот не обязательно прост по устройству. Одна кнопка может запускать проверку наличия товара во внешней системе. И наоборот, свободный текст не означает неограниченного понимания: программа может лишь выбирать из небольшого списка намерений. Поэтому проектное описание должно называть поддерживаемые задачи, а не ограничиваться словами «умный» или «автоматический».

Большая языковая модель, или LLM (large language model), — нейросетевая модель, обученная на больших массивах текста предсказывать его фрагменты с учётом контекста. Такой фрагмент называют токеном: это может быть слово, часть слова или знак. ^[8]

Генерирующая модель последовательно добавляет фрагменты и так создаёт ответ; Google отдельно описывает продолжение истории диалога. ^[8] В учебном примере она могла бы сформулировать вежливое уточнение ссылки, но сама эта фраза не зарегистрировала бы обращение. В предложенной редакцией схеме даже для такого решения отдельно задаются разрешённые действия, источники справочной информации и путь к человеку. Способ написания ответа сам по себе не подтверждает ни правильность факта, ни полномочия менять заказ.

Средства разработки тоже меняются. Microsoft сообщает об архивировании Bot Framework SDK и Emulator и прекращении обслуживания обращений по SDK с 31 декабря 2025 года. SDK — набор средств для разработчика. ^[1] Поэтому описанные понятия полезны для понимания диалога, но старую инструкцию нельзя автоматически принимать за выбор поддерживаемого инструмента для нового проекта.

Как применяется на практике

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

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

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

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

Международные документы показывают разные части такого устройства: Microsoft — обмен событиями, Google — сценарии и переходы, Telegram — связь бота с платформой. ^{[1, 2, 3]} В российском проекте дополнительно оценивают состав и сроки хранения персональных данных по статье 5 закона № 152-ФЗ. ^[5] Это не отдельный «российский тип» бота: правовые условия добавляются к техническому процессу.

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

Как измерить или проверить

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

Формула доли завершения: D = Z / N × 100%. Здесь D — доля завершённых задач в процентах; Z — число подтверждённо завершённых задач; N — все начатые задачи за выбранный период. При N = 0 процент не вычисляют. Числитель и знаменатель относятся к одной группе: нельзя делить сегодняшние завершения по старым обращениям только на сегодняшние новые обращения.

Учебный расчёт: начато 200 задач, автоматически завершены 120, с помощью оператора — ещё 30, не завершены 50. Тогда общая доля D = (120 + 30) / 200 × 100% = 75%. Автоматически завершены 120 / 200 × 100% = 60% всех начатых задач. Это вымышленные данные, не отраслевые нормативы. Доля автоматических среди завершённых составит уже 120 / 150 × 100% = 80%: другой знаменатель отвечает на другой вопрос.

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

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

Время первой реплики и время решения измеряют раздельно. Мгновенное приветствие не означает быстрой помощи. Проверять нужно весь маршрут, включая фактическое получение задачи оператором. Испытания в одном интерфейсе не заменяют испытаний в остальных используемых каналах. ^[1]

Ошибки, ограничения и спорные вопросы

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

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

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

Наконец, накопленная переписка не равна полезной памяти. В учебном проекте сохраняют только сведения, необходимые для определённой задачи. Случайно присланные пользователем лишние данные требуют отдельного порядка обработки; их не стоит превращать в обязательное поле анкеты. Российские принципы неизбыточности и ограничения хранения закреплены в статье 5 № 152-ФЗ. ^[5]

Правовой аспект

Статья 5 Федерального закона № 152-ФЗ в редакции от 26.07.2026 требует законной обработки, заранее определённых целей и соответствия этим целям состава данных. Часть 7 ограничивает хранение в форме, позволяющей определить человека, сроком, нужным для целей обработки, с предусмотренными законом исключениями. ^[5] Следовательно, желание «сохранить весь чат на будущее» само по себе не объясняет необходимость такого хранения.

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

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

Связанные термины

• Telegram-бот
• Чат-бот в MAX
• SMM
• Лидогенерация
• Персональные данные
• Пользовательское соглашение