ShoppingBench: реальный бенчмарк для покупок, основанный на намерениях, для агентов на базе LLM

Исследователи создали симулятор интернет-магазина ("песочницу") и набор сложных покупательских задач, чтобы проверить, насколько хорошо LLM-агенты справляются с реальными запросами. Они обнаружили, что даже самые продвинутые модели, как GPT-4, успешно выполняют задачу менее чем в 50% случаев, если она содержит несколько условий одновременно (например, найти два товара, уложиться в бюджет и применить скидочный купон).

Ключевой результат: Современные LLM крайне ненадежны в выполнении многокомпонентных инструкций и часто "забывают" или игнорируют одно или несколько из заданных условий.

Суть исследования для практика промпт-инжиниринга сводится к одному главному выводу: LLM плохо справляется с многозадачностью в рамках одного запроса. Когда вы даете модели задачу с 3-4 и более ограничениями (например: "найди отель", "в центре города", "с бассейном", "не дороже 100$", "с завтраком"), вероятность того, что она упустит хотя бы одно из них, очень высока.

Авторы показали это на примере e-commerce агентов, которые должны были вызывать разные инструменты (поиск товара, проверка деталей, калькулятор). Но для обычного пользователя это означает, что нельзя полагаться на способность LLM удержать в "рабочей памяти" все ваши условия.

Практическая методика, вытекающая из этого, — "Принудительная Декомпозиция и Пошаговая Верификация":

1. Не пишите сложные промпты "монолитом". Вместо того чтобы вываливать все требования в одном абзаце, разбейте вашу большую задачу на последовательность более мелких и простых подзадач.
2. Ведите LLM по шагам. Выступайте в роли менеджера проекта. Сначала попросите модель выполнить первый шаг (например, найти товары по одному главному критерию). Затем, в следующем сообщении, попросите отфильтровать полученный результат по второму критерию, и так далее.
3. Используйте "принудительное мышление". Включайте в промпт фразы типа «Думай шаг за шагом» или «Составь план своих действий, прежде чем давать ответ». Исследование показало, что такой подход (reasoning) улучшает результаты на сложных задачах.
4. Требуйте явного подтверждения. В конце диалога прямо попросите модель проверить саму себя: «А теперь проверь, соответствует ли твой итоговый ответ всем моим первоначальным требованиям: [список требований]». Это заставляет модель провести самопроверку и снижает количество ошибок.

• Прямая применимость: Низкая. Пользователь не может использовать API-инструменты и "песочницу" из статьи. Однако, он может напрямую применять технику "принудительного мышления" (например, "Думай шаг за шагом"), эффективность которой подтверждается в исследовании для сложных задач.

• Концептуальная ценность: Очень высокая. Исследование дает пользователю реалистичное понимание слабостей LLM. Вместо того чтобы воспринимать модель как "волшебника", пользователь начинает видеть в ней "исполнительного, но забывчивого помощника", которому нужны очень четкие, разбитые на этапы инструкции и постоянный контроль. Это знание — основа для построения надежных и сложных взаимодействий с LLM.

• Потенциал для адаптации: Высокий. Хотя методы агентов (вызов API) недоступны, логику их работы можно полностью воспроизвести в диалоге. Пользователь может сам "оркестрировать" процесс, превращая сложный одношаговый запрос в многошаговый диалог, где каждый шаг — это простой промпт, а результат шага используется как контекст для следующего. Это прямая адаптация агентского подхода для обычного чата.

Представим, что пользователь хочет спланировать сложное мероприятие — день рождения для друга.

Плохой промпт (который, как показывает исследование, скорее всего провалится): "Привет, помоги организовать день рождения для друга в Москве в следующие выходные. Нас будет 8 человек. Он любит итальянскую кухню, но не пиццу. Нужно найти ресторан с отдельным залом, средний чек до 3000 руб на человека. После ужина мы хотим пойти в какой-нибудь бар с живой музыкой (джаз или блюз) недалеко от ресторана. Составь полный план с адресами и примерными ценами."

