Как поднять ИИ-поддержку клиентов на сервере

MAATRIX

Половина обращений в поддержку — одни и те же вопросы: сроки доставки, статус заказа, условия возврата. Пока живой оператор отвечает на них ночью или в выходной, клиент либо ждёт, либо уходит к конкуренту. ИИ-поддержка клиентов на своём сервере закрывает разрыв без очередной SaaS-подписки: бот отвечает по вашим документам, а диалоги и ключи от моделей остаются на сервере, который контролируете вы, а не вендор чат-бота.

Зачем ИИ-поддержке клиентов свой сервер, а не готовый SaaS-виджет

Готовый чат-бот поддержки — Intercom Fin, Zendesk AI и подобные — решает ту же задачу RAG: ищет ответ в документах и подставляет его в промпт модели. Проблема не в идее, а в том, что вся цепочка от нарезки документов до промпта зашита в чужой продукт: поправить нельзя, только открыть тикет вендору и ждать.

Три момента, которые обычно всплывают не сразу:

• Оплата растёт вместе с успехом. Тарифы SaaS-ботов поддержки обычно привязаны к числу решённых обращений или мест операторов — чем лучше бот прижился, тем больше платите за это.
• Переписка клиента уходит третьей стороне. Номер заказа, email, иногда причина недовольства — всё это проходит через инфраструктуру вендора.
• Смена модели невозможна. Вендор выбрал провайдера и версию модели за вас; появится модель точнее или дешевле — ждите, пока её добавят в тариф.

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

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

Архитектура: база знаний, приложение и три канала доставки

ИИ-поддержка клиентов на Dify строится из трёх слоёв, знакомых по любой RAG-системе, только с поправкой на внешнюю аудиторию. База знаний — документы поддержки: FAQ, правила возврата, прайс-лист, инструкции по установке. Приложение — граф Chatflow поверх этой базы: не простой чат-бот, а именно Chatflow, потому что клиентской поддержке нужна ветка «бот не знает ответ», а у обычного чат-бота такой развилки нет. Доставка — то, как клиент вообще попадает к боту.

Каналов для поддержки обычно три, и они не равноценны:

Как режутся документы на фрагменты, что такое Top K и гибридный поиск — разобрано в статье про сборку ИИ-ассистента для команды на Dify: механика поиска та же самая. Здесь — то, что для внешних клиентов иначе: не роли и приглашения сотрудников, а публичный вход без авторизации, эскалация на человека и защита от злоупотребления этим входом.

Сборка бота поддержки: документы, промпт и первый тест

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

Системный промпт для внешнего клиента жёстче, чем для внутреннего справочника: ставки выше, а собеседник не знает контекста компании.

Ты — ассистент поддержки интернет-магазина «...».
Отвечай только на основе фрагментов из блока «Контекст» и общих
рамок вежливого общения. Никогда не обещай скидки, сроки или
условия возврата, которых нет в контексте.
Если ответа в контексте нет — прямо скажи: «Не готов ответить
точно, передаю специалисту» — и не пытайся угадать.
Отвечай на языке, на котором пишет клиент.

Приветственное сообщение и три-четыре «подсказанных вопроса» — не косметика: они показывают, что бот умеет отвечать на конкретные темы, и снижают долю открытых «расскажи про всё», на которые модель отвечает длинно и неточно.

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

<script>
  window.difyChatbotConfig = {
    token: 'ваш-токен-приложения',
    baseUrl: 'https://dify.example.com'
  }
</script>
<script
  src="https://dify.example.com/embed.min.js"
  id="ваш-токен-приложения"
  defer>
</script>

Вставляется перед </body> на страницах сайта, где должен быть виджет. Внешний вид — иконка, цвет, позиция — настраивается в самом приложении, а не в этом скрипте.

Эскалация на человека: чего Dify не умеет из коробки

Честно: в community-редакции Dify нет кнопки «передать оператору». Живой чат, очередь операторов и SLA продают специализированные хелпдески, а не оркестратор LLM. Для клиентской поддержки это не мелочь: рано или поздно бот получит вопрос без ответа в базе знаний, и разговор должен куда-то попасть, а не просто вежливо отказать.

Рабочий вариант собирается на нодах Chatflow, которые уже есть в системе. После ноды «Поиск по знаниям» добавьте «Условие» (IF/ELSE): проверяет, пуст ли список источников — поле retriever_resources в ответе API. Пусто — ветка идёт не в LLM, а в ноду «HTTP-запрос», которая шлёт вопрос и conversation_id живым людям, например в рабочую группу Telegram через Bot API:

POST https://api.telegram.org/bot<TOKEN>/sendMessage
Content-Type: application/json

