■ CoT는 language model을 사용해 reasoning과 computation을 설명하는 text를 생성하고, 마지막으로 question에 대한 answer를 생성한다.
■ 논문에서 제안하는 Program of Thoughts (PoT)는 language model(mainly Codex)을 사용해 text와 programming language statement를 생성하고, 마지막으로 answer를 생성한다.
■ PoT에서는 computation을 program interpreter에게 맡길 수 있다. 이 interpreter는 생성된 program을 실행하는 데 사용되며, 이를 통해 복잡한 computation을 reasoning 및 language understanding으로부터 분리한다.
■ 이러한 PoT는 논문의 실험에서 CoT보다 평균적으로 약 12%의 성능 향상을 달성했으며, PoT를 self-consistency decoding과 결합했을 때, 모든 math dataset과 financial dataset에서 매우 강한 성능을 달성했다.
Program of Thoughts Prompting: Disentangling Computation from Reasoning for Numerical Reasoning Tasks
Recently, there has been significant progress in teaching language models to perform step-by-step reasoning to solve complex numerical reasoning tasks. Chain-of-thoughts prompting (CoT) is by far the state-of-art method for these tasks. CoT uses language m
arxiv.org
1. Introduction
■ numerical reasoning은 인공지능에서 오래전부터 다루어져 온 task이며, 최근에는 deep-learning model이 numerical/arithmetic reasoning을 수행하는 능력을 벤치마킹하기 위해 많은 dataset들이 제안되었다.
■ 널리 사용되는 벤치마크들 중 일부는 Math word problems (MWP)이며, MVP 외에도 수학적 계산이 요구되는 금융 관련 questions에 답해야 하는 financial problems을 다루는 데이터셋도 있다.
■ 이전 연구들은 final answer를 도출하기 위해 intermediate steps를 생성하도록 모델을 처음부터 학습시키거나 fine-tune하는 방법을 연구해 왔다.
■ 이러한 방법들은 많은 학습 데이터가 필요하며, 특히 전문가가 annotation한 step이 포함된 많은 수의 training examples을 필요로 한다.
■ 최근의 연구는 LLM이 few input-output exemplars을 프롬프트로 제공받아도, 별도의 training이나 fine-tuning 없이 이러한 tasks을 해결할 수 있음을 보여주었다.
■ 특히 input, 자연어로 구성된 rationales, 그리고 output이 포함된 몇 개의 examples을 프롬프트로 주면, LLM은 그 demonstrations을 모방하여 rationales을 생성하고 질문에 답할 수 있다.
■ 이러한 프롬프팅 방법은 CoT로 확장되었고, intermediate reasoning steps 생성을 통해 다양한 textual 및 numerical reasoning dataset에서 SOTA 성능을 달성할 수 있었다.
■ CoT는 reasoning과 computation 모두에 LLM을 사용한다. 즉 language model은 mathematical expression을 생성해야 할 뿐만 아니라, 각 step에서 실제 computation도 수행해야 한다.
■ 그러나 PoT 저자들은 language model이 mathematical expression을 푸는 데 이상적이지 않다고 주장한다. 그 이유는 세 가지이다.
- (1) LLM은 특히 큰 숫자를 다룰 때 산술적 계산 오류를 매우 잘 일으킨다.
- (2) LLM은 다항 방정식이나 미분 방정식과 같은 복잡한 mathematical expressions을 풀 수 없다.
- (3) LLM은 iteration 과정을 표현하는 데 매우 비효율적이며, 특히 반복 횟수가 많을수록 그렇다.
- 즉, LLM은 특정 부분에 있어 "계산 자체"를 수행하는 도구로는 부정확하고 비효율적이다.
■ 논문에서는 이러한 문제들을 해결하기 위한 방법으로 program-of-thoughts (PoT) prompting을 제안한다. 이 방법은 computation step을 외부 language interpreter에게 맡긴다.
■ PoT에서 LM은 reasoning step을 Python program으로 표현하며, 실제 computation은 Python interpreter에 의해 수행된다. 이러한 PoT와 CoT의 차이는 Fig 1과 같다.
■ 위의 예시에서 CoT는 iteration을 50번 수행하며, 결과적으로 매우 낮은 accuracy로 이어진다. CoT에서 LM만으로 cubic equation을 풀지 못하고 잘못된 답을 출력함을 볼 수 있다.
■ 반대로 PoT는 iteration 과정을 몇 줄의 코드로 표현할 수 있고, 이 코드는 Python interpreter에서 실행되어 정확한 답을 도출할 수 있다. 이 예시에서 PoT는 Python의 SymPy 라이브러리를 통해 복잡한 방정식을 해결한다.
■ 저자들은 다섯 개의 MWP dataset인 GSM8K, AQuA, SVAMP, TabMWP, MultiArith와 세 개의 financial dataset인 FinQA, ConvFinQA, TATQA에서 PoT prompting을 평가한다.
■ 이 dataset들은 text, table, conversation을 포함한 다양한 input formats을 포함하고 있다. 아래의 Fig 2는 결과에 대한 overview이다.
■ few-shot과 zero-shot setting 모두에서, PoT는 평가된 모든 dataset에 걸쳐 CoT를 유의미하게 능가한다. few-shot setting에서 PoT는 CoT보다 MWP dataset에서는 평균 약 8%, financial dataset에서는 평균 약 15%의 성능 향상을 보인다. zero-shot setting에서 PoT는 MWP dataset에서 CoT보다 평균 약 12%의 성능 향상을 보인다.
■ PoT에 self-consistency (SC)를 결합한 방법도 모든 dataset에 걸쳐 CoT+SC보다 평균 10% 높은 성능을 보인다. PoT+SC는 평가된 모든 MWP dataset에서 best-known result를 달성하고, GPT-4를 제외하면 financial dataset에서도 best-known에 가까운 결과를 달성한다.
2. Program of Thoughts
2.1 Preliminaries
■ In-context learning은 fine-tuning과 비교했을 때, (1) few annotations/demonstrations만 프롬프트로 사용하고 (2) 모델 파라미터를 학습하지 않은 채 inference를 수행한다.
■ In-context learning에서는 LLM이 input-output exemplar들을 prefix로 받은 뒤, 그 뒤에 input problem이 주어지고, 모델은 exemplar들을 모방하여 output을 생성한다.
■ 이후 등장한 CoT prompting은 in-context learning의 specific type으로, CoT에서는 exemplar의 output이 단순한 output만 포함하는 것이 아니라 "thought process" 또는 rationale을 포함한다.
■ 이러한 CoT는 다양한 종류의 tasks에서 LLM의 강한 reasoning capability를 이끌어낼 수 있음을 보여주었다.
2.2 Program of Thoughts
■ CoT처럼 자연어 외에도, 프로그램 역시 사고 과정을 표현하는 데 사용될 수 있다. 의미적으로 유의미한 변수 이름을 사용함으로써, 프로그램은 사람의 생각을 전달하는 자연스러운 표현 수단이 될 수 있다.
■ 예를 들어 Fig 1의 하단 예시을 보면, 먼저 interest_rate라는 이름의 변수를 생성한다. 그런 다음, "interest rate가 적용된 2년 후의 총합"이라는 의미를 sum_in_two_years_with_XXX_interest라는 변수에 연결하고, 이 변수들과 interest_rate 사이의 수학적 관계를 나타내는 equation을 작성한다.
■ 이 equation들은 SymPy가 제공하는 solve 함수 안에 담긴다: ans = solve(..., ...)
■ 이 프로그램은 Python으로 실행되어 equation들을 풀고, 정답 변수인 interest_rate를 도출한다.
■ CoT는 LLM을 사용해 reasoning과 computation을 모두 수행하려고 한다.
■ 반대로 PoT는 CoT와 달리, 일부 computation 과정을 외부 process (Python interpreter)에게 넘긴다. 여기서 LLM은 reasoning process를 programming language로 표현하는 것만 담당한다.
■ 저자들은 이러한 PoT 방식이 numerical reasoning 측면에서 더 표현력이 높고 정확하다고 주장한다.
■ "program of thoughts"은 equations을 직접 생성하는 것과 다르다. 직접 equation을 생성하는 방식에서는 "solve(20000*(1+x)^3−2000−x*20000*3−1000,x)"와 같은 형태가 생성될 것이다.
■ CoT 논문의 관찰에서는, 이런 equation을 직접 생성하는 것은 LLM에게 어려운 문제이다.
■ PoT는 다음 두 가지 측면에서 equation generation과 다르다.
- (1) PoT는 equation을 여러 단계의 'thought' process로 분해한다.
- (2) PoT는 변수에 semantic meanings을 연결하여 모델이 언어에 grounding되도록 돕는다. 예를 들어, 단순한 변수명 "a"보다 "sum_after_three_years_with_compound_interest"은 훨씬 더 풍부한 의미를 담고 있다.
■ 저자들은 이러한 종류의 thoughtful process가 language model의 reasoning capability를 이끌어내고, 더 정확한 프로그램을 생성하게 할 수 있음을 발견했다.
■ Fig 3은 few-shot과 zero-shot setting에서의 PoT prompting 방법을 보여준다.
■ few-shot setting에서는 몇 개의 (question, program of thoughts) 쌍이 demonstration으로서 prompt 앞부분에 붙어(즉, prefix), LLM이 'thoughtful' program을 생성하는 법을 배우도록 한다.
■ zero-shot setting에서는 prompt에 exemplar demonstration 없이 instruction만 포함한다.
■ zero-shot CoT는 'chain of thoughts'에서 answer를 추출하기 위한 과정이 필요하지만, zero-shot PoT는 추가 step 없이 answer를 직접 반환할 수 있다.
■ zero-shot PoT에서 한 가지 주의점은 LLM이 프로그램 코드를 짜는 대신, reasoning chain을 comment로 생성할 수 있다는 것이다. 예: # First, we need to find the total number of apples. # Then, we subtract the number sold.
■ 이에 저자들은 모델이 프로그램을 생성하도록 유도하기 위해 '#' token의 logit을 억제할 것을 제안한다.
2.3 PoT as an Intermediate Step
■ 추가적인 textual reasoning이 필요한 특정 문제들(예: 선택지 형식에 맞추기)에 대해서, 저자들은 계산 부분을 처리하기 위해 PoT를 활용할 것을 제안한다.
■ PoT가 생성한 program은 실행되어 intermediate result를 제공할 수 있고, 이 intermediate result는 question과 다시 결합되어 CoT를 통해 final answer를 도출하는 데 사용된다 (Fig 8): question+PoT intermediate result→CoT reasoning→final answer
■ demonstration에 LLM에게 examples을 제시하여 추가적인 CoT reasoning이 사용되어야 하는지 예측하도록 가르친다.
■ 만약 LLM이 마지막에 "keep prompting"을 출력하면, PoT로부터 얻은 파이썬 실행 결과를 input으로 사용하여 LLM을 다시 prompt하고, CoT를 통해 answer를 도출하게 한다.
■ 예를 들어 Fig 3의 left에서, program은 실행되어 float number인 ans=2.05를 반환하는데, 이는 두 기차가 2.05시간 후에 만난다는 의미이다.
■ 그러나 2.05를 11 AM에 그대로 더하는 것은 말이 되지 않는다. 왜냐하면 2.05시간은 multi-choice question의 제공된 선택지 형식과 일치하는 표준 HH:MM 시간 형식으로 맞추기 위해 minute 단위로 변환되어야 하기 때문이다.
■ 이러한 프롬프팅 전략은 논문에서 다루는 벤치마크 중 AQuA에만 필요하다. 왜냐하면 다른 dataset들은 모두 PoT-only prompting으로 해결될 수 있기 때문이다.
3. Experiments
3.1 Experimental Setup
Datasets
■ Table 1은 평가에 사용한 datasets이며, 다양한 input formats을 가진다. PoT prompting의 generalizability와 applicability를 확인하기 위해, 이렇게 넓은 범위의 dataset에서 실험을 수행한다.
■ 이처럼 다양한 inputs을 수용하기 위한 방법으로, 저자들은 프롬프트 내에서 이러한 inputs을 linearize할 것을 제안한다.
■ input format이 table인 경우, 저자들은 이전 연구와 같은 전략을 사용하여 table을 text string으로 linearize한다: table의 열은 '|' 기호로 구분하고 행은 '\n' (즉, 줄바꿈)으로 구분한다. 표의 셀이 비어 있는 경우 '-' 기호로 채운다.
예:
Year | Revenue | Cost
2020 | 100 | -
2021 | 120 | 80■ text와 table이 함께 있는 hybrid inputs의 경우, text와 table을 '\n'으로 구분한다. conversational history의 경우에도, 대화 turns을 '\n'으로 구분한다.
■ prompt는 task instruction, text, linearized table, question을 concatenate하여 구성된다.
■ conversational question answering의 경우 모든 dialog history를 prompt에 단순히 순서대로 concatenate한다.
Implementation Details
■ 저자들은 실험에서 주로 OpenAI Codex (code-davinci-002) API를 사용한다. ablation experiment를 위해 GPT-3 (text-davinci-002), ChatGPT (gpt-turbo-3.5), CodeGen, CodeT5+, Xgen도 테스트했다.
■ 생성된 program을 실행하기 위해 Python 3.8과 SymPy library를 사용한다
■ few-shot setting에서는 dataset의 난이도에 따라 모든 dataset에 대해 4–8개의 shot을 사용한다.
■ FinQA처럼 단순한 dataset에는 더 적은 shot을 사용하고, AQuA와 TATQA처럼 더 어려운 dataset에는 더 다양한 문제를 포괄하기 위해 8-shot을 사용한다. few-shot에 사용하는 examples은 training set에서 가져온다.
■ 저자들은 10–20개의 example에 대한 prompt를 작성한 뒤, 작은 validation set에서 exemplar selection을 통해 전체 평가에 사용할 최적의 4-8 shot을 선택했다.
■ 또한, zero-shot에서 LLM의 multi-step reasoning 능력을 이끌어내기 위해, 저자들은 demonstration 없이도 LLM이 reasonable program을 생성하도록 유도하는 prompt를 찾았다. 이에 대한 prompt는 Figure 3에 제시되어 있다.
■ PoT에서 한 가지 주의점은, LLM이 program 자체를 생성하는 대신 comment 안에 reasoning chain을 생성할 수 있다는 것이다.
■ 저자들은 이런 경우를 피하기 위해 '#' token의 logit을 작은 bias로 설정하여 `#` token이 생성될 확률을 낮췄다. preliminary study 결과, bias를 -2로 설정하는 것이 가장 좋은 결과를 냈으며, 이 간단한 전략이 성능을 크게 향상시킬 수 있음을 발견했다.
Metrics
■ GSM8K, SVAMP, MultiArith dataset에 대해 exact match score를 평가 지표로 사용한다. 이때 predicted number를 특정 precision으로 반올림한 뒤, reference number와 비교한다.
■ AQuA dataset의 경우, PoT를 사용해 intermediate answer를 계산한 뒤, LLM을 다시 prompt하여 가장 가까운 option을 출력하게 하고, 이를 통해 accuracy를 측정한다.
■ TabMWP, ConvFinQA, TATQA dataset의 경우, GitHub에 제공된 official evaluation script를 사용한다.
■ FinQA의 경우, LLM이 computation을 정밀하게 수행하지 못하기 때문에(특히 high-precision floats, large numbers), CoT에 대한 평가를 완화한다. 그래서 답을 비교할 때 relative tolerance 0.001을 가진 파이썬의 math.isclose를 사용한다.
Baselines
■ Codex, GPT-3, PaLM, LaMDA를 포함한 여러 모델을 사용한다.
■ 출력 방식으로는 direct answer output과 chain-of-thought를 통한 answer derivation이라는 두 가지 prediction strategy를 고려한다.
■ PaLM API는 public하지 않기 때문에, 기존 연구에서 보고된 PaLM 결과만 제시한다.
■ 추가로, CoT 논문에서 제안한 것처럼, CoT가 생성한 모든 equations에 대해 external calculator도 활용하며, 이를 CoT + calc라고 부른다.
■ greedy decoding 외에도 CoT에 self-consistency를 사용한다. 40개의 서로 다른 completion에 대해 majority vote를 수행하여 prediction을 도출한다.
3.2 Main Results
Few-shot Results
■ MWP dataset에서, greedy decoding을 사용한 PoT는 GSM8K, AQuA, TabMWP에서 8% 이상 성능을 향상시킨다. SVAMP에서는 성능 향상이 4%인데, 이는 SVAMP의 문제가 단순하기 때문이다.
■ financial QA datasets에서는 PoT가 CoT보다 FinQA와 ConvFinQA에서 대략 20%, TATQA에서 8% 향상된다.
■ FinQA와 ConvFinQA에서 더 큰 성능 향상이 나타나는 이유는, LLM이 수백만 단위 같은 큰 수를 다룰 때 계산 오류를 일으키기 때문이다.
■ CoT는 LLM이 computation을 수행하도록 하는데, 이는 계산 오류에 매우 취약하다. 반면 PoT는 매우 정밀한 external computer를 사용해 문제를 해결한다.
■ ablation으로, CoT+calc와도 비교한다. CoT+calc는 생성된 chain of thoughts 안의 계산 결과를 보정하기 위해 external calculator를 활용한다.
■ 실험 결과, external calculator를 추가하는 것은 MWP dataset에서 CoT보다 약간의 개선만 보였고, PoT에는 크게 뒤처졌다.
■ 'calculator' 방식의 성능이 낮은 이유는 유연하지 않은 post-processing step 때문이며, 이는 계산 결과를 보정하는 데 낮은 recall을 초래할 수 있다.
Few-shot + Self-Consistency Results
■ 저자들은 자신들의 방법의 upper bound를 확인하기 위해, self-consistency (SC) decoding을 활용한다. 이 sampling-based decoding algorithm은 generation procedure의 randomness를 크게 줄이고 성능을 향상시킬 수 있다.
■ 구체적으로, 저자들은 모든 실험에서 temperature를 0.4, \( K = 40 \)으로 설정한다.
■ Table 2를 보면, PoT+SC는 MWP dataset에서 여전히 CoT+SC를 눈에 띄는 차이로 능가한다.
■ financial datasets에서는 self-consistency decoding이 PoT와 CoT 모두에 대해 영향력이 다소 적은 것을 볼 수 있다. PoT+SC는 CoT+SC보다 FinQA와 ConvFinQA에서 대략 20%, TATQA에서 7% 더 높은 성능을 보인다.
Zero-shot Results
■ Table 3에서 볼 수 있듯이, zero-shot PoT는 평가된 모든 MWP dataset에서 zero-shot CoT를 크게 능가한다. few-shot prompting과 비교했을 때, zero-shot PoT는 zero-shot CoT를 훨씬 더 큰 차이로 능가한다.
■ 평가된 dataset들에서 PoT는 CoT보다 평균 12% 더 높은 성능을 보인다.
■ 이 결과들은 dataset-specific exemplar가 전혀 없어도, 많은 unseen numerical task에 직접 generalize할 수 있는 가능성을 보여준다.
3.3 Ablation Studies
■ backbone models, prompt engineering 등 PoT를 구성하는 다양한 요소들의 중요성을 확인하기 위해 few-shot setting에서 여러 번의 ablation studies을 수행한다.
Backend Ablation
■ PoT가 서로 다른 backbone model에서 어떤 성능을 보이는지 확인하기 위해 text-davinci-002, code-davinci-002, gpt-3.5-turbo, codegen-16B-mono, codegen-16B-multi, CodeT5+, XGen의 성능을 비교한다.
■ Table 4에서 볼 수 있듯이, gpt-3.5-turbo가 가장 높은 점수를 달성하며, Codex인 code-davinci-002를 상당한 차이로 능가한다.
■ 반대로 text-davinci-002는 code-davinci-002보다 약한데, 이는 주로 이후의 text-based instruction tuning이 모델의 code generation 능력을 약화시켰기 때문이라고 저자들은 본다.
■ CodeGen 같은 open-source model이 여러 benchmark 전반에서 상당히 뒤처지는데, 저자들은 이러한 큰 격차가 불충분한 pre-training과 model size 때문일 수 있다고 추측한다.
Sensitivity to Exemplars
■ PoT가 서로 다른 exemplars에 얼마나 민감한지 확인하기 위해 sensitivity analysis를 수행한다.
■ 구체적으로, 저자들은 총 20개의 exemplar를 작성했다. 그리고 \( k \)-shot learning을 위해, 20개의 exemplars 중에서 \( k = (2, 4, 6, 8) \)개를 v1, v2, v3라는 이름으로 세 번 랜덤 샘플링합니다.
■ 이렇게 무작위로 샘플링한 exemplar들을 PoT의 demonstration으로 사용한다. sensitivity analysis 결과는 Figure 5에서 볼 수 있다.
■ shot 수를 늘리는 것이 FinQA보다 GSM8K에서 더 큰 도움이 된다. 이는 GSM8K의 question들이 다양하기 때문이다. 더 많은 exemplar를 추가하면, language model은 다양한 question에 더 잘 generalize할 수 있다.
■ 또 다른 관찰 결과는 주어지는 exemplars의 수가 적을 때 PoT의 성능 분산이 더 크다는 것이다. \( K = 2 \)일 때, 두 dataset 모두에서 성능 분산이 최대 7%까지 커질 수 있다.
- 즉 2-shot처럼 예시가 적으면, 어떤 예시를 골랐느냐에 따라 성능이 크게 달라진다.
■ 더 많은 exemplar를 사용하면 성능이 더 안정적이 된다.
Comparison with PaL
■ PoT를 PaL과 비교한다. Table 5를 보면, PoT가 전반적으로 PaL보다 더 좋고, 특히 SVAMP와 ASDIV에서 더 좋다는 것을 볼 수 있다.
Semantic Binding and Multi-Step Reasoning
■ PoT의 두 가지 핵심은 (1) multiple steps: thought process를 step-by-step program으로 분해하는 것 (2) semantic binding: variable name에 semantic meaning을 연결하는 것이다.
■ 이 두 특성이 어떻게 기여하는지 확인하기 위해, 저자들은 두 가지 variant와 비교했다.
■ 하나의 variant는 semantic binding을 제거하고, 단순히 a, b, c를 변수명(즉, 무의미한 변수명)으로 사용하는 것이다. 다른 variant는 (1)과 반대로 결과를 계산하기 위한 최종 mathematical equation을 directly하게 예측하는 것이다.
■ Table 6에서 볼 수 있듯이, binding을 제거하면 일반적으로 모델 성능이 저하된다. GSM8K처럼 더 많은 변수를 포함하는 복잡한 question에서는 성능 하락이 더 크다.
■ 마찬가지로, LLM에게 target equation을 직접 생성하게 하는 것도 매우 어렵다. target equation을 여러 reasoning step으로 분해해야 성능 향상에 도움이 된다.
Breakdown Analysis
■ CoT와 PoT의 성능이 어떤 종류의 문제에서 가장 크게 차이 나는지를 판단하기 위한 분석을 수행한다. 이를 위한 testbed로 AQuA를 사용한다.
■ 구체적으로, 저자들은 AQuA의 question들을 geometry, polynomial, symbolic, arithmetic, combinatorics, linear equation, iterative, probability 등 여러 category로 수작업 분류한다.
■ Figure 6은 각 subcategory별 accuracy이다. 주요 category는 (1) linear equation, (2) arithmetic, (3) combinatorics, (4) probability, (5) iterative이다.
■ PoT의 가장 큰 성능 향상은 linear/polynomial equation, iterative, symbolic, combinatorics category에서 나타난다. 이 문제들은 해결하기 위해 더 복잡한 arithmetic 또는 symbolic skill을 필요로 한다.
■ 반대로 arithmetic, probability, geometric question에서는 PoT와 CoT가 비슷한 성능을 보인다. 이러한 관찰은 'program'이 더 어려운 문제에서 더 효과적이라는 저자들의 가정을 반영한다.
Error Analysis
■ 저자들은 다음 두 가지 error type을 고려했다.
- (1) value grounding error: 모델이 question과 관련된 변수들에 올바른 값을 할당하지 못하는 경우
- (2) logic generation error: 모델이 정의된 변수들을 바탕으로 question에 답하기 위한 올바른 computation process를 생성하지 못하는 경우
■ Figure 7은 각 error type의 예시를 보여준다. 위쪽 예시에서, 모델은 변수값을 잘못 가져오지만 computation logic 자체는 올바르다. 아래쪽 예시에서, 모델은 관련 변수들을 올바르게 grounding했지만, question에 답하기 위한 적절한 computation logic을 생성하지 못한다.
■ TAT-QA 결과에서 발생한 error들을 수작업으로 검토한 결과, PoT greedy method가 numerical reasoning question에서 실패한 198개 case 중, 47%는 value grounding error를, 33%는 logic error였다.
■ 그리고 15%에서는 두 가지 유형의 오류가 모두 발생했으며, 5%는 저자들이 보기에 실제로는 정답이 맞다고 생각되는 경우였다.
■ 대부분의 오류가 value grounding error이며, 이는 CoT 같은 다른 방법에서도 공통적으로 나타나는 현상이다.
4. Limitations
■ PoT는 LLM이 생성한 code를 실행해야 하는데, 이 generated code 안에는 import os; os.rmdir() 같은 위험하거나 리스크 있는 code snippet이 포함될 수 있다.
■ 이 문제에 대해 저자들은 LLM이 미리 정의된 module만 사용하도록 하고, 그 외 추가적인 modules을 import하지 못하게 제한했다.
■ 이러한 brute-force blocking은 리스크 있는 module import를 막기 때문에 math QA에서는 어느 정도 합리적으로 작동하지만, 다른 unknown symbolic task에서는 PoT의 generalization을 해칠 수 있다.
■ 또 다른 한계는 PoT가 복잡한 algebraic question을 포함한 AQuA dataset에서 여전히 어려움을 겪으며, accuracy가 58%에 그친다는 점이다.
■ 저자들은 AQuA의 question들이 매우 다양하며, 몇 개의 예시만으로는 그 다양성을 모두 포괄할 수 없었기 때문이라고 언급한다.