Хороший промпт (с использованием "Принудительной Декомпозиции и Верификации"):

Ты — опытный организатор мероприятий. Твоя задача — помочь мне спланировать идеальный день рождения для друга в Москве.

**Вот все исходные данные:**
*   **Количество гостей:** 8 человек.
*   **Дата:** Ближайшая суббота.
*   **Задача №1 (Ужин):** Найти ресторан итальянской кухни (паста, ризотто, но НЕ пиццерия) со средним чеком до 3000 руб./чел и возможностью забронировать отдельный зал или уединенный большой стол.
*   **Задача №2 (Продолжение):** Найти джаз- или блюз-бар с живой музыкой, расположенный не более чем в 15 минутах ходьбы от выбранного ресторана.

**Действуй строго по этому плану, шаг за шагом:**

1.  **Шаг 1: Рестораны.** Сначала предложи 3-4 варианта ресторанов, которые соответствуют ВСЕМ критериям из "Задачи №1". Для каждого варианта укажи название, адрес, примерный средний чек и подтверждение наличия отдельного зала.
2.  **Шаг 2: Бары.** Только ПОСЛЕ того, как я выберу один ресторан из твоего списка, ты начнешь искать бары (Задача №2) рядом с ним. Не делай этого заранее.
3.  **Шаг 3: Итоговый план.** Когда мы определимся с рестораном и баром, сведи все в единый план с таймингом, адресами и контактами.

Начнем с **Шага 1**. Жду твои варианты ресторанов.

Этот промпт работает, потому что он напрямую борется с проблемами, выявленными в исследовании:

1. Снижение когнитивной нагрузки: Вместо того чтобы требовать от LLM одновременно решить задачу оптимизации с 6-7 переменными, мы разбиваем ее на две последовательные подзадачи. Модель сначала фокусируется только на ресторане, что значительно повышает шанс найти релевантный вариант.
2. Принудительная пошаговая логика: Инструкция "Действуй строго по этому плану, шаг за шагом" и нумерованные этапы имитируют "reasoning" (мышление) агента из статьи. Мы не даем модели свободы действий, где она может "срезать путь" и упустить детали.
3. Промежуточная верификация пользователем: Конструкция "ПОСЛЕ того, как я выберу..." вводит в процесс человека. Пользователь сам проверяет результат первого шага, прежде чем разрешить модели перейти ко второму. Это гарантирует, что ошибка на раннем этапе не испортит весь итоговый результат.

Задача: Подбор смартфона по множеству критериев.

Выступи в роли эксперта-консультанта по гаджетам. Мне нужен новый смартфон. Я предоставлю тебе свои требования, а ты должен помочь мне выбрать лучшую модель.

**Мои ключевые требования:**
*   `<Бюджет>`: до 40 000 рублей.
*   `<Камера>`: Основной приоритет. Важно качество фото в условиях низкой освещенности.
*   `<Батарея>`: Должна уверенно держать заряд полный рабочий день при активном использовании.
*   `<Экран>`: AMOLED, частота обновления 90 Гц или выше.
*   ``: Обязательно.

**Твоя методология анализа:**

1.  **Рассуждай вслух.** Прежде чем дать ответ, опиши свою логику: какие модели ты рассматриваешь и почему.
2.  **Отбор кандидатов.** На основе моих требований предложи 3 смартфона-кандидата, которые наилучшим образом им соответствуют.
3.  **Сравнительная таблица.** Создай таблицу для этих 3 моделей со следующими колонками: "Модель", "Примерная цена", "Соответствие требованию 'Камера'", "Соответствие требованию 'Батарея'", "Соответствие требованию 'Экран'".
4.  **Финальная рекомендация.** После таблицы напиши, какую из этих трех моделей ты бы порекомендовал именно мне и почему, взвесив все "за" и "против".

Этот промпт эффективен, так как он использует концептуальные выводы из исследования для повышения надежности ответа:

