When are likely answers right? On Sequence Probability and Correctness in LLMs
https://arxiv.org/abs/2606.27359
Johannes Zenn, Jonas Geiping | Max Planck Institute for Intelligent Systems, ELLIS Institute Tübingen, AI Center Tübingen, University of Tübingen, IMPRS-IS | arXiv:2606.27359 | 2026년 6월
대규모 언어 모델의 답변은 항상 어떤 확률분포에서 나온다. 모델은 다음 토큰마다 조건부 확률을 계산하고, 디코딩 알고리즘은 그 확률을 더 날카롭게 만들거나, 낮은 확률 토큰을 잘라내거나, 여러 완성문 중 점수가 높은 문장을 고르는 방식으로 최종 출력을 만든다. 직관적으로는 모델이 더 그럴듯하다고 여긴 답이 더 맞을 것 같지만, 실제 운영에서는 beam search가 오히려 성능을 떨어뜨리거나 self-consistency에서 확률 가중 투표가 단순 다수결보다 나빠지는 사례가 계속 나온다. 이 논문은 그 간극을 정면으로 묻는다. 시퀀스 확률이 높다는 사실은 언제 정확도를 의미하는가, 그리고 언제 그 신호를 디코딩 의사결정에 써도 되는가가 핵심 질문이다.
저자들은 이 문제를 단일 상관계수 하나로 압축하지 않는다. 같은 데이터셋 안에서 여러 문제-답 쌍을 비교할 때, 한 디코딩 방법의 하이퍼파라미터를 바꿀 때, 서로 다른 디코딩 방법을 비교할 때, 그리고 같은 프롬프트에 대한 반복 샘플 안에서 답을 비교할 때 확률-정답 관계가 서로 다르게 움직인다고 본다. 실험은 Qwen3, Qwen2.5, Qwen2.5-Math, Olmo3 계열의 base/posttrained 모델과 MATH500, GPQA, HumanEval, IFEval, MedQA, MMLU 여섯 벤치마크를 대상으로 진행된다. 평가 대상 디코딩도 low-temperature sampling, top-k, top-p, epsilon sampling, beam search, best-of-N, scalable power sampling, power-SMC까지 넓다.
가장 중요한 결론은 부정확한 낙관론을 걷어낸다는 점이다. 논문은 고정된 데이터셋 안에서는 확률이 꽤 유용한 신호가 될 수 있다고 보고한다. 특히 모델이 이미 어느 정도 문제를 맞히는 영역, 예컨대 MATH500에서는 높은 로그확률과 높은 정확도가 강하게 맞물린다. 그러나 그 신호는 곧장 디코딩 선택 규칙으로 이전되지 않는다. 하이퍼파라미터를 조정해 더 높은 확률의 문장을 만들거나, 다른 방법으로 더 probable한 문장을 골라도 정확도가 안정적으로 좋아지지는 않는다. 따라서 이 논문은 “확률은 쓸모없다”보다 더 미묘한 메시지를 낸다. 확률은 어떤 granularity에서 측정하느냐에 따라 신뢰도가 달라지는 운영 신호다.
1. 서론: 높은 확률의 답이 곧 정답이라는 직관의 균열
LLM 디코딩을 다룰 때 흔히 쓰는 설명은 “모델이 가장 그럴듯하게 생각하는 토큰을 고른다”는 식이다. 하지만 토큰 수준의 그럴듯함과 완성 답변 수준의 정확도는 같은 개념이 아니다. 자동회귀 모델은 프롬프트 $\bar{\mathbf{s}}$가 주어졌을 때 continuation $\mathbf{s}=(s_1,\dots,s_T)$의 확률을 $p(\mathbf{s}\mid\bar{\mathbf{s}})=\prod_{t=1}^{T}p(s_t\mid\bar{\mathbf{s}},\mathbf{s}_{<t})$로 계산한다. 이 값은 문장이 모델 분포 안에서 얼마나 자연스러운지를 말해 주지만, 수학 문제의 정답 여부, 코드 생성의 테스트 통과 여부, 지시문 형식 준수 여부를 직접 보장하지는 않는다.
그럼에도 많은 디코딩 방법은 이 확률을 더 높은 방향으로 밀어 올리도록 설계되어 있다. temperature를 낮추면 낮은 확률 토큰이 억제되고, top-k와 top-p는 후보 집합을 제한하며, best-of-N은 여러 문장을 뽑은 뒤 전체 시퀀스 확률이 큰 것을 남긴다. 최근 power sampling 계열은 full sequence 확률분포 자체를 $p(\mathbf{s}\mid\bar{\mathbf{s}})^\alpha$처럼 재가중해 고확률 영역을 더 강하게 샘플링하려 한다. 이런 방법들이 성공하려면 한 가지 전제가 필요하다. 확률을 높이면 정답 가능성도 함께 올라가야 한다.
이 전제는 학습 데이터 관점에서 그럴듯하다. 언어 모델은 대체로 올바른 텍스트와 자연스러운 풀이를 많이 보며 학습하므로, 모델 내부 확률은 정답에 대한 어느 정도의 암묵적 confidence를 담을 수 있다. 그러나 이미 알려진 반례도 많다. beam search는 번역·요약·추론에서 반복적이고 짧거나 장황한 출력을 만들 수 있고, 가장 probable한 문장이 가장 useful한 답이 아닌 경우도 흔하다. 모델이 높은 확률을 부여하는 것은 “훈련 분포에 익숙하다”는 뜻일 수 있으며, 어려운 문제의 올바른 풀이처럼 드문 경로에는 낮은 확률이 붙을 수 있다.
이 논문의 출발점은 그래서 단순한 찬반이 아니다. 질문은 확률과 정확도의 상관 여부를 묻는 데서 멈추지 않고, 그 상관이 어느 비교 단위에서 유지되는가로 이동한다. 같은 데이터셋 안의 쉬운 문제와 어려운 문제를 비교하면 확률이 난이도와 맞물릴 수 있다. 같은 문제에 대해 32개의 답을 뽑아 비교하면 오히려 확률 차이가 정답 차이를 잘 설명하지 못할 수 있다. 한 방법의 temperature를 바꿀 때도, 다른 방법을 바꿔 쓸 때도 상황은 다시 달라진다. 이 granularity 구분이 논문의 핵심 설계다.
Figure 1: 확률-정답 관계를 across-method, within-dataset, within-sample 세 수준으로 나눈 요약도
Figure 1은 논문 전체의 문제 설정을 압축한다. 왼쪽은 디코딩 방법과 하이퍼파라미터를 바꾸며 로그확률과 정확도가 함께 움직이는지 보는 관점이고, 가운데는 같은 방법 안에서 여러 문제-답 쌍을 binning해 정확도를 보는 관점이며, 오른쪽은 같은 프롬프트의 반복 샘플만 비교하는 관점이다. 같은 “확률과 정답의 상관”이라는 표현이라도 비교 단위가 달라지면 실험적 의미가 완전히 달라진다는 점을 먼저 고정한다. 특히 가운데와 오른쪽의 차이는 self-consistency를 해석할 때 중요하다. 문제 간 난이도 신호와 같은 문제 내부 선택 신호를 분리해야 하기 때문이다.
1.1 문제의식: confidence, decoding, self-improvement가 만나는 지점
이 질문은 디코딩 성능 분석을 넘어 verifier-free self-improvement와 연결된다. 만약 모델 확률이 답의 품질을 안정적으로 반영한다면 별도 보상모델이나 외부 검증기 없이도 높은 확률 답을 골라 self-consistency 투표를 하거나, 그 답을 다시 distillation 데이터로 사용할 수 있다. 실제로 최근 reasoning 연구에서는 rollouts를 여러 개 뽑고, 그중 더 좋은 답을 골라 학습하는 방식이 널리 쓰인다. 문제는 “더 좋은 답”을 판정하는 기준이 항상 정답 라벨이나 verifier로 제공되지 않는다는 데 있다. 확률 자체가 신뢰 가능한 대리 지표라면 운영 비용은 크게 줄어든다.
반대로 확률 신호가 잘못 쓰이면 모델은 자기가 이미 좋아하는 형태의 답만 강화하게 된다. instruction following 문제에서 형식은 그럴듯하지만 요구 조건을 놓치는 답, 코드 문제에서 자연스러운 설명은 길지만 테스트는 통과하지 못하는 답, 수학 문제에서 자주 보이는 풀이 패턴을 따라가다 마지막 계산이 틀리는 답이 모두 여기에 해당한다. 확률 기반 선택이 이런 답을 더 자주 남긴다면 self-improvement는 개선 루프에서 벗어나 bias amplification 루프로 바뀐다.
| 비교 단위 | 고정되는 조건 | 묻는 질문 | 논문이 보고한 핵심 결론 |
|---|---|---|---|
| Within-dataset | 모델·데이터셋·디코딩 방법·대표 하이퍼파라미터 | 여러 문제-답 쌍에서 로그확률이 높은 답이 더 맞는가 | 대체로 양의 상관이 있고 MATH500에서 강하다. IFEval base 모델은 음의 상관이 나타난다. |
| Within-method | 모델·데이터셋·디코딩 방법 | 하이퍼파라미터를 바꿔 더 probable한 답을 만들면 정확도도 오르는가 | 확률은 올라가도 정확도는 일관되게 오르지 않는다. 방법·모델·데이터셋별 튜닝이 필요하다. |
| Across-method | 모델·데이터셋 | 서로 다른 디코딩 방법 중 더 높은 확률 답을 만드는 방법이 더 정확한가 | 일부 green cell은 있지만 전체적으로 heterogeneous하다. 어떤 방법도 LTS baseline을 안정적으로 이기지 못한다. |
| Within-sample | 하나의 프롬프트와 반복 샘플 집합 | 같은 문제에 대한 여러 답 중 더 probable한 답이 더 맞는가 | 상관계수는 대체로 0 주변에 대칭적으로 분포한다. 모델이 이미 잘 푸는 프롬프트에서만 양의 경향이 강해진다. |
2. 배경 및 관련 연구: 디코딩은 확률 질량을 어떻게 옮기는가
2.1 로컬 디코딩: 다음 토큰 분포를 매 시점에서 바꾸는 방법
로컬 디코딩은 각 prefix에서 다음 토큰 분포를 직접 변형한다. low-temperature sampling은 $p(s_t\mid\bar{\mathbf{s}},\mathbf{s}_{<t})^\alpha$를 정규화해 높은 확률 토큰을 더 강하게 만든다. top-k는 확률이 큰 k개 토큰만 남기고, top-p는 누적 확률이 임계값을 넘는 최소 후보 집합을 남기며, epsilon sampling은 확률이 일정 값보다 큰 토큰만 유지한다. 이 계열의 공통점은 전체 시퀀스 확률을 직접 최적화하기보다, 매 토큰의 local normalization을 거친 분포에서 샘플링한다는 점이다.
이 차이는 작아 보이지만 중요하다. 로컬 temperature를 낮춘다고 해서 full sequence 수준의 power distribution을 정확히 샘플링하는 것은 아니다. 각 prefix마다 정규화 상수 $ ilde{Z}_\alpha(\bar{\mathbf{s}},\mathbf{s}_{<t})$가 달라지고, 그 값은 이미 생성된 토큰 경로에 의존한다. 따라서 토큰 수준에서 “고확률 토큰을 더 자주 고른다”는 사실과 시퀀스 수준에서 “고확률 완성문을 더 자주 고른다”는 사실 사이에는 구조적 간극이 생긴다. 논문은 이 간극 때문에 로컬 방법의 확률 상승이 정확도 상승으로 곧장 해석되지 않는다고 본다.
2.2 글로벌 디코딩: 완성 시퀀스의 모드와 power distribution
글로벌 방법은 완성 시퀀스 전체를 대상으로 한다. beam search는 근사적으로 가장 높은 확률의 시퀀스를 찾는 search 절차이고, best-of-N은 N개의 샘플 중 시퀀스 확률이 가장 큰 답을 남긴다. N이 커지면 best-of-N은 원래 분포의 mode에 가까워진다. power distribution은 여기서 한 걸음 더 나아가 $p_\alpha(\mathbf{s}\mid\bar{\mathbf{s}})=p(\mathbf{s}\mid\bar{\mathbf{s}})^\alpha/Z_\alpha(\bar{\mathbf{s}})$로 정의되는 full sequence 분포를 생각한다. $\alpha>1$이면 높은 확률 시퀀스의 질량이 더 커지고 낮은 확률 시퀀스는 약해진다.
power distribution은 이론적으로 매력적이지만 실제 LLM에서는 정규화 상수 $Z_\alpha$를 직접 계산할 수 없다. 논문은 scalable power sampling(SPS)과 power-SMC를 실험에 포함한다. SPS는 블록 단위 후보를 만들고 rollout으로 미래 확률 질량을 추정하며, power-SMC는 여러 particle을 이용해 sequence-level 재가중을 근사한다. 이 방법들은 확률 질량을 global하게 고확률 영역으로 옮기려는 시도라는 점에서 top-k/top-p와 다르다. 그러나 논문의 실험은 이 global한 확률 이동도 정확도 개선을 보장하지 못한다고 보여 준다.
| 방법 계열 | 대표 방법 | 확률을 높이는 방식 | 주의할 점 |
|---|---|---|---|
| 로컬 온도 조절 | Low-temperature sampling | 각 토큰 분포를 $p^\alpha$로 날카롭게 만들어 낮은 확률 토큰을 억제 | prefix별 정규화 때문에 full sequence power distribution과 동일하지 않다. |
| 로컬 truncation | Top-k, Top-p, epsilon sampling | 다음 토큰 후보 집합을 제한해 낮은 확률 토큰을 제거 | 후보 집합 밖의 정답 경로가 잘릴 수 있고 데이터셋별 민감도가 크다. |
| 모드 탐색 | Beam search, Best-of-N | 완성 시퀀스 확률이 큰 답을 검색하거나 샘플 중 선택 | beam search는 반복·길이 bias가 생길 수 있고 BoN은 N에 따라 비용이 커진다. |
| Power distribution | SPS, Power-SMC | 시퀀스 확률을 지수 재가중해 high-probability 영역을 더 자주 샘플링 | 추정 비용이 크고, 확률 상승이 correctness 상승을 의미하려면 task별 조건이 맞아야 한다. |
2.3 확률은 confidence인가, familiarity인가
모델 확률을 confidence로 읽는 관점은 calibration 연구와 맞닿아 있다. 하지만 sequence probability는 단순한 confidence score가 아니다. 답변 길이, 토큰화, 언어적 관습, 지시문 형식, posttraining에서 선호된 스타일이 모두 섞인다. 예를 들어 같은 최종 답을 담아도 장황한 chain-of-thought와 짧은 직접 답변은 시퀀스 확률이 다르게 계산된다. 수학 문제에서는 단계별 풀이가 익숙한 패턴을 따를 때 확률이 높아질 수 있지만, 실제 정답 여부는 마지막 수식과 boxed answer에 달려 있다.
이 논문이 기여하는 부분은 확률을 하나의 universal quality score로 취급하지 않는다는 데 있다. 모델 확률이 어떤 조건에서 useful한지를 분해하고, 그 신호가 디코딩 방법 선택·하이퍼파라미터 튜닝·반복 샘플 투표·self-distillation으로 옮겨갈 때 어디서 끊기는지 보여 준다. 기존의 모델 불확실성 보정 논의가 “모델 점수가 신뢰 가능한가”를 묻는다면, 이 논문은 “그 점수를 어느 비교 단위에 적용할 때 신뢰 가능한가”를 묻는다.
3. 방법론: 확률-정답 관계를 네 가지 granularity로 분해하기
3.1 기본 정의와 측정량
실험의 기본 단위는 프롬프트와 완성문 쌍이다. 프롬프트 $\bar{\mathbf{s}}$에 대해 모델이 완성문 $\mathbf{s}$를 만들면, 논문은 해당 완성문의 로그확률 $\log p(\mathbf{s}\mid\bar{\mathbf{s}})$와 correctness label $y\in\{0,1\}$를 함께 기록한다. correctness는 벤치마크별 채점 기준에 맞춘다. MATH500과 GPQA, MMLU, MedQA는 최종 선택지나 boxed answer를 추출하고, HumanEval은 코드 평가, IFEval은 instruction following 조건을 기준으로 한다. 이때 로그확률은 연속값이고 정답 여부는 이진값이므로, 상관 분석에는 Spearman rank correlation과 binned Pearson correlation이 함께 쓰인다.
binned Pearson correlation은 로그확률 값을 같은 개수의 bin으로 나누고 각 bin의 평균 로그확률과 평균 정확도를 계산한 뒤 Pearson $r$을 구한다. 이 방식은 correctness label이 이진이라 raw Pearson이 불안정해질 수 있는 문제를 줄인다. Spearman $ ho$는 rank 기반의 단조 관계를 본다. 논문은 시각화마다 두 지표를 섞어 쓰되, 주된 메시지는 특정 계수 하나의 절대값보다 패턴의 방향과 granularity별 차이에 둔다. 특히 within-dataset에서는 binned trend가 눈에 잘 보이고, within-sample에서는 per-sample rank correlation이 핵심이다.
3.2 네 수준의 granularity
첫째, within-dataset correlation은 모델·데이터셋·디코딩 방법·하이퍼파라미터를 고정하고 여러 프롬프트-답 쌍을 비교한다. 이 수준에서 양의 상관이 나타난다는 것은 같은 세팅 안에서 모델이 높은 확률을 준 답이 더 쉬운 문제 혹은 더 안정적으로 맞는 문제와 연결된다는 뜻이다. 둘째, within-method correlation은 같은 모델과 데이터셋에서 한 디코딩 방법의 하이퍼파라미터를 바꾸며 평균 로그확률과 정확도 변화를 본다. temperature, k, p, beam 수, N, block size 같은 조절 변수가 여기에 들어간다.
셋째, across-method correlation은 low-temperature sampling을 baseline으로 두고 여러 방법의 최적 또는 대표 하이퍼파라미터가 어느 quadrant에 놓이는지 확인한다. 어떤 방법이 baseline보다 높은 확률과 높은 정확도를 동시에 보이면 green signal이고, 높은 확률이지만 낮은 정확도라면 확률 기반 선택에 경고를 준다. 넷째, within-sample correlation은 하나의 프롬프트에 대해 여러 답을 반복 생성한 뒤 그 안에서 확률과 정답 여부가 맞물리는지 본다. self-consistency나 best-of-N이 실제로 쓰는 단위와 가장 가까운 수준이 바로 이 within-sample이다.
Figure 2: Qwen3-8B-Base와 SPS B=192에서 데이터셋별 로그확률-정답률 상관
Figure 2는 fixed method·fixed model 안에서 문제-답 쌍을 비교할 때 확률 신호가 얼마나 다르게 보이는지 보여 준다. MATH500은 bin 평균이 거의 직선적으로 올라가며 양의 상관이 뚜렷하지만, IFEval은 base 모델 조건에서 반대 방향을 보인다. GPQA, HumanEval, MedQA, MMLU는 중간 정도의 양의 경향이다. 같은 로그확률이라도 벤치마크가 요구하는 능력과 모델의 훈련 상태에 따라 의미가 달라진다는 점이 드러난다.
3.3 실험 설계가 겨냥하는 운영 질문
네 수준의 구분은 실제 운영 질문과 대응된다. within-dataset 결과가 좋으면 모델 확률을 confidence-like score로 써서 후처리나 abstention에 활용할 여지가 있다. within-method 결과가 좋으면 temperature나 top-k 같은 하이퍼파라미터를 확률 기준으로 자동 조정할 수 있다. across-method 결과가 좋으면 새로운 디코딩 방법을 평가할 때 평균 로그확률 상승을 proxy metric으로 쓸 수 있다. within-sample 결과가 좋으면 여러 답 중 확률 높은 것을 고르거나 확률 가중 self-consistency를 적용할 수 있다.
논문의 결론은 이 네 운영 질문 중 일부에만 긍정적이다. within-dataset은 꽤 유망하지만, within-method와 across-method는 불안정하고, within-sample은 대체로 약하다. 그래서 확률은 “문제 집합 안에서 어떤 답이 더 신뢰로운지”를 알려 주는 데는 도움이 되지만, “어떤 디코딩 방법을 고를지”나 “같은 문제의 여러 답 중 무엇을 채택할지”를 단독으로 결정하기에는 부족하다. 이 차이는 실제 서비스에서 모델 확률 로그를 어떻게 저장하고, 어느 단위로 집계해야 하는지까지 영향을 준다.
4. 실험 설정: 모델, 벤치마크, 디코딩 방법을 넓게 교차하기
4.1 모델과 벤치마크
실험은 세 모델 계열을 중심으로 구성된다. Qwen3 series는 0.6B, 1.7B, 4B, 8B 크기의 base와 posttrained 모델을 포함하고, Qwen2.5 및 Qwen2.5-Math 8B, Olmo3 7B의 base/posttrained 모델이 추가된다. 논문 본문은 계산 비용 때문에 non-thinking posttrained 모델을 중심으로 보고하고, Qwen3 thinking 모드는 appendix에서 token limit과 관련된 ablation으로 다룬다. 이는 최근 reasoning 모델을 평가할 때 “생각을 더 오래 하면 좋아진다”는 단순 가정이 계산 제약 아래에서 깨질 수 있음을 보여 주는 부가 실험이기도 하다.
벤치마크는 여섯 개다. MATH500은 수학 추론, GPQA와 MMLU는 선택형 지식·추론, HumanEval은 코드 생성, MedQA는 의료 선택형 문제, IFEval은 instruction following을 담당한다. 논문은 대부분의 데이터셋에서 500개 프롬프트를 쓰며, GPQA는 445개를 사용한다. 모든 모델과 데이터셋은 non-empty response를 생성할 수 있는 shared prompt set으로 맞춰져 있고, 각 method·dataset 조합은 H100 80GB GPU 기준 하루 안에 끝나는 예산으로 제한된다. 긴 출력은 3072 token으로 제한된다.
| 데이터셋 | 프롬프트 수 | 주요 능력 | 확률-정답 관계에서 관찰된 특징 |
|---|---|---|---|
| MATH500 | 500 | 수학 추론과 최종 정답 추출 | within-dataset 상관이 가장 강하고 power self-consistency 이득도 비교적 뚜렷하다. |
| GPQA | 445 | 고난도 과학 선택형 추론 | 양의 경향은 있으나 MATH500보다 약하고 방법 간 이질성이 크다. |
| HumanEval | 500 | 코드 생성과 실행 기반 평가 | 확률이 코드 correctness를 일부 반영하지만 반복 샘플 선택 신호로는 제한적이다. |
| IFEval | 500 | 지시문 형식 준수 | base 모델에서는 음의 상관이 나타나며 posttraining 여부가 큰 차이를 만든다. |
| MedQA | 500 | 의료 선택형 문제 | 중간 정도의 양의 상관이 관찰되지만 dataset/method별 변동이 남는다. |
| MMLU | 500 | 지식·추론 선택형 문제 | power self-consistency가 일관되게 좋아지지 않고 probability weighting도 조심스럽게 써야 한다. |
4.2 디코딩 하이퍼파라미터와 계산 제약
디코딩 방법은 총 8개다. SPS는 block size $B\in\{96,192,384\}$, power-SMC는 particle 수 $N\in\{8,16,32\}$, low-temperature sampling은 temperature 계열, beam search는 beam 수 $b\in\{1,2,3\}$, BoN은 $N\in\{8,16,32\}$, top-k는 $k\in\{8,16,32\}$, top-p는 $p\in\{0.8,0.9,0.95\}$, epsilon sampling은 여러 cutoff를 둔다. 본문 요약 그림에서는 각 방법별 canonical hyperparameter를 선택해 평균적인 패턴을 보지만, within-method 분석에서는 극단 하이퍼파라미터 간 이동 방향이 핵심이다.
구현 측면에서는 로컬 sampling 대부분이 vLLM을 통해 실행되고, power-SMC는 기존 저자 코드, SPS는 논문 알고리즘을 따라 구현된다. SPS는 후보 block을 만들고 top 후보를 남긴 뒤, rollout horizon을 이용해 future probability mass를 importance weighting으로 추정한다. 계산 예산은 실험 설계의 중요한 일부다. SPS와 power-SMC는 단순 sampling보다 비싸기 때문에 trajectory length와 모델 크기, prompt 수가 모두 제한된다. 따라서 결과는 “무한 계산에서 최적 디코딩을 찾으면 어떨까”라는 이상화보다, 실제 GPU budget 아래에서 쓸 수 있는 probability-seeking 방법이 무엇을 해 주는지를 보여 준다.
| 디코딩 방법 | 논문에서 쓰는 대표 하이퍼파라미터 | 확률 관점의 역할 | 운영 해석 |
|---|---|---|---|
| LTS | temperature 계열, canonical $\alpha=4$ | 낮은 온도로 로컬 분포를 sharp하게 만든 baseline | 다른 방법의 확률·정확도 차이를 비교하는 기준점으로 쓰인다. |
| BoN | $N=32$ | 여러 샘플 중 시퀀스 확률이 큰 답을 고른다 | mode 탐색에 가깝지만 샘플 수 증가 비용과 diversity 감소 문제가 있다. |
| SPS | $B=192$ | 블록 단위 rollout으로 power distribution을 근사한다 | 수학처럼 확률-정답 관계가 강한 영역에서 이득 가능성이 보인다. |
| Power-SMC | $N=32$ | particle 기반 sequential Monte Carlo로 sequence-level 재가중을 한다 | global 확률 조작이 항상 정확도 개선으로 이어지지는 않는다. |
| Top-k | $k=8$ | 상위 k개 토큰만 남겨 낮은 확률 경로를 제거한다 | 로컬 후보 제한은 task마다 유리·불리가 갈린다. |
| Top-p | $p=0.9$ | 누적 확률 질량 기준으로 후보 집합을 만든다 | 분포 tail을 줄이지만 정답 경로가 tail에 있을 때 손실이 생긴다. |
| Beam search | $N=2$ | 높은 확률 sequence를 search로 찾는다 | length normalization과 반복 문제가 있어 확률 상승의 해석이 까다롭다. |
| epsilon sampling | $\varepsilon=0.0009$ | 확률 cutoff 아래의 토큰을 제거한다 | cutoff 값이 모델·데이터셋별로 민감할 수 있다. |
4.3 베이스라인과 비교 기준
논문에서 LTS는 사실상 anchor 역할을 한다. across-method 분석에서는 LTS의 특정 temperature를 원점으로 삼아 다른 방법이 확률과 정확도에서 어느 quadrant에 놓이는지 본다. 이 설정은 실용적이다. 실제 서비스에서는 완전히 탐욕적인 decoding보다 낮은 온도의 sampling을 기본값으로 두고, 더 복잡한 method가 그 baseline을 얼마나 이기는지 본다. 따라서 논문이 “어떤 방법도 LTS를 안정적으로 이기지 못한다”고 할 때 그 의미는 강하다. 더 비싼 디코딩이 평균 확률을 높이더라도, 정확도와 비용을 함께 보면 자동 채택할 근거가 부족하다는 뜻이다.
또 하나의 비교 기준은 base와 posttrained 모델의 차이다. base 모델은 언어 분포를 잘 모델링하지만 instruction format이나 benchmark-specific answer extraction에는 약할 수 있다. posttrained 모델은 인간 선호, 지시문 준수, 답변 형식에 맞춰 조정되어 있기 때문에 같은 로그확률이라도 correctness와의 연결이 달라진다. IFEval에서 base 모델의 음의 상관이 두드러지는 것은 이 지점과 맞물린다. 확률이 높은 continuation이 instruction을 따르는 답일 수도 있지만, base 모델에게는 그저 그럴듯한 continuation일 뿐일 수 있다.
5. 주요 실험 결과: 확률은 데이터셋 안에서는 말하지만 디코딩 선택에는 침묵한다
5.1 Within-dataset: 문제-답 쌍 사이의 확률 신호
가장 긍정적인 결과는 within-dataset 수준에서 나온다. 같은 모델, 같은 데이터셋, 같은 디코딩 방법과 하이퍼파라미터를 고정한 뒤 여러 prompt-answer pair를 비교하면, 로그확률과 correctness 사이에 일관된 양의 상관이 자주 관찰된다. 특히 MATH500에서는 상관이 강하다. 이는 모델이 수학 문제 중 자기가 더 잘 풀 수 있는 영역과 덜 잘 푸는 영역을 어느 정도 분포 안에 반영하고 있다는 뜻이다. 쉬운 문제나 익숙한 풀이 패턴은 높은 확률과 높은 정답률을 동시에 갖는다.
그러나 이 패턴도 보편적이지 않다. IFEval base 모델에서는 음의 상관이 나타난다. 지시문을 정확히 따르는 답은 base 모델 입장에서는 학습 분포상 가장 자연스러운 continuation이 아닐 수 있다. 예를 들어 특정 형식, 금지 단어, 구조적 출력 조건은 posttraining 이전 모델에게 외부 제약처럼 보인다. 따라서 모델이 높은 확률을 주는 문장은 언어적으로 자연스럽지만 instruction을 위반할 수 있고, 낮은 확률 경로에 오히려 정확한 format compliance가 있을 수 있다. 이 결과는 확률을 correctness proxy로 쓸 때 task ontology를 먼저 확인해야 함을 말한다.
Figure 3: 모델 family와 dataset에 따라 달라지는 within-dataset 상관 구조
Figure 3은 within-dataset 상관이 방법보다 데이터셋과 모델 variant에 더 크게 좌우된다는 점을 보여 준다. posttrained 모델은 대체로 양의 상관을 보이고, base 모델은 IFEval에서 음의 상관이 커진다. MATH500은 모델 family와 방법이 달라도 강한 양의 패턴이 반복된다. 따라서 확률 신호의 유용성은 “어떤 디코딩을 썼는가”보다 “모델이 해당 task를 어떤 방식으로 배웠는가”에 더 가까이 붙어 있다.
5.2 Within-method: 하이퍼파라미터 튜닝의 함정
within-method 분석은 더 냉정하다. 한 디코딩 방법을 고정하고 하이퍼파라미터를 조정하면 평균 로그확률은 대체로 변한다. temperature를 낮추거나 후보 집합을 좁히거나, 더 많은 sample 중 높은 확률 답을 고르면 당연히 더 probable한 시퀀스를 얻기 쉽다. 하지만 정확도는 같은 방향으로 안정적으로 따라오지 않는다. 논문은 극단 하이퍼파라미터를 연결한 slope를 색으로 표시해, 확률 상승과 정확도 변화가 같은 방향인지 다른 방향인지 보여 준다. 결과는 green과 blue 계열이 뒤섞이며 method·model·dataset마다 다르다.
이 결과는 매우 실용적이다. 많은 서비스에서는 validation set 없이 temperature나 top-p를 “확률이 높아지는 방향”으로 조정하고 싶은 유혹이 있다. 그러나 이 논문에 따르면 확률만 보고 하이퍼파라미터를 고르는 전략은 위험하다. 어떤 데이터셋에서는 더 probable한 출력이 더 맞지만, 다른 데이터셋에서는 더 틀릴 수 있다. 특히 로컬 방법은 prefix별 정규화와 length effect 때문에 시퀀스 확률의 변화가 correctness 변화와 분리된다. 결국 하이퍼파라미터는 method·model·dataset 단위의 실제 task metric으로 튜닝해야 한다.
Figure 4: Qwen3 계열에서 디코딩 하이퍼파라미터를 바꿀 때 확률과 정확도가 함께 움직이는지
Figure 4는 한 방법 안에서 하이퍼파라미터를 바꾸는 것이 안정적인 개선 규칙이 되지 못함을 보여 준다. 셀 색은 확률 방향과 정확도 방향의 조합을 나타내며, 같은 방법도 데이터셋과 모델 크기에 따라 다른 색을 띤다. 더 높은 로그확률을 얻는 조정이 자주 가능해도, 그것이 곧 더 높은 정확도로 연결되지는 않는다. 이 그림은 “확률을 높이는 디코딩 튜닝”과 “성능을 높이는 디코딩 튜닝”을 분리해서 봐야 함을 잘 보여 준다. 따라서 배포 전 sweep에서는 평균 로그확률뿐 아니라 실제 task metric을 같은 표에 붙여야 한다. 색이 섞이는 구간은 자동 튜닝보다 검증기나 held-out set이 필요한 영역이다.
5.3 Across-method: 더 복잡한 방법은 LTS를 안정적으로 넘지 못한다
across-method 분석에서는 LTS baseline을 기준으로 각 방법이 확률과 정확도에서 어느 방향으로 이동하는지 본다. 많은 green cell은 존재한다. 즉 어떤 모델·데이터셋 조합에서는 특정 방법이 LTS보다 더 높은 확률과 더 높은 정확도를 동시에 만든다. MATH500에서는 이런 경향이 비교적 강하다. 하지만 전체 표는 균질하지 않다. yellow cell은 더 높은 확률을 얻고도 정확도가 낮아지는 경우이고, blue cell은 확률은 낮지만 정확도는 좋아지는 경우다. 둘 다 확률을 단독 proxy로 쓰기 어렵게 만든다.
논문이 강조하는 점은 oracle hyperparameter를 고른 뒤에도 어떤 방법이 모든 데이터셋에서 안정적으로 baseline을 이기지 못한다는 것이다. 이는 SPS나 power-SMC 같은 global probability-seeking method를 부정하는 결과라기보다, 그들이 작동하는 조건을 좁혀 준다. 수학처럼 모델이 이미 정확한 경로에 높은 확률을 주는 task에서는 power distribution이 유리할 수 있다. 그러나 지시문 준수, 코드, 일반 지식 선택형 문제처럼 correctness가 다른 구조적 조건에 묶여 있으면 probability seeking은 흔들린다.
Figure 5: 여러 디코딩 방법이 baseline보다 높은 확률과 정확도를 동시에 얻는지 비교
Figure 5는 method-level 선택 문제를 직접 보여 준다. 초록 셀은 고확률·고정확도 방향이지만, 노랑과 파랑 셀이 함께 나타난다는 점이 중요하다. 이는 평균 로그확률을 높이는 방법이 항상 좋은 디코더라는 뜻이 아님을 말한다. 특히 beam search는 length normalization과 search bias 때문에 덜 probable하고 덜 정확한 방향으로 보이는 경우가 있고, power 계열도 dataset별로 이득이 분산된다. 실제 적용에서는 방법 이름보다 task별 validation이 우선이다.
5.4 Accuracy가 낮을 때 확률 신호도 약해진다
논문은 within-dataset correlation이 정확도 자체와도 연결된다고 보고한다. 모델이 이미 충분히 맞히는 영역에서는 높은 확률 답과 정답이 더 잘 맞물린다. 반대로 모델이 거의 못 푸는 영역에서는 확률이 높아도 그것이 정답을 가리키지 못한다. 이는 직관적이지만 중요한 운영 조건이다. 확률 기반 self-improvement가 작동하려면 모델이 정답 분포 근처에 어느 정도 도달해 있어야 한다. 완전히 틀린 영역에서 확률은 정확도를 탐색하는 signal에서 벗어나, 모델이 익숙하게 틀리는 방식을 강화하는 signal이 될 수 있다.
이 결과는 verifier-free 학습 루프의 안전장치와도 연결된다. 모델 확률을 이용해 데이터를 걸러내려면 먼저 해당 task에서 모델의 base accuracy나 calibration 상태를 추정해야 한다. 예를 들어 MATH500처럼 일정 정확도 이상이 확보된 영역에서는 확률로 sample filtering을 하는 것이 성능을 높일 수 있다. 그러나 IFEval base 모델처럼 instruction alignment가 부족한 영역에서는 높은 확률 샘플을 모으면 오히려 format violation을 강화할 가능성이 있다. probability-based pipeline은 항상 task-level readiness check와 함께 설계되어야 한다.
Figure 6: 정확도가 높아질수록 확률-정답 상관도 커지는 경향
Figure 6은 확률 신호가 모델 능력에 조건부라는 메시지를 강화한다. 왼쪽과 오른쪽 패널 모두에서 평균 정확도가 올라갈수록 로그확률과 correctness의 상관이 더 긍정적으로 움직이는 경향이 보인다. 이는 probability-based self-improvement가 cold start 해결책이 되기 어렵다는 뜻이다. 모델이 이미 어느 정도 task를 풀 수 있을 때 확률은 좋은 샘플을 고르는 보조 신호가 되지만, 능력이 부족한 영역에서는 확률 자체가 정답 탐색을 대신하지 못한다.
| 결과 축 | 긍정적 해석 | 부정적 해석 | 실무적 결론 |
|---|---|---|---|
| Within-dataset | 같은 세팅 안에서 확률은 쉬운/맞는 답을 어느 정도 가리킨다 | IFEval base처럼 task mismatch가 있으면 반대 방향도 가능하다 | confidence-like score로 쓰려면 task별 calibration 확인이 필요하다. |
| Within-method | 하이퍼파라미터가 확률 분포를 실제로 조절한다 | 확률을 높이는 튜닝이 정확도를 안정적으로 높이지 않는다 | validation metric 없이 확률 기준 자동 튜닝은 피해야 한다. |
| Across-method | 일부 방법은 baseline보다 확률·정확도를 동시에 높인다 | 어떤 방법도 여러 dataset에서 일관된 우위를 보이지 않는다 | 복잡한 디코딩은 task별 cost-benefit 검증 후 채택해야 한다. |
| Within-sample | 모델이 이미 잘 푸는 prompt에서는 양의 경향이 생긴다 | 대부분 상관이 0 주변에 대칭적으로 분포한다 | 확률 가중 투표보다 단순 다수결이 더 안전할 수 있다. |
6. 추가 분석 및 Ablation Study: self-consistency와 power sampling의 경계
6.1 Within-sample: 같은 프롬프트 안에서는 확률이 약하다
within-sample 분석은 self-consistency와 직접 연결된다. 같은 프롬프트에서 32개의 답을 뽑았을 때, 그 답들 중 로그확률이 높은 것이 더 맞는가를 본다. 결과는 대체로 0 주변에 대칭적이다. 즉 어떤 문제에서는 높은 확률 답이 맞고, 어떤 문제에서는 낮은 확률 답이 맞으며, 전체적으로는 확률이 반복 샘플 내부의 정답 선택 기준으로 강하지 않다. MATH500만 예외적으로 양의 평균을 보이지만, 그마저도 prompt가 쉬워서 여러 답이 많이 맞는 경우에 더 강하다.
이 차이는 within-dataset과 대비된다. 여러 문제를 비교할 때 확률이 유용한 이유는 문제 난이도와 모델의 익숙함이 함께 반영되기 때문이다. 하지만 하나의 문제 안에서 생성된 여러 답은 모두 같은 prompt 조건을 공유한다. 남는 차이는 decoding stochasticity, reasoning path, answer extraction, 길이, 표현 방식 같은 세부 요인이다. 이 수준에서 확률은 정답 여부를 안정적으로 구분할 만큼 강하지 않다. 따라서 “여러 답 중 가장 높은 확률 답을 고르자”는 단순 규칙은 기대만큼 안전하지 않다.
Figure 7: 반복 샘플 내부에서 로그확률과 정답 여부의 상관이 대부분 0 주변에 놓이는 모습
Figure 7은 같은 프롬프트 내부 비교가 왜 어려운지 보여 준다. base와 posttrained 모델 모두 correlation coefficient가 0 주변에 넓게 퍼지며, MATH500을 제외하면 평균적으로 강한 양의 신호가 잘 보이지 않는다. 오른쪽 패널은 prompt별 correct fraction이 높을수록 상관이 커지는 경향을 보여 주지만 표준편차가 크다. 따라서 확률은 “이 prompt가 모델에게 쉬운가”를 반영할 수 있어도, “이 prompt의 답 중 무엇을 고를까”에는 약한 신호다.
6.2 Self-consistency: 확률 가중 투표가 항상 낫지 않다
self-consistency는 여러 reasoning sample을 뽑고 최종 답을 다수결로 고르는 방법이다. 여기서 자연스러운 변형은 각 답의 확률로 가중치를 주는 것이다. 확률이 correctness를 잘 반영한다면 probability-weighted voting은 uniform majority보다 나아야 한다. 그러나 논문은 low-temperature sampling 기반 self-consistency에서 확률 가중이 자주 손해를 본다고 보고한다. within-sample correlation이 약하거나 대칭적이면 높은 확률 답에 더 큰 표를 주는 것이 오히려 틀린 답을 강화할 수 있다.
power self-consistency는 power distribution에서 뽑은 샘플을 aggregation에 쓰는 변형이다. 이 방법은 MATH500에서는 plain self-consistency보다 개선되는 경우가 많지만, GPQA와 MMLU 같은 다른 데이터셋에서는 성능이 나빠지기도 한다. 이는 앞선 결과와 일관된다. MATH500에서는 확률-정답 관계가 강하고 power sampling이 더 좋은 영역을 더 자주 방문할 수 있다. 다른 task에서는 확률 재가중이 정답 구조를 잘 반영하지 못하므로 aggregation 단계에서 손실이 생긴다.
Figure 8: MATH500에서는 power self-consistency가 개선되지만 GPQA와 MMLU에서는 성능 저하도 보이는 결과
Figure 8은 power self-consistency의 조건부 유용성을 보여 준다. Qwen3 계열에서 MATH500은 power distribution 기반 sample을 쓰면 self-consistency 성능이 개선되는 경향이 있지만, GPQA와 MMLU에서는 오히려 떨어지는 구간이 보인다. 이 그림은 확률 기반 aggregation을 일반 해법으로 보기 어렵게 만든다. 모델이 이미 task를 잘 풀고, 확률이 correctness와 맞물리는 영역에서만 power sampling의 비용이 보상된다.
6.3 Self-distillation과 thinking mode 부가 실험
appendix의 self-distillation 실험도 같은 메시지를 반복한다. 저자들은 BoN, SPS, power-SMC sample을 이용해 LoRA self-distillation을 수행하고, 샘플의 전반부로 학습한 뒤 후반부에서 평가한다. MATH500처럼 확률-정답 상관이 있는 영역에서는 self-distillation이 비교적 잘 작동하고, power distribution sample이 baseline보다 나을 수 있다. 그러나 다른 데이터셋에서는 결과가 혼합적이며, 단순 LTS sample distillation이 더 나은 경우도 있다. 확률 기반 샘플링은 학습 데이터 품질을 자동 보장하지 않는다.
Qwen3 thinking mode ablation은 계산 제약의 중요성을 보여 준다. 같은 3072 token budget 아래에서 thinking 모델은 긴 구간을 생성하다가 최종 답에 도달하지 못할 수 있고, 일부 데이터셋에서는 성능이 떨어진다. 이는 reasoning 모델 평가에서 token budget과 stop condition을 분리해 다뤄야 함을 시사한다. 확률-정답 관계를 분석할 때도 답변 길이와 내부 reasoning trace가 로그확률에 영향을 주기 때문에, thinking mode와 non-thinking mode를 그대로 섞어 비교하면 해석이 흐려질 수 있다.
| 부가 분석 | 관찰된 결과 | 확률 신호에 대한 의미 |
|---|---|---|
| Probability-weighted self-consistency | LTS sample에서는 uniform majority가 더 나은 경우가 많다 | 같은 프롬프트 내부에서 확률이 정답을 충분히 구분하지 못한다. |
| Power self-consistency | MATH500에서는 개선, GPQA/MMLU에서는 저하도 관찰 | 확률-정답 상관이 강한 task에서만 power sample의 이득이 뚜렷하다. |
| Self-distillation | MATH500에서는 power sample이 도움이 될 수 있으나 다른 dataset은 혼합적 | 고확률 sample을 학습 데이터로 쓰려면 task별 검증이 선행되어야 한다. |
| Qwen3 thinking mode | token limit 때문에 답을 끝내지 못하는 사례가 생김 | reasoning trace 길이와 확률 비교를 함께 통제해야 한다. |
| Sequence length 분석 | beam search가 예외적으로 긴 sequence를 찾는 경향 | 길이 normalization과 로그확률 집계 방식이 method 비교에 영향을 준다. |
7. 한계점 및 향후 연구 방향: 확률 신호를 운영 지표로 만들기까지
7.1 실험 범위와 라벨링 한계
가장 큰 한계는 실험이 여섯 벤치마크와 몇 개 오픈 모델 계열에 집중되어 있다는 점이다. Qwen과 Olmo 계열은 최신 오픈 모델 연구에 적합하지만, 폐쇄형 frontier model이나 multimodal agent, tool-use agent, long-context retrieval 시스템까지 일반화하려면 추가 실험이 필요하다. 특히 tool-use 환경에서는 sequence probability가 자연어 답변과 함께 action schema, tool argument, observation history에 의해 결정된다. 그런 환경에서 “높은 확률의 action”이 task success와 어떤 관계를 갖는지는 별개의 문제다.
correctness label도 task마다 성격이 다르다. MATH500의 boxed answer, HumanEval의 테스트 통과, IFEval의 instruction compliance는 모두 이진 라벨로 표현되지만 오류 구조가 다르다. 수학에서는 최종 수치가 맞으면 긴 풀이의 일부 비약을 용인할 수 있고, IFEval에서는 내용이 맞아도 형식 조건을 어기면 틀린다. 이처럼 라벨의 의미가 다르면 로그확률과의 상관도 달라진다. 논문은 이 차이를 데이터셋별 결과로 보여 주지만, 왜 특정 task에서 상관이 생기거나 깨지는지에 대한 causal 분석은 아직 깊지 않다.
7.2 비용과 token budget의 영향
SPS와 power-SMC는 계산 비용이 크다. 논문은 H100 80GB 기준 하루 예산과 3072 token 제한을 둔다. 이 제약은 현실적이지만, 동시에 결과 해석의 일부다. 더 긴 reasoning budget, 더 많은 particle, 더 큰 sample size를 주면 power distribution 근사가 달라질 수 있다. 특히 thinking model은 token budget 안에서 답을 끝내지 못하는 문제가 나타났기 때문에, 긴 chain-of-thought를 적극적으로 쓰는 모델에서는 확률과 correctness의 관계가 다른 양상을 보일 수 있다.
또한 sequence probability는 길이에 민감하다. raw log-probability는 토큰 수가 길어질수록 더 작아지므로, per-token average log-probability를 쓰는지, length normalization을 쓰는지, 최종 답만 점수화하는지에 따라 해석이 달라진다. 논문 appendix는 sum log-prob와 average log-prob를 비교하고, beam search의 길이 특성도 확인한다. 하지만 실제 서비스에서는 답변 형식과 verbosity를 정책적으로 제어하기 때문에, 확률 신호를 운영 metric으로 쓰려면 길이 보정과 answer extraction 기준을 별도로 설계해야 한다.
7.3 향후 연구: granularity-aware decoding policy
향후 연구는 granularity를 알고 있는 decoding policy로 갈 수 있다. 예를 들어 within-dataset 수준에서 확률이 유용하다면, 먼저 프롬프트 난이도나 모델 confidence를 추정하고, 그 값이 충분히 높은 영역에서만 probability-weighted aggregation을 켤 수 있다. 반대로 확률-정답 상관이 약한 영역에서는 다수결, verifier, external tool, retrieval grounding을 우선하도록 라우팅할 수 있다. 이 접근은 모든 입력에 같은 decoding method를 적용하는 대신, task와 prompt 상태에 따라 확률 신호의 신뢰도를 평가한다.
또 다른 방향은 correctness를 단일 이진값으로 보지 않고 부분 credit, format compliance, reasoning consistency, final answer correctness로 분해하는 것이다. IFEval base 모델의 음의 상관은 모델이 자연스러운 continuation과 지시문 준수를 다른 방식으로 평가하고 있음을 암시한다. 그러면 sequence probability 전체보다 특정 span, final answer token, constraint-relevant token의 확률을 따로 보는 방법이 필요할 수 있다. 확률 신호를 잘 쓰려면 “전체 문장 점수”보다 “어느 부분의 확률을 어떤 라벨과 비교할 것인가”가 더 중요해진다.
| 한계 축 | 논문에서 드러난 제약 | 후속 연구 아이디어 |
|---|---|---|
| 모델 범위 | Qwen/Qwen2.5/Olmo 중심의 오픈 모델 실험 | 폐쇄형 frontier model, agent model, multimodal model로 확장해 비교한다. |
| 태스크 범위 | 여섯 benchmark가 텍스트·코드·선택형 중심 | tool-use, long-context RAG, GUI agent task에서 action probability와 성공률을 분석한다. |
| 계산 예산 | SPS/Power-SMC는 1일 H100 예산과 3072 token 제한 | 긴 reasoning budget과 더 큰 particle/sample size에서 결과가 유지되는지 본다. |
| 라벨 구조 | correctness를 대체로 이진값으로 취급 | format, final answer, reasoning validity, evidence grounding을 분해한 다중 라벨 상관 분석을 한다. |
| 운영 적용 | 확률 신호의 사용 여부를 task별로 수동 해석 | granularity-aware routing으로 확률 기반 선택, verifier, 다수결을 조건부 조합한다. |
8. 내 해석: 확률을 조건부 운영 신호로 읽기
나는 이 논문의 가장 좋은 지점이 “확률이 맞는가 틀리는가”라는 질문을 피하고, 확률을 어디에 쓰려는가로 질문을 바꾼 데 있다고 본다. 이전에 정리한 [[concepts/model-uncertainty-calibration]] 흐름은 모델 점수와 실제 정답률을 맞추는 문제를 다뤘고, speculative decoding 관련 페이지들은 draft token의 확률과 acceptability를 운영 속도 관점에서 봤다. 이번 논문은 그 사이에 놓인다. 확률은 모델 내부에서 매우 쉽게 얻을 수 있는 값이지만, 그것을 confidence, decoder selection, self-consistency weight, distillation filter로 옮겨 쓰는 순간 비교 단위가 달라진다. 이 단위 이동을 명시하지 않으면 확률 기반 최적화가 자기 합리화가 되기 쉽다.
내가 가장 걸리는 약점은 실험이 “확률 신호가 왜 깨지는가”를 충분히 causal하게 분해하지는 못한다는 점이다. 예를 들어 IFEval base 모델에서 음의 상관이 나온 이유를 instruction-following 데이터 부족이나 형식 제약으로 해석할 수 있지만, 실제로 어느 token span의 확률이 format violation과 연결되는지까지 보지는 않는다. HumanEval에서도 전체 sequence log-probability가 낮은 올바른 코드가 왜 생기는지, boilerplate나 docstring, 함수명, 최종 로직 중 어떤 부분이 점수를 흔드는지 더 잘라 볼 수 있다. 이 논문은 granularity를 네 수준으로 나누는 데 성공했지만, sequence 내부 granularity까지 내려가지는 않는다.
내가 이걸 확장한다면 먼저 span-level probability attribution을 붙여 볼 것 같다. 최종 답 토큰, reasoning step, format token, tool argument token을 분리하고, 각 부분의 로그확률이 correctness component와 어떻게 연결되는지 본다. 수학에서는 boxed answer 근처의 확률이 전체 풀이 확률보다 더 강한 신호일 수 있고, IFEval에서는 constraint keyword나 forbidden pattern 주변의 확률이 전체 continuation보다 더 중요할 수 있다. 이렇게 하면 probability-weighted self-consistency도 전체 답 확률 대신 final answer confidence와 reasoning diversity를 함께 보는 방식으로 바꿀 수 있다.
운영 관점에서는 이 논문이 verifier-free self-improvement에 좋은 제동장치를 제공한다고 본다. 모델이 이미 충분히 잘하는 영역에서는 확률이 샘플 필터로 도움이 되지만, 낮은 정확도 영역에서는 확률이 모델의 익숙한 오답을 강화할 수 있다. 따라서 자동 데이터 생성 파이프라인에서는 먼저 task별 base accuracy와 within-dataset calibration을 측정하고, 일정 기준을 넘는 경우에만 probability-based filtering을 켜야 한다. 기준을 못 넘는 영역에서는 verifier, retrieval, symbolic checker, human spot-check 같은 외부 신호가 먼저 들어가야 한다. 이 조건부 설계가 없으면 고확률 샘플은 학습 데이터 품질 보증을 대신하지 못하고 분포적 보수성의 다른 이름이 된다.
8.1 확률 로그를 실제 시스템에 남길 때의 설계 기준
확률 로그를 운영 시스템에 남길 때는 전체 sequence log-probability 하나만 저장하면 해석력이 부족하다. 최소한 최종 답변 길이, 평균 token log-probability, final answer span의 log-probability, 디코딩 방법과 하이퍼파라미터, answer extraction 성공 여부를 함께 남겨야 한다. 이 논문의 결과를 서비스 로그에 적용한다면, 같은 프롬프트의 반복 답변을 비교하는 테이블과 여러 프롬프트를 비교하는 테이블을 분리해야 한다. 둘을 섞어 평균을 내면 within-dataset에서 유용했던 신호를 within-sample decision에 잘못 적용하게 된다. 특히 self-consistency 결과를 저장할 때는 각 sample의 확률뿐 아니라 최종 answer cluster, cluster별 vote 수, cluster 내부 평균 확률을 함께 기록해야 한다.
Calibration dashboard를 만든다면 첫 화면은 데이터셋 단위의 binned reliability plot이 되어야 한다. 로그확률을 10개 bin으로 나누고 각 bin의 실제 정답률을 표시하면, 확률이 task 난이도와 맞물리는지 빠르게 볼 수 있다. 그 다음 화면에서 method별 hyperparameter sweep을 보여 주어야 한다. 여기서 확률이 올라가는데 정확도가 내려가는 구간이 보이면, 그 method는 probability-seeking 목적으로 쓰기보다 diversity 확보나 fallback 생성 용도로 제한하는 편이 낫다. 마지막으로 prompt-level repeated sample plot을 두어 probability-weighted voting이 실제로 안전한지 확인해야 한다.
이 설계는 model uncertainty calibration과도 다르다. 일반 calibration은 예측 확률과 정답률의 정합성을 보지만, 생성형 LLM에서는 무엇이 예측 확률인지가 모호하다. 전체 문장 확률, 마지막 답 토큰 확률, 선택지 토큰 확률, 추론 경로 확률이 서로 다른 의미를 가진다. 이 논문의 granularity 구분은 그런 모호성을 줄이는 출발점이다. “로그확률이 높으니 confidence가 높다”는 식의 단일 문장보다, “이 task의 within-dataset binned correlation은 양수이고, within-sample correlation은 약하므로 abstention에는 쓸 수 있지만 vote weighting에는 쓰지 않는다”처럼 정책 문장으로 바꾸는 것이 더 안전하다.
| 로그 항목 | 저장 이유 | 잘못 쓰면 생기는 문제 |
|---|---|---|
| 전체 sequence log-probability | 문제-답 쌍 수준의 난이도와 모델 familiarity를 추적한다. | 길이와 verbosity 효과를 correctness로 오해할 수 있다. |
| 평균 token log-probability | 답변 길이 차이를 일부 보정한다. | 짧고 단순한 답을 과대평가할 수 있다. |
| Final answer span score | 실제 채점되는 구간의 confidence를 따로 본다. | 풀이 과정의 오류를 놓칠 수 있다. |
| Answer cluster와 vote 수 | self-consistency에서 확률과 다수결을 분리해 분석한다. | 확률 높은 minority answer를 무비판적으로 채택할 수 있다. |
8.2 디코딩 정책으로 옮길 때의 조건부 분기
디코딩 정책으로 옮기면 이 논문은 단일 best method를 주지 않는다. 대신 조건부 분기표를 준다. 첫째, validation set에서 within-dataset correlation이 높고 base accuracy도 충분하면 확률 기반 filtering이나 abstention을 켤 수 있다. 둘째, within-sample correlation이 낮으면 확률 가중 self-consistency를 끄고 uniform majority를 기본값으로 둔다. 셋째, across-method 결과가 heterogeneous하면 복잡한 power sampling을 전역 기본값으로 쓰지 말고, 수학처럼 이득이 확인된 task family에만 붙인다. 이 세 분기는 비용과 품질을 동시에 줄이는 현실적인 정책이다.
나는 특히 fallback routing과의 결합이 중요하다고 본다. 모델이 여러 sample을 생성했는데 확률이 높지만 vote cluster가 갈라지고, final answer span score도 낮다면 그 입력은 verifier나 external tool로 보내는 것이 낫다. 반대로 vote cluster가 모이고 전체 확률과 final answer score가 함께 높다면 빠른 응답으로 처리할 수 있다. 이 구조는 확률을 최종 판정자로 만들지 않고, 사람 검수·검증기·추가 샘플링을 언제 호출할지 정하는 trigger로 사용한다. 논문이 보여 준 negative result는 이런 routing 설계의 근거가 된다.
Power sampling도 같은 방식으로 배치할 수 있다. 모든 프롬프트에 power-SMC를 돌리면 계산비가 커지고, 확률-정답 관계가 약한 task에서는 품질 이득도 불확실하다. 그러나 MATH500류 문제에서 모델 정확도가 이미 높고 within-dataset correlation이 강하다면, power self-consistency를 선택적으로 켜는 것이 합리적이다. 이때도 단순히 확률이 큰 답을 고르는 것이 아니라, power sample이 만드는 answer cluster가 LTS cluster와 어떻게 다른지 비교해야 한다. 정답 cluster가 커지고 diversity가 유지될 때만 비용을 지불할 가치가 있다.
| 상황 | 권장 정책 | 근거 |
|---|---|---|
| 높은 base accuracy와 강한 within-dataset 상관 | 확률 기반 sample filtering 또는 abstention 사용 | 모델이 이미 정답 영역 근처에 있어 확률이 품질을 일부 반영한다. |
| 낮은 within-sample 상관 | uniform majority 또는 verifier 우선 | 같은 프롬프트 내부에서 높은 확률 답이 정답을 안정적으로 가리키지 않는다. |
| 확률은 높지만 answer cluster가 분산 | 추가 샘플링, 도구 검증, 사람 검수로 라우팅 | 모델 confidence와 집단적 일관성이 충돌하는 신호다. |
| MATH류 고정답 task에서 power sample 이득 확인 | 선택적 power self-consistency 적용 | 논문에서 MATH500은 확률-정답 상관과 PSC 이득이 함께 관찰된다. |
8.3 이전 리뷰들과의 연결: agent 평가와 probability proxy의 공통 위험
이 논문은 겉으로는 디코딩 논문이지만, 최근 agent 평가 논문들과도 같은 문제를 공유한다. agent trace에서 progress score, tool success count, retrieval score, log-probability 같은 proxy metric은 모두 실제 task success보다 측정하기 쉽다. 그러나 proxy가 어떤 단위에서만 유효한지 확인하지 않으면, 시스템은 proxy를 높이는 방향으로 최적화된다. Progress Advantage류 논문이 trajectory 진행도를 별도의 보상 신호로 읽을 때도, 그 신호가 최종 성공과 언제 어긋나는지 분석해야 한다. 이번 논문은 그 원칙을 LLM 디코딩 확률에 적용한 사례다.
RAG와 tool-use에서도 유사한 위험이 있다. retrieval score가 높은 문서가 최종 답의 근거가 되지 않을 수 있고, tool call likelihood가 높은 action이 실제 환경에서는 위험할 수 있다. sequence probability는 이런 proxy 중 가장 모델 내부에 가까운 값이다. 내부 값이기 때문에 싸고 항상 얻을 수 있지만, 외부 task success와의 정합성은 별도로 검증해야 한다. 이 논문이 보여 준 granularity-aware 분석은 retrieval score, tool routing score, agent memory score에도 그대로 확장할 수 있다. 같은 query 집합 안에서 유용한 score가 같은 query의 후보 문서 비교에서는 약할 수 있고, 같은 task family에서 유용한 score가 다른 family에서는 반대로 작동할 수 있다.
후속 실험으로는 agent benchmark에서 action log-probability와 success를 네 수준으로 나눠 보는 것이 흥미롭다. 여러 task 사이에서 높은 action probability가 성공률과 맞물리는지, 한 task 내부의 여러 trajectory 중 probability가 높은 trajectory가 더 성공적인지, tool별 하이퍼파라미터를 바꿀 때 probability와 success가 함께 움직이는지를 비교할 수 있다. 만약 이번 논문과 비슷한 패턴이 나온다면, agent 시스템에서도 probability는 task triage에는 쓸 수 있지만 action selection에는 부족하다는 결론이 나올 수 있다. 이 연결이 내가 이 논문을 단순 decoding paper보다 넓게 보는 이유다.
9. 결론: 확률은 좋은 힌트지만 디코딩의 만능 기준은 아니다
이 논문은 LLM 디코딩을 둘러싼 오래된 직관을 정교하게 다시 쓴다. 더 높은 sequence probability는 많은 경우 더 자연스럽고 모델이 더 익숙하게 여기는 답을 의미한다. 고정된 데이터셋 안에서 여러 문제-답 쌍을 비교하면 이 값은 정답 가능성과 꽤 자주 맞물린다. 특히 모델이 이미 높은 정확도를 보이는 영역에서는 확률이 confidence-like signal로 작동한다. 그러나 이 사실은 디코딩 방법 선택, 하이퍼파라미터 조정, 반복 샘플 내부 선택으로 그대로 이전되지 않는다.
핵심 이유는 granularity의 차이다. 문제 간 비교에서 보이는 신호는 같은 문제 내부의 답 후보 비교와 다르다. 방법 간 비교에서 평균 로그확률이 올라가는 것은 정확도 향상과 다르다. 로컬 디코딩은 token-level 분포를 바꾸지만 sequence-level objective와 일치하지 않을 수 있고, global power sampling도 task가 그 신호를 지지할 때만 이득을 낸다. 따라서 확률을 활용하려면 먼저 어느 단위의 비교인지, 어떤 task에서 검증했는지, 모델이 그 task를 이미 어느 정도 풀 수 있는지 확인해야 한다.
실무적으로는 세 가지 원칙이 남는다. 첫째, 로그확률은 저장할 가치가 있다. 답변별 확률 로그는 모델 confidence와 task 난이도 분석에 도움을 준다. 둘째, 확률만으로 디코딩 하이퍼파라미터를 자동 조정하지 않는다. validation metric이 없는 확률 상승은 성능 상승의 증거가 아니다. 셋째, self-consistency나 distillation에서 확률 가중을 쓰려면 먼저 within-sample correlation을 확인한다. 단순 다수결이 더 안전한 상황이 많고, power self-consistency는 MATH500처럼 조건이 맞는 영역에서만 강점을 보인다.
결국 이 논문은 probability-aware decoding을 포기하자는 논문이 아니다. 오히려 확률 신호를 더 잘 쓰기 위한 사용 설명서에 가깝다. 확률은 모델 내부에서 저렴하게 얻을 수 있는 귀중한 정보지만, 그 의미는 task, 모델, 방법, 비교 단위에 따라 달라진다. “높은 확률 답은 언제 맞는가”라는 질문에 대한 답은 “모델이 이미 충분히 잘 알고 있고, 비교 단위가 문제-답 쌍 수준으로 맞을 때”에 가깝다. 그 바깥에서는 확률이 힌트로는 유용해도, 최종 의사결정자는 아니다.
9.1 연구자가 바로 재현해 볼 수 있는 점검 절차
이 논문을 다른 모델이나 사내 태스크에 옮길 때 첫 단계는 데이터셋 단위 binned correlation을 만드는 것이다. 프롬프트별로 여러 답을 만들기 전에, 고정된 디코딩 설정 하나에서 문제-답 쌍을 충분히 모으고 로그확률 bin별 정답률을 계산한다. 이 곡선이 단조적으로 올라가면 모델 확률은 적어도 task difficulty와 연결되어 있다. 이때 전체 평균 정확도도 함께 봐야 한다. 평균 정확도가 너무 낮으면 bin이 올라가도 실제 정답 샘플 수가 부족해 self-improvement 데이터로 쓰기 어렵고, 평균 정확도가 너무 높으면 ceiling effect 때문에 확률 신호가 세밀한 선택 기준으로 남지 않을 수 있다.
두 번째 단계는 반복 샘플 내부 상관을 따로 보는 것이다. 같은 프롬프트에 대해 16개나 32개 답을 만들고, answer extraction으로 같은 최종 답끼리 cluster를 만든다. 그다음 cluster별 vote 수와 평균 로그확률을 비교하면 probability weighting이 다수결을 이길 가능성이 있는지 보인다. 높은 확률 cluster가 작은 vote를 갖고, 큰 vote cluster가 조금 낮은 확률을 갖는다면 확률 가중은 위험하다. 반대로 높은 확률과 큰 vote가 같은 cluster에 모이면 빠른 확정 정책을 둘 수 있다. 이 분석 없이 self-consistency weight를 바꾸는 것은 논문이 경고한 within-sample 함정에 들어가는 일이다.
세 번째 단계는 method sweep이다. temperature, top-p, best-of-N, beam, power sampling을 같은 evaluation split에서 돌리고, 각 method가 accuracy와 log-probability 평면의 어느 quadrant에 놓이는지 본다. 이 표는 새 디코더를 배포할 때 매우 유용하다. 어떤 방법이 확률만 높이고 정확도는 낮춘다면 그 방법은 “모델 confidence를 높인다”는 설명으로 배포해서는 안 된다. 정확도는 높이지만 확률은 낮추는 방법은 oracle-like verifier나 diversity 효과를 통해 이득을 내는 것일 수 있으므로 별도 해석이 필요하다. 확률과 정확도를 둘 다 높이는 방법만 기본 경로 후보가 된다.
네 번째 단계는 오류 유형 분해다. 이 논문의 IFEval 결과처럼 task가 요구하는 라벨이 형식 준수라면 전체 문장 확률이 틀린 방향으로 움직일 수 있다. 따라서 오류를 final answer mismatch, format violation, timeout, empty answer, hallucinated constraint, execution failure처럼 나눈 뒤 각 오류 유형의 평균 로그확률을 확인해야 한다. 오류 유형별로 확률 분포가 다르면 하나의 threshold로 거르기 어렵다. 예를 들어 format violation은 높은 확률에서 많이 생기고 final answer mismatch는 낮은 확률에서 많이 생길 수 있다. 이 경우 threshold 정책보다 오류 유형별 verifier가 더 적합하다.
| 재현 단계 | 필수 산출물 | 통과 기준 |
|---|---|---|
| Within-dataset binning | 로그확률 bin별 정답률 곡선 | 상관이 양수이고 평균 정확도가 충분할 때 confidence proxy 후보로 둔다. |
| Within-sample clustering | answer cluster, vote 수, cluster별 평균 확률 | 확률과 다수결이 충돌하지 않을 때만 probability weighting을 검토한다. |
| Across-method quadrant | baseline 대비 확률·정확도 변화표 | 확률과 정확도를 모두 높이는 method만 기본 배포 후보로 남긴다. |
| Error-type analysis | 오류 유형별 로그확률 분포 | 고확률 오류 유형이 있으면 threshold보다 targeted verifier를 둔다. |
9.2 실제 서비스에서 피해야 할 세 가지 단축 사고
첫 번째 단축 사고는 평균 로그확률 상승을 품질 개선으로 보고하는 것이다. 디코딩 변경 후 평균 로그확률이 올라가면 모델이 더 자신 있어 보이지만, 논문은 그 결과가 정확도와 어긋나는 사례를 여러 수준에서 보여 준다. 특히 method sweep에서 yellow cell이 많다면, 그 변경은 모델이 선호하는 문체나 길이로 출력을 몰아갔을 뿐 task success를 높이지 못했을 가능성이 크다. 따라서 배포 리포트에는 평균 로그확률과 함께 exact-match, execution success, instruction compliance, human preference 같은 외부 metric이 반드시 들어가야 한다.
두 번째 단축 사고는 확률 가중 self-consistency를 기본값으로 두는 것이다. 다수결은 단순하지만 서로 독립적인 reasoning path가 같은 final answer에 모이는지를 본다. 확률 가중은 여기에 모델의 preference를 다시 주입한다. 그 preference가 정답과 맞물리는 task에서는 유리하지만, within-sample correlation이 약한 task에서는 오답 cluster에 과도한 힘을 줄 수 있다. 논문 결과를 따르면 probability weighting은 기본값이 아니라 조건부 옵션이어야 한다. 먼저 task별 prompt-level correlation을 보고, 충돌 신호가 낮을 때만 켜는 편이 안전하다.
세 번째 단축 사고는 base 모델의 확률을 instruction-following confidence로 읽는 것이다. base 모델은 언어적으로 자연스러운 continuation을 잘 예측할 수 있지만, 특정 출력 형식이나 정책 제약을 따르도록 조정된 모델은 아니다. IFEval에서 base 모델의 음의 상관은 이 차이를 잘 드러낸다. posttraining 이후에는 같은 프롬프트에서 확률과 형식 준수가 더 잘 맞을 수 있지만, 그것도 데이터셋별로 확인해야 한다. 따라서 base model log-probability를 prompt filtering이나 synthetic data scoring에 쓸 때는 지시문 준수 라벨을 따로 검증해야 한다.
이 세 가지를 피하면 논문의 negative result는 오히려 제품 설계에 도움이 된다. 확률은 빠른 내부 신호이고, 검증기는 느리지만 외부 신호이며, 다수결은 샘플 집단의 일관성 신호다. 세 신호를 서로 대체재로 보지 말고, 서로 다른 failure mode를 잡는 보완재로 배치해야 한다. 확률이 높고 검증기도 통과하며 다수결도 모이면 자동 통과, 확률만 높고 검증이 실패하면 rejection, 확률은 낮지만 다수결과 검증이 강하면 low-probability correct path로 남겨 분석하는 식의 정책이 가능하다. 이때 논문의 granularity 구분은 각 신호의 책임 범위를 정하는 기준이 된다.
9.3 논문을 읽고 남는 가장 실용적인 기준
최소 검증 기준을 하나만 고르라면, 나는 “확률을 쓰려는 바로 그 수준에서 상관을 다시 계산했는가”를 보겠다. 데이터셋 안에서 sample을 거르는 데 쓸 값이면 within-dataset 곡선을 보고, 같은 프롬프트의 후보 답을 고르는 데 쓸 값이면 within-sample 곡선을 보아야 한다. 방법을 고르는 데 쓸 값이면 across-method quadrant를 봐야 하고, 하이퍼파라미터를 고르는 데 쓸 값이면 within-method slope를 봐야 한다. 이 네 질문을 섞지 않는 것만으로도 probability proxy의 오용은 크게 줄어든다.
두 번째 기준은 정확도 조건이다. 논문은 정확도가 높은 영역에서 확률-정답 상관이 더 잘 보인다고 보고한다. 따라서 확률 기반 자동화는 모델이 이미 못 푸는 영역을 해결하는 만능 장치로 쓰기보다, 어느 정도 풀 수 있는 영역에서 비용을 줄이고 sample selection을 개선하는 장치로 쓰는 편이 맞다. 낮은 정확도 영역에서는 확률 threshold를 올려도 좋은 답을 찾기보다 익숙한 오답을 더 고를 가능성이 있다. 그런 경우에는 retrieval, symbolic checker, executable tests, human feedback 같은 외부 신호가 먼저 필요하다.
세 번째 기준은 cluster와 확률의 충돌이다. 여러 답을 생성했을 때 다수결 cluster와 최고 확률 cluster가 서로 다르면, 그 입력은 자동 확정하지 않는 편이 안전하다. 이 충돌은 모델 내부 preference와 샘플 집단의 일관성이 서로 다른 답을 가리킨다는 뜻이다. 수학 문제라면 추가 계산 검증을 붙이고, 코드 문제라면 테스트를 실행하며, instruction following 문제라면 규칙 기반 checker를 붙일 수 있다. 확률은 여기서 결정을 내리는 값이 아니라, 더 비싼 검증을 호출할지 판단하는 신호가 된다.
마지막 기준은 보고 방식이다. 디코딩 변경을 실험한 리포트에서 “평균 로그확률이 상승했다”는 문장만 있으면 부족하다. 최소한 정확도 변화, 길이 변화, answer extraction 실패율, 반복 샘플 내부 상관, 데이터셋별 편차를 함께 보고해야 한다. 이 논문이 보여 준 핵심은 probability metric이 무의미하다는 뜻이 아니라, 단독 metric으로는 설명 책임을 다하지 못한다는 뜻이다. 확률은 좋은 진단 재료지만, 품질 결론으로 바뀌려면 외부 정답 신호와 같은 단위에서 다시 맞춰져야 한다.
또 하나 놓치기 쉬운 점은 벤치마크별 채점 함수가 확률 신호를 다르게 자른다는 사실이다. MATH500은 final answer extraction이 비교적 명확하고, 여러 reasoning path가 같은 수치로 수렴할 수 있다. 반면 IFEval은 답의 의미보다 조건 충족 여부가 중요하고, HumanEval은 코드가 자연스러워 보여도 실행 테스트를 통과해야 한다. 따라서 같은 sequence probability라도 수학에서는 난이도 신호, instruction following에서는 format mismatch 신호, 코드에서는 스타일 familiarity 신호로 읽힐 수 있다. 이 차이를 분리하지 않으면 하나의 threshold가 여러 태스크에서 서로 다른 오류를 만든다.
서비스 적용 관점에서 나는 확률 기반 정책을 항상 “빠른 1차 triage”로 둔다. 확률이 낮고 vote도 분산된 입력은 즉시 추가 검증으로 보내고, 확률이 높고 vote도 모인 입력은 빠르게 응답하되, 일정 비율은 사후 audit sample로 남긴다. 확률이 높지만 vote가 갈라지는 입력은 가장 위험한 영역이므로, 이 구간을 별도 dashboard로 모아야 한다. 논문이 제안한 네 granularity는 이런 dashboard의 축을 정하는 데 직접 쓸 수 있다. 결국 좋은 운영 정책은 확률을 믿는 정책이 아니라, 확률이 언제 흔들리는지 지속적으로 관찰하는 정책이다.
이 기준을 따르면 probability metric은 모델을 과신하게 만드는 장식이 아니라, 검증 비용을 어디에 써야 하는지 알려 주는 관측값이 된다. 높은 확률은 자동 승인 조건의 일부일 뿐이고, 낮은 확률은 즉시 실패 판정이 아니라 추가 근거 수집 요청일 수 있다. 중요한 것은 확률을 항상 동일한 단위의 정답 신호와 대조해 기록하는 습관이다.
따라서 이 논문을 적용할 때의 기본 태도는 보수적이어야 한다. 확률은 빠르게 계산되지만 정답 라벨을 대체하지 못하고, 정답 라벨은 비싸지만 모델 내부 선호를 설명하지 못한다. 두 신호를 함께 기록할 때만 디코딩 정책이 실제로 개선되는지 확인할 수 있다.
10. 요약 정리: 실무자가 가져갈 핵심 포인트
- 논문은 LLM의 sequence probability와 correctness 관계를 within-dataset, within-method, across-method, within-sample 네 수준으로 나눠 분석한다.
- 고정된 모델·데이터셋·디코딩 세팅 안에서는 높은 로그확률이 정답률과 양의 상관을 보이는 경우가 많고, 특히 MATH500에서 강하다.
- 하이퍼파라미터를 조정해 더 높은 확률의 출력을 얻어도 정확도는 일관되게 오르지 않으므로 확률 기준 자동 튜닝은 위험하다.
- 서로 다른 디코딩 방법을 비교할 때도 평균 로그확률 상승이 LTS baseline 대비 정확도 향상을 안정적으로 보장하지 않는다.
- 같은 프롬프트의 반복 샘플 안에서는 확률-정답 상관이 대체로 0 주변에 분포하므로 probability-weighted self-consistency는 조심해서 써야 한다.
- Power self-consistency와 power sampling은 MATH500처럼 모델이 이미 잘 풀고 확률-정답 상관이 강한 영역에서 더 설득력 있다.
- IFEval base 모델의 음의 상관은 모델 확률이 instruction compliance와 언어적 자연스러움을 구분하지 못할 수 있음을 보여 준다.
- 확률 기반 self-improvement를 적용하려면 task별 base accuracy, calibration, within-sample correlation을 먼저 확인해야 한다.
- 후속 연구는 전체 sequence probability를 final answer, format token, reasoning span, tool argument 같은 부분별 확률로 분해하는 방향이 유망하다.
'[논문 리뷰] > [최신 논문]' 카테고리의 다른 글
| [arXiv 2606.27669] DiscoBench: 질문해야 할 때를 아는 검색 에이전트 벤치마크 (0) | 2026.06.29 |
|---|---|
| [arXiv 2606.27161] TOPS: 비전 토큰 프루닝을 정보 원리에서 다시 설계하기 (0) | 2026.06.28 |
| [arXiv 2606.27330] PEEU for GUI Agents: 자율 경험 탐색과 사후 경험 활용으로 계획 능력 키우기 (0) | 2026.06.26 |
| [arXiv 2606.26080] Progress Advantage: LLM 에이전트의 진행도를 읽는 사후학습 신호 (0) | 2026.06.25 |
| [arXiv 2606.24855] OpenThoughts-Agent: 에이전트 모델을 위한 데이터 레시피 (1) | 2026.06.24 |