GRETEL: Проверка через выполнение вместо угадывания по описанию

Вход: Список инструментов, подобранных семантически (ToolBench-IR)

Для каждого инструмента:
 ШАГ 1 (Planning): LLM извлекает параметры из запроса + спецификация API → API-вызов
 └─ Если не получилось → PLANNING_FAILED (сильный негативный сигнал)
 
 ШАГ 2 (Execution): Выполнить реальный API-вызов в sandbox
 ├─ Успех → сохранить JSON-ответ
 ├─ Ошибка (server-side) → LLM симулирует правдоподобный ответ
 └─ Ошибка (client-side) → фиксируем провал
 
 Результат: (статус, данные, метаданные)

ШАГ 3 (Holistic Re-ranking): LLM получает все доказательства выполнения
 → переранжирует инструменты по функциональной пригодности
 → приоритет: успешное выполнение > семантика

Выход: Список инструментов, отранжированных по факту работы

Все шаги выполняются через LangGraph (stateful workflow) — каждая нода это LLM с точно настроенным промптом.

⚠️ Ограничения метода: GRETEL работает для задач, где можно реально выполнить API/функцию. Не подходит для чисто теоретических вопросов или задач без исполняемых инструментов.

Задача: Ты запускаешь бота для команды, который автоматизирует рутину: бронирование переговорок, поиск контактов клиентов, выгрузка данных из CRM. У тебя интеграция с 15+ сервисами (Google Calendar, Notion, Битрикс24, YouGile и т.д.). Задача боту: "Найди свободное время у команды на неделе и забронируй переговорку на вторник в 14:00".

Проблема: Семантический поиск выдаст: calendar.find_free_slots, notion.check_availability, bitrix.book_room — все звучат подходяще. Но:

• calendar.find_free_slots требует параметр timezone (не указан)
• notion.check_availability возвращает пустоту (календарь не в Notion)
• bitrix.book_room падает с ошибкой авторизации (не настроен)

Промпт с принципом GRETEL:

Задача: Найди свободное время у команды на неделе и забронируй переговорку на вторник в 14:00

Доступные инструменты: [список 15 API]

Не угадывай по описанию. Действуй так:
1. Выбери 3-5 наиболее похожих инструмента
2. Для каждого:
 - Составь валидный вызов с параметрами из задачи
 - Если не хватает параметров → объясни почему не подходит
 - Если параметры ОК → попробуй выполнить (или опиши что ожидаешь)
 - Зафиксируй результат: успех/ошибка/пустой ответ
3. Выбери инструмент, который реально выполнил задачу
4. Если все провалились → объясни причины и предложи ручное действие

Покажи процесс проверки для каждого кандидата.

Результат:

Модель покажет пошаговую проверку каждого инструмента:

• calendar.find_free_slots: "Не хватает timezone → пропускаю"
• notion.check_availability: "Выполнил, но пустой ответ → календаря нет в Notion"
• google_calendar.get_events: "Успех! Нашёл встречи команды → есть слот вторник 14:00"
• bitrix.book_room: "Попытка выполнения → ошибка 401 (не авторизован)"

Финальный вывод: использовать google_calendar.get_events + google_calendar.create_event, остальные отклонены с конкретными причинами.

Слабость LLM: Модели плохо оценивают функциональную пригодность инструментов только по описанию. Они видят совпадение слов ("calendar", "availability", "time") и ранжируют по текстовому сходству. Но не знают: есть ли нужные параметры в запросе? Работает ли API? Вернёт ли валидные данные?

Сильная сторона LLM: Модели отлично анализируют структурированные доказательства (execution evidence). Если показать: "Инструмент А вернул валидный JSON, Инструмент Б упал с ошибкой, Инструмент В дал пустоту" — модель точно выберет А.

Как GRETEL использует это: Вместо гадания по описанию, система генерирует доказательства через реальное выполнение. Каждый кандидат проходит trial: модель пытается собрать вызов → выполняет в sandbox → фиксирует результат. Эти результаты — объективные факты, не предположения. Финальный ре-ранкинг делает LLM, но уже имея hard evidence вместо semantic similarity.

Рычаги управления в промпте:

1. Количество кандидатов для проверки — начни с 3-5 для скорости, расширь до 10 если нужна точность. Баланс: проверка vs токены.
2. Глубина проверки — можно попросить "только собери вызовы, не выполняй" (экономия), или "выполни и покажи полные ответы" (максимум информации).
3. Критерий отбора — можно приоритизировать: "выбери самый быстрый работающий" vs "выбери с самым полным ответом" vs "выбери самый надёжный (без ошибок на всех попытках)".
4. Fallback-стратегия — что делать, если все провалились? GRETEL использует LLM-симуляцию для server-side ошибок. Ты можешь попросить: "если все упали — предложи ручное решение" или "попробуй комбинацию нескольких инструментов".

