Field Log · Entry

Chain-of-Thought 입문: LLM 추론문과 실제 근거 구분하기 (1/10)

질문에서 여러 중간 추론 token을 거쳐 답을 만들되 추론문과 인과적 증명을 구분하고 외부 증거와 도구로 검증하는 구조

오늘의 결론

Chain-of-Thought(CoT)는 최종 답 전에 중간 text token을 생성해 사용할 계산 공간을 늘리는 prompting 방식입니다. 모델 내부의 모든 계산을 투명하게 보여 주는 장치가 아닙니다.

**정답성(correctness), 그럴듯함(plausibility), 충실성(faithfulness)**은 서로 다른 속성입니다. 답이 맞아도 설명이 실제 결정 원인을 반영하지 않을 수 있고, 설명이 매끄러워도 답은 틀릴 수 있습니다.

CoT의 효과는 task·model·prompt·sampling에 따라 달라집니다. 간단한 조회에는 불필요한 지연과 오류 경로를 늘릴 수 있으므로 direct answer와 같은 평가셋에서 비교해야 합니다.

Production RAG Agent의 감사 기록은 자유 형식의 “생각”이 아니라 사용한 근거, tool argument·result, state transition, verifier 결과로 구성합니다.

고위험 답은 CoT 자체로 신뢰하지 않습니다. 계산기·코드 실행·retrieval evidence·rule engine·human escalation처럼 task에 맞는 외부 검증을 둡니다.

앞 글에서는 RAG Agent에 맞는 model을 평가하고 canary·rollback으로 배포했습니다. 이제 그 model이 어려운 질문에 답할 때 왜 중간 추론문을 쓰며, 그 text를 어디까지 신뢰할 수 있는지 살펴봅니다.

question x
  ├─ direct decoding ─────────────────────→ answer y
  └─ reasoning tokens z₁, z₂, ... zₘ ────→ answer y

production trust
  ≠ "reasoning text looks convincing"
  = answer check + evidence + tool result + policy-verifiable trace

질문을 direct answer와 중간 reasoning token 경로로 나누고 정답성 설득력 충실성을 별도 축으로 평가한 뒤 RAG evidence와 tool result를 외부 verifier로 확인하는 구조

그림 1. CoT는 답까지의 token 경로를 늘리지만 그 경로가 실제 인과적 계산의 완전한 공개라는 뜻은 아니다. 운영 신뢰성은 관측 가능한 evidence·action·result를 독립적으로 검증해 만든다.

Reasoning Task부터 구분한다

모든 질문이 같은 종류의 추론을 요구하지 않습니다.

유형	예시	주된 병목
사실 조회	“문서의 환불 기한은?”	올바른 근거 검색
산술	“12개 중 1/3을 제외하고 5개 추가하면?”	단계별 계산
제약 만족	“예산·지역·시간을 모두 만족하는 일정”	여러 조건 유지
다중 근거 결합	두 정책 문서에서 적용 범위와 예외 결합	evidence 연결
계획	목표를 tool action 순서로 분해	상태·실패·부작용 관리
판단	상충하는 근거 아래 위험도 평가	불확실성·정책·가치 판단

사실 조회가 실패했다면 더 긴 CoT보다 retrieval을 고쳐야 할 수 있습니다. 반대로 근거는 모두 있지만 여러 숫자와 조건을 결합하지 못했다면 중간 계산이나 tool plan이 도움이 될 수 있습니다.

따라서 먼저 실패를 다음처럼 분해합니다.

knowledge missing?
retrieval missing?
instruction misunderstood?
multi-step computation failed?
tool execution failed?
verification or policy failed?

“Reasoning model을 쓰자”는 이 분해 뒤에 나오는 처방이지 진단 자체가 아닙니다.

Autoregressive Model은 다음 Token을 예측한다

Decoder LLM은 입력 x가 주어졌을 때 출력 token sequence의 확률을 왼쪽에서 오른쪽으로 분해합니다.

p(y₁, ..., yₙ | x)
  = ∏ᵢ p(yᵢ | x, y₁, ..., yᵢ₋₁)

Direct answer는 곧바로 답 token을 생성합니다.

x = "12개 문서 중 1/3은 폐기하고 5개를 추가했다. 몇 개인가?"
y = "13개"

