Ответы по каталогу в опте: что реально работает, а что — маркетинг

Почему «просто RAG по PDF» не работает в опте

Типовый прайс дистрибьютора — Excel или PDF на сотни страниц: артикулы, упаковки, несколько ценовых колонок, региональные остатки, сноски «цена по запросу».

Если разбить PDF на chunks и положить в векторную базу:

• артикул 048-221 и 048221 окажутся в разных кусках;
• «аналог KNX-…» не найдётся без слоя синонимов;
• оптовая колонка перепутается с розничной в соседнем абзаце;
• при обновлении прайса в понедельник индекс ещё среда — клиент получает старую цену.

Маркетинговые слайды «загрузите документ — бот готов» пропускают главное: в опте ответ — это запись из системы, а не красивый текст.

Три рабочих архитектуры

Практика: цену и остаток отдаёт lookup, LLM — формулировка и уточняющие вопросы. Так снижают галлюцинации: модель не «придумывает» цифру, а цитирует поле price_wholesale.

Как готовить данные

Минимальный набор полей карточки для B2B:

• sku, barcode, name, synonyms[]
• unit, moq, pack_size
• price_retail, price_wholesale (или ссылка на прайс-лист клиента)
• stock, lead_time, region
• category, attributes (JSON: сечение, материал, стандарт)

Текстовые описания — для семантики. Цифры — только из колонок, не из prose в «описании товара».

Пайплайн обновления:

1. Выгрузка из 1С/ERP или мастер-Excel по расписанию.
2. Валидация: дубликаты SKU, пустые цены, отрицательные остатки.
3. Переиндексация embeddings только изменённых карточек.
4. Smoke-test golden set из 20 вопросов — автоматом после каждой выгрузки.

Hybrid search: зачем и как

У технической номенклатуры много точных токенов: ГОСТ, DIN, IP67, 3×2,5. Чистая семантика их «размывает».

Hybrid = keyword (BM25) + вектор + rerank top-10. LangChain, LlamaIndex и Elasticsearch давно рекомендуют этот паттерн для документации с кодами.

Пример: запрос «кабель силовой медь 3х2.5» → BM25 ловит «3х2,5», вектор — «силовой медный кабель» → rerank выбирает карточку с нужным ГОСТ.

Границы RAG: что не отдавать модели

Даже хороший retrieval не заменяет:

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

Правило для архитектуры: если ошибка стоит денег или репутации — эскалация, не генерация.

Как измерять качество

До публичного запуска соберите golden set — 50–100 пар «вопрос клиента → эталонный ответ» с указанием SKU и цены.

Без golden set команда спорит «бот тупой» vs «клиенты не так спрашивают» — объективности нет.

Типовые ошибки внедрения

1. Один индекс на всё — FAQ, регламент, маркетинг и прайс в одной куче.
2. Chunk size «как получится» — разрезали PDF по 512 токенов через таблицу.
3. Нет версии прайса в логе ответа — невозможно разобрать инцидент.
4. Нет opt/retail в metadata — модель смешивает условия.
5. Ожидание 100% автоматизации — в опте 20–35% эскалаций нормальны.

Связка с каналом и CRM

RAG отвечает в Telegram, Max или виджете — но заявка должна уйти в amoCRM/Bitrix с полями:

• найденные SKU и количество;
• тип клиента (если определён);
• цитата запроса;
• версия прайса / timestamp индекса.

Иначе RAG остаётся «умной справкой», а не частью воронки. Про границу с простым ботом — в материале «Когда чат-бот не справится».

Краткий decision tree

• До 500 SKU, редкие изменения → structured lookup + FAQ может хватить без embeddings.
• 500–10 000 SKU, много синонимов → hybrid RAG + lookup цены.
• >10 000 SKU, несколько прайс-листов → обязательны metadata (регион, контрагент, opt/retail) и автотесты.

Fine-tune LLM на каталоге имеет смысл только при стабильной номенклатуре и узком языке — в опте ассортимент меняется быстрее, чем успевают переобучить.

Связанные материалы

• Когда чат-бот не справится — сценарии vs данные.
• Speed-to-lead и первый ответ — зачем ускорять retrieval, а не только «красивый текст».