Служба доставки посылок: RAG-ассистент поддержки в Telegram

TL;DR. RAG-ассистент в Telegram поверх базы из 550 документов о доставке — тарифы, сроки, термины, процедуры приёма и выдачи, возвраты. Клиент получает ответ на типовой вопрос мгновенно; если бот не справляется, обращение уходит живому оператору с сохранённой историей переписки.

Если нужен разбор механики — читайте гайд про RAG-ассистентов.

Ситуация

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

Задача

1. Отвечать на типовые вопросы клиентов в Telegram по базе регламентов и тарифов — без ожидания оператора.
2. Передавать обращение живому оператору, когда бот не справляется, — без потери истории переписки.

Что сделали

RAG-ассистент на aiogram поверх базы из 550 документов (регламенты, тарифы, FAQ), проиндексированной в PostgreSQL с pgvector. Первое сообщение сразу показывает клиенту диапазон тем, которые бот закрывает: отправка, сроки и стоимость, термины, приём и выдача, возвраты и хранение — дальше клиент пишет вопрос обычным текстом.

Эскалация к оператору — по явному запросу клиента («Оператора» и аналогичные формулировки): бот передаёт обращение в очередь поддержки и сообщает клиенту, что с ним скоро свяжутся. Контекст диалога хранится в Redis, чтобы оператор видел историю переписки, а не начинал с нуля.

Результат

• Типовые вопросы закрываются ассистентом сразу, без очереди на оператора.
• 2-3 тыс. обращений в месяц проходят через бота; часть эскалируется оператору с сохранённым контекстом диалога.
• В проде с сентября 2025.

Ключевые технические решения

1. pgvector вместо отдельной векторной БД. При базе в 550 документов отдельный векторный движок избыточен — pgvector переиспользует уже развёрнутый PostgreSQL вместо нового сервиса в инфраструктуре.
2. Redis для контекста диалога. Эскалация к оператору должна сохранять историю переписки, а не начинать разговор заново — состояние диалога живёт в Redis и передаётся вместе с обращением.
3. aiogram вместо no-code конструктора. Логика эскалации и работа с состоянием диалога требуют кода, а не цепочки нод — на no-code такие условные переходы быстро становятся хрупкими.

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

Бот отвечает на вопросы о конкретной посылке — где она сейчас?

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

Как бот понимает, что нужно передать оператору?

По явному запросу клиента — команда «Оператора» или похожая формулировка переводит диалог в очередь поддержки. Бот не пытается угадать сложность вопроса сам — решение всегда остаётся за клиентом.

Почему выбрали GPT-4o mini, а не более крупную модель?

База из 550 документов и типовые вопросы поддержки не требуют модели с большим контекстным окном или сложным рассуждением — компактная модель отвечает быстрее и дешевле при сопоставимом качестве на этом объёме задач.

Что было бы дальше

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

Если у вас похожая задача — служба поддержки, которая тонет в одних и тех же вопросах, — обсудим за 30 минут.