PAL: 신뢰할 수 있는 금융 산술을 위한 프로그램 보조 언어 모델

표 형식 추론(tabular reasoning) 관련 문헌을 살펴본 후, 저는 보완적인 접근 방식을 이해하고 싶었습니다. 즉, LLM이 자연어로 표에 대해 추론하게 만드는 대신, 코드를 작성하게 하고 계산을 완전히 맡기면 어떤 일이 벌어질까요? PAL(Gao 등, 2022, arXiv:2211.10435)은 이에 대한 전형적인 해답이며, 금융 데이터에 대해 신뢰할 수 있는 산술 연산을 수행해야 하는 모든 시스템에 명확한 시사점을 제공합니다.

논문 소개

"PAL: Program-Aided Language Models"(Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023)는 간단한 관찰에서 시작합니다. LLM은 문제를 잘 분해하지만 산술 실행 능력은 떨어집니다. 생각의 사슬(Chain-of-thought) 프롬프팅은 첫 번째 문제는 해결하지만 두 번째 문제는 방치합니다. 제안된 해결책은 LLM이 "추론 단계"로서 생성하는 결과물을 바꾸는 것입니다. 즉, 자연어 산술 대신 파이썬 코드를 생성하게 합니다. 그런 다음 파이썬 인터프리터가 해당 코드를 실행하고 결과를 반환합니다.

분해와 실행의 분리는 명확합니다. LLM은 문제 이해와 프로그램 구조를 담당하고, 인터프리터는 모든 수치 계산을 처리합니다. "Olivia는 23달러를 가지고 있고, 개당 3달러인 베이글 5개를 샀습니다. 남은 돈은 얼마입니까?"와 같은 질문은 모델이 실수할 수 있는 일련의 산술 문장이 아니라 money_left = 23 - (5 * 3)이 됩니다.

핵심 아이디어

• GSM8K(초등 수학 서술형 문제)에서 PAL과 Codex를 결합하면 동일한 Codex 모델을 사용한 생각의 사슬(65.6%)보다 높은 72.0%의 정확도(+6.4%p 향상)를 기록했으며, 훨씬 더 큰 PaLM-540B 모델을 사용한 CoT(56.9%)도 능가했습니다. 더 작은 모델이 산술을 파이썬에 위임함으로써 승리한 것입니다.
• 숫자를 더 큰 값으로 대체한 GSM8K 버전인 GSM-hard에서 PAL은 61.2%를 기록한 반면 CoT는 23.1%에 그쳐 +38.1%p의 절대적인 격차를 보였습니다. 큰 숫자는 토큰 수준의 산술을 무너뜨리지만, 파이썬을 무너뜨리지는 못합니다.
• 40개 샘플에 대한 다수결 투표를 통해 PAL은 GSM8K에서 80.4%에 도달하여, 약 10분의 1 크기 모델로 Minerva-540B(78.5%)를 근소하게 앞섰습니다.
• 이러한 이점은 상징적 추론(symbolic reasoning)으로 일반화됩니다. Object Counting과 같은 BIG-Bench Hard 작업에서 PAL은 96.7%(CoT 73.0%)를 기록했고, Penguins in a Table에서는 93.3%(CoT 79.2%)를 기록했습니다.
• 소거 분석(ablation)을 통해 실제 작업이 어디서 일어나는지 드러납니다. LLM이 자체 인터프리터 역할을 할 때(외부 파이썬 없음) GSM8K 정확도는 23.2%로 급락합니다. 인터프리터는 단순한 향상 도구가 아니라 모든 산술을 수행하는 핵심입니다.
• 변수 이름 지정이 중요합니다. 의미 있는 변수 이름을 임의의 문자로 바꾸면 상징적 작업에서 정확도가 크게 떨어집니다. 모델은 자신이 작성한 코드를 읽습니다.

유효한 점과 그렇지 않은 점

핵심 주장은 명백히 타당하며 실험을 통해 설득력 있게 입증되었습니다. 산술 연산에 있어서는 파이썬이 LLM보다 뛰어나며, GSM-hard는 이 점을 극명하게 보여줍니다. 여기서의 38%p 차이는 벤치마크의 특이점이 아니라, 규모가 커질 때 CoT가 겪는 전형적인 실패 양상을 반영합니다.