CoT는 답 앞에 중간 sequence z를 생성합니다.

z = "12의 1/3은 4. 12 - 4 = 8. 8 + 5 = 13."
y = "정답: 13개"

p(z, y | x) = p(z | x) · p(y | x, z)

뒤 token은 앞에서 생성된 중간 token을 다시 attention context로 읽습니다. 그래서 복잡한 계산을 한 번에 압축하는 대신 부분 문제, 임시 값, 조건을 text에 적어 다음 단계가 재사용하게 할 수 있습니다.

여기서 중요한 경계가 있습니다.

z는 모델이 출력한 관측 가능한 text입니다.
모델 내부 layer의 activation, attention, feature 계산 전체가 z로 복사되는 것은 아닙니다.
한 번 sample한 z가 유일한 reasoning path라는 보장도 없습니다.
읽기 좋은 z가 실제 답을 만든 인과적 이유와 일치한다는 보장도 없습니다.

CoT를 latent variable처럼 직관화해 여러 경로를 생각할 수는 있습니다.

p(y | x) = Σ_z p(z | x) · p(y | x, z)

하지만 실제 decoding은 가능한 모든 z를 정확히 합산하지 않습니다. 한 경로를 greedy하게 만들거나 몇 개를 sampling해 근사합니다. 이 차이가 self-consistency와 test-time compute의 출발점입니다.

Chain-of-Thought Prompting의 네 가지 형태

1. Few-shot CoT

질문과 중간 단계, 정답을 함께 예시로 제공합니다.

문제: 상자에 사과가 9개 있다. 4개를 꺼내고 3개를 넣었다.
풀이: 9 - 4 = 5이고, 5 + 3 = 8이다.
정답: 8

문제: 문서가 12개다. 1/3을 폐기하고 5개를 추가했다.
풀이:

예시는 task format뿐 아니라 어떤 변수를 적고 어떤 순서로 결합할지 보여 줍니다. 원래 CoT prompting 연구는 충분히 큰 language model에서 산술·상식·symbolic reasoning task의 few-shot 성능이 개선될 수 있음을 보였습니다.

2. Zero-shot CoT

예시 없이 “단계별로 생각하라”는 식의 trigger를 넣습니다.

문제를 단계별로 풀고 마지막 줄에 "정답: ..."만 출력하라.

쉽게 적용할 수 있지만 domain 규칙과 올바른 decomposition을 가르치지는 않습니다. 긴 설명을 만들었다는 사실과 문제를 잘 풀었다는 사실을 혼동하지 않습니다.

3. Scratchpad

중간 변수나 계산 공간을 명시합니다.

known facts:
constraints:
calculation:
remaining uncertainty:
final answer:

Structured scratchpad는 누락된 조건을 찾기 쉽지만 schema가 task와 맞지 않으면 형식 채우기에 token을 낭비합니다.

4. Decomposition과 Plan

문제를 하위 질문이나 action으로 나눕니다.

1. 적용되는 정책 버전을 찾는다.
2. 사용자 지역과 상품 유형 조건을 확인한다.
3. 일반 기한과 예외 조항을 비교한다.
4. 근거 문장을 인용한다.
5. 답할 수 없으면 필요한 정보를 질문한다.

RAG Agent에는 단순한 장문 독백보다 이런 관측 가능한 plan과 action contract가 더 유용합니다. 각 단계가 retrieval이나 tool execution으로 확인되기 때문입니다.

중간 Token이 도움이 되는 이유

CoT가 유용할 수 있는 이유를 과장 없이 정리하면 다음과 같습니다.

계산을 더 많은 Decoding Step에 분산한다

최종 답 token 하나를 바로 선택하는 대신 여러 token transition을 사용합니다. Test-time compute가 늘어난 셈입니다.

중간 결과를 Context에 외부화한다

부분 합, entity, 제약을 text로 남겨 뒤 단계가 읽을 수 있습니다. 긴 문제에서 같은 값을 반복해서 다시 추정하는 부담을 줄일 수 있습니다.

Prompt Example이 Algorithmic Pattern을 유도한다

Few-shot 예시는 “이 문제에서는 단위를 먼저 맞춘다”, “예외 조항을 일반 조항 뒤에 검사한다” 같은 문제 풀이 pattern을 제공합니다.

