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%) с модел, който е приблизително 1/10 от неговия размер.
• Печалбите се разпростират и върху символното разсъждение. При задачите BIG-Bench Hard като Object Counting, PAL постига 96,7% срещу 73,0% за CoT; при Penguins in a Table — 93,3% срещу 79,2%.
• Анализ на компонентите (ablation) разкрива къде всъщност се извършва работата: когато LLM действа като собствен интерпретатор (без външен Python), точността в GSM8K се срива до 23,2%. Интерпретаторът не е второстепенно подобрение — той извършва цялата аритметика.
• Именуването на променливите има значение. Замяната на смислени имена на променливи с произволни знаци причинява значителен спад в точността при символни задачи. Моделът чете собствения си код.

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

Основното твърдение е тривиално вярно и експериментите го потвърждават убедително: Python е по-добър от LLM в аритметиката, а GSM-hard прави това брутално видимо. Тези +38 пр.п. там не са странност на бенчмарка — те отразяват категоричен режим на отказ на CoT при мащабиране.

Това, което намирам за по-малко убедително, е рамкирането му като пробив в общото разсъждение. PAL работи върху задачи, които случайно имат детерминистични отговори, изразими чрез Python. Голяма част от това, което е от значение във финансовото разсъждение, не се декомпозира по този начин. Решаването дали даден модел на трансакция е „необичаен за тази сметка през четвъртото тримесечие“ или дали даден превод изисква ръчна проверка, не може да бъде сведено до Python израз. PAL ви дава надежден аритметичен двигател; той не ви дава преценка.

Измерението на сигурността не получава никакво внимание в статията. Бенчмарковете се изпълняват в контролирана среда, но всяко внедряване, което генерира и изпълнява произворен Python в отговор на въведени от потребителя данни, е значителна повърхност за атака. Бягства от ядрата (kernel escapes) на изолирани интерпретатори, достъп до файловата система или тайни, враждебно съставени входни данни, които генерират зловреден код — нищо от това не е адресирано. За финансови приложения това не е просто бележка под линия.

Статията също така не анализира задълбочено режимите на отказ, когато генерирането на код се обърка. Ако PAL произведе синтактично невалиден Python, той не връща нищо. Авторите съобщават за проценти на успеваемост на изпълнението, но не характеризират причините за откази при генерирането или дали те са случайни или систематични. Като се има предвид, че интерпретаторът извършва цялата аритметика, качеството на кода е основното тясно място за надеждността — и то е недостатъчно анализирано.

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

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

Program of Thoughts (arXiv:2211.12588), конкурентна статия, която независимо разработи същата идея, е оценена върху три финансови набора от данни за въпроси и отговори — 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 могат да се възстановяват от собствените си грешки при генериране на код.