TL;DR
RetailRAG — каркас для агента, который отвечает на вопросы сразу по базе данных (заказы, товары) и по текстам (отзывы, обращения клиентов). Работает в три хода: сначала агенту выдают справку по структуре данных, потом он целиком пишет цепочку шагов, где результат одного шага подставляется в следующий. Если шаг упал, чинят только его, а не весь план.
Главная находка: на таких вопросах агенты ломаются не на «умности» модели, а на переходе между источниками. Вопрос вроде «у какого продавца товар с лучшим рейтингом и какая у него выручка» требует достать имя из одной таблицы, найти его в отзывах, потом вернуться в таблицу заказов. Одна ошибка на первом шаге рушит все следующие. Авторы проверили десять моделей, и падение качества по мере роста числа источников видно у всех, и у крупных, и у мелких. Вывод: масштаб модели эту проблему сам не лечит, нужна явная организация перехода между источниками.
Метод решает это тремя приёмами. (1) Перед планированием в промпт кладут сжатую справку: какие есть источники, допустимые значения полей, по каким ключам они связаны, как считаются метрики. (2) План пишется одним проходом: у каждого шага указан источник, запрос и зависимость от предыдущих. (3) При сбое запускается диагностика (что именно сломалось) и перепись одного шага.
Схема метода
ШАГ 0: Справка по данным (один раз на базу) → 4 блока: схема / допустимые значения / ключи связи / формулы метрик
ШАГ 1: Роутер: вопрос простой? → один вызов инструмента. Сложный? → в планирование
ШАГ 2: План целиком, одним проходом → шаги: источник + запрос + зависимость ({результат_шага_1})
ШАГ 3: Выполнение: каждый шаг идёт в свой инструмент, значения из прошлых шагов подставляются в следующие
ШАГ 4: Сбой шага (пусто, нули) → диагноз с типом причины → переписать ТОЛЬКО этот шаг
Шаги 0–2 и 4 можно задать инструкцией агенту. Шаг 3 (подстановка значений) в статье делается кодом.
Пример применения
Задача: Вы аналитик у селлера на Ozon. Есть выгрузка заказов (SQLite-таблица) и папка с текстами отзывов. Вы работаете в Claude Code или Cursor. Руководитель просит: «Найди наш товар с самым низким средним рейтингом, посмотри, на что жалуются в отзывах, и скажи, сколько мы на нём заработали».
Это цепочка из трёх источников. Рейтинг лежит в таблице отзывов, жалобы в тексте, выручка в таблице заказов.
Промпт:
Ты аналитик магазина на Ozon. Отвечаешь только на основе наших данных.
Источники:
- orders (SQL): order_id, product_id, status, price_rub, qty, created_at
- reviews_meta (SQL): review_id, product_id, rating, order_id
- reviews_text (папка ./reviews/*.txt): имя файла = review_id, внутри текст отзыва
Допустимые значения:
- orders.status ∈ {delivered, refunded, cancelled}
- reviews_meta.rating: целое 1–5
Ключи связи:
- product_id связывает orders и reviews_meta
- review_id связывает reviews_meta и файлы в ./reviews/
Метрики:
- выручка = SUM(price_rub * qty) по заказам со status = 'delivered'
- доля возвратов = заказы refunded / все заказы
Перед выполнением напиши ВЕСЬ план одним списком. Для каждого шага укажи:
- источник (SQL или текст)
- конкретный запрос или поисковое условие
- от каких шагов зависит; ссылайся на них как {step1.result}
Только после этого выполняй шаги по порядку, подставляя реальные значения.
Если шаг вернул пустой результат или нулевой агрегат:
1. Назови причину одним из типов: несовпадение схемы / слишком жёсткий фильтр / неверный ключ связи / другое.
2. Перепиши ТОЛЬКО упавший шаг: ослабь фильтр, поправь колонку или переформулируй запрос.
3. Уже выполненные шаги не трогай.
Вопрос: найди товар с самым низким средним рейтингом (минимум 10 отзывов), выпиши главные жалобы из текстов отзывов с низкими оценками и посчитай выручку по этому товару.
Результат: Агент сначала выведет план из трёх-четырёх шагов: SQL по рейтингу, затем выбор отзывов этого товара, чтение текстов, SQL по выручке. В плане будут видны ссылки между шагами. При пустом ответе (например, фильтр по статусу написан с ошибкой) агент назовёт тип причины и перепишет только этот шаг. Финальный ответ: название товара, список жалоб и число выручки в рублях.
Почему это работает
Слабость. Если дать агенту вопрос «в лоб», он угадывает структуру данных по ходу. Он путает названия колонок, пропускает допустимые значения ('Delivered' вместо 'delivered') и не знает, как считается «выручка» именно у вас. Хуже всего, что ошибка на первом шаге молча портит все следующие.
Сильная сторона. Модель хорошо планирует, когда у неё перед глазами карта местности. Она умеет писать SQL и читать тексты по отдельности. Она неплохо диагностирует сбой, если ей показать сигнал: пустой результат или нулевую сумму.
Как метод это использует. Справка заранее снимает угадывание. План одним куском делает зависимости видимыми: «шаг 3 использует результат шага 1». Локальный ремонт сохраняет всё, что уже получилось, и платит за исправление один шаг, а не весь план.
Рычаги управления: - Справка по данным → самый дешёвый рычаг. Добавляйте в неё то, что агент чаще всего путает: допустимые значения, формулы метрик. - Роутер «простой/сложный» → если вопрос в один источник, пропустите планирование. Это экономит вызовы и время. - Типы причин сбоя → дополните своими. Например, «дубликаты при соединении», «не тот часовой пояс». - Правило «не трогай выполненные шаги» → уберите его, если данные могли измениться между шагами.
Шаблон промпта
Ты аналитик по теме {область}. Отвечаешь только по данным из источников ниже. Если данных нет, так и говоришь.
Источники:
- {источник_1} ({тип: SQL или текст}): {колонки или формат}
- {источник_2} ({тип}): {колонки или формат}
Допустимые значения:
- {колонка}: {список значений или диапазон}
Ключи связи между источниками:
- {ключ} связывает {источник_1} и {источник_2}
Формулы метрик:
- {метрика} = {формула через колонки}
Если вопрос укладывается в один источник — ответь одним запросом.
Если нужно несколько источников — сначала напиши весь план одним списком.
Для каждого шага укажи: источник, точный запрос, зависимость от прошлых шагов ({step1.result}).
Потом выполняй шаги по порядку, подставляя реальные значения из прошлых шагов.
Если шаг вернул пусто или ноль:
1. Определи причину: {тип_1} / {тип_2} / {тип_3} / другое.
2. Перепиши только этот шаг. Выполненные шаги не меняй.
Вопрос: {вопрос}
Что подставлять:
- {область} — ваша сфера (розница, доставка, поддержка).
- Блок источников — реальные названия таблиц, папок, колонок. Пример значения в скобках помогает.
- {тип_1..3} — типичные причины сбоев в ваших данных. Из статьи: несовпадение схемы, слишком жёсткий фильтр.
🚀 Быстрый старт — вставь в чат или в агента с доступом к данным:
Вот шаблон RetailRAG-промпта для вопросов по нескольким источникам данных. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие у тебя источники, какие колонки в таблицах, чем связаны таблицы и тексты и как у вас считаются ключевые метрики. Без этого справка пустая, а именно она убирает угадывание структуры. Модель возьмёт паттерн из шаблона и заполнит его под твои данные.
Ограничения
⚠️ Нужен агент с инструментами: Метод строится на выполнении SQL и поиска по текстам. В обычном чате без доступа к данным он превращается в написание плана, а проверить шаги нечем.
⚠️ Полный каркас требует кода: В статье роутер, подстановка значений между шагами и обнаружение сбоев по сигналам выполнения реализованы программой. Инструкцией агенту вы воспроизведёте идею, но не детерминированную подстановку.
⚠️ Данные в тесте синтетические: Бенчмарк построен на симуляции продавцов и покупателей, не на реальной базе компании. Эксперт GS Retail подтвердил реалистичность вопросов, но реальные данные грязнее.
⚠️ Цифры результатов не видны: В доступном тексте нет таблиц сравнения с базовыми системами и результатов по десяти моделям. Есть только заявление авторов, что RetailRAG выигрывает у всех и что главная проблема — переход между источниками. Размер выигрыша оценить нельзя.
⚠️ Готовых промптов нет в тексте: Авторы выложили их в приложении, но здесь его нет. Шаблон выше — реконструкция по описанию этапов, а не копия.
Как исследовали
Авторам нужно было проверять агентов на корпоративных данных ритейла, но реальные данные закрыты. Они симулировали продавцов и покупателей с персонами и прогнали пять стадий: продающий питч, вопрос до покупки, заказ, вопрос после покупки, отзыв. Результат разложили в базу из 8 источников: 5 таблиц и 3 текстовых коллекции. Связаны они только общими идентификаторами, без готовых ссылок.
Потом собрали 1680 вопросов трёх уровней сложности. Сначала простые вопросы по одному источнику, затем слой за слоем их «склеивали»: имя продавца в вопросе заменялось описанием «продавец, который транслировал такой-то товар». Агенту приходится сначала разгадать это описание в одном источнике, а потом искать ответ в другом.
Качество проверяли несколько раз. Это запуск запроса на базе, два LLM-судьи, три эксперта по NLP (согласие 0,89 по коэффициенту Гвета) и эксперт GS Retail с опытом больше десяти лет. Он признал реалистичными 90% вопросов: 97,5% на первом уровне, 90% на втором, 82,5% на третьем.
Затем сравнили RetailRAG с шестью базовыми подходами, среди них ReAct, MAC-SQL, HetaRAG, TableRAG. Через RetailRAG как общий каркас прогнали десять моделей. Логика такая: если каркас слабый, он сам мешает измерить способности модели. Вывод авторов: качество падает при росте числа источников и глубины цепочки у всех моделей, и размер модели этого не исправляет. Для практики отсюда следует: агенту нужна явная организация перехода между источниками.
Адаптации и экстраполяции
🔧 Техника: сделать диагноз видимым → контроль сбоев
Добавьте в блок
строку: «Перед переписыванием шага выведи:ДИАГНОЗ: [тип причины] — [сигнал, по которому понял]». Вы увидите, на чём агент спотыкается чаще всего, и сможете вписать это в справку по данным как новое правило.
🔧 Техника: справка в файле инструкций → один раз и надолго
Справку (источники, допустимые значения, ключи, формулы) вынесите в CLAUDE.md или AGENTS.md проекта. Тогда она работает для любого вопроса автоматически. В промпте остаются только план и диагностика.
Экстраполяция: справка + самопроверка перед ответом
Эта часть уже не из статьи, а комбинация с идеей проверки:
После получения итогового ответа проверь:
1. Каждое число в ответе привязано к конкретному шагу плана?
2. Статусы, значения и формулы совпадают со справкой?
Если нет — назови шаг, который нужно пересчитать, и пересчитай только его.
Ресурсы
- Статья: Toward Agentic Retrieval-Augmented Generation for Enterprise Retail Workflows over Heterogeneous Data Sources
- Код и данные: https://github.com/DISL-Lab/RetailBridge (промпты всех этапов — в Приложении F)
- Авторы: Jeonghwan Choi, Jibin Hwang, Hayoon Park, Hyeonjae Cheon, Hwanjun Song
- Организации: KAIST, Cluvion, GS Retail
- Упомянутые базовые подходы: ReAct (Yao et al., 2023), MAC-SQL, HetaRAG, TableRAG