ToolGrad: как Google предлагает учить модели работе с инструментами

ToolGrad — исследовательский подход Google Research к созданию данных для обучения моделей пользоваться внешними инструментами. Его основная идея проста: вместо бинарной отметки «вызов прошёл или нет» система получает текстовое объяснение ошибки и использует его как направление для следующей попытки. Авторы называют такие сообщения текстовыми градиентами. Это не математический градиент весов модели, а структурированная обратная связь на уровне траектории.

Какую проблему решает метод

Агент может правильно понять вопрос и всё равно провалить задачу: выбрать не тот инструмент, передать аргумент неверного типа, перепутать порядок вызовов или не использовать полученный результат. Для обучения нужны траектории с хорошими действиями, но их дорого размечать вручную. Простая генерация синтетических примеров часто закрепляет те же ошибки, которые делает исходная модель.

ToolGrad пытается превратить ошибку в новый учебный сигнал. Проверяющий компонент анализирует шаг и формулирует конкретное замечание: какой инструмент требовался, какое поле отсутствует, почему ответ нельзя считать завершённым. После этого модель исправляет траекторию. Принятые варианты можно использовать как данные для последующего обучения или оценки.

Из каких частей состоит конвейер

Сначала задаётся среда: доступные инструменты, их схемы, ограничения и критерий выполненной задачи. Затем модель строит решение с вызовами. Исполнитель возвращает фактический ответ инструмента, а оценщик сопоставляет траекторию с целью. Если найден дефект, он создаёт текстовый сигнал, ориентированный на действие, а не общую фразу «попробуйте ещё раз».

Качество оценщика критично. Если он исправляет стиль вместо логики или предлагает недопустимый вызов, система начнёт производить аккуратные, но неверные примеры. Поэтому полезно разделять проверки: валидатор схемы ловит типы, тест проверяет результат, политика контролирует права, а языковой оценщик объясняет смысловое несоответствие.

Чем текстовый градиент отличается от обычного retry

Повтор без обратной связи заставляет модель угадывать. ToolGrad сохраняет причину и связывает её с конкретным шагом. Например, агент запросил календарь до уточнения часового пояса. Полезное сообщение указывает, что время неоднозначно и до вызова нужно получить зону пользователя. Следующая попытка меняет порядок действий, а не только формулировку ответа.

Однако система не должна раскрывать модели секреты или внутренние правила безопасности. Текстовый сигнал формируется из безопасного набора данных. В материале о сетевых границах агента описан принцип минимальных прав: улучшение траектории не должно расширять доступ автоматически.

Где ToolGrad может быть полезен

Первый сценарий — подготовка набора примеров для внутреннего агента с ограниченным числом инструментов. Если команда автоматизирует создание заявки, проверку статуса и подготовку черновика письма, у неё есть чёткие схемы и наблюдаемый итог. Текстовая обратная связь помогает накапливать сложные случаи без ручного переписывания всей траектории.

Второй сценарий — регрессионные тесты. Ошибка после смены модели превращается в постоянный пример с причиной. Команда видит не только процент успеха, но и классы сбоев: неверный выбор инструмента, потерянный аргумент, повторная операция, преждевременный финальный ответ. Такой отчёт полезнее одного среднего балла.

Третий сценарий — учебная песочница. Модель может тренироваться на копиях систем, где действие обратимо. Подход сочетается с повторяемыми средами для агентов: состояние восстанавливается, а каждая попытка сравнима с предыдущей.

Что метод не решает

ToolGrad не делает внешние инструменты надёжными. API может вернуть устаревшие данные, выполнить операцию дважды или изменить схему. Нужны тайм-ауты, идемпотентность, журнал и отдельная обработка отказов. Модель, научившаяся проходить тестовую среду, не получает права работать с боевой системой.

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

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

Как провести небольшой собственный тест

Выберите одну задачу из трёх–пяти шагов и создайте десять входов: обычные, пограничные и опасные. Зафиксируйте инструменты и запретите необратимые действия. Для каждой ошибки запишите место, причину и ожидаемое исправление. Затем сравните три режима: простой повтор, повтор с общим замечанием и текстовый сигнал по конкретному шагу.

Измеряйте долю успешно завершённых задач, число вызовов, повторные операции и время проверки человеком. Обязательно просмотрите несколько «успешных» траекторий вручную. Если улучшился тестовый балл, но выросло число лишних действий, обучение оптимизирует не тот результат.

Вердикт

ToolGrad интересен не обещанием автоматически вырастить хорошего агента, а дисциплиной обратной связи. Ошибка становится именованным учебным объектом, а исправление — проверяемой траекторией. Подход подходит командам с чёткими инструментами и тестируемым итогом. Для открытого браузера, размытых задач и необратимых операций сначала нужны границы среды, а уже затем генерация данных.

Частые вопросы

Нужно ли дообучать модель? Не обязательно для эксперимента: текстовую обратную связь можно оценить в режиме повторных попыток. Дообучение требует отдельной подготовки данных.

Можно ли использовать одну модель как автора и судью? Можно для дешёвого прототипа, но итоговые траектории нужно проверять независимыми тестами и людьми.

Что хранить в журнале? Вход, версию схемы, вызовы, ответы инструментов, текст замечания, исправленную попытку и результат автоматических тестов.