Кейс isklad.com.ua: 92.7% релевантність пошуку OpenCart 3 на 30 000 SKU

Восени 2025 до нас прийшов isklad.com.ua — український інтернет-магазин посуду, дому та аксесуарів з каталогом близько 30 000 SKU на OpenCart 3, у трьох локалях (українська/російська/англійська). Скарга була проста: «покупці пишуть в чат що не можуть знайти товар, хоча він є в каталозі». Розбираємо як це виглядало в цифрах і як ми це виправили.

TL;DR — ключові цифри до/після

Про магазин: 30 000 SKU посуду на OpenCart 3

isklad.com.ua — український інтернет-магазин з власним shop+склад моделлю. Особливості, які важливі для пошуку:

• Дуже широкий каталог: столові набори, чашки, тарілки, склянки, кухонна техніка, текстиль для кухні. Один товар може бути названий 4-6 різними словами (тарілка / блюдо / strap-plate / десертна).
• Три мови: українська + російська (UA-ринок) + англійська (туристи/закордонні клієнти). Кожен товар проіндексований у всіх трьох мовах.
• Складна термінологія: склокераміка / ceramic / керамика — одні й ті самі матеріали різними словами і мовами.
• OpenCart 3.0.4 + кастомізована тема + 8 додаткових модулів (звичайний enterprise-stack).

До AI Search: 30% zero-results і слабка релевантність

До нашого впровадження isklad використовував стандартний OpenCart-пошук + один з популярних "smart search" модулів з маркетплейсу. Реальна картина у GA4 за місяць:

Найболісніші типи запитів:

• Морфологія UA/RU: "чашки" не знаходить "Чашка кавова керамічна 250мл". Покупець бачить "не знайдено", а у каталозі 47 чашок.
• Опечатки на mobile: "сківорода" замість "сковорода" — 0 результатів.
• Cross-language: покупець з російським UI вводить "сковорода", а товар проіндексований лише українською "пательня" — пошук падає.
• Синоніми: "блюдо" / "тарілка" / "блюдце" — три різних слова для одного типу товару.

Чому isklad обрав AI Search замість Klevu/Algolia

Перед нами власник isklad розглядав 3 опції:

Економія за рік порівняно з Klevu: $3 240. Порівняно з Algolia: ~$5 600. Плюс — нативна інтеграція з OpenCart-twig-темою, без overlay-JS поверх існуючого UI.

Установка і reindex 30 000 SKU за 1 годину

Сетап у проді (production OpenCart 3 з реальними покупцями):

1. 0:00 — реєстрація в кабінеті ai-search.cc, оплата плану Business.
2. 0:02 — завантаження aisearch.ocmod.zip, установка через Extensions → Installer.
3. 0:04 — Refresh modifications, додавання license key, ввімкнення модуля.
4. 0:05 — натиснули Reindex now. Магазин у цей час залишався доступним для покупців.
5. 0:08 — перші 1000 товарів у БД (швидкий батч).
6. 0:32 — 50% (15 000 товарів). Прогрес-bar в адмінці. Сайт працює, search-fallback на старий LIKE.
7. 0:54 — 100% (30 000 товарів проіндексовано в трьох мовах = 90 000 embeddings).
8. 0:55 — переключили search-handler на AI. Перші реальні запити з frontend проходять через нову систему.
9. 1:00 — фінальна перевірка топ-50 запитів з GSC: всі знаходять товари. Готово.

Після: 92.7% релевантність, bounce -26 п.п., +14% конверсії

Через 4 тижні після переходу заміри показали:

Релевантність

Власник isklad провів manual review топ-100 пошукових запитів за тиждень: 92.7% запитів мали релевантний товар у топ-3 результатах. До AI Search цей показник був ~58%.

Zero-result rate

Відсоток пошуків з 0 результатами впав з ~30% до ~3%. Залишкові 3% — це справді товари яких немає в каталозі (наприклад покупець шукає "посудомийну машину" — а в isklad тільки посуд).

Bounce rate

Bounce з пошукових сторінок: 78% → 52% (-26 п.п.). Покупець бачить релевантні результати — і клікає на product page замість того щоб закрити вкладку.

Технічні деталі: як працює індексація 30k без падіння магазину

Архітектура запиту

1. Покупець вводить запит у пошук (наприклад "біла керамічна чашка").
2. OpenCart-controller через event hook надсилає текст запиту до AI Search API.
3. API на нашій стороні прогоняє запит через embedding-модель multilingual-e5-large-instruct на GPU. Отримує 1024-вимірний вектор.
4. Вектор порівнюється з 90 000 product-векторами у бінарному форматі (binary embeddings + composite index) — це швидше у 4-8 разів за float-представлення.
5. Топ-K (за замовчуванням K=40) ID товарів повертається в OpenCart.
6. OpenCart-controller рендерить ці товари через стандартний product/category/twig-pipeline (тема, ціни, опції — все без змін).

