ToolCritic: внешняя проверка ошибок при работе LLM с инструментами

ШАГ 1: Определение таксономии ошибок → 8 категорий ошибок при tool-calling:

• Premature invocation (преждевременный вызов)
• Tool-prediction error (неверный инструмент)
• Required arguments (ошибки обязательных параметров)
• Optional arguments (ошибки опциональных параметров)
• Observation reasoning (неверная интерпретация результата)
• Non-invocation confirmation (подтверждение без вызова)
• Non-invocation hesitation (не вызывает когда нужно)
• Non-invocation hallucination (выдумывает вместо вызова)

ШАГ 2: Обучение ToolCritic → Fine-tuning LLaMA 3.1 8B на синтетических диалогах с внедрёнными ошибками → Модель учится детектировать тип ошибки + генерировать reasoning (объяснение)

ШАГ 3: Проверка в диалоге (отдельный запрос к ToolCritic на каждом шаге) → ToolCritic получает историю диалога + текущий ответ assistant → Выдаёт: {тип_ошибки}: {детальное_объяснение} или no error

ШАГ 4: Исправление (отдельный запрос к основной LLM) → Если ошибка обнаружена — assistant получает фидбек → Assistant исправляет ответ на основе конкретного указания → Исправленный ответ идёт пользователю (без повторной проверки)

⚠️ Зона применения метода: Многошаговые задачи с внешними инструментами где важна точность вызовов. Метод не нужен для простых вопросов без инструментов.

Задача: Ты консультант маркетингового агентства. Клиент в чате просит: "Найди данные по конкурентам в нише доставки еды в Москве за последний квартал." У тебя есть доступ к инструментам: поиск в вебе, выгрузка из CRM, анализ соцсетей. Нужно собрать данные точно, без ошибок в запросах.

Промпт для ToolCritic (упрощённая адаптация):

Ты — проверяющий редактор работы ассистента с инструментами.

Вот 8 типов ошибок которые может совершить ассистент:

1. **Premature invocation**: Вызов инструмента до сбора всей нужной информации
2. **Tool-prediction error**: Выбран неправильный инструмент для задачи
3. **Required arguments**: Ошибка в обязательных параметрах запроса
4. **Optional arguments**: Лишние/неверные опциональные параметры
5. **Observation reasoning**: Неверно интерпретирован результат инструмента
6. **Non-invocation confirmation**: Подтвердил действие без реального вызова
7. **Non-invocation hesitation**: Не вызвал инструмент когда нужно было
8. **Non-invocation hallucination**: Выдумал данные вместо запроса к инструменту

Доступные инструменты:
- web_search(query, region, time_period)
- crm_export(client_segment, date_range)
- social_analytics(platform, competitors_list, metrics)

История диалога:
USER: "Найди данные по конкурентам в нише доставки еды в Москве за последний квартал"

ASSISTANT: 
- API CALL: web_search(query="доставка еды конкуренты", region="Москва")
- RESULT: [список статей про рынок доставки]
- RESPONSE: "Вот данные по конкурентам за последний квартал..."

Проверь последний ответ ассистента. Есть ли ошибка? Какая? Объясни подробно.

Результат:

ToolCritic обнаружит premature invocation — ассистент вызвал поиск без параметра time_period, хотя юзер явно указал "последний квартал". Фидбек: "Ты забыл указать временной период в запросе. Пользователь просил данные за Q4, а ты сделал общий поиск. Добавь параметр time_period='Q4 2024'."

Ассистент исправляет → делает новый вызов с корректными параметрами → точный результат.

Слабость LLM: Модели плохо самодиагностируются. Когда просишь LLM "проверь свой ответ" — она часто не видит ошибку или выдумывает несуществующую. Особенно в tool-calling: модель может вызвать API с неверным аргументом, получить пустой результат, но написать пользователю "вот данные" (галлюцинация). Self-correction тут не работает — модель не понимает ЧТО не так.

Сильная сторона LLM: Модели отлично исправляют ответы когда знают конкретную ошибку. Если сказать: "ты вызвал FindBus без параметра leaving_date, а пользователь его ещё не назвал" — модель легко поймёт и переделает. Проблема не в исправлении, а в обнаружении ошибки.