Задача: {описание_задачи}

Доступные инструменты: {список_инструментов_с_описаниями}

Не выбирай инструмент только по описанию. Проверь функциональность:

1. Отбери {N} наиболее подходящих по описанию кандидатов

2. Для каждого кандидата выполни проверку:
 a) Составь вызов API с параметрами из задачи
 - Если параметров не хватает → зафиксируй PLANNING_FAILED
 b) Опиши что ожидаешь от выполнения
 - Успешный результат выглядит как: {...}
 - Возможные ошибки: {...}
 c) Оцени пригодность:
 - Успех → кандидат подходит
 - Ошибка/пустота → объясни причину провала

3. Итоговый выбор:
 - Ранжируй инструменты по доказательствам работы (execution evidence)
 - Приоритет: успешное выполнение > семантическое сходство
 - Для каждого объясни: почему выбрал / почему отклонил

Покажи процесс проверки для каждого кандидата.

Как заполнять:

• {описание_задачи} — конкретная задача для выполнения
• {список_инструментов_с_описаниями} — доступные функции/API с их спецификациями
• {N} — количество кандидатов для проверки (рекомендуется 3-5)

🚀 Быстрый старт — вставь в чат:

Вот шаблон GRETEL для проверки инструментов через выполнение. Адаптируй под мою задачу: {твоя задача}. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит: какие инструменты доступны, какие параметры можешь предоставить, какой критерий выбора важен (скорость/полнота/надёжность) — потому что для trial-based проверки нужно понимать доступные ресурсы и требования к результату. Она возьмёт паттерн из шаблона и адаптирует под задачу.

⚠️ Доступность инструментов: Метод работает только если есть реальные исполняемые инструменты (API, функции). Для чисто теоретических задач бесполезен.

⚠️ Вычислительные затраты: Проверка каждого кандидата через выполнение требует токенов и времени. При 10 кандидатах × 3 этапа (plan-execute-evaluate) = до 30 LLM-вызовов на задачу. Для частых запросов дорого.

⚠️ Stateless API only: GRETEL тестировали только на stateless API (один запрос = один результат). Для многошаговых workflow (авторизация → запрос → обработка) метод требует адаптации.

⚠️ Ложные срабатывания simulation: Когда реальный API недоступен, LLM симулирует правдоподобный ответ. Это помогает не отбрасывать временно упавшие сервисы, но может дать ложную уверенность в работоспособности.

Исследователи взяли ToolBench — бенчмарк с 80,000 реальных запросов к 16,000+ API. Проверяли на полном датасете + детальный анализ на 10,000 примеров. Сравнивали с двумя подходами: классический семантический поиск (PMLM-L3-v2, ToolBench-IR) и современные методы с LLM (ToolkenGPT, ReAct, ToolLLM).

Логика эксперимента: Взяли baseline (ToolBench-IR) — он выдаёт список кандидатов по семантике. Потом GRETEL прогоняет каждого через trial: plan → execute → evaluate. Измеряли три метрики: Recall (нашли ли правильный инструмент), NDCG (качество ранжирования), Pass Rate (строгая функциональная корректность — инструмент реально выполнил задачу).

Результаты удивили масштабом проблемы: Вручную проанализировали провалы у top-5 кандидатов от семантического поиска — 85% оказались функционально непригодны. Распределение провалов показало системный характер semantic-functional gap: 42% упали на этапе планирования (нельзя собрать валидный вызов), 25% вернули пустоту при успешном выполнении (semantic mismatch — API работает, но не для этого запроса), 18% упали с server-side ошибками (авторизация, недоступность). Только 15% работали корректно.

Что противоречило ожиданиям: Semantic mismatch (25%) оказался второй по величине категорией провалов. Инструменты с идеальным текстовым соответствием выполнялись успешно, но возвращали пустые результаты. Пример: поиск рейсов по валидному маршруту возвращает "no results" потому что API не покрывает эту авиакомпанию или регион. Семантический поиск этого не видит — описание API звучит идеально.

Инсайт для практики: Текстовое сходство — слабый прокси для функциональности. GRETEL показал: Pass Rate@10 вырос с 0.690 (baseline) до 0.826 (+19.7%) просто за счёт эмпирической проверки. Это значит: почти каждая пятая задача, которая проваливалась из-за неправильного выбора инструмента, теперь решается корректно. Причём улучшение стабильно на разных метриках: Recall@10 +3.1%, NDCG@10 +6.2%. Execution-based validation — не просто улучшение, а фундаментальное требование для надёжных AI-агентов.

