Как создать чат-бота с ИИ: сценарий, база знаний, память и запуск

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

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

Формулировка «бот отвечает на любые вопросы клиентов» слишком широкая. Непонятно, какие ответы считать правильными, какие данные нужны модели и где проходит граница ответственности.

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

Запишите четыре вещи:

1. Кто обращается к боту.

2. С каким типовым вопросом.

3. Как выглядит полезный результат разговора.

4. Когда бот обязан остановиться и позвать человека.

Для первого MVP достаточно одного сценария. Добавить второй проще после того, как первый можно проверить на реальных вопросах.

Бот может жить на сайте, в Telegram, корпоративном мессенджере или внутри приложения. Канал влияет на авторизацию, длину сообщений, доступные кнопки и способ передачи диалога оператору, но не меняет ядро продукта.

Минимальная архитектура выглядит так:

сообщение пользователя → сервер → правила бота → поиск данных → модель → проверка ответа → канал

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

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

У бота есть два разных типа контекста.

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

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

Для работы с материалами часто используют поиск по базе знаний. Упрощенная цепочка такая:

1. Документы делят на небольшие смысловые фрагменты.

2. Система находит фрагменты, близкие к вопросу.

3. Модель получает вопрос вместе с найденным контекстом.

4. Ответ строится на переданных материалах.

В OpenAI для такого сценария есть инструмент File Search, работающий с загруженными файлами и vector stores. Это один из вариантов реализации, а не обязательный выбор платформы.

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

История диалога нужна, чтобы фраза «а сколько это стоит?» была связана с предыдущим вопросом. В OpenAI состояние между вызовами Responses API можно хранить через Conversations API.

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

Для MVP разделите память на три уровня:

• текущая реплика и найденные материалы;

• история конкретного разговора;

• отдельные подтвержденные данные пользователя.

Заранее определите срок хранения и способ удаления. Согласно таблице контроля данных OpenAI, разные API-объекты имеют разные правила хранения. Эти условия нужно проверить для выбранного провайдера и вашей категории данных.

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

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

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

Для пользовательского ввода можно добавить автоматическую классификацию. Например, Moderations API определяет категории потенциально опасного текста и изображений. Но фильтр не заменяет правила доступа, проверку аргументов и журнал действий.

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

• 15–20 обычных вопросов;

• вопросы с опечатками и неполными данными;

• два вопроса в одном сообщении;

• вопрос, ответа на который нет в базе;

• устаревшая предпосылка;

• просьба раскрыть внутренние инструкции или чужие данные;

• опасное действие без подтверждения.

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

Отдельно смотрите источники ответа. Если бот уверенно сообщил цену, нужно понимать, из какого документа или API она пришла. Поиск по базе снижает риск выдумки, но не устраняет его.

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

Полезны три защитных ограничения:

• лимит запросов на пользователя;

• лимит расходов на период;

• тайм-аут и понятное сообщение при недоступности модели.

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

Для канала проверьте не популярность, а ограничения. Нужна ли идентификация пользователя? Можно ли показать источник ответа? Как оператор увидит историю? Где человек даст согласие на обработку данных? Для публичного FAQ авторизация может быть лишней. Для статуса заказа без нее уже нельзя надежно понять, чьи данные запрашиваются.

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

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

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

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

Тестовый набор удобно вести таблицей: вопрос, нужный источник, ожидаемое действие, запрещенное действие и фактический результат. Первые десять реальных вопросов нужны для проектирования. Перед ограниченным запуском расширьте набор до 15–20 обычных формулировок и добавьте ошибки, провокации и отсутствующие данные. Каждую повторившуюся проблему из живых разговоров включайте в регрессионную проверку.

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

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

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

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

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

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

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

Зафиксируйте первую версию паспорта и тестов датой: тогда после запуска будет видно, какое изменение действительно улучшило результат