Как метод использует это: ToolCritic — специализированная модель, обученная только на одной задаче: находить 8 типов ошибок в tool-calling. Она не генерирует ответы, не рассуждает, не творит — только проверяет. Благодаря узкой специализации и обучению на синтетических примерах всех 8 типов ошибок, ToolCritic точно определяет где ошибка и почему. Основная LLM получает этот фидбек и исправляет прицельно — не вслепую, а точно зная что не так.

Критические детали метода:

Детальность фидбека — ключевой рычаг качества. Исследователи проверили ablation: если давать только "тип ошибки" (например, "required argument error") без объяснения — улучшение минимальное. Если давать полный reasoning ("ты вызвал FindBus с аргументом leaving_date='2019-03-12', но пользователь ещё не назвал дату, ты её выдумал") — прирост точности до 13%. Чем конкретнее фидбек, тем лучше модель исправляет.

Частота проверки — ToolCritic проверяет каждый ответ assistant в диалоге, даже если нет вызова инструмента. Это важно для ошибок типа "non-invocation" — когда модель должна была вызвать инструмент, но не вызвала. Если проверять только обращения к API — такие ошибки останутся незамеченными.

Одна попытка исправления — исследователи сознательно ограничили pipeline: ToolCritic проверяет → даёт фидбек → assistant исправляет один раз → исправленный ответ идёт юзеру без повторной проверки. Это баланс между качеством и стоимостью inference. Бесконечные циклы проверки-исправления дорогие и не всегда полезны (модель может "зациклиться"). Один раунд с точным фидбеком даёт 80% пользы при 20% стоимости.

Важно: Сам ToolCritic — это fine-tuned модель, которую нельзя применить в обычном чате без обучения. НО принципы метода — таксономию ошибок и идею внешней критики — можно адаптировать через multi-agent подход в ChatGPT/Claude.

=== ЧАТ 1: ASSISTANT ===

Ты — ассистент который помогает {описание задачи}.

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

История:
{диалог с пользователем}

Твоя задача: Выполни запрос пользователя используя доступные инструменты.

---

=== ЧАТ 2: CRITIC ===

Ты — проверяющий редактор работы ассистента с инструментами.

Проверь последний ответ ассистента на наличие этих ошибок:

1. **Premature invocation**: Вызвал инструмент до сбора всей информации от пользователя
2. **Tool-prediction error**: Выбран не тот инструмент для задачи
3. **Required arguments**: Ошибка в обязательных параметрах
4. **Optional arguments**: Добавил ненужные или неверные опциональные параметры
5. **Observation reasoning**: Неверно интерпретировал результат инструмента
6. **Non-invocation confirmation**: Подтвердил действие без реального вызова инструмента
7. **Non-invocation hesitation**: Не вызвал инструмент когда это было нужно
8. **Non-invocation hallucination**: Выдумал данные вместо вызова инструмента

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

История диалога:
{диалог}

Последний ответ ассистента:
{ответ из чата 1}

Проверь: есть ли ошибка? Если да — укажи тип и объясни **детально** что не так и как надо.
Если нет — напиши "no error".

Что подставлять:

• {описание задачи} — контекст работы (консультант, аналитик, менеджер проекта)
• {список инструментов} — какие API/функции доступны с описанием параметров
• {диалог} — история сообщений юзера и ассистента
• {ответ из чата 1} — конкретный ответ который проверяем

Workflow:

1. Копируешь запрос юзера в ЧАТ 1 (assistant)
2. Получаешь ответ assistant
3. Копируешь историю + ответ в ЧАТ 2 (critic)
4. Если critic нашёл ошибку — копируешь фидбек обратно в ЧАТ 1
5. Assistant исправляет с учётом фидбека
6. Даёшь исправленный ответ юзеру

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

У меня есть задача где ассистент работает с инструментами. Мне нужно организовать двухчатовую систему:
- ЧАТ 1: assistant выполняет задачи
- ЧАТ 2: critic проверяет ответы assistant на 8 типов ошибок

Вот описание 8 типов ошибок из исследования ToolCritic:
[вставить список из шаблона выше]

Помоги настроить промпты для обоих чатов под мою задачу: {опиши задачу}
Какие инструменты доступны: {список}

LLM спросит детали твоей задачи и инструментов — потому что critic должен знать спецификацию каждого инструмента чтобы ловить ошибки в аргументах. Она адаптирует базовый паттерн под твой контекст.

