Toolformer: Самокероване використання інструментів та його обмеження для фінансового ШІ

Toolformer (Schick et al., 2023, Meta AI) — це основоположна робота, присвячена навчанню мовних моделей виклику зовнішніх API за допомогою самокерованого навчання. Я відкладав уважне читання, оскільки «використання інструментів» стало настільки популярним терміном, що оригінальні твердження розмилися. Перш ніж проектувати будь-якого агента зворотного запису, який викликає інструменти облікової книги (ledger), мені потрібно зрозуміти, що насправді продемонстрував Toolformer — і де він тихо зазнає невдачі.

Стаття

Тімо Шик та семеро співавторів із Meta AI представляють метод навчання мовної моделі приймати рішення про те, коли викликати зовнішні API, які аргументи передавати та як інтегрувати результати у власні прогнози — без необхідності вручну розмічених навчальних даних для кожного інструмента. Підхід є самокерованим: модель генерує потенційні виклики API у правдоподібних позиціях тексту, виконує ці виклики та зберігає лише ті приклади, де результат API дійсно знижує перплексію (perplexity) моделі на навколишніх токенах. Цей відфільтрований набір даних потім використовується для тонкого налаштування (fine-tuning). Протестовані інструменти включають калькулятор, дві пошукові системи (пошук BM25 та пошук у Вікіпедії), модель 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 math Toolformer досягає 40,4% проти 7,5% у GPT-J та 14,0% у GPT-3; у MAWPS — 44,0% проти 9,9% у GPT-J та 19,8% у GPT-3.
• У задачах на фактичні запитання (factual QA) ситуація протилежна: GPT-3 все ще перевершує Toolformer у всіх трьох тестах QA (TriviaQA, WebQuestions, Natural Questions), попри те, що Toolformer використовує інструменти пошуку. Toolformer на TriviaQA: 53,5% проти базової моделі GPT-J з 31,9%, але GPT-3 без інструментів показує ще вищий результат.
• Конвеєр самокерованої генерації даних створює навчальні приклади, де модель вчиться не викликати API, коли це не корисно — етап фільтрації використовує покращення перплексії як сигнал для відповіді на питання: «чи справді цей виклик інструмента допоміг?».
• Здатність використовувати інструменти з’являється лише при певному масштабі: моделі з параметрами менше приблизно 775 млн не вчаться надійно викликати інструменти навіть за наявності того самого навчального сигналу.
• Інструмент «календар» викликається лише у 0,2% випадків у задачах на часове міркування (temporal reasoning); модель переважно спрямовує часові питання до інструмента пошуку у Вікіпедії.

Що залишається актуальним, а що — ні

Основна ідея життєздатна: трюк із фільтрацією на основі перплексії елегантний, оскільки не потребує людської розмітки та «оракула», який знає правильну відповідь — лише того, чи зробив вставлений результат API навколишній текст більш передбачуваним. Це справжній внесок, а результати в математиці вражають. Те, що модель із 6,7 млрд параметрів перемагає GPT-3 на ASDiv, — це не помилка оцінювання; це чітка демонстрація того, що правильний виклик інструмента вартий у ~26 разів більше параметрів у задачах на арифметику.

Менш переконливою мені здається історія з QA. Стаття представляє Toolformer як такий, що загалом покращує продуктивність, але результати QA показують, що він не перемагає GPT-3 — набагато більшу модель без жодних інструментів. Автори визнають це, але формулювання наративу («часто конкурує з набагато більшими моделями») применшує вибірковість перемоги: модель виграє в задачах, які чітко розкладаються на один виклик калькулятора або пошуку, і програє або демонструє такий же результат у задачах, що потребують справжнього міркування над отриманим контентом.

Глибша методологічна проблема полягає в тому, що самокерований конвеєр передбачає, що модель уже достатньо хороша, щоб генерувати правдоподібні виклики API до того, як її цьому навчать. Це проблема самозавантаження (bootstrapping). Для добре структурованих інструментів, таких як калькулятор із чітким форматом введення, це працює. Для інструментів зі складнішими схемами аргументів — саме такими, які потрібні для API зворотного запису в реальні облікові книги — якість вибіркових викликів швидко погіршиться.

Стаття також оцінює кожен інструмент ізольовано, а не в комбінації. Немає демонстрації багатоступеневого конвеєра, де, скажімо, результат пошуку передається в калькулятор. Автори вказують на це як на обмеження, і воно є значним: реальні робочі процеси в бухгалтерії майже завжди потребують ланцюжків викликів інструментів.

Нарешті, оцінювання є zero-shot (без прикладів). Немає порівняння з few-shot (з кількома прикладами) промптами GPT-3 або GPT-4 з інструментами в контексті, що стало домінуючою парадигмою вже за кілька місяців після виходу цієї статті. Дата публікації NeurIPS 2023 означає, що експерименти передували широкому впровадженню API для виклику функцій (function-calling APIs), що робить набір для порівняння дещо застарілим на момент публікації.

Чому це важливо для фінансового ШІ

Стаття про 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.