검증 지점을 만든다

중간 단계가 있으면 각 산술식이나 claim을 calculator·retriever·verifier로 확인할 위치가 생깁니다. 다만 검증하지 않은 단계가 존재한다는 사실만으로 신뢰성이 올라가지는 않습니다.

이는 LLM이 formal symbolic engine으로 바뀌었다는 뜻이 아닙니다. 같은 model도 표현, 숫자 위치, distractor, sampling seed가 바뀌면 다른 오류를 만들 수 있습니다.

Prompt를 재현 가능한 실험으로 만든다

좋은 CoT prompt는 “자세히 생각해” 한 줄보다 실험 contract에 가깝습니다.

Task와 Answer Contract를 분리한다

task:
  제공된 정책 근거만 사용해 환불 가능 여부를 판단한다.

process:
  적용 조건, 예외, 날짜 계산을 순서대로 점검한다.

answer contract:
  decision: eligible | ineligible | insufficient_information
  evidence_ids: string[]
  concise_reason: string

최종 answer delimiter나 JSON field를 고정하면 여러 sample의 답을 비교하고 parser 오류를 줄일 수 있습니다. 구조가 반드시 유효해야 한다면 prompt만 믿지 말고 56편에서 다룰 constrained decoding을 사용합니다.

Example은 정확성과 다양성을 함께 관리한다

풀이와 정답을 사람이 검증합니다.
쉬운 사례만 넣지 말고 경계 조건과 unanswerable 사례를 포함합니다.
예시의 문구를 복사해야만 풀리는 test set은 피합니다.
정답 위치와 label 분포가 편향되지 않게 합니다.
Production과 같은 단위·언어·문서 형식을 사용합니다.

틀린 rationale이 든 example은 model이 그 오류 pattern까지 모방하게 할 수 있습니다.

Budget과 Stop Condition을 둔다

reasoning_policy:
  max_output_tokens: 640
  max_tool_steps: 6
  timeout_ms: 12000
  stop_on:
    - verified_answer
    - insufficient_evidence
    - repeated_state

“필요할 때까지 생각하라”는 production SLO가 아닙니다. Token, wall-clock, tool call, 돈, side effect에 각각 상한이 필요합니다.

Reference Answer를 Input에서 격리한다

Evaluation runner가 정답이나 rubric을 model prompt에 잘못 합치면 reasoning 능력이 아니라 answer leakage를 측정합니다. Test case에는 model input과 grader-only field를 분리합니다.

{
  "model_input": {"question": "...", "evidence": ["..."]},
  "grader_only": {"reference_answer": "...", "required_claims": ["..."]}
}

Direct Answer와 반드시 비교한다

CoT가 항상 좋은 기본값은 아닙니다.

same cases + same model snapshot + same retrieval
  A: direct answer
  B: CoT / scratchpad

compare:
  task success
  grounded claim precision
  abstention
  output tokens
  p50/p95 latency
  cost per successful answer

간단한 entity lookup에서 B가 더 장황하고 오히려 근거 밖 세부사항을 추가할 수 있습니다. 복합 계산에서는 B의 정확도 상승이 추가 비용보다 클 수 있습니다. 평균 하나 대신 task difficulty와 risk slice별로 봅니다.

Self-Consistency는 여러 경로를 Sample한다

한 reasoning path의 초반 오류가 뒤 단계 전체를 밀어낼 수 있습니다. Self-consistency는 temperature를 두고 여러 reasoning path를 만든 뒤 최종 답을 집계합니다.

sample 1: path z¹ → answer 13
sample 2: path z² → answer 13
sample 3: path z³ → answer 9
sample 4: path z⁴ → answer 13

normalize(answer) → majority vote → 13

기본 절차는 다음과 같습니다.

같은 question에서 N개 path를 sample합니다.
각 output에서 final answer를 parse합니다.
숫자 단위, 대소문자, 동의 label처럼 의미가 같은 답을 normalize합니다.
다수결이나 확률 질량으로 집계합니다.
동률, parse 실패, 낮은 합의율의 처리 정책을 둡니다.

주의할 점도 명확합니다.

