RAG для каталога товаров: как построить поиск по продуктам и оборудованию

Каталог товаров — частный, но особенно требовательный случай построения RAG-системы. Общая архитектура из статьи «Как создать эффективную RAG-систему» применима и здесь, но каждый из шести шагов приобретает свою специфику, когда единица данных — не абзац статьи, а карточка товара с ценой, наличием и десятком характеристик. Разбираем на двух разных по природе каталогах: продукты питания (состав, срок годности, масса) и промышленное оборудование (технические характеристики, совместимость, комплектация) — принципы совпадают, детали различаются.

Markdown для карточки товара

Карточки товаров почти всегда приходят из PIM, 1С или CMS в виде HTML-вёрстки или плоской таблицы атрибутов — то есть в формате, который LLM разбирает заметно хуже, чем структурированный Markdown. Перед индексацией стоит привести карточку к единому Markdown-шаблону, где название, характеристики и наличие — явные, отдельные блоки, а не слитный HTML.

Каталог продуктов питания:

## Йогурт натуральный «Ферма», 350 г

### Характеристики
| Параметр | Значение |
| --- | --- |
| Состав | Молоко, закваска |
| Жирность | 3.2% |
| Срок годности | 14 дней |
| Артикул | PR-33821 |

### Наличие
В наличии, 240 шт. Цена: 129 ₽.

Каталог промышленного оборудования:

## Гидравлический погрузчик DL-500X

### Технические характеристики
| Параметр | Значение |
| --- | --- |
| Грузоподъёмность | 5000 кг |
| Высота подъёма | 3.3 м |
| Совместимость | Вилы стандарта ISO 2328, класс IV |
| Артикул | EQ-500X |

### Наличие
Под заказ, срок поставки 21 день. Цена по запросу.

Одинаковая структура шаблона для всех карточек каталога — то, что позволяет и сегментации, и ранжированию работать предсказуемо на любом количестве товаров, будь то 500 или 500 000 позиций.

Сегментация: одна карточка — один чанк

Для обычного текста границу чанка ищут по смыслу; для каталога она уже задана самой структурой данных — одна карточка товара = один чанк (или, для громоздких карточек оборудования с длинными техническими паспортами, отдельно «шапка + характеристики» и отдельно «комплектация + документация», но никогда не смешивая две разные модели в одном чанке).

Частая ошибка при построении RAG-системы поверх уже существующей базы знаний — гнать выгрузку каталога через универсальный чанкер, настроенный на статьи (резать по 500 символов). Результат — характеристики одного товара обрываются на середине таблицы, а остаток утекает в чанк со следующим товаром. При поиске «грузоподъёмность DL-500X» система в лучшем случае найдёт половину нужных данных, в худшем — начнёт путать характеристики двух соседних моделей.

Гибридный поиск по атрибутам и артикулам

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

• Смысловые запросы («йогурт без сахара», «погрузчик для склада с узкими проходами») — здесь работает векторный поиск: он находит подходящие товары, даже если в запросе нет ни одного слова из карточки.
• Точные запросы (артикул PR-33821, модель DL-500X, штрихкод) — здесь нужен keyword/BM25-поиск: для случайного набора символов у векторного поиска попросту нет «смысла», за который можно зацепиться, и он может пропустить точное совпадение ради семантически похожих, но других товаров.

# Дополнительно к общей формуле RRF (см. статью про архитектуру RAG) —
# точное совпадение по артикулу форсируем в топ независимо от score
def search(query, vector_results, keyword_results, catalog):
    exact_sku = catalog.find_by_sku(query)
    fused = reciprocal_rank_fusion(vector_results, keyword_results)
    return ([exact_sku] + fused) if exact_sku else fused

Ранжирование: цена и наличие — тоже сигнал

В обычном RAG ранжирование оценивает только релевантность текста вопросу. Для каталога этого недостаточно: смысловая релевантность и полезность результата — разные вещи. Товар может быть максимально похож на запрос по описанию и при этом быть снят с продажи, закончиться на складе или стоить в три раза дороже прямых аналогов.

Практическая схема — двухэтапное ранжирование: сначала reranker оценивает смысловую релевантность (как описано в статье про архитектуру RAG-систем), затем финальный скор корректируется бизнес-сигналами:

• в наличии — приоритет выше, чем «под заказ» или «нет в наличии»;
• для оборудования — совместимость с уже указанным пользователем контекстом (например, с ранее упомянутой моделью техники) повышает скор;
• для продуктов питания — оставшийся срок годности может понижать приоритет позиции, если пользователь явно спрашивает про товар с длительным хранением.

Без этой поправки RAG-система рискует уверенно продать то, чего физически нет на складе — а для профессионального оборудования это ещё и вопрос доверия к каталогу в целом.

Контекст и структура: карточка не должна разваливаться на части

Тот же принцип, что разобран для медицинских документов в статье про валидацию и Self-RAG, критичен и для каталогов: модель должна видеть карточку товара как целостный документ, а не как случайный набор чанков без связи между собой. Если характеристика «грузоподъёмность 5000 кг» и название модели «DL-500X» физически оказались в разных чанках без явной связи, при ответе на вопрос «какая грузоподъёмность у DL-500X» система рискует либо не найти нужную пару, либо — что хуже — правдоподобно смешать характеристики двух разных моделей из похожих по формулировке чанков.

Решение то же: либо не дробить карточку мельче, чем на «шапка + одна логическая секция», либо использовать parent-document retrieval — искать по мелким фрагментам (для точности поиска), но передавать модели карточку целиком (для целостности ответа).

Особенности разных каталогов

Шаги архитектуры одинаковы для любого каталога, но набор атрибутов, которые нужно учитывать в сегментации, поиске и ранжировании, — свой:

	Продукты питания	Промышленное оборудование
Ключевые атрибуты	состав, аллергены, срок годности, масса/объём	технические характеристики, совместимость, класс/стандарт
Частые точные запросы	штрихкод, артикул	модель, номер детали, стандарт совместимости
Критичный для ранжирования сигнал	остаточный срок годности	наличие и срок поставки под заказ
Риск плохой сегментации	потеря состава/аллергенов при обрыве таблицы	смешение характеристик двух похожих моделей

Если у вас каталог другой тематики — одежда, электроника, автозапчасти, — принцип переносится один в один: определите свои 3–5 ключевых атрибутов, которые чаще всего спрашивают и по которым чаще всего фильтруют, и стройте вокруг них сегментацию, поиск и ранжирование, а не вокруг общего описания товара.

Что дальше

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

Коротко

Чем построение RAG-системы для каталога товаров отличается от RAG для документов?

Единица информации другая — карточка товара со строгой структурой, а не абзац текста. Сегментация, поиск и ранжирование должны опираться на эту структуру.

Как искать товар по артикулу или модели в RAG-системе?

Только гибридным поиском с обязательным keyword/BM25-компонентом — векторный поиск плохо находит точные буквенно-цифровые коды.

Нужно ли учитывать цену и наличие в ранжировании RAG?

Да — иначе система может порекомендовать недоступный товар просто потому, что он семантически ближе всего к запросу.

Можно ли использовать одну RAG-систему для очень разных каталогов?

Архитектурно да — шаги те же. Но набор атрибутов для фильтрации и ранжирования у каждого каталога свой.

Строите поиск или RAG-систему по каталогу товаров или технической документации — пишите нам через форму на сайте, разберём архитектуру под ваши данные.