ToolScan: Бенчмарк для характеристики ошибок в использовании инструментов LLMs

Исследование вводит бенчмарк TOOLSCAN, предназначенный для выявления и классификации ошибок, которые совершают LLM при попытке использовать внешние инструменты (API). Авторы выделили 7 систематических паттернов ошибок, таких как вызов несуществующих функций, использование неверных аргументов или неспособность выполнить все шаги сложного запроса. Вместо простой оценки "получилось/не получилось", их подход позволяет точно диагностировать,почему именнозадача провалена.

Даже самые продвинутые LLM (включая GPT-4) систематически допускают одни и те же типы ошибок при работе с инструментами, и понимание этих паттернов критически важно для создания надежных промптов и LLM-агентов.

Суть исследования в том, чтобы перейти от наивного промптинга ("сделай X") к оборонительному промптингу ("сделай X, но учти, что ты можешь ошибиться вот так, так и так, поэтому вот тебе четкие инструкции, чтобы этого избежать").

Авторы выделили 7 смертных грехов LLM-агентов, которые должен знать каждый промпт-инженер:

1. Insufficient API Calls (IAC) — Недостаточно действий: Модель не выполняет все шаги, необходимые для решения задачи. Например, вы просите найти информацию и отправить ее по email, а модель только находит информацию и останавливается.
2. Incorrect Argument Value (IAV) — Неверное значение аргумента: Модель использует правильный инструмент и правильный аргумент, но подставляет неверное значение. Например, вы просите найти отели с рейтингом >4.5, а она ищет с рейтингом >4.
3. Incorrect Argument Name (IAN) — Неверное имя аргумента: Модель "галлюцинирует" и придумывает несуществующее имя параметра для функции. Например, вместо sort_by='date' пишет sort_order='date'.
4. Incorrect Argument Type (IAT) — Неверный тип аргумента: Модель передает текст вместо числа, или наоборот. Например, для аргумента user_id=123 передает user_id="123".
5. Repeated API Calls (RAC) — Повторные действия: Модель зацикливается и вызывает один и тот же инструмент с теми же параметрами несколько раз без необходимости.
6. Incorrect Function Name (IFN) — Неверное имя функции: Модель придумывает несуществующий инструмент. Например, вместо get_weather() пытается вызвать fetch_weather_forecast().
7. Invalid Format Error (IFE) — Ошибка формата: Модель не может выдать результат в требуемом формате (например, JSON), нарушая его структуру.

Методика для пользователя: При составлении сложного промпта, требующего структурированного ответа или последовательности действий, нужно мысленно "защититься" от каждого из этих 7 грехов.

*Прямая применимость:

* **Для power-user'ов:** При создании кастомных GPT с Actions (которые являются API) или использовании Zapier / Make, эти 7 пунктов — прямой гайд по написанию инструкций. Промпт должен явно перечислять доступные "Actions" (защита от IFN), их параметры (защита от IAN) и давать примеры формата (защита от IFE, IAT, IAV).
* **Для обычных пользователей:** Принципы переносятся на любые запросы, требующие точности. Например, при просьбе составить таблицу или JSON, вы можете в промпте определить "доступные колонки" и "типы данных для каждой колонки", чтобы предотвратить ошибки.

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

• Потенциал для адаптации: Механизм адаптации прост: относитесь к любой сложной инструкции в промпте как к "определению API".

  1. Определите "функции": Четко назовите действия, которые модель должна совершить (Шаг 1: Проанализируй, Шаг 2: Суммаризируй).
  2. Определите "аргументы": Укажите, какие параметры для этих действий важны (Анализируй по критериям: новизна, практичность, Суммаризируй до 100 слов).
  3. Задайте "формат вывода": Покажите точный пример желаемого результата (Ответ дай в формате JSON: {"analysis": ..., "summary": ...}). Этот подход превращает размытый запрос в четкий алгоритм, минимизируя пространство для ошибок.

Представим, что вы SMM-менеджер и хотите, чтобы LLM помогла вам спланировать контент-план.

# РОЛЬ

Ты — AI-ассистент, эксперт по SMM. Твоя задача — помочь мне создать контент-план для Instagram-аккаунта кофейни "Зерно и Пена".

# КОНТЕКСТ

