Что за инструмент и зачем он рознице
RAG (retrieval-augmented generation) — это связка из поиска по вашим данным и языковой модели. Модель не «придумывает» ответ из общих знаний, а сначала находит релевантные фрагменты в вашей базе — карточках товаров, регламентах возврата, FAQ, тикетах прошлой поддержки — и формулирует ответ строго на их основе. Для ритейла и e-commerce это ключевое отличие от «голого» чат-бота: ответ можно сопроводить ссылкой на конкретный источник, а значит — проверить.
Это материал-обзор открытых источников о том, что можно сделать на этом инструменте в отрасли. Это не описание проекта KT.Team, а разбор публичных примеров и исследований.
Какую задачу решает: поддержка покупателей и контент
Типовая боль интернет-магазина — поток одинаковых вопросов: «где мой заказ», «как вернуть», «подойдёт ли этот фильтр к этой кофемашине», «есть ли в наличии размер». По бенчмаркам отрасли RAG-ассистенты закрывают 40–50% рутинных обращений без оператора — именно для повторяющихся запросов: статус заказа, политика возврата, характеристики товара, условия доставки, базовый troubleshooting (Wonderchat, 2025 RAG in Customer Support Benchmark). Важная оговорка из того же отчёта: цифра относится именно к рутине, а итоговый процент зависит от структуры обращений конкретного магазина, а не от выбора модели.
Вторая задача — подготовка контента. Тот же индекс по карточкам и регламентам помогает контент-менеджеру быстро собрать описание товара, ответ в FAQ, сравнение моделей — со ссылкой на первоисточник характеристик.
Открытые примеры из отрасли
Grainger (B2B-дистрибуция, MRO). Компания развернула RAG поверх каталога из 2,5 млн товаров с ~400 000 ежедневных обновлений, чтобы ускорить подбор товара для сейлзов и операторов колл-центра. Заявлены «более быстрый и точный поиск товара» и обработка тысяч запросов в реальном времени. Источник — промо-материал Databricks, поэтому количественные метрики по точности и удовлетворённости там ограничены (ZenML LLMOps Database / Databricks).
Исследование graph-enhanced RAG для e-commerce поддержки. Научная работа описывает систему, которая строит знание из каталога товаров и истории тикетов (50 000 товарных сущностей, 2,3 млн связей, 500 000 решённых обращений) и отвечает, комбинируя структурированный граф и текстовый поиск. Результат против обычного document-only RAG: точность фактов 91% против 74% (+23 п.п.) и удовлетворённость 89% против 67% по оценке 50 опытных агентов поддержки (arXiv 2509.14267). Это показывает, что ответы можно делать проверяемыми и связными именно за счёт привязки к источникам.
Оба примера подтверждают логику: качество RAG в рознице упирается не в модель, а в данные — карточки, регламенты, тикеты — и в дисциплину их актуализации.
Как это устроено технически
Минимальный контур:
1. Источники. Карточки товаров (атрибуты, совместимость, наличие), политики (возврат, доставка, гарантия), FAQ, база решённых тикетов.
2. Индексация. Тексты режутся на фрагменты, превращаются в эмбеддинги, складываются в векторный индекс. Каталог обновляется инкрементально — у Grainger это сотни тысяч изменений в день.
3. Поиск. На вопрос покупателя система достаёт релевантные фрагменты (гибрид: ключевые слова + семантика, в продвинутых вариантах — граф связей «товар-характеристика-совместимость»).
4. Генерация с цитатой. Модель формулирует ответ строго по найденному и прикладывает ссылку на источник.
5. Наблюдаемость. Логируются: какие источники подтянуты, качество ответа, латентность, доля закрытых без оператора обращений.
Где границы и риски
- Мусор на входе — мусор на выходе. Устаревшая карточка или противоречивый регламент возврата дадут уверенно неверный ответ. RAG не лечит беспорядок в данных, он его обнажает.
- Цитата — обязательна. Без ссылки на источник теряется главное преимущество — проверяемость и доверие.
- Не вся рутина одинакова. Часть запросов требует доступа к статусу заказа/оплате — это уже интеграция с бэкендом, а не только RAG по документам.
Вывод: какой бизнес-процесс это улучшает
RAG поверх карточек, политик и FAQ улучшает обработку обращений и подготовку контента: 40–50% рутинных вопросов закрываются автоматически и с источником, операторы и контент-менеджеры разгружаются от повторяющейся работы.
Ключ к устойчивому результату — архитектура. В логике KT.Team такой ассистент строится как слабосвязанный компонент: отдельный сервис поиска и генерации поверх существующих систем (PIM/каталог, helpdesk, база регламентов), а не ещё один монолит, в который «зашили» весь контент. Это даёт два измеримых эффекта. Первый — отчуждаемость: индекс, источники и логика подсказок описаны явно, решение можно передать между командами или подрядчиками без потери контекста. Второй — локальность изменений: обновление карточек или политики возврата не ломает поддержку, потому что RAG читает их из источника, а не хранит копию. Практики DORA и SRE (наблюдаемость по долям закрытых обращений, версионирование источников, маленькая команда 3–7 человек) превращают пилот в воспроизводимый промышленный процесс.