Telegram-бот с базой знаний принимает вопрос пользователя, ищет подходящий фрагмент текста в загруженных документах, формирует ответ с точной цитатой источника и передаёт диалог оператору, если база не содержит релевантной информации. Такая архитектура позволяет автоматизировать типовые запросы и сохранить контроль над качеством информации.
Источники: как формируется база знаний
База знаний состоит из текстовых документов, которые бот сможет процитировать. Выбор формата и структуры источников определяет точность поиска и удобство обновления.
Форматы хранения зависят от объёма и частоты изменений. Небольшие базы до 50 000 слов удобно держать в виде JSON-файлов или простых текстовых документов, разделённых на параграфы. Средние базы от 50 000 до 500 000 слов требуют индексации: здесь подходит SQLite или PostgreSQL с полнотекстовым поиском. Крупные базы свыше 500 000 слов эффективнее обрабатывать с помощью векторных баз данных, где каждый фрагмент текста представлен численным вектором, и поиск идёт по семантической близости.
Структура документа должна обеспечивать атомарность фактов. Каждый параграф или раздел содержит законченную мысль, которую можно процитировать отдельно. Удобно разделять большие тексты на фрагменты по 200–400 слов, сохраняя для каждого заголовок, дату обновления и уникальный идентификатор. Такая сегментация упрощает ссылки на конкретную часть документа и ускоряет поиск.
Метаданные помогают фильтровать результаты поиска. К каждому фрагменту прикрепляют категорию, теги, автора или версию. Когда пользователь уточняет запрос, бот сначала фильтрует по метаданным, затем ищет по тексту. Это снижает количество нерелевантных совпадений.
Обновление и версионирование
База знаний требует регулярного пересмотра. Устаревшие фрагменты помечают флагом «архив» или удаляют, новые добавляют с актуальной датой. Полезно вести журнал изменений, чтобы отследить, когда и почему была изменена формулировка. Это особенно важно для справочных баз, где точность формулировок критична.
При добавлении нового документа его разбивают на фрагменты, генерируют векторы или индексы, сохраняют метаданные и помечают как активные. Старую версию переносят в архив. Если требуется откат, архивный фрагмент восстанавливают.
Приём сообщений через Telegram Bot API
Бот получает текстовые сообщения от пользователей через Telegram Bot API, который представляет собой HTTP-интерфейс для отправки и получения обновлений.
Существуют два способа получения обновлений: длинный опрос (long polling) и webhook. Длинный опрос подходит для разработки и небольших нагрузок: бот периодически запрашивает новые сообщения методом getUpdates. Webhook рекомендуется для продакшена: Telegram отправляет обновления на указанный HTTPS-адрес сразу после получения сообщения. Согласно официальному FAQ, webhook защищают секретным токеном и скрытым путём, чтобы исключить подмену запросов.
При настройке webhook необходимо валидный TLS-сертификат и открытый порт 443, 80, 88 или 8443. Telegram отправляет POST-запрос с JSON-телом, содержащим объект Update. Бот парсит поле message.text, извлекает идентификатор чата и пользователя, затем передаёт текст в модуль поиска.
Обработка команд и свободного текста
Команды начинаются с символа / и обрабатываются отдельно. Типовые команды: /start для приветствия, /help для справки, /operator для немедленной передачи человеку. Свободный текст без команды считается вопросом к базе знаний.
Удобно логировать все входящие сообщения с временной меткой и chat_id. Это позволяет анализировать популярные запросы и выявлять пробелы в базе знаний.
Поиск: от запроса до релевантного фрагмента
Модуль поиска принимает текст сообщения и возвращает список фрагментов с оценкой релевантности. Архитектура поиска зависит от размера базы и требований к точности.
Полнотекстовый поиск работает быстро на базах до нескольких сотен тысяч слов. Запрос разбивается на токены, удаляются стоп-слова, применяется стемминг или лемматизация. База индексируется заранее, и поиск идёт по инвертированному индексу. Релевантность оценивается по частоте совпадения токенов и позиции в документе.
Векторный поиск использует модели эмбеддингов, которые преобразуют текст в числовой вектор фиксированной длины. Запрос пользователя преобразуется в вектор, затем вычисляется косинусное расстояние до векторов всех фрагментов базы. Фрагменты с наименьшим расстоянием считаются наиболее релевантными. Такой подход эффективен для семантически близких, но лексически разных запросов: «как оплатить» и «способы платежа» будут близки по вектору.
Гибридный подход комбинирует полнотекстовый и векторный поиск. Сначала полнотекстовым методом отбирается 50–100 кандидатов, затем векторная модель переранжирует их по семантической близости. Это снижает вычислительную нагрузку и повышает точность.
Порог релевантности
Критически важен порог, ниже которого ответ не отправляется. Если лучший фрагмент имеет оценку релевантности ниже заданного порога, бот сообщает, что не нашёл ответа, и предлагает связаться с оператором. Типовые пороги: для полнотекстового поиска — 0,3 по нормализованной оценке BM25, для векторного — косинусное сходство выше 0,7. Пороги подбираются на тестовой выборке запросов.
| Метод поиска | Скорость | Точность на синонимах | Сложность настройки |
|---|---|---|---|
| Полнотекстовый | Высокая | Низкая | Низкая |
| Векторный | Средняя | Высокая | Средняя |
| Гибридный | Средняя | Высокая | Высокая |
Формирование ответа с цитатой
Когда релевантный фрагмент найден, бот формирует сообщение, включающее прямую цитату источника и ссылку на документ. Такая структура повышает доверие пользователя и позволяет проверить информацию.
Ответ состоит из трёх частей: краткого вступления, цитаты и указания источника. Вступление формулируется шаблонно или генерируется языковой моделью, чтобы связать вопрос и цитату. Например, на вопрос «Как вернуть товар?» вступление может быть: «Возврат товара регулируется следующим образом:». Затем идёт цитата, заключённая в кавычки или выделенная форматированием Telegram (курсив или блок blockquote). В конце указывается название документа, раздел и дата обновления.
Если найденный фрагмент слишком длинный, его сокращают до 300–500 слов, сохраняя ключевые предложения. Удобно использовать алгоритмы экстрактивного суммаризации, которые выбирают наиболее информативные предложения по оценке TF-IDF или векторной близости к запросу.
Форматирование в Telegram
Telegram поддерживает Markdown и HTML-разметку в сообщениях. Удобно выделять цитату курсивом или жирным шрифтом, а ссылку на источник делать кликабельной. Метод sendMessage принимает параметр parse_mode со значением Markdown или HTML. Важно экранировать специальные символы, чтобы избежать ошибок парсинга.
Пример структуры ответа:
Возврат товара возможен в течение 14 дней с момента покупки при наличии чека и целой упаковки.
Источник: Политика возврата, раздел 3.2, обновлено 2026-09-15
Эскалация: передача оператору
Когда база знаний не содержит ответа или пользователь явно запрашивает помощь человека, диалог передаётся оператору. Эскалация требует механизма очередей, уведомлений и переключения контекста.
Триггеры эскалации: оценка релевантности ниже порога, команда /operator, повторный вопрос после неудачного ответа, упоминание слов «оператор», «человек», «менеджер». При срабатывании триггера бот отправляет сообщение: «Передаю ваш вопрос оператору. Ожидайте ответа.» и помещает chat_id в очередь ожидания.
Очередь обрабатывается в порядке поступления или по приоритету. Оператор получает уведомление в отдельном интерфейсе: веб-панели, специальном Telegram-чате или CRM. Уведомление содержит историю диалога, последний вопрос пользователя и контекст поиска (какие фрагменты были найдены, но не использованы).
Роутинг и статусы диалога
Диалог может находиться в одном из статусов: bot (обрабатывается ботом), queue (ожидает оператора), operator (в работе у оператора), closed (завершён). Смена статуса логируется с временной меткой. Когда оператор принимает диалог, статус меняется на operator, и все сообщения пользователя пересылаются напрямую оператору. Ответы оператора отправляются пользователю через Bot API методом sendMessage.
После решения вопроса оператор закрывает диалог, статус меняется на closed, и следующее сообщение пользователя снова обрабатывается ботом. Полезно запрашивать обратную связь: «Ваш вопрос решён? Оцените помощь.»
| Статус диалога | Описание | Кто отвечает |
|---|---|---|
| bot | Вопрос обрабатывается автоматически | Бот |
| queue | Ожидание свободного оператора | Никто |
| operator | Диалог ведёт человек | Оператор |
| closed | Вопрос решён, диалог завершён | Никто |
Рабочий процесс: от загрузки базы до ответа
Полный цикл работы бота включает несколько этапов: подготовку базы, настройку поиска, подключение к Telegram, обработку сообщений, эскалацию и анализ диалогов.
Начальная настройка начинается с загрузки документов. Тексты очищаются от лишнего форматирования, разбиваются на фрагменты, генерируются метаданные. Если используется векторный поиск, для каждого фрагмента вычисляется эмбеддинг и сохраняется в векторной базе. Для полнотекстового поиска строится инвертированный индекс.
Далее создаётся бот через BotFather, получается токен доступа. Настраивается webhook или long polling. Бот регистрирует обработчики для команд и текстовых сообщений.
При получении сообщения бот проверяет статус диалога. Если статус operator, сообщение пересылается оператору. Если статус bot, запускается поиск. Модуль поиска возвращает список фрагментов с оценками. Если лучшая оценка выше порога, формируется ответ с цитатой и отправляется пользователю. Если ниже — включается эскалация.
Обработка сбоев
Сбои возможны на уровне API Telegram, базы данных или модуля поиска. Важно обернуть каждый внешний вызов в обработчик исключений. Если отправка сообщения не удалась, запрос повторяется с экспоненциальной задержкой. Если база данных недоступна, бот переключается в режим эскалации всех запросов до восстановления.
Логирование критично для диагностики. Каждый запрос фиксируется с идентификатором, временной меткой, текстом, результатами поиска и финальным статусом. Это позволяет воспроизвести проблему и проверить корректность ответов.
Условный пример: бот техподдержки интернет-магазина
Представим интернет-магазин электроники, который создаёт бота для ответов на вопросы о доставке, возврате, гарантии и оплате. База знаний состоит из 20 документов общим объёмом 80 000 слов, разбитых на 400 фрагментов. Используется полнотекстовый поиск на PostgreSQL с расширением pg_trgm для поддержки триграмм и морфологии.
Пользователь спрашивает: «Сколько стоит доставка в регионы?». Бот токенизирует запрос, ищет фрагменты, содержащие слова «доставка», «стоит», «регионы». Находится фрагмент с оценкой 0,78 из раздела «Доставка и оплата»: «Стоимость доставки в регионы России рассчитывается тарифами транспортной компании, минимальная сумма 350 рублей». Бот отправляет сообщение с цитатой и ссылкой на раздел справки.
Следующий вопрос: «Можно ли вернуть ноутбук после 20 дней?». Поиск возвращает фрагмент с оценкой 0,45, что ниже порога 0,5. Бот отвечает: «Не нашёл точной информации. Передаю вопрос оператору.» Диалог переходит в очередь. Оператор видит вопрос, проверяет условия возврата и отвечает: «Возврат технически сложного товара возможен в течение 14 дней. Через 20 дней можно обратиться в сервисный центр по гарантии.» Диалог закрывается, пользователь оценивает помощь.
Через неделю в лог-файлах обнаруживается 12 запросов про возврат через 20 дней. Команда добавляет в базу знаний отдельный фрагмент с разъяснением сроков гарантийного обслуживания, и следующие аналогичные вопросы обрабатываются автоматически. Это пример итеративного улучшения базы на основе реальных запросов.
Проверка качества ответов
Качество ответов оценивается по нескольким метрикам: точность (процент корректных ответов среди всех автоматических ответов), полнота (процент вопросов, на которые бот ответил без эскалации), скорость ответа и удовлетворённость пользователей.
Точность проверяется вручную на случайной выборке диалогов. Эксперт читает вопрос, ответ бота и цитату, оценивает, соответствует ли ответ вопросу. Если в 95 из 100 проверенных диалогов ответ корректен, точность составляет 95%. Целевое значение — выше 90%.
Полнота измеряется долей автоматических ответов от общего числа вопросов. Если из 1000 вопросов 700 обработаны ботом, а 300 переданы оператору, полнота 70%. Рост полноты указывает на улучшение базы знаний, но важно не жертвовать точностью.
Скорость ответа фиксируется в логах: время между получением сообщения и отправкой ответа. Целевое значение — менее 2 секунд для полнотекстового поиска, менее 5 секунд для векторного.
A/B-тестирование порогов
Изменение порога релевантности влияет на баланс между точностью и полнотой. Повышение порога снижает количество некорректных ответов, но увеличивает эскалацию. Понижение порога увеличивает охват, но растёт риск нерелевантных ответов. Удобно разделить пользователей на две группы и применить разные пороги, затем сравнить метрики. Оптимальный порог выбирается по максимуму взвешенной суммы точности и полноты.
Типичные ошибки при проектировании
Первая ошибка — слишком крупные фрагменты базы знаний. Если документ не разбит на параграфы, бот может процитировать весь многостраничный текст. Пользователь не прочитает такой ответ. Оптимальный размер фрагмента — 200–400 слов.
Вторая ошибка — отсутствие порога релевантности. Бот отвечает на любой запрос, даже если совпадение слабое. Это создаёт ложное ощущение компетентности и подрывает доверие. Лучше честно сообщить, что ответа нет, и передать оператору.
Третья ошибка — игнорирование контекста диалога. Пользователь может задать уточняющий вопрос: «А если товар бракованный?». Без учёта предыдущего сообщения запрос теряет смысл. Полезно сохранять последние 2–3 сообщения и передавать их в модуль поиска как единый контекст.
Четвёртая ошибка — неясный статус эскалации. Пользователь ждёт ответа оператора, но не знает, сколько времени это займёт. Удобно указывать среднее время ожидания или позицию в очереди: «Вы 3-й в очереди, среднее время ожидания 5 минут».
Пятая ошибка — отсутствие обратной связи. Без оценки ответов невозможно понять, где бот ошибается. Простая кнопка «Ответ помог / Не помог» после каждого автоматического ответа даёт ценные данные для улучшения базы и настройки порогов.
Безопасность и защита данных
Бот обрабатывает личные сообщения пользователей, поэтому требует защиты от несанкционированного доступа и утечек.
Токен бота должен храниться как секрет, недоступный в публичных репозиториях. Рекомендуется использовать переменные окружения или специализированные хранилища секретов. Webhook защищается секретным токеном (secret_token), который передаётся в заголовке X-Telegram-Bot-Api-Secret-Token и проверяется на стороне сервера перед обработкой запроса.
Логи диалогов содержат персональные данные: chat_id, текст сообщений, временные метки. Необходимо ограничить доступ к логам, шифровать их при хранении и удалять через фиксированный период (например, 90 дней). Если законодательство требует согласия пользователя на обработку данных, бот должен запросить его при первом обращении и сохранить отметку о согласии.
Защита от спама и злоупотреблений
Боты подвержены флуду: массовой отправке сообщений для перегрузки системы. Эффективна rate-limiting: ограничение числа запросов от одного пользователя в единицу времени. Например, не более 10 сообщений в минуту. Превышение лимита блокирует пользователя на несколько минут с уведомлением о причине блокировки.
Ещё одна угроза — инъекции команд через текст запроса. Если бот передаёт сообщение в командную строку или SQL-запрос без экранирования, злоумышленник может выполнить произвольный код. Все пользовательские данные должны проходить валидацию и экранирование перед передачей в базу данных или внешние системы.
Чек-лист настройки бота с базой знаний
- Собрать и структурировать тексты базы знаний, разбить на фрагменты по 200–400 слов.
- Присвоить каждому фрагменту уникальный идентификатор, категорию и дату обновления.
- Выбрать метод поиска (полнотекстовый, векторный, гибридный) в зависимости от объёма базы.
- Создать бота через BotFather, получить токен доступа.
- Настроить webhook с HTTPS и секретным токеном или long polling для разработки.
- Реализовать обработку команд
/start,/help,/operator. - Настроить модуль поиска с индексацией и вычислением релевантности.
- Определить порог релевантности на тестовой выборке запросов.
- Реализовать формирование ответа с цитатой и ссылкой на источник.
- Настроить очередь эскалации и уведомления для операторов.
- Реализовать переключение статусов диалога (bot, queue, operator, closed).
- Добавить логирование всех запросов, ответов и переходов статусов.
- Настроить rate-limiting и валидацию пользовательского ввода.
- Провести ручную проверку точности на 100 случайных диалогах.
- Добавить кнопки обратной связи «Ответ помог / Не помог».
- Настроить мониторинг метрик: точность, полнота, скорость ответа, количество эскалаций.
- Организовать регулярное обновление базы знаний на основе анализа необработанных вопросов.
Часто задаваемые вопросы
Можно ли использовать готовые платформы вместо собственной разработки?
Да, существуют платформы для создания чат-ботов с поиском по базе знаний. Они упрощают настройку, но ограничивают гибкость архитектуры и интеграции с внутренними системами. Собственная разработка требует больше времени, но позволяет точно контролировать логику поиска, эскалации и хранения данных.
Как часто нужно обновлять базу знаний?
Частота зависит от динамики информации. Для справочников по продуктам — после каждого обновления ассортимента или условий. Для FAQ — еженедельно или ежемесячно на основе анализа необработанных вопросов. Полезно вести журнал изменений и уведомлять операторов о новых фрагментах.
Как оценить, сколько запросов бот сможет обработать автоматически?
На начальном этапе точная оценка невозможна. Типичная полнота для хорошо подготовленной базы — 60–80%. Чтобы повысить охват, проанализируйте необработанные вопросы за месяц, выявите повторяющиеся темы и добавьте соответствующие фрагменты в базу.
Что делать, если база знаний содержит противоречивые данные?
Противоречия снижают точность и доверие. Перед загрузкой проведите аудит документов: проверьте актуальность, сверьте формулировки, удалите дубли. Если несколько версий документа существуют легально (например, для разных регионов), используйте метаданные для фильтрации результатов поиска по региону пользователя.
Нужна ли языковая модель для генерации ответов?
Не обязательно. Если база знаний хорошо структурирована, достаточно вернуть прямую цитату фрагмента. Языковая модель полезна для перефразирования длинных цитат, создания вступлений или адаптации ответа под контекст диалога. Но модель увеличивает сложность, стоимость и риск галлюцинаций (выдуманных фактов).
Как обрабатывать вопросы на нескольких языках?
Если целевая аудитория многоязычная, подготовьте базу знаний на каждом языке или используйте автоматический перевод запроса перед поиском. Векторные модели могут быть мультиязычными (например, multilingual embeddings), что позволяет искать по всем языкам одновременно. Но точность ниже, чем при использовании монолингвальных моделей.
Практический вывод
Telegram-бот с базой знаний снижает нагрузку на операторов, ускоряет ответы пользователям и поддерживает контроль над точностью информации через прямое цитирование источников. Архитектура строится на четырёх компонентах: структурированные источники с метаданными, модуль поиска с порогом релевантности, формирование ответа с цитатой и механизм эскалации для сложных случаев. Качество работы бота зависит от полноты и актуальности базы знаний, правильного выбора порога релевантности и регулярного анализа необработанных вопросов. Начать стоит с небольшой базы по самым частым вопросам, протестировать на реальных пользователях и итеративно расширять охват на основе логов диалогов.