CRITICTOOL - Оценка возможностей самокритики крупных языковых моделей в сценарии ошибок вызова инструментов.

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

Ключевой результат: Даже самые продвинутые модели, включая GPT-4o, демонстрируют очень слабую способность самостоятельно обнаруживать и исправлять свои ошибки в процессе работы с инструментами, что ведет к провалу задач.

Суть метода заключается в том, чтобы научить пользователя думать как "тестировщик" своего LLM-агента или кастомного GPT. Исследование показывает, что нельзя просто дать LLM доступ к инструментам и надеяться на лучшее. Модель будет неизбежно ошибаться, и ее ошибки предсказуемы.

Практическая методика, вытекающая из исследования, — это упреждающее проектирование промпта (Proactive Prompt Design), которое заранее предусматривает возможные сбои. Вместо того чтобы реагировать на ошибку, вы встраиваете в свой системный промпт инструкции, которые помогают модели ее предотвратить или правильно обработать.

Главные выводы для пользователя:

1. Модель ленива и невнимательна: Она будет путать инструменты (book_hotel вместо book_meeting_room), придумывать несуществующие (book_meeting_room_and_order_pizza), забывать обязательные параметры (time) или передавать их в неверном формате (7:00pm вместо 19:00).
2. "Мусор" в запросе снижает качество: Лишняя информация, длинный предыдущий контекст или просто многословная, расплывчатая просьба (Noisy Query) резко повышают шанс ошибки.
3. Самокритика — не сильная сторона LLM: Модели плохо понимают, что ошиблись. Если среда (API) не вернула явную ошибку, модель часто считает, что все в порядке, и продолжает "врать" пользователю.

Методика для пользователя: при создании сложного промпта для агента нужно явно описать не только что делать, но и что делать, если что-то пошло не так, основываясь на классификации ошибок из статьи.

*Прямая применимость:Пользователь, создающий кастомный GPT (например, "Помощник по путешествиям" с доступом к API погоды и бронирования), может использовать выводы для отладки. Если агент не работает, можно проверить:

1. Не перепутал ли он инструменты? (*Tool Selection Error*)
2. Не пытается ли он вызвать несуществующую функцию? (*Tool Hallucination Error*)
3. Все ли нужные данные он передал в правильном формате? (*Parameter Key/Value Error*)
Эта классификация превращает смутное "оно не работает" в конкретную диагностику.

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

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

  • Четким: Убрать всю "воду" и двусмысленность.
  • Структурированным: Предоставить все необходимые "параметры" (данные) в явном виде.
  • Последовательным: Разбивать задачу на шаги.

Представим, что мы создаем кастомный GPT "Event-менеджер" для организации встреч.

# РОЛЬ

Ты — "Event-менеджер", ассистент по организации встреч. Твоя задача — взаимодействовать с пользователем, чтобы запланировать событие, а затем использовать доступные инструменты для его создания в календаре.

# ИНСТРУМЕНТЫ

Ты можешь использовать ТОЛЬКО следующие инструменты:
- `google_calendar.create_event(title: string, date: string, time: string, guests: list[string])`: создает событие в календаре.
- `date` должно быть в формате `YYYY-MM-DD`.
- `time` должно быть в формате `HH:MM`.
- `email.send_invites(guests: list[string], subject: string)`: отправляет приглашения.

# ПРОЦЕСС РАБОТЫ

1. Сначала уточни у пользователя ВСЕ детали: название встречи, дату, время и список гостей (email-адреса).
2. Если пользователь не предоставил данные в нужном формате (например, "завтра в 7 вечера"), переспроси и попроси уточнить в формате `YYYY-MM-DD` и `HH:MM`.
3. Только после получения всех данных вызови инструмент `google_calendar.create_event`.
4. После успешного создания события, используй `email.send_invites`.

# ПРАВИЛА ОБРАБОТКИ ОШИБОК

- **Если ты не уверен, какой инструмент использовать, или пользователь просит сделать то, для чего у тебя нет инструментов (например, 'заказать пиццу'), вежливо откажи и сообщи о своих возможностях.** Это предотвращает *Tool Hallucination Error*.
- **Если для вызова инструмента не хватает данных (например, нет date), НЕ гадай. Запроси недостающую информацию у пользователя.** Это предотвращает *Parameter Key Error*.
- **Если инструмент вернул ошибку, сообщи об этом пользователю и попроси проверить данные.** Это обработка *Environment Error*.

Этот промпт прямо использует выводы исследования для создания надежного агента:

