RAG по каталогу товаров: характеристики, совместимость и наличие

Ассистент по каталогу полезен, только если может показать, откуда взят ответ, какую ревизию карточки он использовал, для какого рынка ответ действителен и когда нужно остановиться. Гладкий текст, который выдумывает совместимость или выдаёт вчерашний остаток за обещание покупки, хуже честного no-answer.

Этот материал описывает CATALOG-EVIDENCE-9 — ограниченный RAG-workflow для вопросов к каталогу. Он помогает искать и объяснять данные до продажи; он не резервирует товар, не обещает доставку, не устанавливает цену и не заменяет транзакционную продуктовую систему.

Начните с процесса каталога, а не с окна чата

Вопросы к каталогу выглядят короткими: «Подойдёт ли эта деталь?», «Что входит в комплект?», «Есть ли в наличии в Ереване?». За ними стоят разные типы источников и разные последствия. Поэтому сначала нужно разделить сценарии.

• Поиск характеристики: размеры, материал, функции, сертификаты и комплектация.
• Проверка совместимости: связь товара, варианта, модели, ревизии, рынка и иногда условия установки.
• Пояснение наличия: датированный сигнал из учётной системы для конкретной локации, но не резерв и не обещание доставки.
• Сравнение: проверяемое отличие между сопоставимыми актуальными вариантами.
• Эскалация: маршрут для неполных данных, конфликтующих источников, критичного применения или запроса на покупку.

Широкая инженерная задача находится на странице RAG-систем. Эта статья намеренно уже: она превращает один вопрос о товаре в проверяемый контракт ответа. Команды в Армении, которым нужно оценить более широкий AI-проект, могут изучить критерии scope, evidence и эксплуатации на /ru/ai-specialist-armenia.

Контракт источника: у каждого факта каталога должен быть дом

Недостаточно загрузить выгрузку таблицы в векторный индекс и назвать её истиной. До ingestion каждому элементу нужен устойчивый идентификатор и поля, которые определяют, можно ли его показывать в ответе.

В RAG-индексе могут лежать описания и руководства, но источником операционных фактов остаётся продуктовая система. Особенно чувствительно наличие: нужно извлечь актуальный сигнал для магазина или склада, показать время обновления и отправить резерв или заказ в отдельный авторизованный workflow.

Жизненный цикл источников и удаление устаревших записей подробнее разобраны в материале «Обновление индекса RAG: ingestion, версии и удаление данных». А для самого ответа полезна дисциплина evidence и locator из статьи «RAG citations и traceability: как показать источник за каждым ответом»: связное резюме без проверяемой опоры не должно становиться продуктовым фактом.

CATALOG-EVIDENCE-9: практический workflow

Workflow начинается со структурированного запроса, а не со свободного промпта. Система принимает товар или SKU, тип вопроса, trusted locale и канал, а для совместимости — модель или конфигурацию. Затем она ищет только допустимые актуальные записи и проверяет, что у каждого существенного предложения есть locator.

запрос: «Совместим ли SKU A-42 с устройством M-7 в Армении?»
trusted context: locale=hy-AM, channel=web, market=AM

retrieval: active SKU A-42 / active device M-7 / approved compatibility relation
verify: revision связи / market scope / evidence locator / conflict state

answer: совместим при указанной конфигурации; показать ревизию источника
route: clarification без ревизии устройства; review при конфликте источников

Это принципиально отличается от догадки модели по названиям товаров. Похожие названия, архивные варианты и комплекты создают реальные ошибки. Совместимость должна быть отдельной записью с левым и правым ID, условиями, действующей ревизией, владельцем и статусом. Если не хватает модели или конфигурации, корректный маршрут — уточнение.

Семь полезных сценариев и их границы

1. Пояснение карточки товара — процитировать актуальные характеристики и объяснить поле на языке посетителя.
2. Выбор варианта — сопоставить допустимые актуальные варианты без выдуманной рекомендации.
3. Проверка совместимости — показать подтверждённую связь, условия и ревизию источника.
4. Поиск аксессуаров — вывести утверждённые дополнения для выбранного SKU и рынка.
5. Поиск руководства и инструкции — извлечь актуальный раздел документа и его locator.
6. Сигнал об остатке — показать датированный статус по локации без «гарантированно в наличии».
7. Передача в sales или support — собрать evidence и неотвеченные поля для named owner.

Ассистент не должен публиковать цену, одобрять замену, принимать критичное решение об установке или фиксировать остаток. Это отдельные системные действия с собственными permissions, детерминированными проверками и read-back.

Интеграции — это контракты, а не коннекторы

Для пилота обычно нужны три слоя. Каталог/PIM отдаёт атрибуты товара, варианты, lifecycle и владельцев. Слой связей отдаёт граф совместимости и условия. ERP, WMS или commerce-система даёт датированный сигнал об остатке. Identity и policy канала определяют, что разрешено увидеть посетителю или сотруднику.

Для каждого слоя зафиксируйте ID источника, разрешённые поля, ожидаемое обновление, владельца, событие удаления или снятия, поведение при сбое и границу ответа. Задержавшийся inventory feed не должен незаметно выглядеть актуальным: ответ обязан сказать, что наличие не подтверждено. Удалённый SKU должен стать недоступным для retrieval, а не остаться в векторном индексе.

Риски, для которых нужны явные маршруты

Обычная ошибка — не только hallucination. Это правдоподобный ответ, приложенный к неверному варианту, рынку или моменту времени. В acceptance set должны войти:

• два товара с похожим названием, но разными вариантами;
• заменённая связь совместимости;
• источник, допустимый в одном рынке и запрещённый в другом;
• остаток старше согласованного окна свежести;
• конфликт между руководством и карточкой товара;
• неразрешённое поле каталога;
• вопрос без достаточной модели или конфигурации.

Во всех этих случаях ассистент уточняет, показывает uncertainty, передаёт вопрос человеку, запрещает приватное поле или отказывается отвечать. «Evidence не найдено» — это операционный результат, а не сломанный интерфейс.

Простая ROI-модель пилота без выдуманных результатов

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

Например, если команда отвечает на 120 вопросов о характеристиках в неделю по 6 минут, базовая линия — 720 минут. Пилот может сократить повторный поиск, но добавляет владение источниками, review и обработку исключений. Отчёт должен показывать диапазон с assumptions: черновик ответа не означает автоматическую продажу или подтверждённую экономию времени.

Acceptance criteria перед rollout

Минимально убедительному пилоту нужны named owner, зафиксированный acceptance set и наблюдаемый rollback route.

Эксплуатируйте систему как каталожную capability

После запуска наблюдайте coverage ответов с citations, устаревшие inventory signals, долю clarification, конфликты источников, недостающие связи совместимости и результаты review. Это не маркетинговые метрики: они указывают на владельца product data, relation record или integration event, который требует работы.

Начните с одного семейства товаров, одного рынка и одного типа вопросов. Назначьте владельцев каталожных данных, совместимости и остатков. Затем решите, достаточно ли evidence, acceptance cases и operating path для расширения пилота. Для обсуждения контролируемого внедрения начните со страницы RAG-систем или посмотрите инженерные доказательства в /ru/case-studies.