ИИ-ассистент магазина: как ограничить ответы данными каталога и заказов

01.11.2026 Эксперт 17 мин чтения

---

Техническая рамка внедрения: источники ответа, границы доступа к заказу, разбор ложных ответов и метрики качества.

Покупатель спрашивает у ассистента цену, срок доставки и статус заказа — и ждёт ответ, который совпадёт с кассой, складом и личным кабинетом. Языковая модель сама по себе так не работает: она продолжает текст по вероятности, а не сверяется с базой магазина. Разберём, как ограничить ответы данными каталога и заказов и чем проверять, что ограничение держится.

Ассистент, который отвечает только по данным магазина

Определение на техническом языке

Ассистент магазина с ограниченными ответами — диалоговый интерфейс над языковой моделью (LLM, large language model), где формулировку даёт модель, а факты приходят из трёх источников магазина: каталога, базы знаний и системы заказов. Модель получает вопрос покупателя вместе с найденными фрагментами этих источников и отвечает только по ним. Когда поиск ничего не нашёл, ответ не формулируется: вопрос уходит оператору или закрывается заранее утверждённой формулировкой отказа. Такой подход в индустрии называют ответом по найденным документам, или RAG.

Бизнес-перевод: три границы ответа

Для бизнеса ограничение раскладывается на три границы, и каждая задаётся отдельно:

• Тематическая граница — ассистент говорит про товары, условия и заказы магазина, остальные темы отклоняет.
• Фактическая граница — в ответе остаются только те цифры и свойства, которые есть в найденных записях.
• Субъектная граница — данные заказа доступны подтверждённому покупателю и только по его заказам.

Границы проверяются независимо друг от друга: тематическую закрывает классификатор вопроса, фактическую задаёт состав переданного контекста вместе с проверкой ответа, субъектную держит авторизация в системе заказов.

Эффект ограничения ответов для бизнеса

Ограничение источников меняет не только тон переписки с покупателем, но и экономику поддержки.

Меньше ошибочных обещаний покупателю

Неверно названная цена и подтверждённое наличие отсутствующего товара возвращаются в магазин отменой, возвратом или претензией. Когда ответ строится из полей каталога, этот класс ошибок сжимается до случаев, когда данные неверны в самом каталоге. Такая задача управляема: её закрывают регламентом обновления данных, а не настройкой модели.

Разгрузка первой линии поддержки

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

Ограничения ассистента на данных магазина

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

Архитектура: каталог, база знаний и система заказов

Каталог как источник истины по товарам

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

База знаний для условий и правил

Условия доставки и оплаты, правила возврата, гарантия, программа лояльности и действующие акции образуют отдельный источник. Хранить его удобно короткими документами по одной теме, и у каждого документа должны быть раздел, дата последнего обновления и срок действия. Документ без срока действия особенно опасен в акциях: просроченное условие ассистент будет цитировать месяцами.

Система заказов как источник по сделке

Статус, состав, сумма, трек-номер и дата отправки берутся из системы заказов по идентификатору покупателя. Эти данные не индексируются и не хранятся в поисковом слое ассистента: они запрашиваются на каждый вопрос и не сохраняются после диалога.

Маршрутизация вопроса к источнику

Перед поиском вопрос классифицируется, и маршрут определяет, какой источник опрашивается. Один вопрос может потребовать двух источников: «придёт ли мой заказ до пятницы» — это статус из системы заказов плюс условия доставки из базы знаний. Карта маршрутов описывается до запуска и становится частью тестового набора.

Маршрут вопроса и поведение ассистента, когда данных нет

Актуальность цен и наличия

Разделение поискового индекса и точечных запросов

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

Метка времени и порог давности

Каждое числовое значение в ответе сопровождается временем, на которое оно получено. Для ответа задаётся порог давности: данные старше порога не используются как утверждение. Порог зависит от категории — для товаров с быстрой оборачиваемостью он короче, для крупной бытовой техники длиннее. У акций обязательным полем становится срок действия, и просроченное условие в ответ не попадает.

Проверяемый пример ответа про цену

Вопрос «сколько стоит и есть ли в наличии» закрывается ответом из четырёх элементов: цена, статус наличия, время получения данных, переход в карточку товара. Статусы наличия удобно держать в канонических значениях — «в наличии», «нет в наличии», «предзаказ», «под заказ». Эти значения входят в перечень поля доступности товара в разметке schema.org ItemAvailability.

Когда остаток не подтверждён, в ответе остаётся формулировка «наличие уточняется» вместо «есть». Разница в одном слове определяет, появится ли у покупателя повод для претензии.