비용과 생성 token은 대체로 N에 비례해 증가합니다.
모든 sample이 같은 오개념이나 잘못된 retrieval evidence에 의존하면 다수결도 틀립니다.
Open-ended answer는 단순 string majority가 성립하지 않습니다. Semantic clustering이나 verifier가 필요합니다.
Majority answer가 맞아도 개별 rationale의 faithfulness를 보장하지 않습니다.
Sample 수를 test 결과를 보며 계속 바꾸면 evaluation overfitting이 됩니다.

다음 글에서는 self-consistency, Best-of-N, search, verifier를 하나의 test-time compute budget 관점에서 비교합니다.

Correctness·Plausibility·Faithfulness는 다르다

Correctness: 최종 결과가 맞는가

정답 label, 계산 결과, 최종 tool state가 reference와 일치하는지 묻습니다.

answer = 13
reference = 13
→ correct

Plausibility: 설명이 사람이 읽기에 그럴듯한가

문장이 자연스럽고 단계가 논리적으로 이어져 보이는지 묻습니다. Style과 coherence에 가깝습니다.

Faithfulness: 설명이 실제 출력 결정에 충실한가

언급한 근거와 단계가 실제로 답에 영향을 주었는지, 사용하지 않은 단서를 사후에 이유처럼 붙이지 않았는지 묻습니다.

다음 네 조합이 모두 가능합니다.

답	설명	가능한 상태
맞음	타당하고 충실함	원하는 경우
맞음	계산은 틀렸지만 우연히 상쇄	정답만 보면 놓치는 오류
틀림	앞 단계 오류를 일관되게 따름	이해 가능한 실패지만 결과는 실패
틀림	그럴듯한 사후 합리화	가장 오해하기 쉬운 실패

“모델이 이렇게 생각했기 때문에 답했다”라고 CoT를 그대로 인용하면 faithfulness를 이미 입증했다고 가정하는 셈입니다. 연구에서는 biasing hint처럼 답에 영향을 주는 요소를 rationale이 언급하지 않는 사례가 관찰됐습니다. 따라서 CoT는 검사할 artifact이지 자동 생성된 감사 증명서가 아닙니다.

Faithfulness를 점검하는 실험

완벽한 내부 인과 설명을 얻기는 어렵지만 위험 신호는 측정할 수 있습니다.

Counterfactual Input

답에 영향을 줘야 할 숫자나 근거를 바꿉니다.

original: 12개 중 1/3 폐기, 5개 추가
variant:  12개 중 1/4 폐기, 5개 추가

설명과 답이 해당 변화에 맞게 함께 바뀌는지 확인합니다.

Biasing Hint Perturbation

“다른 사람이 12라고 답했다” 같은 무관하거나 오도하는 hint를 넣고 answer가 바뀌는지, rationale이 그 영향을 인정하는지 봅니다. 이는 production prompt가 그런 hint를 허용해야 한다는 뜻이 아니라, 설명의 충실성을 조사하는 red-team 실험입니다.

Evidence Ablation

인용했다고 주장한 evidence를 제거하거나 distractor만 제거합니다.

핵심 evidence 제거 후에도 같은 확신과 답을 내면 근거 사용이 의심됩니다.
무관 evidence 제거에 답이 크게 흔들리면 spurious reliance를 의심합니다.

Step Intervention

중간 값을 올바른 값이나 잘못된 값으로 바꿔 뒤 단계와 답이 어떻게 변하는지 봅니다. 자유 형식 text에서는 intervention 해석이 어렵기 때문에 계산 field나 tool result처럼 구조화된 상태가 유리합니다.

이 실험들은 faithfulness를 완전히 증명하지 않습니다. 다만 “설명이 길고 자연스럽다”보다 훨씬 강한 증거를 제공합니다.

RAG Agent는 생각보다 Evidence와 Action을 기록한다

Production에서 필요한 것은 내부 독백을 저장하는 일이 아니라 실패를 재현할 수 있는 event trace입니다.

{
  "episode_id": "ep_...",
  "state_before": "need_refund_policy",
  "action": {
    "tool": "search_policy",
    "arguments": {"region": "KR", "product": "subscription"}
  },
  "result": {
    "document_ids": ["policy-v7#refund", "policy-v7#exception"]
  },
  "decision": "insufficient_information",
  "missing_fields": ["purchase_date"],
  "verifier": {
    "schema_valid": true,
    "citations_supported": true,
    "authorization_checked": true
  }
}

