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

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

Статья

Тимо Шик и семь соавторов из Meta AI представляют метод обучения языковой модели самостоятельно решать, когда вызывать внешние API, какие аргументы передавать и как включать результаты в свои собственные предсказания — и все это без необходимости вручную размеченных данных для каждого инструмента. Подход основан на самообучении: модель генерирует потенциальные вызовы API в подходящих местах текста, выполняет эти вызовы и оставляет только те примеры, где результат API действительно снижает перплексию модели на окружающих токенах. Этот отфильтрованный набор данных затем используется для тонкой настройки (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 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% случаев в задачах на временные рассуждения; модель преимущественно перенаправляет вопросы о времени на поиск в Wikipedia.

Что подтверждается, а что нет

Основная идея долговечна: трюк с фильтрацией на основе перплексии элегантен, поскольку не требует участия человека или «оракула», знающего правильный ответ — важно лишь то, сделал ли вставленный результат API окружающий текст более предсказуемым. Это настоящий вклад, и результаты в математике поражают. Модель 6.7B, побеждающая GPT-3 на ASDiv, — это не ошибка оценки, а чистая демонстрация того, что правильный вызов инструмента стоит примерно в 26 раз большего количества параметров в арифметических задачах.

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

Более глубокая методологическая проблема заключается в том, что конвейер самообучения предполагает, что модель уже достаточно хороша, чтобы генерировать правдоподобные вызовы API еще до того, как ее этому обучили. Это проблема бутстрапинга (самозапуска). Для хорошо структурированных инструментов, таких как калькулятор с четким форматом ввода, это работает. Для инструментов с более сложными схемами аргументов — именно такими, которые нужны для реального API обратной записи в бухгалтерскую книгу, — качество сгенерированных вызовов будет быстро деградировать.

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

Наконец, оценка проводится в режиме zero-shot. Нет сравнения с few-shot промптингом GPT-3 или GPT-4 с инструментами, предоставленными в контексте, что стало доминирующей парадигмой через несколько месяцев после выхода этой статьи. Дата публикации на 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.