Тема аккаунта: Спешелти-кофе, уютная атмосфера, десерты ручной работы.
Целевая аудитория: Студенты и фрилансеры 20-35 лет.
Цель: Увеличить вовлеченность и число посетителей.

# ИНСТРУКЦИЯ

Создай контент-план на 3 дня (понедельник, вторник, среда). Для каждого дня предложи по одной идее для Поста и одной идее для Stories.

# ДОСТУПНЫЕ ИНСТРУМЕНТЫ (Форматы контента)

Тебе доступны только два формата контента. Используй только их:
1. `create_post(topic, visual_idea, text_idea)`
2. `create_stories(topic, interactive_element)`

# ТРЕБОВАНИЯ К АРГУМЕНТАМ

- `topic` (string): Краткая тема публикации.
- `visual_idea` (string): Описание визуала (фото или видео).
- `text_idea` (string): Краткое содержание текста поста.
- `interactive_element` (string): Один из следующих вариантов: 'ОПРОС', 'ВИКТОРИНА', 'ВОПРОС-ОТВЕТ'. Не придумывай свои варианты.

# ФОРМАТ ВЫВОДА

Предоставь результат СТРОГО в формате JSON-массива. Не добавляй никаких комментариев до или после JSON.

**Пример формата:**
`json
[
 {
 "day": "Понедельник",
 "post": {
 "tool_used": "create_post",
 "arguments": {
 "topic": "Пример темы поста",
 "visual_idea": "Пример визуала",
 "text_idea": "Пример текста"
 }
 },
 "stories": {
 "tool_used": "create_stories",
 "arguments": {
 "topic": "Пример темы сторис",
 "interactive_element": "ОПРОС"
 }
 }
 }
]`

Этот промпт является прямой реализацией "оборонительной" методики из исследования TOOLSCAN:

• Защита от IFN (Неверное имя функции): Раздел ДОСТУПНЫЕ ИНСТРУМЕНТЫ четко ограничивает модель, разрешая использовать только create_post и create_stories. У нее нет возможности "придумать" make_reel или design_publication.
• Защита от IAN (Неверное имя аргумента): В том же разделе и в ТРЕБОВАНИЯ К АРГУМЕНТАМ перечислены точные имена: topic, visual_idea и т.д. Модель не сможет использовать post_theme вместо topic.
• Защита от IAV (Неверное значение аргумента): Для interactive_element мы явно перечислили допустимые значения ('ОПРОС', 'ВИКТОРИНА', 'ВОПРОС-ОТВЕТ'), что не дает модели подставить некорректное значение вроде 'ГОЛОСОВАНИЕ'.
• Защита от IAT (Неверный тип аргумента): В требованиях мы указали тип (string), что снижает вероятность ошибки.
• Защита от IFE (Ошибка формата): Мы предоставили строгий пример JSON-формата, которому модель должна следовать. Это самая надежная защита от некорректной структуры ответа.
• Защита от IAC (Недостаточно действий): В инструкции Создай контент-план на 3 дня... по одной идее для Поста и одной идее для Stories мы явно указываем полный объем работы, снижая риск, что модель сделает план только на один день.

Задача: Спланировать короткую поездку на выходные для семьи.

# РОЛЬ

Ты — AI-ассистент по планированию путешествий.

# КОНТЕКСТ

Планируем семейную поездку на выходные (Суббота, Воскресенье) в город Суздаль.
Состав: 2 взрослых, 1 ребенок (8 лет).
Интересы: История, природа, вкусная еда, развлечения для ребенка.
Бюджет: Средний.

# ИНСТРУКЦИЯ

Составь план поездки на 2 дня. Для каждого дня необходимо запланировать 3 активности, используя доступные "действия".

# ДОСТУПНЫЕ ДЕЙСТВИЯ

1. `plan_activity(time_slot, activity_type, description, target_audience)`
2. `plan_meal(time_slot, meal_type, place_recommendation)`

# ТРЕБОВАНИЯ К АРГУМЕНТАМ

