기술 요약: 컴파일이 아닌 교정(Calibration)

문제 정의

대규모 언어 모델(LLM)은 확률적 프로그램(예: Stan, Pyro, NumPyro)을 작성하는 데 점점 더 많이 사용되고 있습니다. 이러한 프로그램들은 종종 컴파일되고, 실행되며, 전통적인 유닛 테스트를 통과하지만, **통계적으로 오설정(misspecified)**된 상태로 남을 수 있습니다. 흔한 오류로는 두꺼운 꼬리(heavy-tailed) 데이터를 가진 데이터에 가우시안 우도(Gaussian likelihood)를 사용하거나, 과분산(over-dispersed)된 카운트에 포아송 분포를 사용하는 것, 잘못된 사전 분포 지지 영역(invalid prior supports), 또는 병리적 파라미터화(예: 계층적 깔때기 구조에서의 중심 파라미터화) 등이 있습니다.

본 논문은 중요한 격차를 식별합니다: 표준 소프트웨어 검증(컴파일 및 유닛 테스트)은 이러한 통계적 오류를 감지하지 못합니다. "코드가 실행되고 유한한 샘플을 반환한다"는 프로그램은 여전히 사후 분포가 제대로 교정되지 않았을 수 있으며, 홀드아웃 데이터(held-out data)와 일치하지 않을 수 있습니다. 저자들은 이를 **코드 불투명한 오설정(code-invisible misspecifications)**이라 명명합니다. 핵심 문제는 표준 "테스트 오라클"(코드가 실행되는가?)이 통계적 정확성에 대한 정보를 전혀 제공하지 못하며, 결과적으로 필요한 수정을 억제하여 잘못된 확신을 유도할 수 있다는 점입니다.

방법론

교정 오라클 (The Calibration Oracle)

저자들은 유닛 테스트 오라클을 베이지안 워크플로에서 유도된 **교정 오라클(Calibration Oracle)**로 대체할 것을 제안합니다. 이 오라클은 모델이 통계적으로 올바른지 검증하기 위해 네 가지 계열의 진단 도구를 종합합니다:

1. 사후 예측 점검 (Posterior Predictive Checks, PPC): 모델이 꼬리 확률(tail probabilities)을 통해 주요 데이터 통계량(평균, 표준편차, 최댓값, 제로 카운트 등)을 재현할 수 있는지 평가합니다.
2. 시뮬레이션 기반 교정 (Simulation-Based Calibration, SBC): 사전 추출물(prior draws)과 사후 추출물(posterior draws) 간의 순위 분포(rank distribution)를 조사하여 추론 절차가 모델의 사전 분포와 자기 일관성(self-consistent)을 갖는지 확인합니다.
3. 샘플러 진단 (Sampler Diagnostics): 분할-$\hat{R}$(split-$\hat{R}$), 유효 샘플 크기(ESS), 발산(divergent transitions)을 모니터링하여 도달 불가능한 사후 분포 기하 구조를 가진 파라미터화를 탐지합니다.
4. 홀드아웃 예측 밀도 (Held-out Predictive Density): 모델을 참조 모델과 비교하기 위해 엄격하게 적절한 스코어링 규칙(strictly proper scoring rule)으로서 홀드아웃 데이터에 대한 로그 예측 밀도를 사용합니다.

오라클은 모델이 모든 임계값(예: $\hat{R} < 1.05$, 낮은 발산 횟수, 0 또는 1에 가깝지 않은 PPC $p$-값, 높은 홀드아웃 밀도)을 통과할 때만 승인한다는 판결을 내립니다.

실험 설정

• 벤치마크: 10개의 모델 패밀리와 14개의 오설정 유형에 걸친 200개의 인스턴스로 구성된 데이터셋. 모든 인스턴스는 컴파일되고 실행됩니다.
• 버그 분류학 (Bug Taxonomy):
  • 코드 가시적(Code-visible): 중립적인 짧은 브리프(brief) 하에서 소스 코드를 검사하여 탐지 가능한 오류 (예: 아주 작은 노이즈를 하드코딩함).
  • 코드 불투명(Code-invisible): 코드는 브리프를 충실히 구현했으나 특정 데이터에는 틀린 오류 (예: 잘못된 우도 선택). 이것이 주요 초점이며, 테스트 오라클이 실패하는 지점입니다.
• 수정 루프 (Repair Loop): LLM이 프로그램을 작성하면, 오라클이 이를 평가하고, 만약 교정되지 않았다면 구조화된 진단(예: "데이터의 확산이 극단적인 꼬리 부분에 위치함")을 LLM에 피드백하여 수정을 유도하는 반복 프로세스입니다.
• 모델: 15개의 라이터(오픈 소스: DeepSeek, Qwen, Llama, Phi; API: GPT, Claude, Gemini)를 대상으로 평가되었습니다.

주요 기여

