← all posts
AI 2026.05.05 · 14 min read Advanced

프롬프트는 어떻게 추론을 만드는가

Zero-shot 트리거 한 줄부터 코드 실행, 자동 최적화까지 — LLM 추론을 elicit하는 다섯 가지 기법의 메커니즘과 트레이드오프를 추적한다.

📚 Llm Reasoning Deep Dive 2 / 7
  1. 01 LLM Reasoning의 모든 기법은 하나의 질문에서 나온다
  2. 02 프롬프트는 어떻게 추론을 만드는가
  3. 03 LLM이 나무를 타고 답을 찾는 법
  4. 04 PRM은 왜 ORM을 이기는가 — Step-Level Reward의 수학
  5. 05 GRPO는 어떻게 PPO의 Critic을 없앴는가
  6. 06 LLM Agent는 어떻게 도구를 쓰고, 실패에서 배우고, 함께 생각하는가
  7. 07 LLM Reasoning의 세 가지 도약 — o1, o3, R1이 만든 새 균형점

“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%를 달성한다. 왜인가?

명제 1 · Demonstration의 dominant signal

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 모델에서 두 방법의 효과가 수렴한다. □\square

∎

그러나 이 결론에는 조건이 있다. Kojima 2022 Table 6에서 PaLM 8B는 zero-shot 트리거로 거의 이득이 없고, 62B부터 의미 있는 향상이 나타난다. 트리거는 추론 능력을 만들지 않는다. 이미 latent하게 존재하는 능력을 elicit할 뿐이다.

단일 체인의 한계 — 분해로의 전환

CoT가 단일 시퀀스로 추론을 생성한다는 사실 자체가 약점을 만든다. 100단계 문제에서 초반 오류는 후반에 증폭되고, 긴 chain의 후반부는 초반부를 제대로 attend하기 어렵다.

Least-to-Most Prompting(Zhou 2023)은 이를 explicit 분해로 해결한다.

yi∼π(⋅∣xi, {(xj,yj)}j<i),y=yny_i \sim \pi(\cdot \mid x_i,\, \{(x_j, y_j)\}_{j < i}), \quad y = y_n

각 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 루프를 반복한다.

yt=R(yt−1, C(yt−1))  →t→∞  y∗— fixed point, possibly sub-optimaly_t = R(y_{t-1},\, C(y_{t-1})) \;\xrightarrow{t \to \infty}\; y^* \quad \text{— fixed point, possibly sub-optimal}

열린 태스크(대화, 작문, 코드 최적화)에서는 효과가 크다. Sentiment Reversal에서 8.8% → 30.4%, Dialogue Response에서 36.4% → 63.6%. 그러나 GSM8K에서는 75.0% → 75.7%, 통계적 노이즈 수준이다.

이유는 자명하다. 같은 가중치 θ\theta를 가진 모델은 같은 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로 제공하며 더 높은 점수를 내는 프롬프트를 요청하는 과정을 반복한다.

p∗  =  arg⁡max⁡p  Ex∼T[Acc(π(⋅∣p⊕x))]p^* \;=\; \arg\max_p \;\mathbb{E}_{x \sim \mathcal{T}}[\mathrm{Acc}(\pi(\cdot \mid p \oplus x))]

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에 실행을 위임한다.

z∼π(⋅∣x, τcode),y=exec(z)z \sim \pi(\cdot \mid x,\, \tau_{\text{code}}), \quad y = \text{exec}(z)

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) 패러다임의 직접적인 선행이다.

⚠ PAL의 전제조건

코드로 표현 불가능한 추론 — 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의 탐색 패러다임과 어떻게 다른지 추적한다.

REF
Kojima et al. · 2022 · Large Language Models are Zero-Shot Reasoners · NeurIPS
REF
Gao et al. · 2023 · PAL: Program-Aided Language Models · ICML
# llm # chain-of-thought # prompting # reasoning # program-aided