Контекст: Авторы описывают структуру GRETEL как LangGraph workflow с тремя ключевыми компонентами.

# Algorithm 1: Trial-based Evidence Generation
# Input: Query q, Tool ti with API specification Ai
# Output: Evidence tuple (status, result, metadata)

1: params ← PLAN(q, Ai) # Planning stage
2: if params = ERROR or params = INVALID_JSON then
3: return (PLANNING_FAILED, error_msg, ∅)
4: end if

5: api_call ← format_call(ti.name, params)
6: result ← REAL_EXECUTE(ti, params) # Real execution
7: if result.status = success then
8: metadata ← {simulation_used: false}
9: else if result.status = error then
10: result ← SIMULATE(q, ti, api_call, result) # LLM simulation
11: metadata ← {simulation_used: true}
12: else
13: metadata ← {simulation_used: false}
14: end if
15: return (result.status, result.data, metadata)
```

**Core Prompt Templates (из Table 1):**
```
Planner:
"Given query '{query}' and API spec '{api_spec}'. 
Extract parameter values from the query that match the API requirements.
Return valid JSON with all required parameters."

Simulator:
"Generate realistic JSON response for failed API call '{api_call}' 
based on query context. The response should represent what a successful 
call would return if the API were available."

Evaluator:
"Rank candidate tools using execution evidence. 
Prioritize tools with successful execution or simulation evidence.
Penalize tools that failed during planning or execution.
Output JSON list of [Tool, API] pairs in ranked order."
```

**Важно:** Это не упрощённая версия, а точные компоненты из исследования. LangGraph управляет state machine, каждая нода (Planner/Executor/Evaluator) — это LLM с конкретным промптом. Алгоритм показывает последовательность: plan → execute → simulate (if needed) → collect evidence → re-rank.

---

## Адаптации и экстраполяции

### 💡 Адаптация для обычного чата (без API)

Принцип GRETEL "проверка через выполнение вместо угадывания" применим для **выбора между несколькими подходами к задаче**:
```
Задача: Написать email клиенту с отказом в скидке, но сохранить отношения

Не угадывай лучший тон сразу. Проверь три подхода:

1. Подход "Прямолинейный":
 - Напиши черновик в стиле: честно объясни причины, без лишних извинений
 - Оцени: как клиент может отреагировать на такой тон?
 - Риски: {...}

2. Подход "Эмпатичный":
 - Напиши черновик в стиле: сочувствие, понимание ситуации клиента
 - Оцени: как клиент может отреагировать на такой тон?
 - Риски: {...}

3. Подход "Альтернативное предложение":
 - Напиши черновик в стиле: отказ + встречное предложение (бонус, апгрейд)
 - Оцени: как клиент может отреагировать на такой тон?
 - Риски: {...}

Финальный выбор: ранжируй подходы по прогнозу реакции клиента
Рекомендация: [лучший вариант] потому что [execution evidence из оценки]
```

Здесь "execution" = симуляция реакции клиента, не реальный API. Но паттерн тот же: **пробуем → оцениваем → выбираем по доказательствам**, не по первому впечатлению.

---

### 🔧 Техника: Уменьшить N кандидатов → экономия токенов

Если задача простая, не нужно проверять 10 инструментов. Измени `N` в шаблоне:
```
1. Отбери 3 наиболее подходящих по описанию кандидатов # было: 5-10
```

**Эффект:** В 3 раза меньше вызовов LLM, быстрее результат. Для рутинных задач (бронирование, поиск контактов) трёх хватает.

---

### 🔧 Техника: Добавить "explain reasoning" → видеть логику выбора

По умолчанию GRETEL фокусируется на результате. Добавь в финальный этап:
```
3. Итоговый выбор:
 ...
 - Для каждого объясни: почему выбрал / почему отклонил
 + Покажи рассуждение: какие факторы были критичными в выборе?
 + Если бы задача была другой, изменился бы выбор? Как?

Эффект: Видишь не только "что выбрано", но и "почему". Полезно для обучения и отладки workflow.

GRETEL: A Goal-driven Retrieval and Execution-based Trial Framework for LLM Tool Selection Enhancing

Ключевые отсылки:

• ToolBench benchmark (https://github.com/OpenBMB/ToolBench) — датасет с 16,000+ реальных API
• LangGraph library (https://github.com/langchain-ai/langgraph) — framework для multi-agent workflows
• ReAct framework [Yao et al., ICLR 2023] — reasoning-action sequences для LLM-агентов

Zongze Wu, Yani Guo, Churong Liang, Runnan Li

Beijing University of Posts and Telecommunications, Beijing, China