{
  "chat_id": "-1002XXXXXXXXX",
  "text": "Клиент спросил: {{#sys.query#}}. Бот не нашёл ответа, conversation_id: {{#sys.conversation_id#}}"
}

Список системных переменных — в выпадающем списке самой ноды. Клиенту в этот момент бот отвечает заготовленной фразой («передаю специалисту») — для него это выглядит как решение, а не как сработавший в фоне HTTP-запрос. Тот же узел можно направить не в Telegram, а в API вашего хелпдеска, если нужны SLA и очередь, а не просто уведомление вручную.

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

Публичный виджет: модерация и защита от накрутки счёта

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

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

Второй рубеж — то, чего в самом Dify нет: сдерживание частоты запросов с одного адреса. Ставится перед Dify, на уровне nginx:

limit_req_zone $binary_remote_addr zone=dify_public:10m rate=5r/s;

server {
    location /chat/ {
        limit_req zone=dify_public burst=15 nodelay;
        proxy_pass http://127.0.0.1:80;
    }
}

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

Нюансы: языки, качество ответов и цена ошибки перед клиентом

Ошибка внутреннего ассистента раздражает коллегу. Ошибка бота поддержки, который пообещал клиенту скидку или срок возврата, которых на самом деле нет, — это уже разговор с юристом или потерянные деньги. Системный промпт снижает риск, но не убирает его целиком: держите под рукой раздел «Журналы» и в первый месяц просматривайте его не реже раза в неделю, заводя аннотации на повторяющиеся ошибки — подробнее об этом в статье про сборку ассистента для команды. Собирайте и оценки клиентов: у API Dify есть эндпоинт POST /v1/messages/{message_id}/feedbacks с телом {"rating": "like"} — если виджет вызывает его по клику «полезно / не полезно», в логах будет видно не только что ответил бот, но и что об этом подумал клиент.

Языки — отдельная ловушка. Модель обычно отвечает на языке вопроса, даже если база знаний на русском, — переводит на лету. Для FAQ это работает прилично, но для юридически значимых формулировок (возврат, гарантия) перевод «на лету» — риск: смысл может сместиться. Если у бизнеса клиенты на нескольких языках, ключевые документы стоит завести в базе на каждом языке отдельно, а не полагаться на перевод в момент ответа.

Если данные клиентов по правилам не могут покидать периметр компании, у Dify есть путь без облачного API — модель через OpenAI-совместимый эндпоинт (Ollama, vLLM). Но учтите пределы CPU: на нашем тестовом сервере (AMD EPYC 9554, 16 vCPU) qwen2.5:7b в Q4_K_M на Ollama 0.33.1 упирается в потолок генерации около 7,6 токена в секунду уже на 4 потоках — это память, не процессор, — а на 32 потоках обваливается до 0,35 токена в секунду. Для пары одновременных диалогов этого мало: нужен отдельный сервер с GPU, а не тот, что описан здесь.

Какой сервер под ИИ-поддержку клиентов заказать в MAATRIX

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

Честный минимум: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Ровно порог из документации Dify: бот на базе в пару сотен документов и умеренный поток посетителей на нём работает. Три ограничения прямо: swap обязателен (подробнее — в статье сколько RAM нужно для Dify), запас под всплеск модерации и эскалации почти нулевой, а обновление базы прямо во время наплыва клиентов — та ситуация, где четырёх гигабайтов не хватает сразу на индексацию и на диалоги.

Комфортный вариант: 4 vCPU, 8 ГБ RAM, 60–80 ГБ NVMe. Здесь есть место для пары воркеров без риска OOM, для nginx с лимитом запросов из раздела выше и для модерации, которая не крадёт заметную задержку у ответа. Если сайт ждёт всплеск — запуск рекламы, распродажа — берите сразу 16 ГБ, а не догоняйте нагрузку по ходу кампании.

Локация — Великобритания, Лондон. С британского адреса OpenAI, Anthropic и Google отвечают без региональных отказов — их держат ключи, а не IP сервера. Лондон ближе по задержке к клиентам из Европы и России, чем Нью-Йорк, а один ответ бота — несколько обращений подряд: поиск, модерация, модель, — и каждая лишняя сотня миллисекунд умножается на все три. Плюс соседство с контуром GDPR — важно при аудитории из ЕС. Для строго российской аудитории с требованием держать данные в РФ по 152-ФЗ — другая локация.

Dify есть в каталоге apps.maatrix.io и разворачивается автоматически при заказе — вручную поднимать Docker и compose не придётся, работает на Ubuntu и Debian. Адрес панели и первые доступы появятся в личном кабинете. Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT: иностранная карта не нужна, хотя сервер стоит в Лондоне. Настройка после заказа — в статье «Как установить и настроить Dify на VPS», авария — в разборе частых ошибок Dify.

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