Месяц назад мне надоело отвечать на одни и те же вопросы. Каждый день — одно и то же: «как оплатить», «где мой заказ», «можно ли вернуть». Я решил поставить бота с языковой моделью внутри. Казалось бы, задача простая. Оказалось — нет.
Расскажу, как это устроено у меня сейчас, через что я прошёл и где споткнулся. Не инструкция — честная история.
Почему обычный бот не работает
Сначала я пробовал классический вариант: кнопки, сценарии, дерево диалогов. Месяц возился с Botpress, настраивал ветки. В редакторе выглядело красиво. На практике пользователи немедленно находили вопрос, который выбивался из схемы, и бот зависал на «не понял, выберите из меню».
Дело в том, что реальные вопросы в поддержку — кривые. Человек пишет «ааа помогите плачу третий раз а доступа нет», и никакие кнопки тут не спасут. Нужно понять контекст, уточнить детали, дать живой ответ.
Вот где языковая модель меняет уравнение. Не потому что она умная — а потому что нормально читает произвольный текст.
Как я это собрал
Стек простой: python-telegram-bot для хука, OpenAI API как движок, небольшая база для хранения истории диалогов. Никакой экзотики.
Главное, что я понял на этапе архитектуры: бот не должен знать всё. Он должен знать своё. Три дня я потратил только на системный промпт — описал продукт, прописал типичные случаи, указал, когда переключать на живого человека. Без этого модель начинала фантазировать: отвечала «уточните у менеджера» на вопрос о часах работы, которые висят на сайте.
Контекст диалога храню в Redis — последние 10 сообщений на пользователя. Этого хватает для большинства разговоров. Больше — дороже и почти не нужно.
На одном моменте я сжёг несколько часов зря: не нужно давать модели весь FAQ целиком через длинный контекст. Сначала я именно так и делал — вставлял всю документацию в системный промпт. Получал медленные ответы и путаницу. Потом перешёл на RAG: векторный поиск по документам, в промпт летят только релевантные куски. Стало заметно лучше.
Где модель ошибается — и что с этим делать
Иллюзий не держу: модель ошибается. Иногда уверенно. Это главное, с чем нужно смириться, и выстраивать систему именно вокруг этого факта.
Я логирую все диалоги и раз в неделю просматриваю случайную выборку. Именно так я обнаружил, что бот несколько дней подряд неправильно называл сроки возврата. Поправил формулировку в документации — и проблема ушла.
Ещё есть список триггеров на эскалацию. Слова «юрист», «суд», «обман», упоминание сумм выше порога — и бот сразу переключает на человека, не пытаясь разрулить самостоятельно. Это избавило меня от нескольких неприятных ситуаций.
Пользователь всегда может написать «хочу с человеком» и получить живого оператора. Без уговоров, без «попробуйте сначала описать проблему подробнее». Сразу.
Сколько это стоит и что даёт
На моих объёмах — около 200-300 диалогов в день — выходит примерно 15-20 долларов в месяц на OpenAI. Меньше, чем один час работы саппорт-менеджера.
Около 70% вопросов бот закрывает без участия человека. Остальные 30% эскалирует. Меня это устраивает, потому что те 30% — как раз сложные случаи, где живой человек реально нужен. Бот не пытается геройствовать там, где не должен.
Время ответа — секунды. Это само по себе снижает раздражение пользователей. Люди злятся не только от плохого ответа, но и от долгого ожидания.
Что я бы сделал иначе
Не стал бы тратить месяц на сценарные боты перед тем, как перейти к LLM-подходу. Это было потерянное время.
Зато системный промпт и базу знаний начал бы готовить раньше — это самая трудоёмкая часть. Не код и не архитектура, а именно «научить бота понимать твой конкретный продукт». Тут не срезать углы.
И кое-что я понял поздновато: бот — это не «поставил и забыл». Первые две недели я смотрел на него каждый день. Без этого он бы тихо продолжал ошибаться, а я бы не знал.
Если думаете поставить что-то похожее — начните не с кода, а с вопроса: какие именно запросы вы хотите закрыть автоматически? Запишите 20-30 реальных примеров из вашей поддержки. Это и станет основой для промпта и тестов. Без этого всё остальное — пальцем в небо.
