나쁜 reasoning 디버깅 — trace 읽어

~14 min · reasoning, debugging

Level 0수련생

0 XP0/100 lessons0/14 achievements

0/120 XP to next level120 XP to go0% complete

Trace가 어디서 잘못됐는지 알려줘

Reasoning 모델이 틀린 답 만들면 trace가 evidence야. 대부분 팀이 trace 안 읽어 — 감으로 프롬프트 tweak, work할지 안 할지 모르는 fix ship, 다음으로. Trace 읽기는 처음엔 느린데 분기 단위로 빨라.

뭘 찾아야 하나

잘못된 premise — 모델이 input의 load-bearing 아닌 phrase에 anchor.
건너뛴 step — constraint 체크 없이 conclusion 점프.
반복된 step — 진전 없이 같은 sub-result restate.
Verifier rejection — verifier가 plan kill했는데 다음 branch가 materially 다르지 않음.
토큰 budget exhaustion — answer 전에 trace가 공간 다 씀.

trace를 eval input으로

annotated 나쁜 trace 몇 개 있으면 failure mode가 test case 돼. eval set에 추가. 다음 프롬프트 변경이 그것 fix하면 progress count; 안 하면 안 count.

Code

Trace logging shape·json

{
  "request_id": "req_abc123",
  "model": "claude-opus-4-7",
  "prompt_version": "support.draft@7",
  "thinking_tokens": 4823,
  "output_tokens": 287,
  "thinking": "...",
  "answer": "...",
  "verifier_pass": false,
  "verifier_error": "missing required field 'sla_tier'"
}

External links

Exercise

지난주에 verifier 실패한 response 10개 pull. 각 trace 읽어. failure mode 분류. fix할 곳이 프롬프트인지 verifier인지 식별.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousReasoning output의 confidence calibrating Next →퀴즈 · 4 questions

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.