현장에서 AI 답변 품질을 올리겠다고 하면 가장 먼저 붙는 장치가 self-correction이다. 초안 생성 뒤 “검토하고 고쳐라”를 한 번 더 호출한다. 문제는 여기서 시작된다. 맞는 답도 흔들리고, 틀린 답은 그럴듯하게 포장된다. 운영팀은 개선인지 변형인지 구분하지 못한다.
Self-correction 연구도 같은 지점을 보고 있다. 2025년 TACL의 비판적 서베이는 self-correction이 언제 성공하는지에 합의가 없고, 평가 설계가 과대평가를 만들 수 있다고 정리했다. https://transacl.org/index.php/tacl/article/view/6755 (transacl.org)
수정은 기본 동작이 아니다
좋은 루프의 기본값은 revise가 아니라 preserve다. 모델이 두 번째 답을 냈다는 이유만으로 첫 번째 답을 버리면 안 된다.
Verifier-gated self-correction은 순서가 다르다. 먼저 초안을 만든다. 다음으로 Verifier가 결함 증거를 낸다. 마지막으로 증거가 있는 부분만 고친다. 결함 증거가 없으면 원문을 유지한다.
수정은 품질 개선 행위가 아니다. 증거가 있는 결함을 제거하는 행위다.
Microsoft Research의 2025년 ICLR 2026 논문은 process verifier의 작은 오류가 생성 과정에서 증폭될 수 있다고 지적한다. 그래서 verifier는 “좋다/나쁘다” 점수기가 아니라, 결함 위치와 근거를 남기는 장치로 설계해야 한다. https://www.microsoft.com/en-us/research/publication/taming-imperfect-process-verifiers-a-sampling-perspective-on-backtracking/ (microsoft.com)
Verifier는 의견이 아니라 증거를 반환한다
Verifier 출력은 문장 평가가 아니라 결함 티켓이어야 한다. 최소 필드는 네 가지다.
| 필드 | 의미 | 없으면 생기는 문제 |
|---|---|---|
| claim_id | 어떤 주장인지 | 전체 답변을 다시 쓰게 된다 |
| defect_type | 사실 오류, 누락, 정책 위반, 형식 오류 | 수정 방향이 흔들린다 |
| evidence | 로그, 테스트 결과, 원문 출처, 룰 ID | LLM-as-judge 감상평이 된다 |
| severity | 보존, 국소 수정, 전면 재생성 기준 | 사소한 표현까지 바꾼다 |
Anthropic은 2026년 agent evals 글에서 agent 평가를 task, trial, grader, transcript, outcome, evaluation harness로 분해한다. 이 구분은 그대로 운영 루프에 적용된다. Verifier는 transcript를 읽고, grader는 assertion을 확인하며, 최종 판단은 outcome 기준으로 남긴다. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents (anthropic.com)
Preserve-or-revise는 국소 수정을 강제한다
루프는 세 단계로 충분하다.
- Draft: 답변을 claim 단위로 구조화한다. 주장, 근거, 사용한 도구, 출처를 분리한다.
- Verify: Verifier는 결함 증거만 반환한다. 증거 없는 비평은 폐기한다.
- Patch: Reviser는 defect ticket이 지정한 claim만 수정한다. 수정 뒤 regression check를 다시 돈다.
이 구조에서 “다시 써라”는 금지어다. 다시 쓰기는 비용이 크고, 추적이 어렵고, 이미 맞던 부분을 망가뜨린다. 운영 루프는 문서 편집기가 아니라 결함 제거 파이프라인이다.
형식 검증, 룰 검증, 계산 검증, 코드 실행, 검색 출처 대조는 먼저 기계적으로 처리한다. LLM verifier는 마지막에 쓴다. 기계가 판정할 수 있는 문제를 LLM에게 맡기면 verifier가 말솜씨에 설득된다.
Goedel-Prover-V2는 Lean compiler feedback을 활용해 proof를 반복 수정하는 verifier-guided self-correction을 제시했다. 이 사례가 주는 운영적 교훈은 단순하다. 강한 verifier는 모델의 반성문보다 실행 가능한 피드백을 준다. https://arxiv.org/abs/2508.03613 (arxiv.org)
AX Ops는 루프를 운영 단위로 잠근다
Verifier-gated self-correction은 프롬프트 한 줄이 아니다. 운영 설계다. 누가 기준을 소유하는지, 어떤 로그가 남는지, 어떤 결함에서 사람에게 넘기는지 정해야 한다.
Project Aletheia는 2026년 논문에서 conflict detection과 backtracking을 최종 답이 아니라 수리 과정 자체로 학습시키는 접근을 제시했다. 기업 운영에서도 같은 원리가 필요하다. 정답만 저장하지 말고, 결함 증거와 수정 결정을 함께 저장해야 한다. https://arxiv.org/abs/2601.14290 (arxiv.org)
AX Ops에서 이 루프는 다음 산출물로 고정된다.
- claim schema와 defect ticket schema
- verifier 우선순위: deterministic check → tool check → LLM judge
- preserve/revise/escalate 판정표
- 수정 전후 diff와 regression log
- 운영 리뷰에서 보는 defect taxonomy
얕은 요약은 이렇다. self-correction을 붙인다고 답이 좋아지지 않는다. 결함 증거를 요구하고, 증거가 없으면 보존하며, 증거가 있으면 해당 부분만 고치는 루프가 운영 품질을 만든다. 이 설계를 파일럿이 아니라 운영 표준으로 묶는 일이 AX Ops의 역할이다. AX Ops 방법론 →
참고
- Kamoi et al., “When Can LLMs Actually Correct Their Own Mistakes?”, TACL, 2025. https://transacl.org/index.php/tacl/article/view/6755
- Microsoft Research, “Taming Imperfect Process Verifiers: A Sampling Perspective on Backtracking”, ICLR 2026 / 2025. https://www.microsoft.com/en-us/research/publication/taming-imperfect-process-verifiers-a-sampling-perspective-on-backtracking/
- Anthropic, “Demystifying evals for AI agents”, 2026. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- Lin et al., “Goedel-Prover-V2: Scaling Formal Theorem Proving with Scaffolded Data Synthesis and Self-Correction”, arXiv, 2025. https://arxiv.org/abs/2508.03613
- Dixit et al., “Project Aletheia: Verifier-Guided Distillation of Backtracking for Small Language Models”, arXiv, 2026. https://arxiv.org/abs/2601.14290