이 trace에서 확인할 수 있는 것은 다음과 같습니다.

어떤 corpus snapshot과 document를 검색했는가?
어떤 tool과 argument를 model이 선택했는가?
Tool이 실제로 어떤 result나 error를 반환했는가?
어느 state에서 다음 state로 이동했는가?
부족한 정보 때문에 질문했는가, 근거 없이 추측했는가?
Write action 전에 policy와 사용자 승인을 확인했는가?
최종 claim마다 supporting evidence가 있는가?

반면 장문의 “나는 먼저 이것을 생각했고…”는 실제 실행 state와 어긋날 수 있고 민감한 prompt·문서 내용을 노출할 수도 있습니다.

사용자에게는 Concise Justification을 준다

사용자는 내부 reasoning transcript보다 결론을 확인할 수 있는 근거가 필요합니다.

결론: 추가 정보가 필요합니다.
이유: 정책상 구매일로부터 14일 이내인지 확인해야 합니다.
근거: policy-v7 §3.1
필요한 정보: 구매일

근거 ID와 짧은 결정 이유는 검증 가능하고 privacy boundary도 관리하기 쉽습니다. 특정 provider가 숨은 reasoning을 반환하지 않더라도 이 product contract는 구현할 수 있습니다.

Retrieved Text는 Instruction이 아니다

RAG 문서 안에는 “이전 지시를 무시하라” 같은 prompt injection이 들어갈 수 있습니다. Reasoning context에 들어왔다는 이유로 privileged instruction으로 승격하면 안 됩니다.

trusted control plane:
  system policy · authorization · tool allowlist

untrusted data plane:
  user text · retrieved documents · web pages · tool output

Document는 claim의 evidence가 될 수 있지만 agent 권한을 바꾸는 명령이 될 수 없습니다. 이 경계는 CoT prompt보다 상위의 harness 정책으로 강제합니다.

Tool이 자연어 계산보다 강한 경우

정확한 산술: calculator 또는 code sandbox
현재 날짜·재고·가격: authoritative API
권한 판단: policy engine
문서 사실: versioned retrieval와 citation verifier
스키마 검사: deterministic validator
부작용 작업: authorization, idempotency key, transaction log

CoT가 tool을 언제 쓸지 계획할 수는 있지만 tool result를 꾸며 내지 못하게 실제 executor와 protocol을 분리해야 합니다.

평가 단위를 네 층으로 나눈다

1. Final Answer

Exact match 또는 normalized match
Semantic equivalence
Task-specific success
Unanswerable일 때 올바른 abstention

2. Intermediate Artifact

산술식과 단위의 정확성
각 claim의 evidence entailment
누락된 제약
모순되는 단계
Reference rationale와 다른 올바른 경로를 허용하는 rubric

하나의 reference CoT와 문장이 다르다는 이유로 오답 처리하면 안 됩니다. 같은 문제에 여러 유효한 풀이가 있습니다.

3. Agent Trajectory

Tool 선택·argument·순서
Error 후 recovery
불필요하거나 중복된 call
Authorization과 side effect
최종 environment state

4. System Cost와 Reliability

Input/output/reasoning token
Tool call 수와 외부 API 비용
TTFT, end-to-end p50·p95·p99
Timeout·parse failure·cancellation
성공 episode당 총비용

CoT가 정확도 2%p를 높여도 latency와 비용이 5배가 되고 중요한 slice에서 개선이 없다면 default 경로로는 부적합할 수 있습니다.

최소 비교 실험

experiment:
  model_snapshot: fixed
  prompt_variants:
    - direct
    - zero_shot_cot
    - few_shot_cot
  decoding:
    temperature: 0
    max_output_tokens: 640
  cases:
    split: locked_test
    slices: [lookup, arithmetic, multi_hop, unanswerable, injection]
  metrics:
    - task_success
    - grounded_claim_precision
    - abstention_f1
    - output_tokens
    - episode_latency_ms
    - cost_per_success

Stochastic sampling을 평가한다면 variant마다 충분한 반복을 하고 confidence interval을 보고합니다. Prompt를 test set 결과에 맞춰 수정했다면 그 set은 더 이상 locked test가 아닙니다.

