Skrepka AI: RAG – это не панацея. Особенности внедрения ИИ чат бота в интернет-магазинах.

Каталог, с которым мы работали, — более 12 000 продуктов.
Каждая позиция — это электронные компоненты:
➡️ резисторы
➡️ конденсаторы
➡️ интегральные схемы
➡️ транзисторы

У каждого продукта есть набор параметров:
➡️ номинальное значение
➡️ корпус
➡️ напряжение
➡️ ёмкость
➡️ допуск
➡️ температурный диапазон

Первая проблема: пользователи вводят запросы так, как им удобно:
«10ком 0603 1%», «резистор 10k 0805», «заменитель bc547» и т.д.

Поиск должен был быть быстрым и безошибочным.

Сначала мы пошли по стандартному пути:

• разбили описания товаров на чанки
• создали эмбеддинги
• внедрили векторный поиск

Мы потратили много времени на итерации и поиск «идеальных» настроек RAG.

• В итоге — в этом кейсе это просто не сработало.

Запрос «резистор 10 kΩ 0805»:

• мог вернуть 10 kΩ, но в другом корпусе
• или 100 kΩ
• или даже конденсатор

Почему:

• эмбеддинги плохо различают числа и единицы
• чанкинг:
• большие чанки → размытые результаты
• маленькие чанки → потеря контекста (например, допуск, мощность)

❎ Результат: ❎

• низкая точность
• более длительное время ответа
• нестабильные результаты

Мы протестировали практически все гипотезы, которые могли дать 100% точность — безуспешно.

✅ 1. Классическая база данных
PostgreSQL, где:
одна запись = один продукт:

• тип
• номинальное значение
• корпус
• допуск
• SKU
• ссылка на datasheet

✅ 2. Нормализация запроса (с использованием AI + словаря клиента)
Перед поиском мы стандартизируем запрос:

• убираем лишние пробелы
• приводим к нижнему регистру
• нормализуем единицы:
• «ком» → «kΩ»
• извлекаем числовые значения и параметры

❇️ Пример:
"10kom 0603 1%" → "10 kΩ 0603 1%"
3️⃣ Поиск без векторов❇️ Мы формируем текстовое поле:
тип + номинал + корпус + допуск
И используем классический полнотекстовый поиск с индексом.

❇️ Результат:
~20 мс время ответа
~95% точность
✅ Дополнительно мы добавили:

• таблицу синонимов
• простые правила замены

Этого оказалось достаточно, чтобы при десятках тысяч товаров получать очень точные результаты.

В случае e-commerce каталога с чётко определёнными параметрами:
RAG оказался избыточным — классический поиск работает лучше.

Потому что здесь важно:
точное совпадение значений, а не «семантическая близость».

✅ Мы оставили RAG для:

• неструктурированных данных (тексты, статьи)
• общих запросов
• случаев, где точность чисел не критична