След като прекарах време с литературата за таблично разсъждение, исках да разбера допълващия подход: вместо да караме 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 разлагат проблемите добре, но изпълняват аритметиката лошо. Промптването с верига на разсъждение решава първия проблем, но оставя втория недокоснат. Предложеното решение е да се промени какво произвежда LLM като своите "стъпки на разсъждение" — вместо аритметика в естествен език, той генерира Python код. Python интерпретаторът след това изпълнява този код и връща отговора.
Разделението разлагане-изпълнение е чисто: LLM се справя с разбирането на проблема и структурата на програмата; интерпретаторът се справя с всичко числово. Въпрос като "Оливия има $23, купува пет геврека по $3 всеки — колко ѝ остава?" става money_left = 23 - (5 * 3), а не поредица от прозови аритметични операции, които моделът може да обърка.
Ключови идеи
- При GSM8K (училищни математически задачи с текст), PAL с Codex достига 72.0% точност срещу 65.6% за веригата на разсъждение със същия Codex модел — печалба от +6.4pp — и 56.9% за CoT с много по-големия PaLM-540B модел. По-малък модел печели, като делегира аритметиката на Python.
- При GSM-hard, версия на GSM8K, където числата са заменени с по-големи стойности, PAL постига 61.2% срещу 23.1% за CoT — абсолютна разлика от +38.1pp. Големите числа счупват аритметиката на ниво токени; те не счупват 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%.
- Една аблация разкрива къде всъщност се извършва работата: когато LLM действа като собствен интерпретатор (без външен Python), точността при GSM8K пада до 23.2%. Интерпретаторът не е незначително подобрение — той извършва цялата аритметика.
- Наименуването на променливите има значение. Замяната на смислени имена на променливи със случайни символи причинява значителни спадове в точността при символните задачи. Моделът чете собствения си код.
Какво издържа — и какво не
Основното твърдение е тривиално вярно и експериментите го потвърждават убедително: Python е по-добър от LLM в аритметиката, а GSM-hard прави това брутално видимо. Увеличението от +38pp там не е странност на бенчмарка — то отразява категоричен начин на отказ на CoT при мащабиране.
Това, което намирам за по-малко убедително, е рамкирането като общ пробив в разсъждението. PAL работи върху задачи, които случайно имат детерминистични, изразими в Python отговори. Голяма част от това, което има значение във финансовото разсъждение, не се разлага по този начин. Решението дали модел на транзакции е "необичаен за тази сметка през Q4" или дали превод заслужава флаг за ръчна проверка не може да бъде сведено до 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-стил агенти могат да се възстановят от собствените си неуспехи в генерирането на код.