⚠️ Применение системы требует fine-tuning: Сам ToolCritic — это обученная LLaMA 3.1 8B модель. Чтобы использовать именно её, нужно fine-tuning на твоих данных + deployment отдельного сервиса. Это недоступно в обычном чате. Зато принципы метода (таксономия ошибок + внешняя критика) адаптируются через multi-agent подход.

⚠️ Inference cost: Каждая проверка = 2 дополнительных запроса к LLM (critic + исправление assistant). В длинных диалогах это дорого. Для экономии: проверяй выборочно — только шаги где есть вызовы инструментов или подтверждения действий, пропускай простые реплики без API.

⚠️ Специфично для tool-calling: Метод разработан для диалогов с внешними инструментами (API, функции, сервисы). Для обычных вопросов-ответов без инструментов эта система избыточна. Применяй когда assistant активно использует search, code execution, database queries, booking APIs и подобное.

⚠️ Одна проверка, одно исправление: ToolCritic проверяет ответ один раз. Если assistant исправился, но опять ошибся — второго раунда нет. Это ограничение дизайна для баланса cost/quality. В сложных кейсах может понадобиться ручной контроль.

Команда взяла датасет Schema-Guided Dialogue (SGD) — большой набор диалогов про бронирование билетов, гостиниц, поиск автобусов. В нём 40 разных инструментов, тысячи диалогов. Сначала вручную проанализировали какие ошибки делают LLM при работе с инструментами и выделили 8 категорий.

Дальше — синтетическая генерация ошибок. Исследователи написали по 5-7 примеров для каждой категории вручную: взяли корректный диалог, внедрили конкретную ошибку (например, "assistant вызвал FindBus до того как узнал дату поездки"), добавили детальное объяснение "почему это ошибка". Потом few-shot промптинг Claude 3.5 Sonnet: показали примеры → попросили сгенерировать ещё 300 диалогов с ошибками каждого типа. Итого 2400 диалогов с ошибками + столько же корректных = 4800 примеров.

Интересная деталь: в промпт для генерации добавляли hint — случайный номер шага диалога и тип ошибки. Это предотвращало bias модели: без hint Claude чаще внедряла ошибки в начало диалога или в популярные инструменты из few-shot примеров. Hint обеспечил разнообразие.

Обучили LLaMA 3.1 8B full fine-tuning на этих данных (5 epochs, learning rate 1e-5). Модель училась только на ответах — градиенты шли только от генерации reasoning, не от чтения диалога. Получилась ToolCritic.

Тестировали на трёх LLM: Claude 3 Sonnet, Mistral Large 2, LLaMA 3.1 70B. Сравнивали 4 сетапа:

1. Baseline (zero-shot) — модель сама генерирует ответы
2. Self-correction — модель сама себя проверяет (Reflexion метод)
3. ToolCritic error-only — только тип ошибки без reasoning
4. ToolCritic full feedback — тип + детальное объяснение

Метрики: Success rate (весь диалог корректен), Precision/Recall для tool-вызовов, Incorrect action rate (сколько неверных action-вызовов).

Ключевое открытие: Self-correction почти не помог, а местами даже ухудшил результаты. Claude 3 Sonnet в baseline: success rate 14.15%, с self-correction: 16.62% (мизерный рост), с ToolCritic full feedback: 27.88% (почти в 2 раза лучше!). LLaMA 3.1 70B в baseline: 5.46%, с self-correction: 3.90% (стало хуже!), с ToolCritic full feedback: 10.15%.

Это подтвердило гипотезу: модели не умеют находить свои ошибки, но отлично исправляют когда точно указать где и что не так.

Human evaluation на 100 диалогах показала: ToolCritic исправил 26.67% ответов полностью и улучшил ещё 26.67% частично. В контрольной проверке ни одной ошибки не попало за пределы 8 категорий — таксономия оказалась исчерпывающей.

ToolCritic: Detecting and Correcting Tool-Use Errors in Dialogue Systems

Hassan Hamad (USC), Yingru Xu, Liang Zhao, Wenbo Yan, Narendra Gyanchandani (Amazon)

Schema-Guided Dialogue (SGD) dataset, ToolTalk dataset

Fine-tuned на LLaMA 3.1 8B Instruct