불확실성만으론 부족하다: 코드 생성 self-correction 실증 연구
When Uncertainty Isn't Enough: An Empirical Study of Self-Correction in Code Generation
TL;DR Highlight
불확실성 점수로 코드를 재생성하면 오히려 정확도가 떨어지고, 테스트 검증만 올렸다
Who Should Read
코드 생성 LLM이 틀린 코드를 낼 때 자동으로 다시 생성하게 만들려는 코딩 어시스턴트 개발자
Core Mechanics
- 불확실성 점수로 재생성하면 더 나빠졌다
- 불확실성 기반 self-correction은 6개 설정 중 5개에서 Pass@1이 떨어졌다.
- 하락폭은 -3pp~-10pp였다.
- 싼 불확실성 지표는 정답과 상관이 약했다
- 토큰 엔트로피(생성 토큰별 확률 분포의 불확실도), verbalized confidence(모델이 말로 말하는 자신감), semantic entropy probe 모두 상관이 약했다.
- 다중 샘플 P(True)만 강한 상관을 보였지만 K번 롤아웃이 필요해 비싸다.
- 테스트 실행 기반 재생성만 꾸준히 올랐다
- 통과할 때까지 최대 5번 다시 생성하는 방식만 모든 설정에서 Pass@1이 올랐다.
- HumanEval +6~+26pp, BigCodeBench +8~+20pp였다.
- 약한 모델일수록 검증 효과가 컸다
- DeepSeek-Coder-1.3B가 두 벤치마크 모두에서 가장 크게 올랐다.
- 강한 모델은 원래 맞히는 문제가 많아 오를 여지가 적었다.
- 적응형 디코딩은 비용만 키웠다
- 6개 설정 중 4개에서 정확도가 떨어졌다.
- TBG 방식은 기준 대비 지연이 2.8×~10.1×였다.
Evidence
- HumanEval에서 불확실성 재생성은 전부 하락
- 3개 모델 모두 -3.23pp~-9.68pp였다(Greedy 기준, n=31).
- Llama-3.2-3B는 0.39→0.29로 떨어졌고 지연은 4.6×였다.
- HumanEval 검증 재생성 이득
- DeepSeek-Coder-1.3B는 0.61→0.87(+25.81pp)이고 지연은 2.4×였다.
- Qwen2.5-Coder-3B는 0.81→0.87(+6.45pp)이고 지연은 1.9×였다.
- BigCodeBench에서도 같은 패턴
- 검증 재생성은 Llama 0.271→0.368, Qwen 0.297→0.374, DeepSeek 0.181→0.381이었다(n=155).
- 지연은 5.0×~5.9×였다.
- 불확실성 지표와 정답의 Pearson 상관(HumanEval)
- P(True)는 Llama 0.842, Qwen 0.782, DeepSeek 0.303이었다.
- Semantic entropy probe는 -0.196~-0.475로 약했다.
How to Apply
- 재생성 트리거를 테스트 실행 결과로 바꾸기
- 코드 생성 파이프라인에서 확신도 점수로 재시도하는 로직이 있으면 단위 테스트 통과 여부로 교체하라.
- 실패하면 최대 5번까지 다시 생성하게 하라.
- logprob·자신감 점수 단독 재시도 A/B 테스트하기
- 내부 평가셋에서 재시도 없음, 점수 기반, 테스트 기반 세 가지로 Pass@1을 비교하라.
- 점수 기반이 기준보다 낮으면 끄라.
- 불확실성은 검증을 부를지 결정하는 게이트로만 쓰기
- 지연이 중요한 서비스에서는 점수가 높은 요청에만 테스트 실행 루프를 돌려라.
- 이 조합은 논문에서 직접 실험하지 않았으니 작은 평가셋으로 먼저 확인하라.
- 지연 예산을 먼저 측정하기
- 검증 재생성은 기준 대비 1.9×~5.9× 걸렸다.
- 서비스의 허용 지연 안에 들어오는지 확인하라.
Try It
# Claude Code 또는 ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 테스트 통과까지 최대 5번 재생성)
아래 함수 명세와 테스트를 보고 파이썬 코드를 작성해 줘.
[명세]
{{함수 명세}}
[테스트]
{{단위 테스트 코드}}
규칙:
1. 코드를 작성하고 테스트를 실제로 실행해.
2. 실패하면 실패 메시지를 보고 처음부터 다시 작성해. 최대 5번까지 시도해.
3. 자신감 점수는 말하지 마. 테스트 통과 여부만 기준이야.
4. 마지막에 시도 횟수와 통과 여부를 한 줄로 알려줘.
이어서 해 볼 것: 같은 문제를 테스트 없이 한 번만 생성하게 해서 결과를 비교해 봐.Terminology
관련 논문
The Judge Can Debias Itself: LLM-as-a-Judge가 스스로 편향을 고치게 하는 법
심사 프롬프트에 편향 경고를 넣거나 스스로 비판시켰더니 21개 중 20개 조합에서 정확도가 올랐다
미국 노동시간의 90%는 AI 벤치마크가 제대로 다루지 못하는 일이다
벤치마크 29개를 직업 과제에 매핑했더니 노동시간 90%가 커버 밖
Postgres 19, AI 코드 리뷰가 버그를 너무 많이 찾아 출시 연기
LLM 코드 리뷰가 버그를 쏟아내 Postgres 19가 11월로 밀리고 기능 8~10개가 빠졌다
StarSkirmish Bench v0.2: LLM이 1시간 만에 짜는 StarCraft 봇 대결
LLM에게 1시간 동안 StarCraft 봇을 짜게 했더니 GPT-6 Astra가 1위
그럴듯한 설명 하나면 멀티모달 LLM 심사위원도 속는다 (JUPE 벤치마크)
정답은 그대로 두고 설명만 붙였더니 MLLM 심사위원의 오답 거절률이 12.7~13.8%p 떨어졌다
신경망은 이미 깔끔하다: polysemanticity의 원인 재해석
뉴런을 직접 들여다봤더니 대부분 한 가지 역할이 있었다는 주장
Linus Torvalds의 첫 LLM 보조 패치 시리즈
Linus가 LLM으로 folio 조회 패치 10개를 만들어 read() 벤치가 10배 빨라졌다
Original Abstract (Expand)
Large language models for code generation often produce incorrect solutions without reliable indicators of failure. We study whether uncertainty estimation methods developed for natural language transfer to code generation, and whether such signals can improve code generation via selective self-correction. We evaluate five uncertainty methods: mean token entropy, verbalized confidence, $P(\text{True})$, entropy ensembles, and semantic entropy probes, across three small code LLMs on HumanEval and BigCodeBench. We find that multi-sample $P(\text{True})$ achieves the strongest correlation with correctness, while all the other methods, including semantic entropy probes, yield only weak correlation. We then use these uncertainty signals to drive three self-correction policies: adaptive decoding, uncertainty-based regeneration, and verification-based regeneration. Our results reveal a stronger negative finding than anticipated: uncertainty-based self-correction fails to reliably improve Pass@1, degrading accuracy in 5 of 6 configurations across both benchmarks ($-3$pp to $-10$pp), and adaptive decoding degrades accuracy in 4 of 6 configurations. Only verification-based self-correction reliably improves Pass@1, with gains of $+6$ to $+26$ percentage points on HumanEval and $+8$ to $+20$ percentage points on BigCodeBench, scaling inversely with baseline strength. These findings replicate consistently across both benchmarks and suggest that cheap uncertainty estimators are insufficient on their own to improve code correctness, and that their practical value lies in serving as gating signals for costlier execution-based correction loops rather than as standalone substitutes for verification.