Toolformer (Schick et al., 2023, Meta AI) е основополагащата статия за обучението на езикови модели да извикват външни API чрез самоконтролирано обучение. Отлагах внимателното ѝ прочитане, защото „използването на инструменти“ се превърна в толкова клиширана дума, че първоначалните твърдения се замъгляват. Преди да проектирам какъвто и да е агент за запис обратно, който извиква счетоводни инструменти, трябва да разбера какво всъщност е демонстрирал Toolformer – и къде тихо се проваля.
Статията
Тимо Шик и седем съавтори от Meta AI представят метод за обучение на езиков модел да решава кога да извиква външни API, какви аргументи да подава и как да включва резултатите в собствените си предсказания – без да изисква ръчно обозначени обучителни данни за всеки инструмент. Подходът е самоконтролиран: моделът генерира кандидат-извиквания на API на правдоподобни позиции в текста, изпълнява тези извиквания и запазва само примерите, където резултатът от API наистина намалява перплекситета на модела за околните токени. Този филтриран набор от данни след това се използва за фино настройване. Тестваните инструменти включват калкулатор, две търсачки (BM25 извличане и Wikipedia търсене), модел за въпроси и отговори, преводач и календар.
Обученият модел е базиран на GPT-J с 6.7B параметри и го наричат Toolformer. Статията е приета на NeurIPS 2023.
Ключови идеи
- По математически текстови задачи (SVAMP), Toolformer 6.7B постига 29.4% – в сравнение с базовия GPT-J при 5.2%, OPT 66B при 4.9% и GPT-3 175B при 10.0%. Използването на инструменти ефективно премахва обичайната крива на мащабиране за аритметика.
- По математика ASDiv, Toolformer достига 40.4% срещу GPT-J при 7.5% и GPT-3 при 14.0%; по MAWPS, 44.0% срещу GPT-J при 9.9% и GPT-3 при 19.8%.
- По задачи за фактически въпроси и отговори картината се обръща: GPT-3 все още превъзхожда Toolformer на всичките три сравнителни теста за ВО (TriviaQA, WebQuestions, Natural Questions), въпреки че Toolformer използва инструменти за търсене. Toolformer TriviaQA: 53.5% срещу базовия GPT-J при 31.9%, но GPT-3 без инструменти е още по-високо.
- Конвейерът за самоконтролирано генериране на данни създава примери за обучение, където моделът се учи да не извиква API, когато това не е полезно – стъпката за филтриране използва подобрението на перплекситета като сигнал за „това извикване на инструмент наистина ли помогна?“
- Способността за използване на инструменти се появява само при мащаб: модели под приблизително 775M параметри не се научават надеждно кога да извикват инструменти, дори със същия обучителен сигнал.
- Календарният инструмент се извиква само в 0.2% от случаите в задачи за времеви разсъждения; моделът преимуществено насочва времевите въпроси към инструмента за wiki търсене.
Какво издържа – и какво не
Основното прозрение е трайно: трикът с филтриране по перплекситет е елегантен, защото не изисква човешко обозначаване и не изисква оракул, който знае верния отговор – само дали вмъкнатият резултат от API е направил околния текст по-предсказуем. Това е истински принос, а математическите резултати са впечатляващи. Модел с 6.7B, който побеждава GPT-3 на ASDiv, не е трик на оценката; това е чиста демонстрация, че правилното извикване на инструмент си струва приблизително 26× повече параметри по аритметични задачи.
Това, което намирам за по-малко убедително, е историята с ВО. Статията представя Toolformer като цялостно подобряващ производителността, но резултатите от ВО показват, че той не побеждава GPT-3 – много по-голям модел без никакви инструменти. Авторите признават това, но разказателната рамка („често конкурентен на много по-големи модели“) подценява колко избирателна е победата: моделът печели по задачи, които чисто се разлагат на единично извикване на калкулатор или търсене, и губи или изравнява по задачи, изискващи истински разсъждения върху извлеченото съдържание.
По-дълбокият методологичен проблем е, че самоконтролираният конвейер предполага, че моделът вече е достатъчно добър, за да генерира правдоподобни извиквания на API, преди да е обучен да го прави. Това е проблем на самозареждане. За добре структурирани инструменти като калкулатор с ясен входен формат работи. За инструменти с по-сложни схеми на аргументи – точно от вида, който бихте искали за реален API за запис обратно в счетоводство – качеството на извадените извиквания бързо би се влошило.
Статията също така оценява всеки инструмент изолирано, а не в комбинация. Няма демонстрация на многоетапен конвейер, където например резултат от търсене се подава на калкулатор. Авторите отбелязват това като ограничение, но то е значително: реалните счетоводни работни потоци почти винаги изискват верижни извиквания на инструменти.
Накрая, оценката е при нулев контекст. Няма сравнение с GPT-3 или GPT-4 с няколко примера в подкана и инструменти в контекста, което стана доминиращата парадигма в рамките на месеци след тази статия. Датата на публикация NeurIPS 2023 означава, че експериментите предхождат широкото приемане на API за извикване на функции, което прави сравнителния набор донякъде остарял към момента на публикуването.
Защо това има значение за финансовите ИИ
Статията за Toolformer отговаря на въпрос, който ме вълнува за Bean Labs: може ли модел да се научи надеждно да извиква API за запис обратно и на каква цена? Отговорът от математическите резултати е „да, ако интерфейсът на инструмента е чист и задачата се разлага на единично извикване.“ Но режимите на отказ директно се проектират върху най-трудните части на счетоводния проблем.
Действията за запис обратно в Beancount – класифициране на транзакция, извеждане на счетоводни съответствия, генериране на журнален запис – не са едноетапни извиквания на калкулатор. Те включват извличане на контекст (предишни записи, сметкоплан), прилагане на правила (правила за осчетоводяване, валутни ограничения) и генериране на структуриран изход, който трябва да бъде синтактично валиден. Това са поне три верижни извиквания на инструменти, а архитектурата на Toolformer изрично не може да верижно свързва инструменти. Обучителният сигнал, базиран на перплекситет, също би бил трудно приложим тук: не е ясно какво означава „по-нисък перплекситет на околния счетоводен текст“, когато изходът е структуриран .beancount файл, а не естествено езиково продължение.
По-полезният урок от Toolformer за нашите цели е отрицателното пространство: агент за запис обратно не може просто да бъде фино настроен езиков модел, който е запомнил кога да извиква счетоводния API. Той се нуждае от изричен слой за разсъждение (ReAct или подобен), който може да планира, изпълнява и проверява междинни резултати, преди да извърши запис. Toolformer демонстрира, че използването на инструменти работи; той не демонстрира, че работи безопасно върху структурирани операции със странични ефекти.
Какво да прочетете след това
- ReAct: Синергизиране на разсъждението и действието в езиковите модели (arXiv:2210.03629) – добавя изрични стъпки на мисловна верига, преплетени с извиквания на инструменти; архитектурата, която адресира ограничението на Toolformer за верижно свързване и е основата за повечето съвременни агенти.
- ToolLLM: Улесняване на големите езикови модели да овладеят 16000+ реални API (arXiv:2307.16789, ICLR 2024) – мащабира използването на инструменти до над 16 000 реални API чрез набора от данни ToolBench; най-близкото до стрес тест за извикване на инструменти на нивото на сложност, пред което би се изправил реален счетоводен агент.
- FinMaster (arXiv:2505.13533) – сравнителен тест за цялостни счетоводни работни потоци, включително журнални записи и съпоставяне; ще покаже дали печалбите, които Toolformer демонстрира по аритметика, се обобщават до многоетапните задачи със схематични ограничения, които имат значение за Beancount.
