AI-чат-бот для интернет-магазина: где ломается поиск
Покупатель ищет «куртка, чтобы не промокала под дождём» или «чехол, чтобы телефон не грелся в машине» — и получает пустую выдачу. В каталоге лежат название, артикул и характеристики, а не те слова, которыми люди описывают потребность. Поиск по точному совпадению слов такие запросы не находит, и доля нулевых результатов поиска растёт незаметно: сначала на единицах процентов трафика, потом на заметной части запросов.
Цена такой выдачи выше, чем кажется. Покупатель не просто закрывает вкладку — он уходит к конкуренту или пишет в чат, и вопрос переезжает на первую линию поддержки. Нагрузка на первую линию поддержки растёт в основном за счёт однотипных вопросов: «есть ли у вас…», «подойдёт ли…», «чем отличается…». Оператор вручную отвечает то, что должен был показать поиск.
Расширить словарь синонимов и дописать ключевые слова в описания товаров помогает лишь частично — пока формулировки повторяются. Поиск по описаниям товаров, завязанный на точные слова, не вытягивает опечатки, иной порядок слов, смешение языков и бытовые названия категорий. Каталог растёт, словари устаревают быстрее, чем их успевают править, а правило «добавить ещё синоним» перестаёт масштабироваться.
Семантический поиск по каталогу убирает разрыв между запросом и товаром: и то и другое сравнивается по смыслу, а не по буквам, поэтому выдача не зависит от того, угадал ли покупатель наше внутреннее название позиции. Ниже разбираем, как это закрывается и что именно меняется в поиске, в карточках товаров и в работе первой линии.
Что даёт семантический поиск и диалоговый ассистент
Семантический поиск начинается с того, что каждая карточка получает векторное представление — по названию, атрибутам, категории и текстам отзывов. Запрос вроде «нужны кроссовки для бега по асфальту, чтобы не скользили» кодируется в то же пространство, и выдача ранжируется по смысловой близости, а не по попаданию слов в название. За счёт этого уходит целый класс отказов «ничего не найдено»: подбор товара по свободному описанию работает и там, где покупатель не знает точной модели.
Индексы держим рядом с каталогом: PostgreSQL с расширением для векторного поиска позволяет обновлять представление товара в той же транзакции, что и саму карточку. Каталог и поисковый индекс не расходятся — снятый с продажи размер исчезает из выдачи сразу, а не после следующей пересборки.
Диалоговый ассистент ставится поверх этого поиска и берёт на себя уточнение: назначение, размер, совместимость с уже купленным. Ответ собирается только из найденных карточек и утверждённых текстов, поэтому выдуманных характеристик в ответе не появляется — риск закрыт на уровне источника данных.
Вторая половина эффекта — поддержка. Типовые обращения (статус доставки, условия возврата, совместимость) закрываются без оператора, а люди переключаются на нестандартные случаи. На запуске смотрим три числа: доля заказов, оформленных через диалог, время подбора товара от первого запроса до корзины и конверсия поиска по каталогу.
Форматы решения: поиск по каталогу, ассистент, гибрид
Простой поиск по словам держится на точном совпадении: покупатель вводит название из карточки — и получает результат. Как только запрос становится описательным («тёплый свитер на зиму», «подарок ребёнку до трёх лет») или содержит опечатку в артикуле, выдача пустеет, и часть посетителей уходит, не дойдя до корзины. Разбираем, какие схемы применяют на практике и где проходит граница возможностей каждой.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Поиск по словам | Каталог небольшой, названия товаров совпадают с формулировками покупателей, важна предсказуемость выдачи | Не понимает синонимы, опечатки, описательные запросы; доля пустых выдач растёт вместе с ассортиментом |
| Поиск с опорой на базу знаний | Каталог от нескольких тысяч позиций, есть заполненные карточки, инструкции, отзывы — ответы собираются из них | Нужна подготовка базы: разметка, разбиение на фрагменты, регулярное обновление индекса. Без этого ассистент уверенно отвечает не тем |
| Готовые облачные платформы для ассистента | Нужен запуск за считанные недели и нет своей команды на постоянное сопровождение | Слабая связка с учётными системами и остатками склада, ограниченная настройка логики под свои правила, зависимость от политики поставщика |
| Гибридная схема поиска и диалога | Крупный каталог, нетиповые вопросы, нужны и точный подбор, и уточнение деталей в диалоге | Дороже в разработке: два контура, оценка качества на живом трафике, постоянный мониторинг и переобучение на новых запросах |
Выбор диктуют три вещи: объём каталога, качество данных в карточках и то, кто будет вести индекс после запуска. Там, где поиск по словам теряет заметную долю запросов, окупается гибридная схема.
Этапы работы: аудит, схема, настройка, приёмка
Каждый этап заканчивается результатом, который можно проверить на данных магазина. Поэтому начинаем с аудита фактических запросов, а не с догадок о том, что спрашивают покупатели.
- Аудит поисковых запросов. Выгружаем журнал поиска по сайту и обращения в поддержку: где выдача пустая, какие формулировки не находят товар — синонимы, опечатки, артикулы, бытовые названия вместо каталожных.
- Разбор каталога. Структура карточек и атрибутов, наличие, остатки: что нужно дополнить, чтобы бот отвечал по факту, а не по общему описанию.
- Схема интеграции с каталогом. Как приходят актуальные данные, как часто обновляется база знаний, что происходит при снятии товара с продажи или сбое выгрузки. Точки отказа и поведение бота в них фиксируем заранее.
- Правила ответов и эскалации. Что бот не имеет права домысливать, при каких условиях передаёт диалог оператору, отдельные ветки для доставки, оплаты и гарантии.
- Проверка качества ответов. Набор эталонных вопросов с ожидаемыми ответами и прогоны на нём: доля верных попаданий, доля честных «не знаю» вместо выдумки, время ответа.
- Приёмка на реальном трафике. Теневой режим на части посетителей, сравнение с текущим поиском, ручная разметка спорных диалогов — до полного включения.
- Передача управления. Документация, панель с метриками, порядок пополнения базы знаний и откат к прежней версии.
После приёмки у вашей команды остаётся регламент: как добавлять категории, как проверять новые ответы и куда смотреть, если качество просело.
Комплект поставки: конфигурации, схемы, регламенты
Проект заканчивается не демонстрацией диалога, а набором артефактов, с которыми команда заказчика работает без нас. Всё, что мы настраивали в ходе работ, передаётся в репозиторий и внутреннюю базу знаний: конфигурации, схемы, политики, регламенты. Ниже — что именно остаётся на руках и как этим пользоваться.
- Рабочие конфигурации ассистента — сценарии диалога, системные инструкции, правила эскалации на оператора, пороги уверенности. Разворачиваются в чистой среде одним прогоном, без ручных правок.
- Схема интеграций с учётной системой — карта обмена: какие сущности (наличие, цены, статусы заказов) откуда читаются, с какой периодичностью, что происходит при недоступности источника. Диаграмма плюс описание точек отказа и поведения при рассинхроне.
- Политики доступа к данным — разграничение ролей, что ассистент видит из карточки клиента и истории заказов, что маскируется в журналах обращений. Отдельным блоком — правила и сроки хранения переписки.
- Регламент обновления базы знаний — кто и как загружает новые статьи, в каком формате, как проверяется качество ответов после обновления, как откатывается неудачная версия поискового индекса.
- Документация по ассистенту — архитектура решения, словарь сущностей предметной области, перечень сценариев, инструкции для оператора поддержки и для контент-менеджера.
- Набор проверок — тестовые вопросы с ожидаемыми ответами; прогон перед каждым обновлением базы знаний показывает, какие темы ассистент перестал закрывать.
- План передачи — сессия с командой заказчика, разбор типовых инцидентов, выдача доступов и ролей, порядок эскалации на период сопровождения.
После передачи ассистента можно развивать своими силами: правки сценария или пополнение базы знаний не требуют нас как посредника.
Кейс: ассистент для каталога на несколько десятков тысяч позиций
Запускали ассистента на каталоге около сорока тысяч позиций: инструменты, расходники, совместимые артикулы. До этого поиск работал по точному совпадению слов, и запросы вида «насадка для старого перфоратора» уходили оператору — клиент либо ждал, либо закрывал корзину.
Что измеряли и что изменилось
| Показатель | До | После |
|---|---|---|
| Запросы, по которым не нашлось ни одной позиции | 27% | 6% |
| Обращения, закрытые без оператора | 14% | 68% |
| Среднее время подбора товара | 4 мин 20 с | 35 с |
| Выдачи с нерелевантной первой карточкой | 31% | 9% |
Ассистент отвечает не «из головы» языковой модели, а сборкой фактов из карточек: название, артикул, совместимость, остаток. Выдача гибридная — лексический поиск плюс векторное сопоставление по смыслу, поверх переранжирование с учётом истории покупок. Если уверенность ниже порога, бот не выдумывает товар, а уточняет запрос или передаёт диалог оператору.
Elasticsearch держит и лексический индекс, и векторные представления в одном кластере — не нужно синхронизировать две базы и ловить рассинхрон при обновлении остатков.
Вывод в работу занял шесть недель: две — на сбор и разметку пар «запрос — товар» из логов, две — на настройку поиска и переранжирования, остальное — на оценку на отложенной выборке и контролируемое включение на часть трафика с ежедневным разбором ошибок.
Что делать, если чат-бот уже собран на готовой платформе
Готовую платформу выбрасывать не нужно — она остаётся каналом и диалоговым каркасом, меняется только слой, который готовит ответ. Бот перестаёт искать совпадение по ключевому слову и начинает ходить в каталог: сначала за фактами о товаре, потом за формулировкой. Если он работает в Telegram, подменяется обработчик сообщений — меню, кнопки и точки входа остаются на месте.
Подходы к ответам сравниваем по типу вопроса, а не «какой современнее». Доставку, оплату, возврат и гарантию надёжнее держать на жёстких шаблонах — формулировку согласовали один раз, и она не поплывёт. Поиск по смыслу подключаем там, где вопрос про товар: совместимость, отличия моделей, наличие нужного размера. В итоге получается не один подход вместо другого, а три уровня, и каждый работает на своём классе обращений.
Каталог подключаем через выгрузку из учётной системы: артикул, характеристики, наличие, совместимость. Описания индексируем реже, остатки и статусы тянем отдельным потоком, чтобы бот не отвечал по устаревшей карточке. Если уверенность ниже порога, вопрос уходит в шаблон или живому оператору — выдуманный товар хуже, чем «уточню у менеджера».
Перенос сценариев на новую схему делаем пошагово: инвентаризируем ветки, помечаем, какие остаются жёсткими, а какие становятся подсказкой для модели, прогоняем накопленные диалоги и сравниваем ответы. Что ломается — остаётся на старом движке до исправления, переключаем группами вопросов. Историю обращений сохраняем вместе с идентификатором пользователя, а каждый ответ логируем с источником: карточка каталога, шаблон или оператор.
Технические сомнения: вопросы перед стартом проекта
Перед стартом проекта заказчики задают одни и те же практические вопросы — и это правильные вопросы. Ниже — короткие ответы на четыре технических сомнения, которые чаще всего всплывают на этапе оценки решения.
Что если покупатель напишет запрос с ошибкой или другими словами?
Поисковый слой сопоставляет не строки, а смысл запроса, поэтому опечатки, падежи и синонимы («кроссовки» / «кеды» / «спортивная обувь») приводят к одной и той же выдаче. Поверх этого ведём словарь доменных синонимов и торговых названий, который пополняем по логам запросов без результата.
Как ассистент отвечает, если товара нет в наличии?
Он не додумывает наличие: ответ собирается только из данных каталога. Если позиции нет, бот прямо сообщает об этом и предлагает близкие аналоги по категории, цене и характеристикам либо оформляет подписку на поступление.
Откуда берутся актуальные остатки и цены?
Остатки и цены подтягиваем из учётной системы магазина — по расписанию и по событию при изменении складских данных. Карточки и связанные с ними ответы пересобираются при обновлении, поэтому бот не продаёт то, что уже закончилось.
Как вы контролируете качество ответов ассистента?
Собираем логи диалогов и размечаем выборку по трём метрикам: доля ответов без опоры на источник, доля обращений, ушедших на оператора, и доля запросов без ответа. По этим цифрам правим инструкции ассистента, состав поискового индекса и порог передачи живому менеджеру.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы оценка ассистента опиралась на ваши данные, а не на усреднённые допущения, полезно прислать срез каталога и обезличенные логи поиска за месяц. Ничего закрытого не нужно — достаточно структуры полей, выгрузки и описания сценариев, которые бот должен закрывать. Тогда разбор текущего поиска и расчёт объёма работ идут по факту, а не по ощущениям.
Что полезно подготовить и что мы разберём на созвоне:
- выгрузка каталога: категории, атрибуты, варианты товара, наличие — по ним строится семантический индекс и подбирается стратегия чанкинга карточек;
- логи поиска: доля запросов без результата, длина формулировок, опечатки и синонимы — показывают, где текущий поиск теряет покупателя;
- как устроен поиск сейчас: правила ранжирования, словари синонимов, фильтры и сортировки — чтобы не сломать работающее;
- точки интеграции: каталог, склад, служба поддержки, канал обращения — определяют состав и порядок этапов;
- ограничения: персональные данные, права доступа, требования к хранению истории диалогов;
- эталонные вопросы: 20–30 типовых обращений с ожидаемым ответом — база для проверки качества;
- критерии приёмки: доля верных ответов, доля отказов, время ответа — фиксируем до старта.
Опишите задачу в свободной форме — вернёмся с оценкой проекта ассистента и планом работ по этапам: от разбора поиска и подготовки данных до подключения к каналу и передачи документации.