• Явное определение инструментов (# ИНСТРУМЕНТЫ) борется с Tool Selection Error (не перепутает инструменты) и Tool Hallucination Error (не будет придумывать новые).
• Требования к формату данных (date должно быть в формате YYYY-MM-DD) и инструкция переспросить пользователя нацелены на предотвращение Parameter Value Error.
• Инструкция "сначала уточни ВСЕ детали" предотвращает Parameter Key Error (ошибку отсутствия обязательного параметра).
• Секция # ПРАВИЛА ОБРАБОТКИ ОШИБОК — это прямое внедрение логики "самокритики" из исследования. Мы не надеемся, что модель сама догадается, что делать, а даем ей четкий алгоритм действий на случай разных типов сбоев.

Кастомный GPT "SMM-ассистент" для публикации постов в Telegram.

# РОЛЬ

Ты — "SMM-ассистент". Твоя задача — помогать мне готовить и публиковать посты в Telegram-канал.

# ИНСТРУМЕНТЫ

У тебя есть доступ только к одному инструменту:
- `telegram.post(channel_id: string, text: string, image_url: string (optional))`: публикует пост.
- `text` не может быть длиннее 4096 символов.
- `image_url` должен быть прямой ссылкой на .jpg или .png файл.

# ПРОЦЕСС РАБОТЫ

1. Получи от меня текст для поста.
2. Если я предоставляю изображение, уточни прямую ссылку на него.
3. Перед вызовом инструмента, проверь длину текста.
4. Вызови инструмент `telegram.post` с `channel_id = "my_awesome_blog"`.

# ПРАВИЛА ОБРАБОТКИ ОШИБОК

- **Если текст длиннее 4096 символов, не вызывай инструмент. Сообщи мне о превышении лимита и предложи сократить текст.** Это предотвращает *Parameter Value Error*.
- **Если я прошу тебя опубликовать видео или опрос, вежливо откажи, сославшись на то, что твой инструмент telegram.post этого не умеет.** Это предотвращает *Tool Hallucination Error* (попытку вызвать `telegram.post_video`).
- **Если инструмент telegram.post возвращает ошибку 400 Bad Request (например, из-за неверной ссылки на картинку), сообщи мне об этом и попроси проверить image_url.** Это обработка *Environment Error*.

Этот промпт работает, потому что он перекладывает ответственность за надежность с "интеллекта" LLM на четкость инструкций.

• Ограничение ответственности (# ИНСТРУМЕНТЫ): Четко очерчивая доступный функционал, мы не даем модели пространства для "творчества", которое, как показывает исследование, часто приводит к ошибкам галлюцинации инструментов.
• Пре-валидация данных (проверь длину текста, уточни прямую ссылку): Промпт заставляет модель выполнять проверку "на входе", до вызова инструмента. Это прямой способ предотвратить Parameter Value Error, который является одним из самых частых, согласно исследованию.
• Конкретные инструкции по ошибкам (# ПРАВИЛА ОБРАБОТКИ ОШИБОК): Вместо общей просьбы "быть умным", мы даем модели конкретные сценарии "если -> то". Это превращает сложную задачу "самокритики" в простую задачу следования инструкции, с которой LLM справляются гораздо лучше. Мы фактически реализуем логику try-catch на уровне промпта.

• A. Релевантность техникам промтинга: Низкая. Исследование не предлагает новых формулировок для первоначальных промптов, а анализирует поведение LLM в процессе выполнения многошаговых задач с инструментами (tool-calling).
• B. Улучшение качества диалоговых ответов: Высокая. Фокусируется на критически важной теме — способности LLM восстанавливаться после ошибок, что напрямую ведет к успешному (а не провальному) результату в сложных диалоговых сценариях.
• C. Прямая практическая применимость: Средняя. Выводы напрямую применимы для продвинутых пользователей, создающих кастомные GPT или LLM-агентов с помощью no-code/low-code инструментов. Для базовых пользователей, задающих вопросы в обычном чате, польза только концептуальная.
• D. Концептуальная ценность: Очень высокая. Дает превосходную "ментальную модель" того, почему LLM-агенты терпят неудачу. Классификация ошибок (не тот инструмент, не те параметры и т.д.) — это отличный диагностический инструмент для пользователя.
• E. Новая полезная практика: Работа четко попадает в несколько кластеров:
  • Кластер 2 (Поведенческие закономерности): Раскрывает, как LLM ведут себя при ошибках.
  • Кластер 5 (Извлечение и структурирование): Анализирует ошибки, связанные с передачей параметров (ключ/значение) в инструменты.
  • Кластер 6 (Контекст и память): Показывает, что "длинный контекст" и "зашумленные запросы" ухудшают производительность.
  • Кластер 7 (Надежность и стабильность): Вся работа посвящена повышению надежности агентов через понимание и исправление ошибок.
• Чек-лист практичности: Дает четкие ответы на вопросы о структурировании сложных запросов, неочевидных особенностях поведения LLM и способах повысить точность. (+15 баллов).

Оценка 87 отражает огромную концептуальную и практическую ценность исследования для растущего сегмента пользователей, которые переходят от простых чатов к созданию собственных LLM-агентов и кастомных GPT. Это не 90+ баллов, так как выводы не универсальны и не применимы к простейшим use-кейсам (например, "напиши стих").