RAG — не магия «скормить PDF и забыть». В опте работает связка: структурированный каталог (SKU, MOQ, остаток) + текстовые поля для синонимов + жёсткие правила для цен и скидок. Fine-tune модели на прайсе — редко оправдан; поиск и фильтры — чаще. Почему «просто RAG по PDF» не работает в опте Типовый прайс дистрибьютора — Excel или PDF на сотни страниц: артикулы, упаковки, несколько ценовых колонок, региональные остатки, сноски «цена по запросу». Если разбить PDF на chunks и положить в векторную базу: • артикул 048-221 и 048221 окажутся в разных кусках; • «аналог KNX-…» не найдётся без слоя синонимов; • оптовая колонка перепутается с розничной в соседнем абзаце; • при обновлении прайса в понедельник индекс ещё среда — клиент получает старую цену. Маркетинговые слайды «загрузите документ — бот готов» пропускают главное: в опте ответ — это запись из системы, а не красивый текст. Три рабочих архитектуры Подход | Когда уместен | Риск Structured lookup — API/БД: SKU → поля | Цена, MOQ, остаток, штрихкод | Нужна нормализация данных Hybrid RAG — BM25 + embeddings по карточкам | Синонимы, описания, «что-то как…» | Плохая нарезка chunks FAQ + fallback RAG | 70% типовых + 30% товарных | FAQ и каталог в одном индексе без меток Практика: цену и остаток отдаёт 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 и цены. Метрика | Что считаем SKU accuracy | Верный артикул в top-1 / top-3 Price accuracy | Цифра совпала с прайсом на дату теста Coverage | Доля вопросов без «не нашёл» Escalation rate | Сколько ушло менеджеру — целевой коридор 15–35% Без 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, а не только «красивый текст». Ключевые факты • Типовой оптовый каталог: 2 000–50 000 SKU; чистый векторный поиск по PDF-прайсу даёт 15–30% неверных совпадений на синонимах и аналогах без нормализации • LangChain и практики enterprise RAG рекомендуют hybrid search (keyword + semantic) для технических номенклатур • Цену и остаток industry best practice отдаёт API/БД, не генерации текста — LLM формулирует ответ из проверенных полей • Обновление прайса 1–3 раза в неделю требует пайплайна переиндексации ≤15 мин — иначе RAG устаревает быстрее Excel на диске у менеджера