Интернет-магазин: ИИ-консультант на своём сервере

MAATRIX

Клиент пишет в чат в 23:40: «а платье из третьей коллекции есть в 44-м размере и сколько идёт доставка в Казань» — и до утра никто не ответит. Держать саппорт на подхвате 24/7 дорого, а готовые SaaS-виджеты с ИИ считают каждый диалог и на потоке в тысячи обращений в месяц превращаются в отдельную статью расходов. Разберём, как поднять чат-консультанта на своём сервере через AnythingLLM: он отвечает по каталогу и условиям доставки/возврата на основе реальных документов магазина, а не выдумывает — и честно скажет клиенту, что не может проверить актуальный остаток на складе.

Что реально умеет и не умеет такой консультант

ИИ-консультант на RAG (Retrieval-Augmented Generation) — это не «умный продавец», а справочная система с языковой обёрткой. Он ищет ответ в базе документов, которые вы сами загрузили, и формулирует его по-человечески. Это принципиально меняет, что от него можно ожидать:

• Умеет. Отвечать по каталогу (материалы, размерная сетка, состав, уход), условиям доставки (сроки, стоимость, регионы), политике возврата и обмена, способам оплаты, часто задаваемым вопросам о бренде.
• Не умеет без доработки. Проверять актуальный остаток конкретного товара на складе, статус конкретного заказа, оформлять заказ или менять данные в CRM. Это требует интеграции с реальной базой данных магазина (1С, CRM, движок сайта) — отдельная и более сложная задача, выходящая за рамки справочного бота.

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

Архитектура: почему AnythingLLM и RAG, а не просто GPT-обёртка

Обычный чат-бот поверх LLM без RAG будет либо галлюцинировать (сочинять несуществующие модели и цены), либо отвечать общими фразами. RAG решает это иначе: перед генерацией ответа система ищет в векторной базе фрагменты ваших документов, релевантные вопросу, и передаёт их модели как контекст с инструкцией «отвечай только на основе этого текста».

AnythingLLM для этого сценария удобен тем, что уже собирает весь конвейер в одном приложении:

• загрузка документов и парсинг (PDF, DOCX, CSV, TXT, страницы сайта);
• эмбеддинг и хранение в векторной базе (встроенный LanceDB или внешний Qdrant/Chroma/PGVector);
• workspace с системным промптом, ограничивающим модель рамками загруженной базы;
• готовый встраиваемый чат-виджет для сайта (embed widget) с настройкой брендинга.

Если вы ещё не разворачивали AnythingLLM, пошаговая установка на Ubuntu разобрана в статье про установку AnythingLLM на VPS; там же — вариант через Docker, который проще всего поддерживать в дальнейшем.

Что загружать в базу знаний

Разделите документы на два workspace или на чётко подписанные разделы внутри одного — это заметно снижает количество нерелевантных ответов:

1. Каталог. Экспорт товаров в CSV/JSON (название, категория, состав, размеры, цена, ссылка на карточку) плюс текстовые описания коллекций. Чем структурированнее файл, тем точнее модель цитирует характеристики.
2. Доставка и возврат. Отдельный документ (DOCX или markdown) с тарифами по регионам, сроками, условиями бесплатной доставки, порядком возврата/обмена, реквизитами для претензий.
3. FAQ бренда. Материалы, уход за вещами, сертификаты, программа лояльности — всё, что снижает нагрузку на живой саппорт.

Каталог стоит обновлять регулярно — минимум раз в неделю, при активных распродажах чаще, — иначе бот будет уверенно рассказывать про товар, который уже сняли с продажи. AnythingLLM позволяет переиндексировать документ без пересоздания workspace, но сам процесс обновления файла нужно автоматизировать скриптом на стороне вашего сервера (выгрузка из CMS в CSV по расписанию).

Честное ограничение: про остатки на складе