1. Структурирование ограничений: Использование XML-подобных тегов (<Бюджет>, <Камера>) помогает модели четко выделить и идентифицировать каждое отдельное условие, снижая риск "пропуска атрибута" (#AM - attribute mismatch), который был одной из главных причин ошибок в исследовании.
2. Принудительное мышление и самопроверка: Требование "Рассуждай вслух" заставляет LLM активировать цепочку рассуждений (Chain-of-Thought). Создание сравнительной таблицы — это форма принудительной самопроверки. Модель не может просто заявить, что смартфон подходит; она должна явно заполнить ячейки таблицы, что заставляет ее сопоставить каждую модель с каждым требованием. Это напрямую борется с ошибкой "условие не выполнено" (#CNS - constraint not satisfied).
3. Фокус на релевантности: Вместо того чтобы просить "список всех телефонов", промпт просит "3 лучших кандидата" и "финальную рекомендацию". Это смещает фокус с простого поиска на анализ и сравнение, что является более сильной стороной LLM, чем точное соблюдение жестких фильтров.

• A. Релевантность техникам промтинга: Низкая. Исследование не предлагает конкретных формулировок промптов для пользователя, а использует LLM для генерации тестовых запросов для оценки LLM-агентов.
• B. Улучшение качества диалоговых ответов: Косвенное. Фокус на успешности выполнения задачи агентом, а не на качестве диалога.
• C. Прямая практическая применимость: Очень низкая. Методология основана на использовании специальных API-инструментов (find_product, python_execute) и симулированной среды ("песочницы"), недоступных обычному пользователю в стандартных чат-ботах.
• D. Концептуальная ценность: Высокая. Исследование наглядно демонстрирует фундаментальное ограничение современных LLM: их низкую надежность при выполнении задач с несколькими (3-4+) жесткими условиями. Понимание этого факта кардинально меняет подход к написанию сложных промптов.
• E. Новая полезная практика: Работа попадает в кластеры #2 (Поведенческие закономерности LLM) и #7 (Надежность и стабильность). Она выявляет, что даже у SOTA-моделей (GPT-4) процент успеха в задачах с несколькими ограничениями (бюджет, атрибуты товара, правила купона) падает ниже 50%. Это ключевая поведенческая закономерность, влияющая на надежность.
• Чек-лист практичности (+15 баллов): Да, работа раскрывает неочевидные особенности поведения LLM (провал на многокритериальных задачах) и концептуально показывает, как структурировать сложные запросы (необходимо разбивать их на части).

Аргументы за оценку 65: Оценка отражает высокую концептуальную ценность при почти нулевой прямой применимости. Исследование не дает готовых "рецептов" промптов, но предоставляет пользователю гораздо более ценную вещь — реалистичную "ментальную модель" LLM. Оно учит не доверять модели в сложных задачах и вместо одного сложного запроса использовать серию простых с промежуточной проверкой. Вывод о том, что даже GPT-4 проваливает половину реалистичных многоусловных задач, — это холодный душ для любого, кто считает LLM всемогущим инструментом. Это знание напрямую влияет на стратегию взаимодействия с чат-ботом и заставляет пользователя быть более методичным.

Контраргументы: * Почему оценка могла быть ниже (30-40): Работа на 95% сфокусирована на разработке и оценке LLM-агентов, а не на промпт-инжиниринге для конечного пользователя. Все выводы сделаны в контексте специализированных инструментов, что делает их непереносимыми "в лоб". Пользователь, ищущий готовые фразы для промпта, не найдет здесь ничего. * Почему оценка могла быть выше (75-80): Понимание фундаментального ограничения LLM в работе с множественными约束 (constraints) — это, возможно, один из самых важных практических инсайтов для продвинутого пользователя. Осознав это, пользователь перестает писать промпты "наудачу" и начинает выстраивать диалог как последовательность логических шагов, что кардинально повышает итоговое качество и надежность. Этот концептуальный сдвиг может быть полезнее, чем изучение десятка мелких техник.