Quick Flow

prompt chaining은 한 작업을 여러 API call로 쪼개는 것이 아니라, 중간 결과를 검사·저장·분기해야 할 때 각 판단 책임을 분리하는 pipeline입니다. 단순 질문이나 한 번의 변환은 단일 prompt가 더 낫습니다. source extraction, 기준표 review, 승인 대기, retry 정책처럼 중간 산출물의 상태가 중요할 때만 chain을 만듭니다.

extract evidence -> draft -> review against criteria -> refine -> final validation
     |                |              |                  |
   source IDs       draft ID       findings[]          pass / needs-review

단계 계약을 정하는 법

각 stage는 입력, output schema, 성공 조건, 실패 행동을 가져야 합니다. "더 잘 검토해"처럼 앞 stage 전체를 다시 넘기면 chain이 길어질수록 state가 흐려집니다. 다음 stage가 필요한 field만 전달하고, model이 만든 해석과 원문·사용자 입력을 다른 field에 둡니다.

{
  "stage": "review",
  "input": {
    "draft_id": "d-104",
    "criteria": ["source coverage", "required fields", "unsafe claim"]
  },
  "output": {
    "status": "pass | revise | needs_human_review",
    "findings": [{"criterion":"source coverage","evidence":"...","action":"..."}]
  }
}

흔한 self-correction 흐름은 draft -> review -> refine입니다. review 단계는 초안을 더 멋지게 쓰는 역할이 아니라 미리 정한 criteria에 대해 finding을 내는 역할입니다. refine 단계는 finding과 draft를 받아 확인된 항목만 고치고, source가 부족하거나 risk가 큰 항목은 needs_human_review로 넘깁니다.

실행·검증·재시도

모델이 한 request 안에서 여러 단계를 reasoning할 수 있으므로, 모든 multi-step 일을 chain으로 만들 필요는 없습니다. explicit chain은 intermediate output을 log·평가·분기해야 하는 제품 workflow에 유용합니다. latency, token cost, prompt injection surface, failure mode도 단계 수만큼 늘어나므로, stage를 추가할 때는 없을 때 검증할 수 없는 조건을 하나씩 명시합니다.

자주 틀리는 부분

피해야 할 chain
"분석해" -> "더 잘해" -> "다시 확인해"

검증 가능한 chain
extract quote -> map claim -> validate schema -> review criteria -> human approval

각 stage의 input·output, model·prompt version, 실행 시간, retry reason을 기록해 두면 prompt를 바꿨을 때 어느 단계가 좋아지거나 나빠졌는지 확인할 수 있습니다. 전체 성공률만 보지 말고 format violation, evidence coverage, human escalation 비율을 함께 평가합니다.