Пять паттернов провала LLM в multi-step задачах

Что происходит: Агент делает точный запрос ("AMD Ryzen 9 5900X") → не находит → останавливается. Пропускает варианты написания: "Ryzen 9 5900X", "R9 5900X", просто "5900X".

Как избежать: Начинай с широкого запроса, постепенно сужай. Если не нашёл — расширяй, а не останавливайся.

Промпт-паттерн:

Шаг 1: Найди все товары/сервисы в категории {широкая категория}
Шаг 2: Отфильтруй по {критерий 1}
Шаг 3: Из оставшихся выбери те, что соответствуют {критерий 2}
Если на шаге N ничего не нашёл → вернись на шаг N-1 и попробуй {альтернативный критерий}

Что происходит: Агент находит первый подходящий результат в магазине 1 → сразу отвечает → пропускает магазины 2-4. Частая ошибка агентов без памяти — они не помнят что ещё есть источники для проверки.

Как избежать: Явно проси проверить все источники перед ответом.

Промпт-паттерн:

1. Проверь источник 1 → запиши результаты
2. Проверь источник 2 → запиши результаты
3. Проверь источник 3 → запиши результаты
4. ТОЛЬКО ПОСЛЕ проверки всех → сравни и выбери лучший

НЕ отвечай пока не проверил все {N} источников.

Что происходит: Агент нашёл в источнике 1: "товар X за 500₽" → переходит в источник 2 → забывает про находку из 1 → начинает с чистого листа.

Как избежать: Используй явную память — после каждого источника делай summary с ключевыми данными.

Промпт-паттерн:

После проверки каждого источника — заполняй таблицу:

| Источник | Найденный товар/сервис | Цена | Особенности | Ссылка |
|----------|------------------------|------|-------------|--------|
| 1 | | | | |
| 2 | | | | |

В конце — сравни все строки таблицы и выбери лучший вариант.

Что происходит: Агент возвращает неполные URL (только домен без страницы товара), мешает форматы (то таблица, то список), пропускает важные детали.

Как избежать: Задавай чёткий формат вывода с примером. Не "верни URL", а "верни полный URL в формате https://...".

Промпт-паттерн:

Верни ответ СТРОГО в формате:

Название: {название товара}
Цена: {цена с валютой}
URL: {ПОЛНЫЙ URL страницы товара, например https://example.com/product/12345}
Почему выбрал: {1-2 предложения}

НИКАКОГО другого текста. Только эти 4 строки.

Что происходит: Агент следует одной стратегии (например, поиск по точному названию) → застревает → не меняет подход → исчерпывает лимит попыток.

Как избежать: Дай fallback-сценарии для случаев когда основной план не работает.

Промпт-паттерн:

План А: Найди товар по точному названию "{название}"
Если не нашёл → План Б: Поищи по частичному совпадению (убери бренд из запроса)
Если всё ещё не нашёл → План В: Найди аналоги в той же ценовой категории {ценовой диапазон}
Если ни один план не сработал → сообщи "не нашёл" и объясни почему

Задача: Найти лучший коворкинг в Москве для удалённой команды из 5 человек с бюджетом до 80,000₽/мес. Нужно проверить несколько сервисов (WorkClass, Часы, Рабочая Станция), сравнить цены и условия.

Промпт:

Твоя задача: найти лучший коворкинг для команды из 5 человек в Москве.

Требования:
- Бюджет: до 80,000₽/мес
- Локация: в пределах ТТК
- Нужно: переговорка, кухня, стабильный интернет

ЭТАПЫ (выполняй последовательно):

1. Проверь сайты: WorkClass.ru, chasy.me, rabochayastanciya.ru
 Для каждого сайта:
 - Найди тарифы для команд
 - Запиши: название пространства, цена, адрес, что входит
 
2. После проверки КАЖДОГО сайта заполняй таблицу:
 
 | Коворкинг | Тариф | Цена/мес | Адрес | Переговорка | Кухня | Интернет | URL |
 |-----------|-------|----------|-------|-------------|-------|----------|-----|
 
3. ТОЛЬКО после заполнения всех строк → сравни варианты и выбери ТОП-2

4. Финальный ответ в формате:
 
 **Лучший вариант:**
 Название: [...]
 Цена: [...] ₽/мес
 Адрес: [...]
 Почему: [2-3 предложения]
 URL: [ПОЛНЫЙ URL]
 
 **Альтернатива:**
 [то же самое]

FALLBACK: Если на сайте нет тарифов для команд → поищи тарифы для 5 резидентов и посчитай сумму.

Результат: Модель последовательно проверит три сайта, заполнит таблицу сравнения (вы увидите промежуточные результаты по каждому источнику), затем выдаст финальный ответ с двумя лучшими вариантами в чётком формате. Если на каком-то сайте нет прямого тарифа "для команд" — применит fallback и посчитает стоимость для 5 человек.

LLM плохо держит контекст в длинных последовательностях действий. Когда агент переходит от источника 1 к источнику 2, он может "забыть" что нашёл в первом — не потому что стёрлась память (контекст-то сохраняется), а потому что модель не знает на что обращать внимание. Она видит весь предыдущий диалог, но без явных инструкций "запомни это" она может проигнорировать важные детали.

Структурированные инструкции и таблицы — это внешняя память. Когда вы просите "после каждого источника заполняй таблицу", вы создаёте чёткую структуру для хранения промежуточных результатов. Модель больше не полагается на "помню/не помню" — она смотрит в таблицу и видит все собранные данные. Это аналог accessibility tree для агентов: вместо размытой картинки контекста модель видит чёткий список элементов.

Fallback-сценарии снижают жёсткость стратегии. LLM склонны зацикливаться на одном подходе — если задали "найди по точному названию" и не получилось, они могут просто остановиться. Явное описание альтернативных планов расширяет пространство поиска и даёт модели разрешение попробовать другой путь, вместо того чтобы застрять.

Чёткий формат вывода с примером — это few-shot. Когда вы пишете не "верни результат", а показываете точный формат с плейсхолдерами, вы даёте модели шаблон для заполнения. Это резко снижает вариативность вывода и вероятность ошибок форматирования.

⚠️ Длинные multi-step задачи — дорого: GPT-4.1 потребляет 130-180k токенов на задачу (около $0.30-0.40), Claude Sonnet 4 — до 480k токенов (до $1.60). Если задача требует 30-50 шагов через 4 источника с промежуточными summary — счёт может уйти в рубли быстро.

⚠️ Fallback-сценарии усложняют промпт: Каждый дополнительный "План Б" и "План В" добавляет инструкций. Для простых задач это overkill — модель может запутаться в условиях. Fallback имеет смысл для действительно сложных поисков, где один подход часто проваливается.

⚠️ Таблицы не панацея: Если задача требует глубокого анализа текста (например, сравнить подход двух статей к проблеме), таблица с 3-4 колонками не поможет. Структурированное хранение работает для фактических данных (цена, адрес, характеристики), но не для смысловых нюансов.

Команда из University of Mannheim создала четыре онлайн-магазина на WordPress/WooCommerce с разными шаблонами и интерфейсами. Товары (компьютерные комплектующие, периферия, электроника) взяли из Common Crawl — около 4,400 офферов от сотен реальных магазинов. Это создало высокую гетерогенность: описания товаров различаются по длине (от 6 до 14,000 символов), стилю, детальности — как в реальном интернете. Деревья категорий в каждом магазине свои, поисковые строки в разных местах — нет унифицированного UI.

Протестировали 8 конфигураций агентов на базе Browsergym/AgentLab: GPT-4.1 и Claude Sonnet 4, каждый в четырёх вариантах — (1) только accessibility tree, (2) accessibility + память, (3) accessibility + скриншоты, (4) только скриншоты. Память = persistent memory между шагами, где агент может хранить промежуточные находки. Каждому агенту давали до 50 шагов на задачу.

Результаты показали явный паттерн: accessibility tree критична. Конфигурации без структурированных данных проваливались на 60-90% задач. Агенты со скриншотами часто не могли найти поисковую строку или кнопку "добавить в корзину" — визуальная модальность не компенсирует отсутствие структуры. Интересно что память помогает сильнее для GPT-4.1 (рост с 56% до 75% на базовых задачах), чем для Claude Sonnet 4. Это может означать что Claude лучше использует контекстное окно без явных подсказок "запомни это".

Самая частая причина провала (по логам траекторий) — преждевременная остановка: агент нашёл первый подходящий товар и сразу отправил ответ, не проверив остальные три магазина. На втором месте — жёсткость поиска: агент сделал специфичный запрос, не нашёл результатов, попробовал ещё раз тот же запрос и сдался. Такие "глупые" ошибки происходят даже с топовыми LLM — это показывает что стратегия важнее сырой мощности модели.

WebMall: A Multi-Shop Benchmark for Evaluating Web Agents

Ralph Peeters, Aaron Steiner, Luca Schwarz, Julian Yuya Caspary, Christian Bizer

University of Mannheim, Data and Web Science Group

Репозиторий: github.com/wbsg-uni-mannheim/WebMall

Датасет: Common Crawl (октябрь 2024) через WDC Extraction