- `time_slot` (string): Один из: 'Утро (10:00-13:00)', 'День (14:00-17:00)', 'Вечер (18:00-20:00)'.
- `activity_type` (string): Один из: 'Экскурсия', 'Прогулка', 'Развлечение', 'Музей'.
- `description` (string): Краткое описание активности.
- `target_audience` (string): Один из: 'Для всех', 'Для взрослых', 'Для ребенка'.
- `meal_type` (string): Один из: 'Завтрак', 'Обед', 'Ужин'.
- `place_recommendation` (string): Название и краткая характеристика заведения.

# ФОРМАТ ВЫВОДА

Представь ответ в виде markdown таблицы с колонками: "День", "Время", "Тип активности/еды", "Описание/Рекомендация", "Аудитория".
Не используй другие форматы.

Этот промпт, как и предыдущий, применяет принципы TOOLSCAN для повышения надежности и точности ответа:

• Предотвращение IFN и IAN: Секции ДОСТУПНЫЕ ДЕЙСТВИЯ и ТРЕБОВАНИЯ К АРГУМЕНТАМ работают как "белый список" разрешенных операций и их параметров. Модель не может предложить book_hotel или использовать параметр duration.
• Предотвращение IAV: Мы жестко задаем возможные значения для ключевых аргументов, таких как time_slot, activity_type, target_audience. Это заставляет модель выбирать из предложенных вариантов, а не галлюцинировать.
• Структурирование вывода (защита от IFE): Требование предоставить ответ в виде markdown таблицы с конкретными колонками дает модели четкий шаблон для заполнения, что гораздо надежнее, чем просьба "опиши план в свободной форме".
• Обеспечение полноты (защита от IAC): Инструкция Составь план поездки на 2 дня... запланировать 3 активности задает точный объем работы, не позволяя модели схалтурить и предложить план на один день или одну активность.

• Предварительный фильтр: Исследование прошло фильтр. Его основной фокус — генерация LLM текстовых команд (API-вызовов), что является продвинутой формой промпт-инжиниринга для управления LLM-агентами. Это не про генерацию изображений или аудио.

• A. Релевантность техникам промптинга: Высокая. Хотя исследование не дает прямых фраз для чата, оно выявляет 7 конкретных паттернов ошибок, которые можно предотвратить с помощью правильно структурированных промптов.

• B. Улучшение качества диалоговых ответов: Опосредованное. Фокус на качестве выполнения задач (tool use), а не на диалоге. Однако, принципы помогают получать более точные и структурированные ответы в задачах, требующих четких действий.
• C. Прямая практическая применимость: Высокая для power-user'ов, создающих кастомные GPT или использующих LLM в автоматизациях (agents). Для обычного пользователя, который только чатится, применимость ниже, но концепции все равно полезны для получения структурированных данных.
• D. Концептуальная ценность: Очень высокая. Исследование дает великолепную "ментальную модель" ограничений LLM при работе со строгими инструкциями. Понимание 7 типов ошибок — это ключ к отладке неработающих промптов.
• E. Новая полезная практика (кластеризация): Работа попадает сразу в несколько ключевых кластеров:
  • #2 (Поведенческие закономерности): Четко описывает, как и почему модели ошибаются (повторяют вызовы, игнорируют часть запроса).
  • #3 (Оптимизация структуры): Демонстрирует важность формата инструкций и их влияние на результат.
  • #5 (Извлечение и структурирование): Вся суть работы — в получении строго структурированного вывода (API-вызова).
  • #7 (Надежность и стабильность): Основная цель — выявить и снизить количество ошибок, повышая надежность LLM-агентов.
• Чек-лист практичности (+15 баллов): ДА, исследование раскрывает неочевидные особенности поведения LLM (7 паттернов ошибок), показывает, как структурировать сложные запросы (неявно, через демонстрацию ошибок при плохой структуре) и предлагает способы улучшить точность (через понимание и предотвращение ошибок). Это дает +15 баллов к базовой оценке.

Аргументы в пользу оценки 85: Исследование имеет огромную концептуальную ценность для любого пользователя, который хочет перейти от простых диалогов к решению сложных, многошаговых задач. Классификация 7 типов ошибок — это, по сути, готовый чек-лист для "отладки" промпта, когда LLM не справляется с инструкцией. Эти принципы применимы не только к API, но и к любой задаче, где нужен структурированный вывод (например, генерация JSON, таблиц, форматированного текста). Для растущей аудитории пользователей, создающих свои GPTs с "Actions", это исследование — настоящий must-read.