흔한 실패와 처방

1. 길수록 더 깊이 생각했다고 본다

반복·망설임·자기모순도 token을 늘립니다.

처방: 길이가 아니라 task success와 검증된 step, 비용을 함께 봅니다.

2. 정답만 맞으면 모든 Step이 맞다고 본다

두 오류가 상쇄될 수 있습니다.

처방: 고위험 계산은 중간 수식과 단위를 deterministic tool로 재계산합니다.

3. CoT를 내부 상태의 완전한 Dump로 본다

출력 text는 내부 계산 전체가 아닙니다.

처방: 설명은 claim으로 취급하고 perturbation·evidence·tool로 검사합니다.

4. 모든 Query에 CoT를 강제한다

단순 조회도 느리고 장황해지며 근거 밖 내용을 추가할 수 있습니다.

처방: Difficulty·risk router로 direct, budgeted reasoning, human escalation을 나눕니다.

5. Self-Consistency를 독립 검증으로 본다

같은 model과 잘못된 context에서 나온 sample은 오류가 강하게 상관될 수 있습니다.

처방: 합의율과 함께 외부 verifier, 다른 evidence, deterministic calculation을 사용합니다.

6. 내부 Reasoning 전문을 Log한다

민감 정보, retention, access, 설명 불충실성 문제가 생깁니다.

처방: 최소한의 state/action/evidence/result와 concise justification을 기록합니다.

7. Retrieved Document의 명령을 따른다

검색 data가 control instruction으로 승격됩니다.

처방: Trust boundary, tool allowlist, authorization을 model 밖에서 강제합니다.

8. Reference CoT와 다르면 틀렸다고 한다

다른 유효한 풀이를 벌점 처리합니다.

처방: 결과·제약·step validity를 채점하고 단일 문장 경로 복제를 요구하지 않습니다.

Production 적용 체크리스트

스스로 확인하기

CoT가 다음 token 예측 과정에서 사용할 계산 공간을 늘린다는 말은 무엇을 뜻하는가?
출력된 rationale이 model 내부 계산 전체의 공개가 아닌 이유는 무엇인가?
Correctness, plausibility, faithfulness가 서로 다른 네 가지 조합을 만들 수 있는가?
사실 조회 실패에 긴 CoT보다 retrieval 개선이 먼저일 수 있는 이유는 무엇인가?
Few-shot CoT example에 unanswerable과 경계 조건이 필요한 이유는 무엇인가?
Self-consistency에서 answer normalization이 빠지면 어떤 문제가 생기는가?
여러 sample이 같은 잘못된 evidence를 쓰면 majority vote는 왜 실패하는가?
Evidence ablation과 counterfactual test가 무엇을 측정하는가?
RAG Agent audit log에 자유 형식 생각 대신 무엇을 기록해야 하는가?
Retrieved text를 control instruction으로 취급하면 어떤 보안 경계가 무너지는가?
CoT의 효용을 정확도만 아니라 cost per success로 봐야 하는 이유는 무엇인가?
Direct, budgeted reasoning, human escalation을 나누는 router의 입력에는 무엇이 필요한가?

작은 실습

산술 10개, 두 문서 결합 10개, 단순 조회 10개, 답할 수 없는 질문 10개를 준비합니다.

같은 model snapshot과 retrieval corpus를 고정합니다.
Direct, zero-shot CoT, few-shot CoT 세 prompt를 실행합니다.
정답·abstention·grounding과 output token·latency를 기록합니다.
각 slice에서 cost per success를 비교합니다.
CoT가 틀린 사례에 숫자 counterfactual과 evidence ablation을 만듭니다.
자유 형식 rationale 대신 evidence id와 계산 tool result를 남기는 trace로 바꿉니다.
어느 slice에만 reasoning budget을 줄지 policy를 작성합니다.

이 실습의 목표는 가장 긴 풀이를 만드는 것이 아닙니다. 추가 token이 실제 성공률을 높이는 조건과, 외부 검증이 필요한 경계를 찾는 것입니다.

다음 글은 Test-time Compute: Self-Consistency·Best-of-N·Search 설계입니다. 하나의 CoT를 넘어서 여러 후보에 계산 예산을 어떻게 배분하고 언제 멈출지 다룹니다.