Это стоит проговорить отдельно, потому что именно на этом чаще всего спотыкаются готовые внедрения. Загруженный в RAG каталог — это снимок на момент экспорта, а не живые данные. Если в промпте не оговорить это явно, модель при вопросе «есть ли в наличии» начнёт отвечать по последним загруженным цифрам, которые могут разойтись с реальностью на десятки товаров в день при активных продажах.

Правильная настройка системного промпта в AnythingLLM для такого случая:

Ты консультант интернет-магазина. Отвечай только на основе
предоставленного контекста (каталог, доставка, возврат).
Никогда не утверждай точный остаток товара на складе —
у тебя нет доступа к live-данным склада. На вопрос о наличии
отвечай: "Актуальный остаток уточните у менеджера в чате
или по телефону [номер] — каталог могу описать подробно".
Если ответа нет в контексте — прямо скажи, что не знаешь,
и предложи связаться с поддержкой.

Проверка актуального остатка «в реальном времени» — это уже интеграция с базой данных магазина: вызов API 1С/CRM или прямой запрос к БД движка сайта по SKU. Технически это делается через function calling — модель распознаёт намерение «проверить наличие» и дёргает ваш внутренний эндпоинт, а не векторную базу. Это отдельный, более сложный проект: нужен API с аутентификацией, кеширование запросов и защита от злоупотреблений. Если каталог у вас небольшой и меняется предсказуемо, для старта разумнее ограничиться справочной частью и добавить live-остатки вторым этапом, когда будет понятно, что бот вообще снижает нагрузку на людей.

Экономика: свой сервер против SaaS-виджета за диалог

Готовые чат-виджеты с ИИ (Intercom Fin, Tidio AI и аналоги) обычно тарифицируют по количеству диалогов или уникальных сессий в месяц. Это удобно на старте — не нужно ничего разворачивать, — но при потоке в несколько тысяч обращений в месяц стоимость линейно растёт вместе с трафиком, и именно в сезон распродаж, когда обращений больше всего, счёт за SaaS оказывается самым высоким.

Свой сервер работает по другой модели расходов:

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

Ресурсы сервера зависят от размера каталога и модели: для справочного бота с каталогом в несколько тысяч позиций достаточно конфигурации среднего VPS без GPU, если использовать облачный API для генерации ответов (например, через OpenRouter) и держать на сервере только векторную базу и логику RAG. Если хотите полностью локальную модель без внешних API-вызовов — потребуется GPU-сервер, расчёт ресурсов под конкретный размер модели разобран в статье сколько RAM нужно для AnythingLLM.

Как развернуть: пошагово

1. Арендуйте VPS. Для старта хватит 4 vCPU / 8 ГБ RAM, если модель работает через внешний API; под локальную модель — смотрите требования конкретной модели. Общий подбор конфигурации под интернет-магазин — в статье сколько ресурсов нужно VPS для интернет-магазина.
2. Поднимите AnythingLLM через Docker:

   docker run -d -p 3001:3001 \
     -v anythingllm_storage:/app/server/storage \
     -e STORAGE_DIR="/app/server/storage" \
     mintplexlabs/anythingllm

1. Создайте workspace «Каталог и доставка», загрузите документы (CSV каталога, DOCX с политикой доставки/возврата), запустите переиндексацию эмбеддингов.
2. Настройте системный промпт с ограничением по остаткам (пример выше) и температурой пониже (0.2–0.4) — чтобы бот меньше импровизировал за пределами контекста.
3. Включите embed widget во вкладке Embed workspace, вставьте выданный <script> на сайт магазина перед закрывающим </body>.
4. Настройте HTTPS и reverse proxy (nginx/Caddy) перед AnythingLLM — виджет с чужого сайта будет обращаться к вашему серверу по публичному домену, и без TLS браузер такой скрипт заблокирует.
5. Протестируйте на реальных вопросах из истории обращений в поддержку — это быстрее всего покажет пробелы в загруженной базе знаний.

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

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