Час на крок 3 (embedding-обчислення): ~50ms на нашій стороні. Крок 4 (vector similarity search): ~30ms. Network: ~70ms. Render: ~50ms. Всього ~200ms.

Reindex 30 000 SKU без падіння

Стандартна проблема при reindex великих каталогів — навантаження на shop-сервер. У наївному варіанті потрібно:

• Прочитати 30k товарів з БД
• Для кожного — обчислити embedding (це CPU/GPU-важка задача)
• Зберегти векторний індекс

На shared-hosting або середньому VPS це або падає, або займає 6-12 годин блокуючи магазин.

Наш підхід:

Конкретні числа для isklad:

• 30 000 товарів × 3 мови = 90 000 embeddings для обчислення.
• Батч 50 товарів обробляється на GPU за ~1 секунду.
• 1800 батчів = ~30 хвилин теоретичного часу.
• Реальний час: 49 хвилин — додатковий час на network round-trips, retry на rate-limits, оновлення прогрес-бару в адмінці.

Зберігання у packed binary форматі

Кожен embedding — 1024 числа float32 = 4096 байт. На 90 000 embeddings — приблизно 350 МБ.

Раніше ми зберігали embeddings у JSON-форматі (текстове представлення [0.123,0.456,...]), що займало ~8000 байт на embedding. У версії v1.0.5 перейшли на packed float32 binary (через PHP pack('f*', ...)) з magic-header AIS1 для backward compatibility. Це дало:

• ~2× менше storage (350 МБ замість ~700 МБ для 90k embeddings)
• ~3-5× швидший read/parse (unpack('f*') замість json_decode)
• Composite SQL index на (store_id, language_id, type) — основний фактор прискорення queries

Vector similarity search обчислюється як cosine через dot product на нормалізованих векторах. На каталозі 90 000 embeddings весь сценарій (embedding запиту + similarity search + render результатів) укладається у ~200ms на типовому VPS магазину.

Що ми навчилися з цього кейсу

1. Зробіть baseline-вимірювання ДО запуску. isklad нам надав GA4-доступ і ми зафіксували bounce 78% і ~30% zero-result rate. Без цих чисел "як стало краще" — лише відчуття. З цифрами — це конкретний бізнес-кейс.
2. Reindex на проді — нормально якщо архітектура правильна. Embedding-обчислення на нашому боці означає що shop-сервер не страждає. Для каталогів <100k SKU не потрібен maintenance window.
3. Multilingual-first модель критична для UA-ринку. Стандартні OpenSearch/MeiliSearch конфігурації натреновані переважно англійською. multilingual-e5-large однаково добре працює на українській, російській, польській, німецькій.
4. Manual review релевантності > automated benchmarks. Власник isklad сам пройшов топ-100 запитів і оцінив "знайдено / не знайдено" вручну. Це дало нам реальну цифру 92.7% — її не отримаєш через synthetic тести.
5. Свобода cancel anytime — це продаюча фіча. isklad власник зазначив що при виборі Klevu його зупинив річний контракт. AI Search дає month-by-month — і це знизило бар'єр до спроби.

FAQ

Скільки часу займає reindex для каталогу 50 000 SKU?

Приблизно 80-90 хвилин на стандартному тарифі Business / Pro. На Enterprise (виділений GPU) — 30-40 хвилин. Магазин не падає під час reindex.

А якщо у мене 100 000 SKU?

На Pro-тарифі ($79/міс, ліміт 50 000 SKU) — не вистачить. Потрібен Enterprise ($199/міс, без обмеження). Reindex для 100k SKU — 2-3 години. Тестували на каталогах до 80k без проблем.

Чи треба reindex після додавання нових товарів?

Ні. AI Search автоматично індексує нові товари в фоні (через cron, кожні 15 хвилин). Reindex потрібен лише після масових змін — наприклад зміни мовного ланцюжка, або апгрейду embedding-моделі.

Що з проміжним станом під час reindex? Чи бачать покупці поломаний пошук?

Ні. AI Search має fallback на стандартний LIKE-пошук. Поки індексація не завершилась — покупець продовжує бачити результати від OpenCart. Тільки після successful повної індексації search-handler перемикається на AI.

Як AI Search впливає на швидкість сайту в цілому?

Жодного впливу на сторінки які не пов'язані з пошуком (категорії, продукти, кошик, оплата). Наш API для пошукового запиту відповідає за ~200ms (без впливу на render інших сторінок). Немає JS-overlay, тема не модифікується.

Чи можна зробити такий же кейс для мого магазину?

Так. Зареєструйтесь, встановіть AI Search Free (до 200 SKU безкоштовно) для тестування. Якщо у вас 1k+ SKU — оберіть тариф під ваш об'єм. Якщо потрібен супровід реалізації — напишіть на [email protected], допоможемо.