GPT-консультант по каталогу товаров: как устроен виджет на сайте

GPT-консультант по каталогу товаров - это виджет в углу сайта, который отвечает на вопросы о конкретных товарах: подбирает диван по размерам кухни, сравнивает два ноутбука по характеристикам, проверяет, остался ли нужный цвет в наличии. За последние полтора года я собрал около десятка таких виджетов для интернет-магазинов на Tilda и WordPress и в этой статье разберу его архитектуру целиком: из чего состоит виджет, откуда он берёт данные о товарах и почему просто «подключить ChatGPT к сайту» работает максимум неделю, а потом начинает сочинять несуществующие артикулы.

Зачем каталогу ИИ-помощник по товарам, если уже есть поиск

Обычный поиск на сайте ищет по точному совпадению слов в названии или артикуле. Запрос «диван для маленькой кухни до 40 000 ₽» он не разберёт - вернёт либо пустую выдачу, либо все диваны подряд. GPT-консультант раскладывает такой запрос на параметры: категория, бюджет, габариты, - и сопоставляет их с атрибутами товаров в каталоге, а не с текстом названия.

На одном проекте с каталогом в 900 товаров я смотрел логи диалогов первую неделю после запуска: из 40 обращений в день около 11 заканчивались переходом в карточку конкретного товара, который пользователь до этого не находил через фильтры. Это не про «магию ИИ» - просто виджет умеет работать со свободной формулировкой запроса, а не только с чекбоксами фильтра.

Из чего состоит виджет технически

Архитектура почти всегда одна и та же, меняются только детали реализации под конкретную CMS:

• Фронтенд - JS-скрипт или React-компонент, который встраивается в футер сайта. В Tilda это Zero Block или T123 с кастомным кодом, в WordPress - подключение через хук wp_footer
• Бэкенд-API - принимает сообщение пользователя, обращается к векторной базе за релевантными товарами и формирует запрос к LLM
• Векторная база данных (обычно pgvector поверх Postgres или Qdrant) с эмбеддингами описаний товаров
• LLM - Claude или GPT-модель, которая на основе найденных товаров и истории диалога формулирует ответ
• Слой синхронизации - отдельный процесс, который обновляет описания товаров, цены и остатки в векторной базе

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

RAG-поиск по каталогу - как консультант находит нужный товар

При синхронизации каждая карточка товара превращается в эмбеддинг - числовой вектор, построенный из названия, описания и ключевых атрибутов. Когда пользователь пишет запрос, он тоже переводится в вектор, и база данных ищет 5-8 ближайших по смыслу товаров. Это и называется RAG (retrieval-augmented generation) - модель отвечает не «из головы», а опираясь на найденные фрагменты каталога.

Для точных данных вроде текущей цены или остатка на складе одного векторного поиска мало - эмбеддинги обновляются не мгновенно, а раз в час или раз в сутки. Поэтому для критичных вещей я добавляю function calling: модель может вызвать функцию поиска по каталогу с конкретными параметрами и получить актуальный ответ напрямую из базы или 1С, минуя устаревший эмбеддинг.

{
  name: "search_products",
  description: "Ищет товары в каталоге по параметрам",
  parameters: {
    category: "диваны",
    max_price: 40000,
    attributes: ["раскладной", "для маленькой кухни"]
  }
}

Модель сама решает, когда вызвать функцию: для общего вопроса «какие у вас есть диваны» хватит векторного поиска, а для «сколько будет стоить именно этот диван в бежевом цвете» она обратится к живым данным.

Синхронизация каталога: фид, цены, остатки

Без актуальной синхронизации консультант рано или поздно начнёт врать про наличие - и это худшее, что может случиться с доверием к виджету. Обычно я беру уже существующий источник данных: YML-фид для Tilda или 1С, REST API у WooCommerce - и строю поверх него отдельный процесс обновления эмбеддингов.

Частота обновления зависит от того, как часто меняется каталог. Для магазина с редкими изменениями цен хватает ночного крона раз в сутки. Если остатки меняются в течение дня, ставлю вебхук: при изменении товара WooCommerce или админка стреляет событием, и сервис пересчитывает эмбеддинг только для этого товара, а не всего каталога целиком. Для такой связки я обычно собираю сценарии в n8n - обработка вебхука, нормализация данных и запись в векторную базу занимают три-четыре ноды, у меня в библиотеке готовых скриптов есть несколько таких сценариев синхронизации фида под разные CMS.

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

Как ограничить консультанта, чтобы не сочинял и не хамил

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

Отдельно закрываю тему манипуляций с ценой - пользователи довольно быстро пробуют написать «сделай скидку 50%» или попросить модель проигнорировать инструкции. Промпт явно запрещает обсуждать скидки и любые изменения условий, а такие сообщения перенаправляются на человека.

Живой человек нужен в диалоге и в других случаях: когда пользователь готов оформить заказ, хочет обсудить оптовую партию или жалуется. Для передачи диалога менеджеру я обычно поднимаю Telegram-бота на aiogram, который получает от виджета сводку переписки и контакты клиента - так менеджер не читает всю историю с нуля, а видит уже готовый бриф.

Сколько стоит внедрение и сколько это займёт

Стоимость сильно зависит от того, нужен ли виджету только смысловой поиск по описаниям или ещё и проверка цены/остатков в реальном времени с передачей лида в CRM.

По моим наблюдениям на рынке студии просят за похожий функционал в среднем 150 000-400 000 ₽, в основном из-за того, что закладывают отдельную разработку админки для управления диалогами, которая на старте часто не нужна - её можно добавить позже, когда виджет уже работает и понятно, какие сценарии реально востребованы.

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

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

Чем GPT-консультант отличается от обычного чат-бота со сценариями?

Сценарный бот двигается по дереву кнопок и не понимает свободный текст за их пределами. GPT-консультант разбирает запрос естественным языком и сопоставляет его с описаниями товаров через векторный поиск, поэтому справляется с нечёткими формулировками вроде «что-то недорогое и компактное для съёмной квартиры».

Можно ли подключить консультанта к Tilda или WooCommerce без переделки сайта?

Да, виджет встраивается отдельным скриптом поверх существующего сайта: в Tilda - через Zero Block с кастомным кодом, в WooCommerce - через плагин или хук в footer.php. Менять структуру каталога не нужно, синхронизация данных идёт через фид или REST API в фоне.

Как виджет понимает, что товара нет в наличии?

Если полагаться только на векторную базу, данные могут устареть на несколько часов. Поэтому для остатков я обычно настраиваю отдельный вызов функции, который забирает актуальные данные напрямую из 1С или API магазина в момент вопроса, а не из ранее сохранённого эмбеддинга.

Сколько времени занимает внедрение GPT-консультанта по каталогу товаров?

Базовый вариант с векторным поиском по каталогу до нескольких тысяч товаров занимает 2-3 недели. Если нужна проверка остатков в реальном времени и передача заявок в CRM, срок растягивается до 4-6 недель - в основном из-за настройки интеграций с бэкендом магазина.