TL;DR
Что это: Исследование провалов LLM при многошаговой работе с инструментами — когда модель сама должна читать файлы, запрашивать базы данных, писать код для анализа CSV. Команда вручную разобрала 900 сценариев выполнения трёх моделей (от 32B до 671B параметров) в бенчмарке KAMI v0.1, который тестирует не "знаешь ли столицу Франции", а "сможешь ли создать нужные папки, извлечь данные из базы через JOIN трёх таблиц, посчитать среднее по CSV в полной точности".
Главная находка: Размер модели почти не определяет надёжность в реальных задачах. Llama 4 Maverick (400B параметров) в некоторых сценариях работает лишь чуть лучше Granite 4 Small (32B) — разница в 20 раз по размеру даёт прирост на проценты. DeepSeek V3.1 доминирует не потому что у неё 671B параметров, а потому что её тренировали через reinforcement learning специально на агентные задачи. Сравнение с архитектурно идентичной DeepSeek V3 (без такого RLHF) это подтверждает: 92% против 59% accuracy при одинаковой архитектуре.
Четыре паттерна провала повторяются у всех моделей: (1) Преждевременное действие — модель угадывает схему базы данных вместо того чтобы запросить её инструментом, (2) Избыточная услужливость — подставляет правдоподобное но неверное значение когда данных нет ("клиент не указан? подставлю самого вероятного"), (3) Уязвимость к мусору — наличие лишних таблиц-дистракторов в базе сбивает с толку, модель начинает JOIN'ить не те таблицы, (4) Деградация при нагрузке — ошибки накапливаются: сломанные вызовы инструментов, циклы генерации, противоречия в логике после 10-15 шагов.
Зачем это читателю
Ты даёшь LLM задачу в чате: "Проанализируй эти данные и выдай отчёт". Модель начинает, делает 5 шагов, и вдруг выдаёт чушь. Или угадывает вместо того чтобы проверить. Или подставляет "разумное предположение" там где нужно признать "данных нет".
Это исследование показывает типичные точки провала и даёт принципы как их обойти через промпт-дизайн: - Явно требуй "сначала проверь факт, потом действуй" - Запрещай гадать: "если не уверен — так и скажи, не подставляй правдоподобное" - Маркируй что игнорировать: "в папке 10 файлов, 7 — мусор, вот признаки нужных" - Дроби длинные задачи: после каждых 3-5 шагов — промежуточный checkpoint
Это не готовый промпт, но понимание как модель ломается — чтобы писать промпты которые эти поломки предотвращают.
Четыре архетипа провала
1. Преждевременное действие без проверки
Что происходит: Модель пишет SQL-запрос, угадывая названия колонок. База возвращает ошибку "колонка ORDER_ID не существует". Модель пробует ORDERID, потом ID_ORDER — перебирает варианты вместо того чтобы один раз запросить схему инструментом sqlite_get_schema.
Почему: LLM обучены предсказывать правдоподобный текст. "Колонка с ID заказа" → правдоподобные названия ORDER_ID, ORDERID, ID. Запрос схемы требует остановиться и проверить, что противоречит "генерирую следующий токен по вероятности".
Как обойти в промпте:
Перед каждым действием с данными:
1. Проверь схему инструментом
2. Выпиши точные названия полей
3. Только потом пиши запрос
Запрещено угадывать названия колонок/файлов/переменных.
2. Избыточная услужливость под неопределённостью
Что происходит: Задача: "Найди средний возраст клиентов из Москвы". В данных нет клиентов из Москвы. Модель не говорит "данных нет", а выдаёт: "Средний возраст клиентов из Москвы: 34.2 года" — взяв среднее по ВСЕМ клиентам или угадав "разумное" число.
Почему: Модели тренированы быть полезными и давать ответ. "Я не знаю" воспринимается как провал. RLHF усиливает это — модель избегает отказов.
Как обойти в промпте:
Если данных для ответа нет или ты не уверен:
- НЕ угадывай правдоподобное значение
- НЕ подставляй похожие данные
- Напиши явно: "Данных нет" или "Требуется уточнение: ..."
Честное "не знаю" ценнее чем правдоподобная неправда.
3. Уязвимость к мусору в контексте
Что происходит: База данных содержит 6 таблиц. Для ответа нужны 3. Остальные 3 — дистракторы (похожие названия, релевантные поля, но неактуальные данные). Модель начинает JOIN'ить не те таблицы или смешивать данные из дистракторов.
Пример: Есть таблица orders_archive (старые данные) и orders_current (актуальные). Модель видит обе, не различает, джойнит обе — результат: дубли и несовпадение с реальностью.
Почему: LLM обрабатывает весь контекст как "релевантный по умолчанию". Нет встроенного механизма "это важно, это — шум". Всё в контексте имеет вес.
Как обойти в промпте:
В окружении есть мусорные данные:
- Файлы с префиксом "archive_" — НЕ используй
- Таблицы с суффиксом "_old" — игнорируй
- Если файл называется "draft", "temp", "backup" — не трогай
Используй ТОЛЬКО: [явный список нужных источников]
4. Деградация при длительной работе
Что происходит: После 10-15 шагов модель начинает: - Вызывать несколько инструментов за раз (хотя разрешён один) - Генерировать тысячи токенов вместо короткого ответа (зацикливание) - Противоречить собственным выводам из предыдущих шагов - Ломать синтаксис вызовов инструментов (JSON с ошибками)
Почему: Контекст растёт, внимание (attention) размывается. Ранние шаги теряют вес. Модель "забывает" что уже делала, начинает повторять или импровизировать. При температуре >0 стохастичность накапливается — вероятность сбоя растёт с каждым шагом.
Как обойти в промпте:
Задача разбита на чекпоинты:
ШАГ 1-3: [подзадача А]
→ По завершении: выпиши результат, жди подтверждения
ШАГ 4-6: [подзадача Б]
→ По завершении: выпиши результат, жди подтверждения
ШАГ 7-9: [подзадача В]
→ Финальный вывод
После каждого чекпоинта — пауза для проверки.
Или технически: начинай новый чат с саммари предыдущего каждые 5-7 шагов (ручное управление контекстом).
Практические принципы
Принцип 1: Верификация перед действием
Не надейся что модель "сама догадается проверить" — она генерирует правдоподобное, не верифицирует по умолчанию.
Шаблон:
Перед выполнением задачи:
1. Проверь [что именно проверить]
2. Запиши результат проверки
3. На основе проверки — действуй
Без пункта 1 и 2 — не переходи к пункту 3.
Пример: "Перед SQL-запросом: запроси схему, выпиши названия колонок, затем пиши SELECT."
Принцип 2: Запрет на угадывание
Заставь модель признавать неуверенность вместо подстановки "разумного предположения".
Шаблон:
Если ты не уверен или данных недостаточно:
- Скажи "Не могу ответить точно, потому что [причина]"
- Перечисли чего не хватает
- Предложи как получить недостающее
НЕ подставляй правдоподобные значения. НЕ гадай.
Пример: "Если возраст не указан — пиши null, не бери 'средний по отрасли'."
Принцип 3: Явная маркировка мусора
Контекст без разметки = всё релевантно для модели. Укажи что игнорировать.
Шаблон:
Источники данных:
✅ Используй: [точный список]
❌ Игнорируй: [признаки мусора — префиксы, суффиксы, паттерны]
Если сомневаешься — спроси перед использованием.
Пример: "В папке 20 файлов. Нужны только файлы вида report_2024_*.csv. Файлы с draft_, old_, backup_ — не трогай."
Принцип 4: Чекпоинты для длинных задач
Контекст разрастается = внимание размывается. Дроби задачу, делай промежуточные остановки.
Шаблон:
Задача разбита на 3 части:
ЧАСТЬ 1: [подзадача]
→ Результат: [формат]
→ ЖДИ ПОДТВЕРЖДЕНИЯ ПЕРЕД ЧАСТЬЮ 2
ЧАСТЬ 2: [подзадача]
→ Результат: [формат]
→ ЖДИ ПОДТВЕРЖДЕНИЯ ПЕРЕД ЧАСТЬЮ 3
ЧАСТЬ 3: [финал]
Или технически: каждые 5-7 шагов — новый чат с кратким саммари предыдущего.
Размер модели ≠ надёжность
Ключевой инсайт исследования: параметры не определяют агентную способность.
Факты из бенчмарка: - Granite 4 Small (32B): 58.5% accuracy - Llama 4 Maverick (400B, в 12.5 раз больше): 74.6% accuracy — прирост всего 16% - DeepSeek V3 (671B, RLHF слабый): 59.4% accuracy - DeepSeek V3.1 (та же архитектура, сильный RLHF): 92.2% accuracy
Разница между DeepSeek V3 и V3.1: одинаковая архитектура, но +33% accuracy благодаря reinforcement learning на агентных задачах.
Вывод: Если модель не тренировали на многошаговую работу с инструментами — размер не спасёт. 400B параметров без RLHF проигрывают 32B с правильной подготовкой в реальных задачах.
Для читателя: Не гонись за "самой большой моделью". Смотри на как тренировали, не сколько параметров. И пиши промпты которые компенсируют слабости — принципы выше работают для любой модели.
Ограничения
⚠️ Это про агентные сценарии: Исследование тестирует работу с инструментами (файлы, базы, код). В обычном чате без tool-use паттерны могут проявляться иначе, но принципы универсальны — модели угадывают, подставляют правдоподобное, теряют фокус при длинных задачах и в обычном диалоге тоже.
⚠️ Ручной анализ 12.5% данных: Команда вручную разобрала 900 trace'ов из 7200 доступных. Паттерны устойчивые (повторяются у всех трёх моделей), но это не полная картина.
⚠️ Температура 0.4 фиксирована: Все модели тестировали с temperature=0.4 (компромисс между детерминизмом и гибкостью). При 0.0 или 0.7 поведение может измениться — авторы планируют это исследовать отдельно.
⚠️ Без thinking-режимов: Тестировали обычный режим. Модели с extended reasoning (o1, DeepSeek-R1 и подобные) могут вести себя иначе — их явное "размышление" перед действием может снижать преждевременные действия и угадывания.
Как исследовали
Команда создала бенчмарк KAMI v0.1 (Kamiwaza Agentic Merit Index) — 19 сценариев реальных рабочих задач. Для этого анализа взяли 10 сценариев (200, 300, 400, 500 серии):
- Серия 200: Создай файлы и папки по ASCII-дереву (проверка базовой работы с filesystem)
- Серия 300: Извлеки строки 47 и 892 из текстового файла на 1500 строк (заставляет использовать инструмент
read_fileс параметрамиstart_line/end_line, а не гадать) - Серия 400: Посчитай среднее по CSV в полной точности (нет специального инструмента — модель должна сама догадаться писать Python-код для точности)
- Серия 500: SQL-запросы с JOIN'ами 2-3 таблиц, среди 4-6 таблиц в базе (дистракторы, надо выбрать правильные)
29 инструментов доступны всегда: filesystem (read_file, write_file, create_directory...), Python (execute_code), SQLite (get_schema, execute_query), плюс git и web (не нужны в этих задачах, но присутствуют — тест на умение выбрать нужное).
Как тестировали: - 3 модели (Granite 4 Small 32B, Llama 4 Maverick 400B, DeepSeek V3.1 671B) - По 240+ попыток на каждый сценарий для каждой модели — параметры рандомизируются: имена файлов, содержимое CSV, данные в базе меняются каждый раз - Это по методологии PICARD [23]: не тестируем "запомнила ли модель правильный ответ", а тестируем реальную способность - Максимум 20 шагов на задачу (один инструмент за шаг) - Температура 0.4, контекст 32K токенов
Анализ: Вручную разобрали 900 execution trace'ов (по 30 случайных попыток на сценарий для каждой модели = 30×10×3). Каждый trace — полная последовательность: что модель сказала → какой инструмент вызвала → что получила → как отреагировала → следующий шаг. Trace для одной задачи — десятки тысяч токенов.
Паттерны искали эмерджентно: читали последовательно, отмечали повторяющееся поведение. Сначала разобрали Granite 4 Small (самая слабая), потом DeepSeek V3.1 (самая сильная), потом Llama 4 Maverick (середина) — и перепроверяли: паттерн найденный у DeepSeek, есть ли у Granite? Да, есть, но реже. У Llama? Тоже есть.
Почему такой подход ценен: Aggregate scores (92% vs 58%) говорят "эта модель лучше", но не говорят почему она лучше и где конкретно ломается слабая. Ручной разбор показал: DeepSeek V3.1 проверяет схему перед запросом, Granite 4 Small — угадывает. Llama 4 Maverick умеет восстанавливаться после ошибок, Granite — зацикливается. Эти находки невидимы в числе "74.6% accuracy".
Удивительное: Размер модели почти не влияет на надёжность. Llama 4 (400B) всего на 16% лучше Granite 4 (32B) — при разнице в 12.5 раз по параметрам. А вот RLHF влияет радикально: DeepSeek V3.1 (с RLHF на агентные задачи) на 33% лучше архитектурно идентичной DeepSeek V3 (без такого RLHF). Вывод: как тренировали важнее чем сколько параметров.
Практический инсайт: Сравнили DeepSeek V3.1 (92.2%) и V3 (59.4%) — модели с одинаковой архитектурой и размером. Единственная разница — V3.1 прошла длительный RL-тренинг на агентных сценариях. Это объясняет почему она проверяет схемы вместо угадывания, почему признаёт неуверенность вместо подстановки "разумного", почему различает дистракторы. Эти behaviour были натренированы, не "emergent from scale".
Ресурсы
"How Do LLMs Fail In Agentic Scenarios? A Qualitative Analysis of Success and Failure Scenarios of Various LLMs in Agentic Simulations" — JV Roig, Kamiwaza AI, декабрь 2025.
KAMI v0.1 benchmark (Kamiwaza Agentic Merit Index) — 19 агентных сценариев, методология PICARD [23].
Архитектуры: IBM Granite 4, Meta Llama 4, DeepSeek V3/V3.1.