Можно ли научить ИИ пользоваться инструментами на 500 примерах
ToolGrad сначала строит успешную цепочку вызовов, а затем придумывает запрос. Разбираем, почему этот порядок помог небольшим Gemma 3, что измеряли авторы и где заканчивается результат.
Можно ли научить небольшую языковую модель надёжно выбирать инструменты всего на пятистах синтетических примерах? 10 сентября Google Research представила ToolGrad — метод, который меняет порядок создания обучающих данных: сначала строится успешно выполненная цепочка вызовов, а уже затем для неё формулируется правдоподобный запрос пользователя. В блоге Google этот подход описан как способ снизить стоимость подготовки данных и повысить качество вызовов инструментов. Работа сама по себе не новая: её версия v3 появилась на arXiv 17 июня 2026 года, а рецензированная публикация вышла в Findings of ACL 2026. Свежий повод для разбора — именно публикация Google Research, а не новая версия исследования.
Результат выглядит эффектно: датасет ToolGrad-500 содержит лишь 500 основных примеров, а обученная на нём Gemma 3 12B в авторском запуске BFCL почти сравнялась с Gemini 2.5 Pro. Но из этого нельзя заключать, что пятисот примеров достаточно для универсального агента. Исследование проверяет более узкий навык — выбор и формирование вызовов функций в одном ходе. Ценность работы в другом: она показывает, насколько сильно результат зависит не только от объёма данных, но и от способа их построения.
Почему обычный порядок создаёт тупик
Типичный синтетический конвейер начинается с запроса. Модель придумывает задачу вроде поиска погоды, отеля и транспорта, после чего другой агент должен найти рабочую последовательность API. Если нужный инструмент сломан, требует неизвестный параметр или просто не позволяет решить сформулированную задачу, поиск заканчивается неудачей. Даже успешная траектория может содержать лишние или ошибочные шаги, которые затем попадут в обучающий набор как образец поведения.
ToolGrad меняет порядок подготовки примера. Система берёт небольшой набор описаний API, выбирает несколько перспективных кандидатов, реально выполняет их и оставляет удачный вызов. После нескольких итераций она получает проверенную цепочку действий. Только тогда отдельная модель пишет пользовательский запрос и итоговый ответ, согласованные с уже известными результатами инструментов. Неразрешимая задача не появляется случайно: запрос строится под данные, которые система уже сумела получить.
Как устроен эксперимент
Авторы использовали библиотеку ToolBench. После двух этапов фильтрации в ней осталось 15 368 API с достаточно понятными описаниями и хотя бы одним успешным тестовым вызовом. Для каждого образца ToolGrad случайно выбирал пакет из 50 API, предлагал до трёх кандидатов и запускал их параллельно. Селектор сравнивал отчёты выполнения и добавлял один полезный вызов к цепочке. Цикл повторяли десять раз. Роль генератора выполняла Gemini 2.5 Flash-Lite.
Авторы называют решение селектора «текстовым градиентом», но подчёркивают: это аналогия, а не математический градиент. Вес модели на этом этапе не меняется. Сигнал улучшения — текстовый отчёт о выполнении и дискретный выбор следующего API. После обновления цепочки LLM заново формулирует запрос и ответ, чтобы они соответствовали накопленному набору действий.
Так получили 500 основных примеров. Для обучения к ним добавили 20% отрицательных случаев: в набор доступных функций помещали только неподходящие инструменты, а правильным ответом считали пустой список вызовов. Затем методом supervised fine-tuning обучили Gemma 3 размером 1B, 4B и 12B. Для 4B и 12B применяли LoRA; все варианты обучались три эпохи с контекстом 8 тысяч токенов. Это компактный, но специально подготовленный набор для single-turn function calling, а не коллекция полноценных многоходовых диалогов.
Что именно улучшилось
В 500 попытках генерации ToolGrad дал 99,8% успешных образцов против 63,8% у базового поиска DFS. Средняя цепочка содержала 3,4 целевого вызова инструмента вместо 2,1, хотя на её построение потребовалось 20,0 вызова инструментов против 34,3. Число LLM-вызовов почти не изменилось — 63,9 против 64,5. Значит, главный выигрыш получен не от резкого сокращения обращений к модели, а от меньшего числа бесполезных проб инструментов и почти полного устранения пустых результатов.
После обучения результаты выросли у всех трёх размеров Gemma 3. На ToolBench авторские оценки поднялись относительно базовых моделей на 13,1 пункта для 1B, на 6,4 для 4B и на 9,8 для 12B. Этот тест, однако, сильно зависит от LLM-судей. Авторы дополнительно взяли восемь запросов, ответы двенадцати моделей и двух программистов-оценщиков. Средняя оценка автоматических судей коррелировала с человеческой на уровне ρ=0,88 при p<0,001. Корреляция высокая, но выборка из восьми запросов слишком мала, чтобы снять вопрос о надёжности автоматического оценивания в целом.
Более полезная проверка — BFCL v1/v2, где набор инструментов почти не пересекался с ToolBench. В single-turn части ToolGrad улучшил общий балл базовых Gemma 3 на 8,1 пункта для 1B, 8,0 для 4B и 6,3 для 12B. У ToolGrad-12B среднее по live и non-live частям составило около 83,1 балла, у Gemini 2.5 Pro — около 83,2. Это сравнение относится к конфигурации авторов: модели без нативного function calling запускались в prompt-режиме, а многоходовые сценарии BFCL v3/v4 в исследование не входили.
Почему пятьсот примеров не означают магию
Первое ограничение — постановка задачи. Модель училась предсказывать все вызовы функций за один шаг. Она не наблюдала промежуточный результат, не меняла план после ошибки и не вела длинный диалог. Авторы прямо пишут, что рассуждающие схемы ReAct и DFS, многоходовое использование инструментов и обучение с подкреплением остались за рамками работы. Поэтому результат нельзя переносить на агентов, которые часами работают с браузером, файлами и меняющимся состоянием приложения.
Второе ограничение — синтетические запросы. Даже если цепочка API технически корректна, созданная моделью формулировка может отличаться от речи реального человека: быть слишком аккуратной, явной или однообразной. Особенно показательно, что прирост на синтетической non-live части BFCL был больше, чем на live-данных. Для ToolGrad-12B балл вырос с 79,44 до 87,81 на non-live и с 74,24 до 78,46 на live. Улучшение на живых данных есть, но оно скромнее.
Третье ограничение обнаружили сами авторы при масштабировании. Они обучили Gemma 3 4B на 100, 500, 1000, 1500 и 2000 образцах. Результат BFCL сначала рос, а затем снижался. Генератор часто возвращался к похожим сочетаниям инструментов, потому что между независимыми запусками у него не было общей памяти. Больше синтетических данных в таком конвейере означало больше повторов, а не обязательно больше навыков. Поэтому число 500 оказалось удачной точкой текущей реализации, а не универсальным законом.
Есть и практическая оговорка о стоимости. Авторы сообщают 1, 1,67 и 2,67 суммарных GPU-часа на четырёх A100 для вариантов ToolGrad 1B, 4B и 12B. Для моделей, обученных на ToolBench, указаны 29, 68 и 370 GPU-часов на восьми H100. Эти цифры подтверждают разницу в вычислительном бюджете конкретных рецептов, но напрямую сравнивать их как цену нельзя: использованы разные ускорители, объёмы данных и режимы обучения.
Что это меняет для разработчиков агентов
Главный вывод ToolGrad не в том, что небольшая модель внезапно стала сильнее крупных систем во всех задачах. Исследование показывает более приземлённую вещь: узкий навык можно заметно улучшить, если каждый обучающий пример начинается с проверяемого успешного действия. Для корпоративного набора инструментов это означает, что качество трасс, разнообразие сценариев и наличие отрицательных примеров могут быть важнее механического наращивания количества запросов.
Подход также предлагает полезное разделение контроля. Сначала система проверяет, что вызовы действительно работают и возвращают достаточные данные. Затем она формулирует естественный запрос. Наконец, отдельная оценка проверяет перенос на незнакомые функции. Такая последовательность уменьшает риск обучать модель на красивой задаче, которую доступными инструментами невозможно выполнить.
Но для реального продукта этого мало. Нужны пользовательские запросы, многоходовые тесты, обработка ошибок и изменение плана, контроль прав доступа, а также проверка на собственных API после каждого их обновления. ToolGrad даёт убедительный метод подготовки исходного набора и открывает код, датасет и модели по Apache 2.0. Он не заменяет испытание агента в той среде, где тот будет действовать.
Ответ на исходный вопрос поэтому условный. Пятьсот тщательно построенных синтетических примеров действительно смогли улучшить single-turn function calling у Gemma 3 и дать перенос на почти незнакомый набор инструментов. Исследование не доказало, что такого объёма достаточно для общего агентного поведения. Его сильнейший результат — демонстрация того, что проверяемость и структура данных способны дать больше, чем ещё одна крупная, но шумная коллекция траекторий.
