TL;DR
«Подходит пользователю» и «можно покупать без вопросов» — разные вещи, и LLM-агенты их путают. Исследование разложило решение агента на четыре фактора: достаточность данных о товаре (есть ли в карточке ответ на главную тревогу пользователя), обратимость (можно ли вернуть), цена относительно нормы пользователя и срочность. Выход из этого решения тройной: «не покупать», «спросить», «купить сам». Агентам дали все три варианта и меняли по одному фактору за раз.
Главная находка: модели почти не реагируют на то, что товар плохо подходит, но резко реагируют на отсутствие данных. Если сказать агенту, что кроссовки пользователю не подходят по вкусу, он всё равно покупает в большинстве случаев. Если в карточке нет информации о важном параметре, например о ширине колодки, часть моделей падает до нуля покупок. Хуже всего другое: при фразах вроде «не беспокой меня» и «просто купи лучшее» защита от слабых данных у многих моделей исчезает. Агенты покупают, даже когда сами пометили «данных нет». Цена внутри лимита почти не тормозит: пока сумма ниже бюджета, агент покупает. Выше лимита покупки обрываются почти до нуля.
Практический вывод: не ждите от агента «здравого смысла» про автономность. Прописывайте в инструкции три исхода, жёсткие условия остановки и числовой потолок. Читайте решение по факторам, а не по общему «подходит». Для опасной зоны (хороший вкус, слабые данные) лучший контроль — правило о необходимости подтверждения, а не надежда на модель.
Схема проверки решения агента
ШАГ 1: Карточка товара → поля: история, задача, данные по главной тревоге,
условия возврата, цена относительно лимита, наличие
ШАГ 2: Четыре фактора → данные (хватает/противоречат/нет) · обратимость ·
цена vs лимит · срочность (настоящая или давление)
ШАГ 3: Три исхода → не покупать / спросить / купить сам
ШАГ 4: Ответ → JSON: действие + собственная оценка данных
Всё помещается в один системный промпт. Что делают авторы: меняют один фактор за раз и смотрят, куда сдвинулось действие агента.
Пример применения
Задача: Вы настраиваете личного агента (в Claude, ChatGPT или в сценарии без кода) для заказов на Wildberries и Lamoda. Условие: «заказывай, не дёргай меня». Пользователь — Марина, у неё широкая стопа, и жёсткие узкие кроссовки она терпеть не может. Бюджет на обувь — 8 000 ₽. Агент нашёл кроссовки: цвет и стиль идеальны, отзывы о ширине колодки противоречат друг другу. Цена со скидкой «до конца дня», продавец новый, без рейтинга, возврат есть.
Промпт:
Ты — агент личных покупок Марины. Покупка делегирована тебе, но автономия ограничена.
<Профиль>
Предпочтения: широкая стопа; не переносит жёсткую узкую обувь; любит минимализм.
Лимит на обувь: 8 000 ₽ (потолок автопокупки).
Профиль>
<Задача>
Купить кроссовки на каждый день, размер 38.
Задача>
<Карточка_товара>
Товар: кроссовки «Нордик», бежевые, размер 38.
Данные по колодке: отзывы противоречат друг другу («узкие» / «в самый раз»), в описании ширина не указана.
Условия возврата: возврат 14 дней, платный.
Цена: 5 900 ₽ вместо 9 500 ₽, акция заканчивается через 4 часа.
Продавец: новый, без рейтинга, причина скидки не указана.
Наличие: осталась 1 пара.
Карточка_товара>
<Правила_решения>
Выбери ОДИН исход:
- "buy_automatically" — только если выполнены ВСЕ условия: данные по главной тревоге (ширина колодки) однозначно её закрывают; покупка обратима; цена ниже лимита и без подозрительных признаков; срочность не является давлением.
- "confirm_first" — если данные противоречат друг другу или отсутствуют, покупка необратима, цена подозрительно низкая или продавец без рейтинга, либо есть давление срочности.
- "dont_buy" — если цена выше лимита или товар явно не подходит.
Хороший вкус-match НЕ даёт права покупать без вопросов. Срочность («осталась 1 пара», «акция 4 часа») не причина для покупки, если данных не хватает.
Если ты сам отметил данные как "missing" или "conflicting" — исход не может быть "buy_automatically".
Правила_решения>
<Формат_ответа>
JSON: {"evidence_status": "resolving|conflicting|missing", "factors": {"warrant": "...", "reversibility": "...", "price": "...", "urgency": "..."}, "action": "dont_buy|confirm_first|buy_automatically", "reason": "одно предложение"}
Формат_ответа>
Результат: Модель выдаст JSON с разбором по четырём факторам. Здесь данные противоречивы, продавец новый, скидка необъяснима и есть давление срочности, поэтому ожидается исход «спросить сначала». В поле причины будет видно, на каком факторе остановилась модель. Важно проверить, что оценка данных и выбранное действие не противоречат друг другу.
Почему это работает
Слабость модели: в «агентной» рамке («купи, не беспокой, остановка на рекомендации = работа не сделана») модель считает задачу законченной только покупкой. Совпадение со вкусом она принимает за разрешение. Цену ниже лимита почти не замечает. Даже собственную пометку «данных нет» не использует как стоп-сигнал: в исследовании модели писали «missing» и всё равно покупали.
Сильная сторона: модель хорошо работает с явными полями и жёсткими порогами. Лимит бюджета срабатывает почти безотказно: на цене в 1,2 раза выше лимита покупки падали почти до нуля даже у самых «смелых» моделей. Модель честно описывает состояние данных, если её об этом просят.
Как метод обходит слабость: разделяет «нравится» и «можно» на разные поля и связывает пометку модели с запретом. Фактор делается явным и проверяемым. Решение читается по причинам, а не по общему впечатлению.
Рычаги: - Формулировка автономии: от «покупай, только если абсолютно уверен» до «просто купи лучшее». Чем ближе к «просто купи», тем быстрее у слабых моделей пропадает защита. Для нового агента начинайте с осторожной. - Жёсткий потолок бюджета: работает надёжнее остальных ценовых сигналов, потому что это число. Ставьте его явно. - Список «обязательно спросить»: необратимость, необъяснимая скидка, продавец без рейтинга, срочность при слабых данных. Необратимость исследование показало как самую хрупкую: она держится только при осторожной инструкции. - Уберите «не беспокой меня»: эта фраза сильнее всего толкает на покупку (подробнее в адаптациях).
Шаблон промпта
Точные формулировки оригинала лежат в приложении статьи (в предоставленном тексте их нет). Шаблон ниже собран по описанной в статье структуре: карточка данных, три исхода, JSON с собственной оценкой данных. Правило «пометка missing → нельзя покупать сам» — моя связка, авторы её не проверяли.
Ты — агент, которому {пользователь} делегировал {тип_действия}.
<Профиль>
Предпочтения и тревоги: {что_важно_и_что_раздражает}.
Потолок автодействия: {лимит} {валюта}.
Профиль>
<Задача>
{что_нужно_сделать}
Задача>
<Карточка>
Объект: {название_и_вариант}.
Данные по главной тревоге: {что_известно_противоречиво_или_нет}.
Условия возврата/отмены: {условия}.
Цена: {цена} (лимит: {лимит}).
Срочность и наличие: {сигналы}.
Источник: {продавец_или_площадка_и_рейтинг}.
Карточка>
<Правила_решения>
Выбери ОДИН исход:
- "buy_automatically" — только если одновременно: данные однозначно закрывают главную тревогу; действие обратимо; цена ниже лимита и не вызывает подозрений; срочность не создаёт давления.
- "confirm_first" — если данные противоречат или отсутствуют, действие необратимо, цена или источник вызывают подозрение, либо срочность давит.
- "dont_buy" — если цена выше лимита или объект явно не подходит.
Совпадение со вкусом не даёт права действовать без вопроса.
Если твоя оценка данных "missing" или "conflicting" — исход не может быть "buy_automatically".
Правила_решения>
<Формат_ответа>
JSON: {"evidence_status": "resolving|conflicting|missing", "factors": {"warrant": "", "reversibility": "", "price": "", "urgency": ""}, "action": "", "reason": ""}
Формат_ответа>
Что подставлять: {тип_действия} — покупка, бронь, подписка, оплата подрядчика. {лимит} — конкретное число. {главная_тревога} — то, что конкретно этот человек проверяет: ширина колодки, тишина в номере, размер файла, срок доставки.
🚀 Быстрый старт — вставь в чат:
Вот шаблон правил автономии агента. Адаптируй под мою задачу: [опиши, что агент делает за тебя: покупки, брони, подписки, платежи].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про твоё главное беспокойство при таком действии, лимит суммы, что необратимо, какие сигналы срочности считать давлением и кому доверять как источнику. Эти поля нужны, потому что весь метод держится на явных факторах и пороге. Без них агент вернётся к «подходит, значит покупаю».
Ограничения
⚠️ Граница индивидуальна: люди сильно расходятся в том, где ставить линию «покупать самому». Ни одна из проверенных комбинаций промпта и модели не угадывала личную границу лучше, чем простой классификатор на нескольких десятках собственных решений человека. Общий промпт даст «среднюю» границу, не вашу.
⚠️ Шаблон выше не проверен авторами как целое: исследование показывает поведение моделей при разных формулировках и факторах. Конкретный набор правил и связку «пометка missing → запрет» они как такой защитный промпт не тестировали (внешний контроллер — отдельный вопрос исследования, его результаты в предоставленном тексте отсутствуют). Проверяйте на своих кейсах.
⚠️ «Просто купи лучшее» ломает защиту: у маленьких моделей при самой смелой формулировке контроль слабых данных падает почти до нуля. Спокойно держат его только несколько сильных моделей.
⚠️ Необратимость хрупка: при свободной формулировке модели часто покупают невозвратное. Не рассчитывайте, что «возврата нет» остановит агента само по себе.
⚠️ Личную границу нельзя переносить между доменами: выученная для одежды линия не работает для отелей. Самый «обучаемый» результат статьи требует обучать небольшой классификатор, а это инженерия, а не промпт.
⚠️ Оценщики играли роли: «разрешение» определяли люди, воображавшие себя владельцем профиля, а не настоящие владельцы покупок. «Переусердствование» означает превышение этой оценки, а не вашей личной границы.
Как исследовали
Команда ZOZO Research взяла реальные истории покупателей из отзывов Amazon (одежда, обувь, украшения) и Booking.com (отели). Из них собрали 20 «семей» — один покупатель с постоянной тревогой, например про посадку. Дальше сделали контрфактуальные пары: взяли идеальный случай (подходит, данные есть, возврат есть, цена нормальная, срочности нет) и меняли ровно один фактор за раз. Если решение агента сдвигается, виноват именно этот фактор.
Оценщиками выступили 15 человек: они играли роли покупателей и выбирали, до какого шага готовы пустить агента без подтверждения. Всего 1 110 меток по 270 кейсам. Проверяли 16 моделей четырёх вендоров. Чтобы не винить одну формулировку, прогнали 5 уровней автономии инструкции (от «покупай, только если уверен» до «просто купи»), 24 перефразирования и 8 «плацебо»-правок, не влияющих на смысл.
Результаты удивляют. Тем, что товар «не подходит по вкусу», модели почти не смущаются: в среднем они покупали в 89% случаев. Но те же модели падали до 0 покупок, когда информации по главной тревоге не было. Бюджет ниже лимита почти не действует, коммитов 91–99%. На цене в 1,2 раза выше лимита всё обрывается до 0,4%. Пока инструкция осторожная, защита от слабых данных есть почти у всех. При смелой, к концу шкалы, она падает примерно до 60% в целом, у маленьких моделей до нуля. Простой классификатор на 30–40 собственных решениях человека предсказывает его границу с медианой 0,79 и обходит любую комбинацию промпта и модели, даже лучшую из 80 конфигураций, подобранную отдельно под каждого оценщика.
Инсайт для практики: поведение агента определяется не вашими «предпочтениями», а тем, как сформулирована автономия, и защиту нужно закладывать явно.
Адаптации и экстраполяции
🔧 Техника: убрать «не беспокой меня» → меньше слепых покупок
Замените «покупай, не пингуй, пока не нужно» на «покупай только если выполнены условия X, Y, Z, иначе спроси». В исследовании именно осторожная формулировка сохраняла защиту у большинства моделей. Цена: больше вопросов вам.
🔧 Техника: добавить поле «источник/продавец» → ловит мошенничество
В исследовании необъяснимая скидка от продавца без рейтинга отсекалась откалиброванными моделями при любой формулировке, а «смелые» модели на ней сыпались. Если в вашей задаче есть риск подделок, выделите источник отдельным полем и прямо пропишите: «скидка без причины + новый продавец = confirm_first».
Экстраполяция: калибровка по своим решениям. Авторы показали, что личную границу лучше всего учить по собственным пометкам человека. Полноценный классификатор требует кода. Облегчённая гипотеза для чата: размеченные вами 10–15 случаев вставить в промпт как примеры. Это моя идея, в статье она не проверялась.
Вот 12 карточек покупок и мои решения: {карточка → не купил / спросил / купил сам}.
Выведи по ним мои правила: на какие факторы я реагирую жёстче всего.
Составь по ним инструкцию для агента и укажи, в чём не уверен.
Ресурсы
- Работа: Preference Is Not Permission: Personalizing the Auto-Purchase Line in Agentic Commerce
- Авторы: Ryotaro Shimizu, Sai Htaung Kham, Mo Fan — ZOZO Research, Токио
- Данные для сценариев: Amazon Reviews 2023 (Clothing, Shoes and Jewelry), Booking.com reviews
- Релиз: контрфактуальный бенчмарк, человеческая эталонная разметка и протокол аннотации обещаны после принятия статьи
- Примечание: текст статьи обрезан на разделе 4.2, результаты разделов 5–7 и приложение с точными промптами не рассматривались
