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% у ланцюжка думок з тією ж моделлю 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, таких як підрахунок об'єктів (Object Counting), PAL набирає 96,7% проти 73,0% у CoT; на Penguins in a Table — 93,3% проти 79,2%.
• Абляційне дослідження показує, де насправді відбувається робота: коли LLM діє як власний інтерпретатор (без зовнішнього Python), точність на GSM8K падає до 23,2%. Інтерпретатор — це не незначне покращення, він виконує всю арифметику.
• Найменування змінних має значення. Заміна осмислених назв змінних на випадкові символи спричиняє значне падіння точності в символьних завданнях. Модель читає свій власний код.

Що витримує критику, а що — ні

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

Що мені здається менш переконливим, так це подання цього як загального прориву в міркуванні. PAL працює на завданнях, які мають детерміновані відповіді, що виражаються мовою Python. Багато з того, що має значення у фінансових міркуваннях, не декомпонується таким чином. Рішення про те, чи є паттерн транзакцій "незвичним для цього рахунку в 4 кварталі", або чи потребує переказ прапорця для ручної перевірки, не зводиться до виразу Python. PAL дає вам надійний арифметичний двигун; він не дає вам судження.

Аспекту безпеки в статті не приділено уваги. Бенчмарки запускаються в контрольованому середовищі, але будь-яке розгортання, яке генерує та виконує довільний код Python у відповідь на введення користувача, є суттєвою поверхнею атаки. Втеча з ядра пісочниці інтерпретатора, доступ до файлової системи або секретів, зловмисно створені вводи, що генерують шкідливий код — нічого з цього не розглядається. Для фінансових додатків це не просто примітка.

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

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

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

Program of Thoughts (arXiv:2211.12588), паралельна стаття, яка незалежно розвинула ту саму ідею, провела оцінку на трьох наборах фінансових даних для QA — FinQA, ConvFinQA та TATQA — і повідомила про середній приріст ~12% порівняно з ланцюжком думок. Це найбільш прямий доказ того, що підхід із генерацією програм допомагає в міркуваннях у фінансовій сфері, а не лише в математиці для початкової школи.

Питання безпеки запису, однак, стоїть гостріше в контексті бухгалтерської книги, ніж у бенчмарках. Агент, який генерує 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 відновлюватися після власних помилок генерації коду.