제가 덜 설득력 있다고 느끼는 부분은 이를 일반적인 추론의 돌파구로 프레임화하는 것입니다. PAL은 우연히 결정론적이고 파이썬으로 표현 가능한 정답이 있는 작업에서 잘 작동합니다. 금융 추론에서 중요한 많은 부분은 이런 방식으로 분해되지 않습니다. 특정 거래 패턴이 "이 계정의 4분기 상황에 비추어 비정상적인지" 또는 이체가 수동 검토 플래그를 지정할 가치가 있는지 결정하는 것은 파이썬 표현식으로 환원될 수 없습니다. PAL은 신뢰할 수 있는 산술 엔진을 제공할 뿐, 판단력을 제공하지는 않습니다.

보안 측면은 논문에서 전혀 다뤄지지 않았습니다. 벤치마크는 통제된 환경에서 실행되지만, 사용자 입력에 응답하여 임의의 파이썬을 생성하고 실행하는 모든 배포 환경은 중대한 공격 표면이 됩니다. 샌드박스 처리된 인터프리터에서의 커널 탈출, 파일 시스템이나 비밀 정보에 대한 접근, 악성 코드를 생성하도록 정교하게 설계된 입력 등은 전혀 언급되지 않았습니다. 금융 애플리케이션에서 이는 단순한 각주 이상의 문제입니다.

또한 이 논문은 코드 생성이 잘못되었을 때의 실패 모드를 깊이 분석하지 않습니다. PAL이 구문적으로 잘못된 파이썬을 내뱉으면 아무런 결과도 내지 못합니다. 저자들은 실행 성공률을 보고하지만, 생성 실패의 원인이 무엇인지, 혹은 그것이 무작위적인지 체계적인지 특성화하지 않습니다. 인터프리터가 모든 산술을 수행한다는 점을 감안할 때 코드 품질은 신뢰성의 병목 구간이지만, 이에 대한 분석은 부족합니다.

금융 AI에 중요한 이유

이 논문은 제가 읽은 것 중 Beancount에 가장 직접적으로 적용 가능한 논문 중 하나입니다. 원장 작업은 카테고리별 거래 합산, 환율 적용, 여러 로트(lot)에 걸친 세금 기준 계산, 은행 명세서 총액과 원장 잔액 대조 등 PAL이 잘하는 작업과 거의 완벽하게 일치합니다. 이러한 작업은 결정론적이고 산술 집약적이며 파이썬으로 표현 가능합니다. CoT 기반 에이전트는 여기서 숫자를 환각할 것이지만, 프로그램 구조만 올바르다면 PAL은 그렇지 않을 것입니다.

동일한 아이디어를 독립적으로 개발한 동시기 논문인 Program of Thoughts(arXiv:2211.12588)는 FinQA, ConvFinQA, TATQA라는 세 가지 금융 QA 데이터셋에서 평가를 진행했으며, 생각의 사슬보다 평균 약 12% 향상되었다고 보고했습니다. 이는 프로그램 생성 방식이 단순한 초등 수학뿐만 아니라 금융 도메인 추론에도 도움이 된다는 가장 직접적인 증거입니다.

하지만 쓰기 작업의 안전성 문제는 벤치마크보다 원장 맥락에서 더 날카롭게 다가옵니다. Beancount 데이터를 읽기 위해 파이썬을 생성하는 에이전트는 위험이 낮습니다. 그러나 원장 항목을 쓰기 위해 파이썬을 생성하는 에이전트는 원장 객체만 건드릴 수 있고 다른 것은 건드릴 수 없는 엄격하게 제한된 실행 환경이 필요합니다. 또한 예외 발생 시 폐쇄형으로 실패(fail closed)해야 하며, 생성된 코드가 실행 전 화이트리스트를 통과해야 합니다. PAL은 인터프리터를 중립적인 계산 엔진으로 취급하지만, 실제 금융 에이전트는 그렇게 할 수 없습니다.

더 읽어보기

• Program of Thoughts Prompting (Chen 등, arXiv:2211.12588) — FinQA, ConvFinQA, TATQA에서 평가하여 CoT 대비 평균 약 12% 향상을 보고한 동시기 연구로, PAL이 미뤄두었던 금융 특화 평가를 담고 있습니다.
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen 등, EMNLP 2021) — PoT 금융 평가의 기초가 된 벤치마크입니다. 실제로 무엇이 테스트되는지 이해하면 실제 Beancount 사용 사례로의 전이 가능성을 가늠할 수 있습니다.
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan 등, arXiv:2303.17651) — PAL과 제1저자가 동일하며, 코드 생성 통찰력을 반복적인 자가 수정 루프로 확장합니다. PAL 스타일의 에이전트가 자신의 코드 생성 실패를 복구할 수 있는지와 관련이 있습니다.