Google Research представи ToolGrad: рамка с подход „отговорът на първо място“ постига 99,8% успеваемост при генериране на данни за използване на инструменти

Обучението на LLM за надеждно извикване на инструменти изисква набори от данни, които свързват потребителски заявки с правилни вериги за използване на инструменти. Създаването на такива данни в голям мащаб досега беше бавно и скъпо. Екип от изследователи от Google, Токийския университет, RIKEN AIP и университета Тохоку представя ToolGrad. Изследователската работа обръща обичайния процес: първо се изгражда проверена верига от инструменти, а след това се създава заявката. Моделите Gemma-3, дообучени върху 500 примера от получените данни, постигат резултати, сравними с тези на водещи собствени модели в Berkeley Function Calling Leaderboard.

Може ли да бъде внедрен? Да. Кодът е с лиценз Apache-2.0, наборът от данни ToolGrad-500 и моделите с 1B, 4B и 12B параметъра са налични в Hugging Face, а има и PyPI пакет.

Проблемът с генерирането, започващо от заявката

Предишни подходи като ToolBench и ToolACE следват процес, започващ от заявката. Системата избира извадка от API, кара LLM да измисли правдоподобна потребителска инструкция, а след това изпраща агент за търсене в дълбочина (DFS), който да намери път за използване на инструменти, удовлетворяващ заявката. Търсенето не гарантира успех. Когато стигне до задънена улица, изчислителният ресурс, изразходван за проучването, се губи, а примерът се отхвърля. В статията това е описано като извличане на ценни траектории от сложно и често неуспешно изследване от агент — процес, който по своята същност е неефективен.

ToolGrad обръща реда. Първо изгражда действителна верига за използване на инструменти чрез изпълнение на API, а след това анотира тази верига със съответстваща потребителска заявка. Ясната, работеща верига е много по-малко двусмислена от хипотетичната подкана, така че стъпката от верига към заявка изисква само едно извикване на LLM.

Четири модула в цикъл

Всяка итерация изпълнява последователно четири модула:

• API Proposer стеснява избрания набор от API до няколко кандидата, които могат да разширят текущия работен процес.
• API Executors изпълнява тези кандидати паралелно и генерира подробни отчети за изпълнението.
• API Selector преглежда отчетите, избира едно-единствено най-добре представило се извикване и го добавя към работния процес. Неговата насочваща обратна връзка представлява текстовия градиент.
• LLM Updater пренаписва синтетичната потребителска заявка и отговора на AI, така че да съответстват на новия набор от API.

Повтарянето на цикъла създава един пример: потребителска заявка, проверен работен процес с API и финален отговор. Конфигурацията по подразбиране на хранилището изпълнява 10 итерации върху 50 избрани API за всеки работен процес.

Ефективност на генерирането в ToolBench

Изследователският екип оцени генерирането на данни в базата данни с API на ToolBench, която съдържа над 16 000 реални API, и сравни ToolGrad с подхода на ToolBench, започващ от заявката и базиран на DFS. Според изследователската статия:

• Процентът на успешните изпълнения се е увеличил от 63,8% (DFS) на 99,8% (ToolGrad).
• Броят на използванията на инструменти, представляващи реалната истина, за пример се е увеличил от 2,1 на 3,4, което означава по-дълги вериги.
• Стъпките за използване на инструменти за пример са намалели от 34,3 на 20,0.
• Извикванията на LLM за пример са намалели незначително — от 64,5 на 63,9.

Случаят на неуспех от 0,2% е възникнал, когато агентът не е успял да получи успешен отговор от 3 избрани API във всичките 10 итерации и е записал празен пример.

Интерактивно обяснение

Резултати от BFCL с Gemma-3

Изследователите са създали ToolGrad-500 — набор от данни с 500 примера, изграден с Gemini 2.5 Flash-Lite — и са го използвали за последващо обучение на Gemma-3 с 1B, 4B и 12B параметъра. Те са извършили оценка в Berkeley Function Calling Leaderboard, който използва набор от инструменти, различен от този в ToolBench, което го превръща в тест извън разпределението с неизвестни инструменти. Констатациите, докладвани от авторите:

• Дообучаването с ToolGrad-500 е подобрило резултатите при използване на инструменти при всички размери на модела.
• ToolGrad-12B е получил 83,1 точки в сравнение с 83,2 за Gemini 2.5 Pro, 82,8 за Claude 4.5 Opus и 74,4 за GPT-5 според измерванията към момента на публикуване.
• Моделът ученик с 12B параметъра е надминал Gemini 2.5 Flash-Lite — модела учител, генерирал данните за обучението му.
• ToolGrad-12B е изпреварил отворени специализирани модели за използване на инструменти, включително ToolACE и Hammer-2.1-7B.

Скриптовете за възпроизвеждане в хранилището са насочени към BFCL V1 и V2 чрез персонализиран форк, изпълняват извеждането в Docker образ с vLLM и са проверени на една NVIDIA A100 40GB.

Основни изводи

• ToolGrad обръща генерирането на данни за използване на инструменти: първо се проверява веригата, а след това се създава заявката.
• Процентът на успешните изпълнения в ToolBench се увеличава от 63,8% на 99,8%, като веригите са по-дълги, а стъпките с инструменти — по-малко.
• Само 500 примера повишават Gemma-3-12B до 83,1 в BFCL — близо до Gemini 2.5 Pro с 83,2.
• Моделът ученик надминава своя учител Gemini 2.5 Flash-Lite.

---

Разгледайте статията, страницата в GitHub и блога на Google Research. Също така, не се колебайте да ни последвате в Twitter и не забравяйте да се присъедините към нашия 150k+ ML SubReddit и да се абонирате за нашия бюлетин. Чакайте! В Telegram ли сте? вече можете да се присъедините към нас и в Telegram.

Имате нужда от партньор за популяризиране на вашето GitHub хранилище, страница в Hugging Face, продуктова премиера, уебинар и т.н.? Свържете се с нас