Автоматизация техподдержки на базе LLM для интернет-магазинов Ташкента
Первая линия поддержки в узбекистанском e-commerce — это три вопроса: «где заказ», «есть ли размер» и «как оплатить». LLM закрывает их полностью, если дать ей доступ к данным, а не к фантазии.
Что реально спрашивают
Разберите логи переписок за месяц и вы увидите, что подавляющее большинство обращений сводится к статусу заказа, наличию товара, условиям доставки в конкретный район и способам оплаты. Это не разговоры, а запросы к базе данных.
Из этого следует архитектура: модель нужна для понимания вопроса и формулировки ответа, но сам ответ должен собираться из ваших данных. Модель, отвечающая про наличие товара «по памяти», через неделю создаст вам поток возвратов.
Отдельный пласт — вопросы, где ответ есть в документах: условия возврата, гарантия, сроки доставки в регионы. Здесь работает RAG: поиск по вашей базе знаний с последующей генерацией ответа строго по найденным фрагментам.
Архитектура: RAG плюс инструменты
Разделите два механизма. Для документов — векторный поиск по чанкам базы знаний. Для оперативных данных — вызовы функций: get_order_status, check_stock, get_delivery_price. Модель выбирает инструмент, бэкенд отдаёт факт.
Базу знаний ведите на двух языках. Автоперевод русской базы на узбекский даёт заметный процент искажений в формулировках гарантий и возвратов — а это ровно те места, где цена ошибки максимальна.
Обязательно задайте поведение при отсутствии данных: если инструмент вернул пусто, модель говорит об этом прямо и предлагает оператора. Запрет на выдумывание должен быть в промпте явным и продублирован проверкой на выходе.
Эскалация на человека
Настройте автоматическую передачу оператору по триггерам: два неуспешных ответа подряд, ключевые слова о возврате денег и жалобах, явная просьба позвать человека, а также любое сообщение с эмоциональной окраской выше порога.
Оператор должен получать не «пришёл новый диалог», а полный контекст: что спросил клиент, что ответил бот, какие данные подтянулись. Без этого поддержка тратит время на повторное выяснение и клиент раздражается вдвойне.
Учитывайте часы работы. Ночью бот должен честно сказать, что оператор ответит утром, и зафиксировать заявку, а не изображать, что помощь придёт сейчас.
Каналы: Telegram, сайт, Instagram
В Узбекистане основной поток идёт в Telegram и Instagram Direct, виджет на сайте обычно третий по объёму. Логику и базу знаний держите единой, а каналы подключайте адаптерами — иначе через полгода у вас будет три расходящиеся версии ответов.
Instagram Direct имеет более жёсткие ограничения на форматирование и на окно ответа. Заранее решите, что делать с обращениями, пришедшими за пределами окна: обычно это перевод диалога в Telegram по ссылке.
Виджет на сайте должен быть лёгким. Тяжёлый скрипт чата, загружающий мегабайты, на 3G в регионах просто не откроется, и вы потеряете обращение молча.
Метрики и экономика
Считайте долю диалогов, закрытых без оператора, среднее время первого ответа и долю эскалаций с негативом. Первый показатель в зрелой реализации обычно выходит на уровень, при котором операторы занимаются только сложными случаями.
Ориентир по стоимости внедрения на рынке: 25 000 000 – 60 000 000 сум в зависимости от числа каналов и глубины интеграции с учётной системой. Ежемесячные расходы на модель при среднем потоке магазина — 500 000 – 2 000 000 сум.
Экономия считается не через увольнение операторов, а через отсутствие найма при росте потока. Это честная и проверяемая метрика, в отличие от абстрактной эффективности.
Типичные провалы
Запуск без базы знаний. Модель без данных отвечает правдоподобно и неверно, и первые же ошибки про сроки доставки бьют по доверию сильнее, чем отсутствие бота вообще.
Отсутствие логирования. Если вы не пишете все диалоги с указанием, какие инструменты вызывались, вы не сможете ни отладить, ни доказать, что бот ответил корректно в спорной ситуации.
Игнорирование регионов. Сроки и стоимость доставки в Нукус и в Мирзо-Улугбекский район отличаются кардинально, и обобщённый ответ «доставим за 1-2 дня» гарантированно порождает конфликты.