Доступ к статусу заказа

Подтверждение личности покупателя

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

Границы выдаваемых полей

Список полей, которые ассистент имеет право назвать, фиксируется до запуска. Разумная граница делится на три части:

• Можно назвать — статус, дата отправки, трек-номер, состав и сумма заказа, способ получения.
• Нельзя назвать — платёжные реквизиты, полные данные получателя, адрес, если заказ оформлен на другого человека.
• Только с подтверждением — отмена, смена адреса, оформление возврата: по умолчанию ассистент работает в режиме чтения.

Запрос к системе заказов идёт от имени покупателя, с его токеном доступа, а не сервисным ключом с правом читать все заказы. Это ограничивает последствия внедрения инструкций в данные — класса атак, который описан в OWASP Top 10 для приложений на больших языковых моделях под названием prompt injection. Даже если текст в описании товара или в отзыве попросит показать заказы другого покупателя, технической возможности их получить у ассистента не остаётся.

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

Передача оператору

Условия немедленной передачи

Передача человеку описывается правилами, а не настроением модели. Диалог уходит оператору, когда срабатывает любое из условий:

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

Контекст, который передаётся оператору

Переключение без контекста обесценивает работу ассистента: покупатель пересказывает историю заново. Оператору передаются:

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

Срок, за который ответит оператор, ассистент не называет, пока очередь обращений не контролируется. Вместо срока он сообщает режим работы поддержки и номер обращения.

Ложные ответы: источники и ограничители

Пять типов ложных ответов

Ложные ответы (в индустрии — галлюцинации) распадаются на пять разных задач, и каждая закрывается своим ограничителем.

Типы ложных ответов ассистента и ограничители под каждый тип

Ограничители на стороне кода, а не только инструкции

Фраза в системном сообщении «отвечай только по переданным данным» — необходимый, но слабый ограничитель: модель способна её нарушить. Устойчивая часть ограничений живёт в коде сервиса:

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

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

Тестовый набор вопросов и оценка качества

Состав тестового набора

Набор собирается до запуска и остаётся главным инструментом приёмки. В него входят:

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

Каждому вопросу ставится эталонный ответ и признак, что считать ошибкой. По нашей практике рабочий минимум — 150–200 вопросов: меньший набор не покрывает статусы заказа и отказные сценарии.

Регулярность проверки набора

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

Метрики, которые считаются автоматически

Качество измеряется шестью показателями с понятной реакцией на отклонение.

Метрики качества ответов и реакция на отклонение

Выборочная проверка диалогов руками

Автоматические показатели не видят уместность и интонацию. Раз в неделю выборка диалогов читается руками: два проверяющих независимо отмечают ошибки, спорные случаи разбираются отдельно и дополняют тестовый набор. Выборку смещают в сторону диалогов с передачей оператору и с низкой оценкой покупателя.

Чек-лист внедрения

Перед запуском стоит получить «да» на десять вопросов:

• У каждого поля каталога есть один владелец, и цена не дублируется в тексте карточки?
• Цена, остаток и срок доставки запрашиваются в момент ответа, а не берутся из поискового индекса?
• Для каждой категории товаров задан порог давности данных?
• У документов базы знаний есть дата обновления и срок действия?
• Карта маршрутов «тип вопроса — источник» описана и покрыта тестами?
• Доступ к заказу открывается только после подтверждения личности покупателя?
• Запрос к заказам идёт с токеном покупателя, а не сервисным ключом на все заказы?
• Список полей заказа, которые ассистент называет, зафиксирован письменно?
• Условия передачи оператору описаны и проверены на тестовом наборе?
• Метрики считаются с первого дня, и у них есть ответственный в команде?

Итог

Ограничение ответов данными каталога и заказов — выигрышный путь для магазина, который хочет отвечать покупателю за секунды и при этом не брать на себя обещаний, которых не выполнит. Работу делают три решения: разделение источников по типу вопроса, точечный запрос короткоживущих данных в момент ответа и подтверждение личности перед выдачей заказа. Проверяемость держится на тестовом наборе с эталонами и на метриках, которые считаются каждую неделю.

Границы ассистента и способ проверки каждой из них

Обсудить задачу

Начать обсуждение удобно с двух документов: списка 20–30 самых частых вопросов покупателей за последний месяц и описания того, где сегодня живут цена, остаток и статус заказа. По этой паре видно, какую часть вопросов ассистент закроет источниками магазина, а какая останется за оператором. Напишите нашей команде — разберём ваш список и покажем, какие маршруты данных понадобятся.