프롬프트는 어떻게 추론을 만드는가
Zero-shot 트리거 한 줄부터 코드 실행, 자동 최적화까지 — LLM 추론을 elicit하는 다섯 가지 기법의 메커니즘과 트레이드오프를 추적한다.
“Let’s think step by step.” 이 여덟 글자가 왜 GSM8K 정확도를 17%에서 78%로 끌어올리는가? 그리고 왜 어떤 모델에서는 아무 효과도 없는가? 프롬프트가 추론을 만드는 방식을 이해하면, 그것이 실패하는 방식도 보인다.
트리거 하나 vs 예제 여덟 개
Wei 2022의 Few-shot CoT와 Kojima 2022의 Zero-shot CoT는 같은 목표를 다른 방식으로 달성한다. Few-shot은 (질문, 추론 과정, 답) 형태의 demonstration k개를 프롬프트에 직접 포함시켜 모델이 그 형식을 따르도록 한다. Zero-shot은 트리거 문장 하나(“Let’s think step by step”)만 붙인다.
놀라운 것은 InstructGPT 기준 결과다. GSM8K에서 8-shot demonstration이 78.0%를 달성하는 동안, 트리거 한 줄이 78.7%를 달성한다. 왜인가?
Few-shot CoT demonstration의 reasoning chain을 무작위로 섞어도 GSM8K 성능 감소가 <5%다. Format 신호(단계적 추론 + “The answer is X”)가 content 신호보다 dominant하다.
Wei 2022 Section 5의 ablation: demonstration의 reasoning chain을 서로 다른 예제의 것으로 교체하면 reasoning content는 완전히 틀리지만 성능 저하는 미미하다. 모델이 demonstration에서 배우는 것은 reasoning의 내용이 아니라 reasoning의 형식이다. Zero-shot 트리거도 같은 형식 신호를 제공하므로, instruction-tuned 모델에서 두 방법의 효과가 수렴한다.
그러나 이 결론에는 조건이 있다. Kojima 2022 Table 6에서 PaLM 8B는 zero-shot 트리거로 거의 이득이 없고, 62B부터 의미 있는 향상이 나타난다. 트리거는 추론 능력을 만들지 않는다. 이미 latent하게 존재하는 능력을 elicit할 뿐이다.
단일 체인의 한계 — 분해로의 전환
CoT가 단일 시퀀스로 추론을 생성한다는 사실 자체가 약점을 만든다. 100단계 문제에서 초반 오류는 후반에 증폭되고, 긴 chain의 후반부는 초반부를 제대로 attend하기 어렵다.
Least-to-Most Prompting(Zhou 2023)은 이를 explicit 분해로 해결한다.
각 sub-problem의 답이 다음 sub-problem의 입력이 된다. SCAN compositional generalization 벤치마크에서 결과가 극적이다 — standard prompting 16%, CoT 35%에서 Least-to-Most 99%로. 도약의 메커니즘은 단순하다: 훈련 데이터에 없던 길이의 명령(OOD length)을 훈련 분포 안의 짧은 sub-problem들의 시퀀스로 환원하기 때문이다.
Plan-and-Solve(Wang 2023)는 다른 방향을 취한다. 먼저 flat plan을 생성하고(“Let’s first understand the problem and devise a plan”), 그 plan을 따라 실행한다. GSM8K에서 Calculation error가 7%에서 2%로, Missing step이 12%에서 6%로 줄어든다. 명시적 plan이 모델이 어떤 단계를 빠뜨렸는지 스스로 확인하게 만든다.
Least-to-Most는 sub-problem 수만큼 forward pass가 필요하고(O(n)), 순서 의존성이 강해 병렬화가 어렵다. Plan-and-Solve는 2 pass(O(2))로 끝나지만 작은 모델에서 plan을 생성 후 무시하는 현상이 나타난다. 두 방법 모두 단일 CoT보다 비용이 높다.
자기 비판의 한계
Self-Refine(Madaan 2023)은 generate → critique → refine 루프를 반복한다.
열린 태스크(대화, 작문, 코드 최적화)에서는 효과가 크다. Sentiment Reversal에서 8.8% → 30.4%, Dialogue Response에서 36.4% → 63.6%. 그러나 GSM8K에서는 75.0% → 75.7%, 통계적 노이즈 수준이다.
이유는 자명하다. 같은 가중치 를 가진 모델은 같은 systematic bias를 공유한다. Generator가 hallucinate한 사실을 critic도 그럴듯하다고 받아들인다. Huang 2023은 이를 정량화했다: GPT-3.5에서 intrinsic self-correction이 오히려 성능을 저하시킨다(75.9% → 74.7%). Oracle feedback이 있을 때만 84.3%로 향상된다.
프롬프트를 최적화하는 프롬프트
APE(Zhou 2023)와 OPRO(Yang 2024)는 한 단계 더 나아간다. LLM이 LLM의 프롬프트를 최적화한다.
APE는 (입력, 출력) demonstration들로부터 K개의 프롬프트 후보를 생성하고 held-out set에서 점수를 매겨 최선을 선택한다. BIG-Bench Hard 24개 태스크 평균에서 human-designed CoT 39%를 auto-generated 프롬프트 45%가 앞선다.
OPRO는 이전 프롬프트들과 그 점수를 history로 제공하며 더 높은 점수를 내는 프롬프트를 요청하는 과정을 반복한다.
OPRO가 GSM8K에서 발견한 최적 프롬프트는 “Take a deep breath and work on this problem step-by-step”이다. “Let’s think step by step” 대비 +2.2%. “Take a deep breath” 같은 의인화 지시어가 왜 효과적인지는 이론적으로 불명확하다 — pretraining corpus에서 신중한 추론과 공기하는 표현일 가능성이 가장 유력한 가설이다.
두 방법의 공통 한계는 capability ceiling이다. 최적화 LLM 자체의 능력보다 좋은 프롬프트는 만들 수 없고, 특정 태스크에 최적화된 프롬프트가 다른 태스크로 잘 전이되지 않는다.
코드로 추론을 위임하다
PAL(Gao 2023)은 CoT의 가장 큰 약점인 산술 오류를 다른 방식으로 해결한다. 추론을 Python 코드로 표현하고 interpreter에 실행을 위임한다.
Codex 기준 GSM8K에서 CoT 65.6%가 PAL 72.0%로 향상된다. 더 중요한 숫자는 error 분류다: CoT의 calculation error 30%가 PAL에서 0%가 된다. Interpreter는 결정론적이기 때문이다.
# CoT: LLM이 직접 계산 (오류 가능)
# "3 rows × 17 trees = 51 trees."
# PAL: LLM은 논리만, 숫자는 interpreter가
rows = 3
trees_per_row = 17
answer = rows * trees_per_row # exec() → 51
PAL의 ablation 결과 하나가 흥미롭다: interpreter 없이 PAL 코드만 자연어로 평가해도 CoT보다 약간 정확하다. 명시적 변수 할당이 reasoning chain 자체를 더 체계적으로 만들기 때문이다.
PoT(Program of Thoughts)는 sympy, numpy 같은 라이브러리까지 허용해 적분, 방정식, 통계 계산으로 범위를 확장한다. 이는 이후 Toolformer와 ReAct의 일반적인 도구 사용(tool use) 패러다임의 직접적인 선행이다.
코드로 표현 불가능한 추론 — commonsense reasoning, 창의적 글쓰기, 주관적 평가 — 에는 PAL이 적합하지 않다. 코드 생성 자체가 작은 모델에서 실패하고, exec()는 반드시 sandboxing이 필요하다.
정리
다섯 기법은 같은 질문에 대한 다섯 가지 답이다: 모델의 latent 추론 능력을 어떻게 끌어낼 것인가.
- Zero-shot CoT는 트리거 하나로 instruction-tuned 큰 모델의 형식 능력을 elicit한다. 작은 모델에서는 elicit할 능력 자체가 없다.
- Decomposition은 긴 chain의 오류 누적을 sub-problem의 독립적 해결로 환원한다. 조합 일반화와 계산 정확도가 동시에 향상된다.
- Self-Refine은 열린 태스크에서 강하지만 검증 가능한 태스크에서 self-blindspot으로 막힌다. External verifier 없이는 이론적 ceiling이 존재한다.
- APE/OPRO는 manual prompt engineering을 자동화하지만, 최적화 모델 자체의 능력이 ceiling이다.
- PAL/PoT는 arithmetic을 interpreter에 위임해 계산 오류를 구조적으로 제거한다.
모든 기법은 inference compute를 어떻게 쓸 것인가의 다른 답이다. 다음 글에서는 이 단일 경로 접근들이 Tree of Thoughts의 탐색 패러다임과 어떻게 다른지 추적한다.