Toolformer: Самообучено използване на инструменти и неговите ограничения за финансовия ИИ

Toolformer (Schick et al., 2023, Meta AI) е основополагащата научна статия за обучение на езикови модели да извикват външни API чрез самообучение (self-supervised training). Отлагах внимателното ѝ четене, защото „използването на инструменти“ (tool use) се превърна в такава модерна дума, че първоначалните твърдения се размиват. Преди да проектирам какъвто и да е агент за записване (write-back agent), който извиква счетоводни инструменти, трябва да разбера какво всъщност демонстрира Toolformer — и къде тихомълком се проваля.

Статията

Тимо Шик и седем съавтори от Meta AI представят метод за обучение на езиков модел да решава кога да извика външни API, какви аргументи да предаде и как да включи резултатите в собствените си прогнози — без да е необходимо ръчно етикетиране на данни за обучение за всеки инструмент. Подходът е самообучен: моделът генерира кандидат-извиквания на API на правдоподобни позиции в текста, изпълнява тези извиквания и запазва само примерите, при които резултатът от API действително намалява перплексията (perplexity) на модела върху околните токени. Този филтриран набор от данни след това се използва за фина настройка (fine-tuning). Тестваните инструменти включват калкулатор, две търсачки (BM25 извличане и търсене в Wikipedia), QA модел, преводач и календар.

Обученият модел е базиран на GPT-J с 6,7 милиарда параметри, който те наричат 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% срещу 7,5% за GPT-J и 14,0% за GPT-3; при MAWPS, 44,0% срещу 9,9% за GPT-J и 19,8% за GPT-3.
• При фактологични QA задачи картината се обръща: GPT-3 все още превъзхожда Toolformer и в трите QA бенчмарка (TriviaQA, WebQuestions, Natural Questions), въпреки че Toolformer използва инструменти за търсене. Toolformer TriviaQA: 53,5% срещу 31,9% за базовия GPT-J, но GPT-3 без инструменти е още по-добър.
• Пайплайнът за самообучено генериране на данни произвежда примери за обучение, при които моделът се научава да не извиква API, когато това не е полезно — стъпката на филтриране използва подобрението на перплексията като сигнал за това „дали това извикване на инструмент всъщност помогна?“.
• Способността за използване на инструменти се появява само при определен мащаб: модели под приблизително 775 милиона параметри не се научават надеждно кога да задействат инструменти, дори със същия тренировъчен сигнал.
• Инструментът за календар се извиква само в 0,2% от случаите при задачи за времево разсъждение; моделът предимно насочва времевите въпроси към инструмента за търсене в Wikipedia вместо това.

Какво се потвърждава — и какво не

Основното прозрение е трайно: трикът с филтриране въз основа на перплексия е елегантен, защото не изисква човешко етикетиране и никакъв оракул, който знае правилния отговор — само дали вмъкнатият резултат от API е направил околния текст по-предвидим. Това е истински принос и математическите резултати са поразителни. Модел с 6,7 милиарда параметри, побеждаващ GPT-3 на ASDiv, не е трик на оценката; това е ясна демонстрация, че правилното извикване на инструмент струва ~26 пъти повече параметри при аритметични задачи.

Това, което намирам за по-малко убедително, е историята с QA (въпроси и отговори). Статията представя Toolformer като широко подобряващ производителността, но резултатите от QA показват, че той не побеждава GPT-3 — много по-голям модел без никакви инструменти. Авторите признават това, но наративната рамка („често конкурентен на много по-големи модели“) омаловажава колко селективна е победата: моделът печели при задачи, които чисто се разлагат на еднократно извикване на калкулатор или търсене, и губи или съвпада при задачи, изискващи истинско разсъждение върху извлеченото съдържание.

По-дълбокият методологичен проблем е, че самообученият пайплайн предполага, че моделът вече е достатъчно добър, за да генерира правдоподобни API извиквания, преди да е бил обучен да го прави. Това е проблем на самозареждането (bootstrapping). За добре структурирани инструменти като калкулатор с ясен входен формат, това работи. За инструменти с по-сложни схеми на аргументи — точно такива, каквито бихте искали за API за записване в реална счетоводна книга — качеството на взетите проби от извиквания би се влошило бързо.

Статията също така оценява всеки инструмент изолирано, а не в комбинация. Няма демонстрация на многостъпков пайплайн, където например резултат от търсене се подава в калкулатор. Авторите посочват това като ограничение, но то е значително такова: реалните счетоводни работни процеси почти винаги изискват верижни извиквания на инструменти.

И накрая, оценката е zero-shot (без предварителни примери). Липсва сравнение с GPT-3 или GPT-4 с few-shot подсказки (prompts) и инструменти, предоставени в контекста, което се превърна в доминиращата парадигма месеци след тази статия. Датата на публикуване в NeurIPS 2023 означава, че експериментите предхождат широкото приемане на API за извикване на функции (function-calling), което прави сравнителния набор донякъде остарял към момента на публикуване.

Защо това е важно за финансовия ИИ

Статията за Toolformer отговаря на въпрос, който ме вълнува за Bean Labs: може ли един модел да се научи да извиква надеждно API за записване и на каква цена? Отговорът от математическите резултати е „да, ако интерфейсът на инструмента е чист и задачата се разлага до едно извикване“. Режимите на отказ обаче се припокриват директно с най-трудните части на проблема със счетоводната книга.

Действията за записване в Beancount — класифициране на трансакция, извеждане на съответствия на сметки, генериране на запис в дневника — не са едностъпкови извиквания на калкулатор. Те включват извличане на контекст (предишни записи, сметкоплан), прилагане на правила (правила за осчетоводяване, ограничения на валутата) и създаване на структуриран изход, който трябва да бъде синтактично валиден. Това са поне три верижни извиквания на инструменти, а архитектурата на Toolformer изрично не може да верижи инструменти. Сигналът за обучение, базиран на перплексия, също би бил труден за прилагане тук: не е ясно какво означава „по-ниска перплексия върху околния текст на счетоводната книга“, когато изходът е структуриран .beancount файл, а не продължение на естествен език.

По-полезният урок от Toolformer за нашите цели е негативното пространство: един агент за записване не може просто да бъде фино настроен езиков модел, който е наизустил кога да извика API на счетоводната книга. Той се нуждае от изричен слой за разсъждение (ReAct или подобен), който може да планира, изпълнява и проверява междинните резултати, преди да извърши запис. Toolformer демонстрира, че използването на инструменти работи; той не демонстрира, че работи безопасно върху структурирани операции със странични ефекти.

Какво да прочетете след това

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) — добавя изрични стъпки за разсъждение „верига от мисли“ (chain-of-thought), преплетени с извиквания на инструменти; архитектурата, която решава ограничението на Toolformer за верижно свързване и е в основата на повечето модерни агенти.
• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — мащабира използването на инструменти до над 16 000 реални API чрез набора от данни ToolBench; най-близкото нещо до стрес тест на извикването на инструменти на нивото на сложност, с което би се сблъскал реален счетоводен агент.
• FinMaster (arXiv:2505.13533) — бенчмаркове за цялостни счетоводни работни процеси, включително вписване в дневника и равняване; ще покаже дали ползите, които Toolformer демонстрира при аритметиката, се обобщават за многостъпковите задачи с ограничени схеми, които са важни за Beancount.