1. 탐지 능력: 교정 오라클은 AUC 0.97로 오설정을 탐지합니다. 코드 불투명 버그의 경우, 유닛 테스트 오라클은 0%를 탐지하는 반면, 교정 오라클은 2%의 거짓 양성률(false-positive rate)에서 **93%**의 사례를 잡아냅니다.
2. 참조 없는 작동 (Reference-Free Operation): 시스템은 수기로 작성된 정답 프로그램을 요구하지 않습니다. 참조 없는 버전(PPC + 샘플러 + SBC)은 **62%**의 버그를 탐지합니다. 고전적인 GLM 베이스라인을 추가하면 이 수치는 **68%**로 높아지며, 자동화된 모델 탐색(작은 라이브러리에 대한 LOO)은 **78%**에 도달합니다. 초록에서 언급된 88%라는 수치는 알려진 정답 참조가 있다고 가정했을 때의 상한선입니다.
3. 수정 효능 (Repair Efficacy): 교정 피드백을 사용하는 것은 "피드백 없음" 또는 "유닛 테스트 피드백"보다 훨씬 뛰어난 성능을 보입니다.
   • 유닛 테스트 피드백은 해롭습니다: "모든 테스트를 통과했다"고 말하는 것은 모델이 미스스펙(misspecified)된 모델을 올바르다고 믿게 만들어 수정을 억제하며, 종종 피드백을 전혀 주지 않았을 때보다 낮은 수정률을 초래합니다 (예: Claude의 경우 피드백이 있을 때 25% vs 피드백이 없을 때 75%).
   • 교정 피드백은 효과적입니다: 강하지만 아직 포화되지 않은(strong-but-unsaturated) 모델의 경우, 교정 피드백은 수정률을 극적으로 향상시킵니다 (예: GPT-5.1: 33% $\to$ 92%; Claude: 75% $\to$ 100%).
4. 실제 검증: 중립적인 브리프로부터 처음부터 작성된 프로그램에 대해, **15~47%**의 실행 가능한 프로그램이 통계적으로 오설정되어 있습니다 (유닛 테스트는 하나도 잡지 못함). 교정 가이드 수정은 LLM-as-judge 리뷰, 베이지안 체크리스트, 데이터 요약 셀프 디버그를 포함한 베이스라인들을 유의미하게 능가합니다.

결과

• 탐지: 오라클은 우도 오류, 분산 문제, 제로-인플레이션(zero-inflation)에 대해 거의 완벽합니다. 다만 확률적 변동성(stochastic volatility) 및 데이터 모멘트를 보존하는 특정 링크 오류에는 약간 어려움을 겪습니다.
• 지역화 (Localization): 오라클은 75%의 top-2 정확도로 버그 유형을 지역화할 수 있으며, 잘못된 우도, 나쁜 파라미터화, 과분산을 구분해 냅니다. 다만 때때로 과분산을 사전-데이터 갈등(prior-data conflict)과 혼동하기도 합니다.
• 비단조적 능력 (Non-Monotone Capability): 교정 피드백의 이점은 비단조적입니다. 진단을 수행할 능력이 부족한 모델이나, 스스로 수정할 수 있을 만큼 충분히 강력한 모델에게는 이점이 미미합니다. 이 기능은 "강하지만 포화되지 않은" 모델들에게 가장 결정적입니다.
• 통계적 유의성: 쌍체 맥니머 검정(Paired McNemar tests) 결과, 교정 피드백이 피드백 없음($p=4.4 \times 10^{-3}$) 및 유닛 테스트 피드백($p=6.5 \times 10^{-7}$)보다 유의미하게 우수함을 확인했습니다. 유닛 테스트 피드백은 피드백 없음($p=3.4 \times 10^{-3}$)보다 유의미하게 나쁩니다.

의의 및 주장

본 논문은 확률적 프로그램의 경우, 정확성은 컴파일이 아니라 교정(calibration)이다라고 주장합니다.

• 패러다임의 전환: LLM이 작성한 확률적 코드의 적절한 검증기는 테스트 스위트가 아니라 베이지안 워크플로 그 자체입니다.
• 테스트의 능동적 해악: 유닛 테스트 통과는 유능한 모델이 미스스펙된 모델을 올바른 것으로 믿게 만들어, 수정 과정을 능동적으로 방해할 수 있습니다.
• 실질적 영향: 교정 오라클은 참조가 거의 필요 없는(reference-light) 원칙적인 토대를 제공합니다. 이는 코드 생성과 통계적 타당성 사이의 간극을 메워, 전통적인 소프트웨어 엔지니어링 도구가 감지할 수 없는 "코드 불투명한" 오류를 해결할 수 있는 유능한 LLM을 지원합니다.

저자들은 한계점을 명시합니다: 오라클은 보편적인 인증서가 아닙(예측 분포가 동일하다면 인과적 구조 오류를 감지할 수 없으며, 고차원 SBC 비용 문제로 어려움을 겪음). 그러나 이는 LLM이 범하는 일반적인 통계적 오류에 대해서는 강력한 검증 도구입니다.