
Статья для бизнеса · 07.10.2026
Умный поиск по каталогу можно собрать своим: агент подключает ИИ к вашим товарам
Когда готовый поиск закрывает задачу магазина, когда нужна своя сборка и что принять у разработчика. На устройстве поиска vibecoding.ru, без обещаний роста продаж.
Подготовлено машиной агентов под надзором инженера, который ведёт vibecoding.ru. Факты проверены 7 октября 2026.
Умный поиск на сайт можно собрать под ваш каталог: ИИ-агент пишет интеграцию, а выдача работает по правилам магазина.
Разберём, что проверить до заказа, на примере собственного поиска vibecoding.ru. Клиентского кейса интернет-магазина у нас пока нет.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Большой каталог сам по себе не требует ИИ.
Что нужно исправить: артикул не находится, опечатка даёт пустую выдачу или поиск не понимает задачу? Размер каталога не отвечает на этот вопрос.
Опечатки и синонимы не требуют генератора ответов. Meilisearch позволяет разрешить ошибки в названиях и сохранить точное совпадение для артикулов.
В нашем поиске «кодекс» находит Codex через алиас. Проверено 7 октября 2026: модель для перехода между этими названиями не нужна.
Способ поиска выбирают по ошибке, которую нужно исправить.
Meilisearch, настройка опечаток; Elastic, Hybrid search. Прочитано 07.10.2026. Таблица показывает способ выбора, не результаты эксперимента магазина.
2. Сервис покупают ради обслуживания, свою сборку ради своих правил.
Обязательно ли собирать самим? Нет, если сервис находит нужные товары и его условия подходят магазину. Вы покупаете поиск вместе с обслуживанием.
Сервисы тоже читают ваш каталог: anyQuery через XML/YML, SearchBooster через YML. anyQuery даёт скрипт или API. Проверено 7 октября 2026.
Особое правило выдачи стоит сравнить на обоих решениях. Например, наличие по городу вместе с совместимостью. Попросите сервис показать это на вашем каталоге.
Выбирайте, кто будет менять и обслуживать поиск.
Официальные описания anyQuery и SearchBooster, 07.10.2026. Критерии выбора сформулированы редакцией; цены и возможности поставщиков не приравниваются.
Свой код тоже требует расходов: вычисления, обновление данных, работу инженера. Сравните полную стоимость на вашей нагрузке.
3. Агент собирает поиск, а товары выбирает работающая система.
Кто здесь агент: разработчик или продавец в каждом запросе? Агент пишет интеграцию и проверки. Поиск затем работает без запуска агента-разработчика.
Машина агентов собрала наш /search. Но выдача сопоставляет слова с названиями, описаниями и алиасами. ИИ-модель запрос не обрабатывает.
Правила для ИИ-агентов лежат рядом с кодом. Для поиска в них нужны источник каталога, условия выдачи и проверки перед выпуском.
Наш поиск доказывает свою сборку, товарный поиск ещё надо проверить.
Публичный /search и разбор его реализации редакцией 07.10.2026. Существующие проверки прочитаны; новый прогон для статьи не выполнялся.
Поиск по смыслу связывает запрос с описаниями. Текстовый путь сохраняют для точных кодов товаров. Elastic называет такое сочетание гибридным поиском.
4. Модель ищет смысл, а каталог задаёт цену и наличие.
Можно ли сразу открыть поиск покупателям? Сначала задайте ограничения выдачи: размер и город. Подходящий по смыслу товар бывает недоступен к покупке.
Учебный запрос: «обувь для прогулок под дождём». Модель находит кандидатов. Водостойкость, размер и наличие должны подтверждаться данными каталога.
Название «для туризма» не обещает защиту от воды. Если свойство не заполнено, поиск должен уточнить выбор. Придумывать характеристику нельзя.
Подходящий смысл не отменяет условий покупки.
Предложенный редакцией договор приёмки для учебного магазина обуви, 07.10.2026. Основа устройства: Hybrid search, Elastic. Это не измерение работающего магазина.
При сбое модели покупателю нужна текстовая выдача. До разработки задайте предел ожидания и переключение режима. Свежесть каталога проверяется отдельно.
5. Приёмка на ваших запросах полезнее красивого демо.
Как принять выдачу? Для запросов из текущего поиска задайте допустимые результаты. Elastic использует такие пары в проверке качества поиска.
Ожидаемые товары утверждает сотрудник, который знает ассортимент. Агент прогоняет сравнение. Если он сам назначает правильный ответ, проверка повторяет его ошибку.
Ошибки своей машины дают разные уроки. Индекс не знал название раздела, а проверка ответа пропустила поле. Язык посетителя и стык систем проверяют отдельно.
Две правки нашей машины подсказывают, что проверять в поиске.
11.08
Раздел назывался на сайте «Учебник», а поисковый список знал «Практику». Добавили алиас «учебник»: индекс должен знать имя, которое видит посетитель.
24.09
После изменения ответа страницы новостей падали, хотя проверки проходили. Добавили сверку полей ответа с валидатором: проверять надо и стык между частями системы.
История изменения собственного поиска и первичная запись журнала машины за 24.09.2026, сверены 07.10.2026. Второе событие произошло в новостях; перенос урока на поиск предложен редакцией.
Проверьте запрос без подходящего товара. Выдать что-нибудь недостаточно: ботинок другого размера не становится подходящим оттого, что экран непустой.
Приёмка нужна и для сбоев: удалён товар, изменилась цена, отказала модель. Ответственность за ошибки ИИ разбираем отдельно.
У приёмки разные сигналы для разных ошибок.
Рекомендации редакции, 07.10.2026. Проверка выдачи опирается на Ranking evaluation, Elastic; сигналы продаж не считаются результатом нашего эксперимента.
6. Первый заказ должен дать сравнение со старым поиском.
Начните с категории, где известны ошибки текущего поиска. Сравните подходы на ней. Переделывать весь сайт до такого сравнения незачем.
Задача ИИ-агенту называет данные и ожидаемую выдачу. Для обуви это поиск по коду и назначению с проверкой размера и наличия.
Закажите сравнение с текущим поиском и способ вернуться к нему. Обещание «подключим ИИ» не объясняет, какие запросы стали работать.
Первый заказ состоит из проверяемых результатов.
Предлагаемый порядок заказа редакции, 07.10.2026. Это состав результатов, не обещание календарного срока.
Запросы без результата возвращаются в задачи. Инженер меняет правило, прогоняет контрольный набор и смотрит следующий замер. Так поиск растёт с ассортиментом.
Если вести разработку некому, пройдите тест для руководителя. Он оценивает готовность работы с агентами. Каталог разбирается отдельно.
«Один проект» на /services: 250 000 ₽ в месяц, один продукт и один поток на 7 октября 2026. Это тариф разработки, не смета поиска.
Разовая правка синонимов не требует подписки на разработку. «Один проект» имеет смысл, когда магазину постоянно нужны правки поиска и других частей продукта.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Поиск vibecoding.ru | Живая страница /search на запрос «кодекс» и чтение реализации. Поиск использует названия, описания и алиасы, без модели на пути запроса. Проверки прочитаны, новый прогон для статьи не выполнялся. Клиентского кейса интернет-магазина нет | 2026-10-07 |
| Готовые сервисы | Официальные описания anyQuery и SearchBooster: оба подключают каталог магазина. Рекламные проценты роста продаж и чужие цены не использованы | 2026-10-07 |
| Устройство и приёмка | Elastic: Hybrid search и Ranking evaluation. Meilisearch: настройка опечаток. Контрольные запросы, условия наличия и замер покупок предложены редакцией; эксперимент на каталоге магазина не проводился | 2026-10-07 |
| Цена разработки | Живая /services, 7 октября, 19:20 МСК: «Один проект», 250 000 ₽ в месяц, один продукт и один поток работы. Это тариф услуги, не смета сборки поиска | 2026-10-07 |
7. Частые вопросы
Можно ли встроить поиск без замены сайта?+
Да, поиск можно подключить отдельной интеграцией. anyQuery прямо описывает скрипт и API. Для своей сборки нужно проверить, как текущий сайт отдаёт каталог и показывает результаты.
Нужен ли чат вместо строки поиска?+
Нет. Поиск по смыслу может возвращать обычный список товаров. Чат добавляют, если покупателю нужно уточнить задачу, а не ради самого ИИ.
Сколько стоит своя сборка?+
Считать нужно подключение данных, качество выдачи, нагрузку и сопровождение. Цена «Один проект» на /services относится к месяцу разработки, а не к любому поиску с любым каталогом.
Можно ли поручить всё агенту без инженера?+
Агент подготовит код и проверки, а правила выдачи принимает человек, который знает товары. Работу системы должен вести инженер. Покупать такую сборку без ответственного за обслуживание незачем.
Нужно ли обучать свою модель?+
Начинать лучше с проверки готовой модели на ваших запросах. Если ошибка в названии, характеристике или обновлении остатков, обучение её не исправит.
Какие данные дать разработчику для первого разбора?+
Схему каталога и примеры поисковых запросов без контактов и заказов покупателей. Вопросы персональных данных и ИИ-агентов разобраны отдельно.
Источники
- anyQuery: каталог XML/YML, скрипт и API (проверено 07.10.2026) — официальный сайт
- SearchBooster: передача каталога магазина (прочитано 07.10.2026) — официальная документация
- Elastic, Hybrid search (прочитано 07.10.2026) — официальная документация
- Elastic, Ranking evaluation (прочитано 07.10.2026) — официальная документация
- Meilisearch, Take control of typo tolerance (прочитано 07.10.2026) — блог разработчика
- Наш поиск: запрос «кодекс» (проверено 07.10.2026) — публичный экран
- Машина vibecoding.ru: контекст собственной разработки и истории изменений (сверено 07.10.2026) — наш опыт
- Агентная разработка: «Один проект» (проверено 07.10.2026, 19:20 МСК) — наши условия
Запомнить
1. Разберите ошибки текущего поиска: артикул, опечатка и задача покупателя требуют разных способов поиска.
2. Сравните сервис и свою сборку на вашем каталоге. Выбирайте вместе с тем, кто будет обслуживать систему.
3. Возьмите цену, наличие и свойства из данных магазина. Поиск по смыслу должен соблюдать условия покупки.
4. Примите выдачу на запросах с ожидаемыми товарами, затем измерьте покупки. Красивое демо не заменяет оба шага.
5. Закажите сначала сравнение со старым поиском и способ возврата. После запуска возвращайте ошибки выдачи в задачи.