PAL: Программно-вспомогательные языковые модели для надежной финансовой арифметики

Изучив литературу по табличным рассуждениям, я захотел понять дополняющий подход: вместо того чтобы заставлять LLM рассуждать о таблицах на естественном языке, что произойдет, если позволить им писать код и полностью передать вычисления? PAL (Gao et al., 2022, arXiv:2211.10435) — это канонический ответ, имеющий очевидные последствия для любой системы, которой необходимо надежно выполнять арифметические действия над финансовыми данными.

О статье

«PAL: Program-Aided Language Models» (Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023) начинается с простого наблюдения: LLM хорошо декомпозируют задачи, но плохо выполняют арифметические действия. Промптинг методом «цепочки рассуждений» (chain-of-thought) решает первую проблему, но оставляет вторую без внимания. Предлагаемое решение заключается в изменении того, что LLM выдает в качестве «шагов рассуждения» — вместо арифметики на естественном языке она генерирует код на Python. Затем интерпретатор Python запускает этот код и возвращает ответ.

Разделение на декомпозицию и выполнение предельно четкое: LLM отвечает за понимание задачи и структуру программы, а интерпретатор берет на себя всё числовое. Вопрос вроде «У Оливии есть $23, она покупает пять рогаликов по $3 за штуку — сколько осталось?» превращается в money_left = 23 - (5 * 3), а не в последовательность прозаических арифметических действий, в которых модель может ошибиться.

Ключевые идеи

• В GSM8K (задачи по математике для начальной школы) PAL с Codex достигает точности 72,0% по сравнению с 65,6% у chain-of-thought с той же моделью Codex — прирост +6,4 п.п. — и 56,9% у CoT с гораздо более крупной моделью PaLM-540B. Меньшая модель побеждает за счет делегирования арифметики Python.
• В GSM-hard, версии GSM8K, где числа заменены на более крупные значения, PAL достигает 61,2% против 23,1% у CoT — абсолютный разрыв в +38,1 п.п. Большие числа ломают арифметику на уровне токенов; они не ломают Python.
• При мажоритарном голосовании по 40 выборкам PAL достигает 80,4% в GSM8K, опережая Minerva-540B (78,5%) с моделью примерно в 10 раз меньшего размера.
• Эти преимущества распространяются и на символические рассуждения. В задачах BIG-Bench Hard, таких как подсчет объектов, PAL набирает 96,7% против 73,0% у CoT; в «Пингвинах в таблице» — 93,3% против 79,2%.
• Абляция показывает, где на самом деле происходит работа: когда LLM выступает в роли собственного интерпретатора (без внешнего Python), точность в GSM8K падает до 23,2%. Интерпретатор — это не незначительное улучшение, он выполняет всю арифметику.
• Именование переменных имеет значение. Замена осмысленных имен переменных случайными символами приводит к существенному падению точности в символических задачах. Модель «читает» свой собственный код.

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

Основное утверждение тривиально верно, и эксперименты убедительно его подтверждают: Python лучше справляется с арифметикой, чем LLM, и GSM-hard делает это предельно очевидным. Разрыв в +38 п.п. — это не причуда бенчмарка, а отражение категориального отказа CoT при масштабировании.

Менее убедительным мне кажется позиционирование этого как общего прорыва в рассуждениях. PAL работает в задачах, которые имеют детерминированные ответы, выразимые на Python. Многое из того, что важно в финансовых рассуждениях, не декомпозируется таким образом. Решение о том, является ли структура транзакции «необычной для этого счета в четвертом квартале» или заслуживает ли перевод пометки для ручной проверки, не сводится к выражению на Python. PAL дает вам надежный арифметический движок; он не дает вам способности к суждению.

Вопросу безопасности в статье не уделяется внимания. Бенчмарки запускаются в контролируемой среде, но любое развертывание, которое генерирует и выполняет произвольный Python-код в ответ на ввод пользователя, является серьезной поверхностью атаки. Побег из ядра изолированных интерпретаторов, доступ к файловой системе или секретам, специально сформированные входные данные для генерации вредоносного кода — ничего из этого не рассматривается. Для финансовых приложений это не просто примечание.

В статье также глубоко не анализируются сценарии отказов при сбоях генерации кода. Если PAL выдает синтаксически неверный Python, всё рушится. Авторы сообщают о показателях успешности выполнения, но не характеризуют причины ошибок генерации и не уточняют, являются ли они случайными или систематическими. Учитывая, что интерпретатор выполняет всю арифметику, качество кода является единственным узким местом надежности — и оно недостаточно проанализировано.

Почему это важно для финансового ИИ

Это одна из самых практически применимых к Beancount статей, которые я читал. Операции в учетной книге почти идеально совпадают с тем, что PAL делает хорошо: суммирование транзакций по категориям, применение курсов валют, расчет налоговой базы по нескольким лотам, сверка итогов банковских выписок с балансами в книге. Это детерминированные, тяжелые с точки зрения арифметики задачи, выразимые на Python. Агенты на базе CoT будут галлюцинировать числами в таких случаях; PAL — нет, при условии правильной структуры программы.

В статье «Program of Thoughts» (arXiv:2211.12588), опубликованной одновременно и независимо развивающей ту же идею, оценка проводилась на трех финансовых наборах данных QA — FinQA, ConvFinQA и TATQA — и показала средний прирост около 12% по сравнению с chain-of-thought. Это самое прямое доказательство того, что подход с генерацией программ помогает в рассуждениях в финансовой сфере, а не только в школьной математике.

Однако вопрос безопасности записи в контексте бухгалтерской книги стоит острее, чем в бенчмарках. Агент, генерирующий Python для чтения данных Beancount, несет низкий риск. Агенту, генерирующему Python для записи записей в книгу, требуется жестко ограниченная среда выполнения — такая, которая может затрагивать только объекты книги и ничего больше, которая прекращает работу при любом исключении и требует, чтобы сгенерированный код прошел через белый список перед выполнением. PAL рассматривает интерпретатор как нейтральный вычислительный движок. Серийный финансовый агент не может себе этого позволить.

Что почитать дальше

• Program of Thoughts Prompting (Chen et al., arXiv:2211.12588) — сопутствующая работа, в которой оцениваются FinQA, ConvFinQA и TATQA и сообщается о среднем приросте ~12% по сравнению с CoT; та самая финансовая оценка, которую PAL оставляет на потом.
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen et al., EMNLP 2021) — бенчмарк, лежащий в основе финансовых оценок PoT; понимание того, что на самом деле тестируется, помогает откалибровать степень доверия к переносу на реальные сценарии использования Beancount.
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., arXiv:2303.17651) — тот же первый автор, что и у PAL, расширяет идею генерации кода до итеративных циклов самокоррекции; актуально для понимания того, могут ли агенты в стиле PAL восстанавливаться после собственных ошибок генерации кода.