Pass@k와 Pass^k, 슬라이더로 직접 만져 보기
모델 발표 자료를 보다 보면 "Pass@1", "Pass@10" 같은 숫자가 꼭 나온다. 솔직히 나도 처음엔 대충 "정답률이겠지" 하고 넘겼다. 그러다 에이전트 평가 쪽 자료에서 pass^k라는 표기를 보고 나서야, 이게 비슷하게 생긴 전혀 다른 숫자라는 걸 알았다.
한 줄로 정리하면 이렇다.
- Pass@k: AI에게 같은 문제를 k번 풀게 했을 때, 그중 한 번이라도 맞힐 확률
- Pass^k: k번 시도(또는 k개 단계)가 전부 성공할 확률
설명보다 만져 보는 게 빠르다. 아래 슬라이더를 움직여 보자.
각 시도의 성공 확률이 같고, 서로 독립이라고 가정한 이론값이다.
1회 성공률 80%에 6번 시도하면 Pass@6은 99.99%, 거의 확실하다. 그런데 같은 조건에서 Pass^6은 26.21%밖에 안 된다. 같은 80%짜리 AI인데 숫자가 이렇게 갈린다.
AI에게 코딩 문제를 시킨다고 해 보자
개발자 관점에서 예를 들어 보면 이해가 쉽다. AI가 코드를 한 번 생성했을 때 테스트를 통과할 확률이 60%라고 가정하자.
- Pass@1: 한 번 생성해서 성공할 확률 → 60%
- Pass@3: 세 번 생성해서 하나라도 성공할 확률 → 1 − 0.4³ = 93.6%
- Pass@10: 열 번 생성해서 하나라도 성공할 확률 → 1 − 0.4¹⁰ ≈ 99.99%
각 시도가 독립이라고 가정하면 계산은 간단하다. "전부 실패할 확률"을 구해서 1에서 빼면 된다. 위 위젯의 성공률을 60%로 내려 놓고 k를 1, 3, 10으로 옮겨 보면 같은 숫자가 나온다.
이상하게 들릴 수 있는데, 60%짜리 모델도 열 번 돌리면 거의 100%가 된다. 여기까지만 보면 "그럼 그냥 여러 번 돌리면 되겠네?" 싶다. 나도 그렇게 생각했다. 이 생각이 어디서 틀리는지는 조금 뒤에서 다시 얘기하겠다.
왜 둘은 반대로 움직일까
Pass@k는 기회가 많을수록 유리하다. 같은 문제를 10번 풀게 하고 그중 맞는 거 하나만 골라 쓰면 되니까. 시도가 늘수록 "적어도 하나는 맞는다" 쪽으로 확률이 쌓인다.
Pass^k는 반대다. 단계가 늘어날수록 불리하다. 하나만 틀려도 전체가 실패니까, 곱할 때마다 확률이 깎인다.
AI 에이전트가 이런 보험 업무를 처리한다고 생각해 보자.
- 보험 청구서 분석
- 약관 검색
- 지급 여부 판단
- 결과 통보
각 단계 성공률이 95%면 꽤 잘하는 것처럼 들린다. 그런데 모든 단계가 성공해야 하고 단계끼리 독립이라면, 전체 업무를 오류 없이 끝낼 확률은 0.95⁴ = **81.45%**다. 다섯 건 중 한 건 가까이는 어딘가에서 틀린다.
각 단계의 성공 확률이 같고, 서로 독립이라고 가정한 이론값이다.
단계를 10개로 늘리면 59.9%, 20개면 35.8%까지 떨어진다. 각 단계를 99%로 끌어올려도 20단계면 81.8%다. 에이전트 데모가 그럴듯하게 돌아가는데 막상 운영에 올리면 이상하게 자주 깨지는 이유가 여기 있다고 본다. 데모는 한 번 성공하면 끝이지만, 운영은 매번 전 단계가 성공해야 하니까.
여담인데, 엄밀히 말하면 에이전트 평가에서 쓰는 pass^k는 "여러 단계"가 아니라 같은 작업을 k번 반복했을 때 k번 모두 성공할 확률이다. τ-bench가 이 지표를 내세웠는데, 매번 똑같이 잘 해내는지, 즉 일관성을 보려는 숫자다. 다단계 업무의 성공률과는 묻는 질문이 다르지만, "전부 성공해야 한다"는 구조라서 계산식은 똑같이 곱셈이 된다. 이 글에서는 둘을 같은 틀로 묶어서 설명했다.
핵심 차이
| Pass@k | Pass^k | |
|---|---|---|
| 성공 조건 | 한 번만 성공해도 OK | 전부 성공해야 OK |
| 횟수가 늘면 | 성공 확률 증가 | 성공 확률 감소 |
| 대표 사례 | 코딩 문제 여러 번 생성 | 에이전트 다단계 작업, 반복 일관성 |
Pass@k가 높다고 안심하면 안 되는 이유
앞에서 "여러 번 돌리면 되겠네?"라는 생각이 틀린다고 했는데, 이유는 이거다.
Pass@k가 높다는 건 AI가 여러 번 시도하면 정답을 만들어낼 가능성이 높다는 뜻이지, 그중 어느 게 정답인지 AI가 스스로 구별할 수 있다는 뜻은 아니다. 코딩 문제는 테스트 코드라는 채점기가 있어서 10개 중 통과한 걸 기계적으로 고를 수 있다. 그래서 Pass@k가 실제로 쓸모가 있다.
보험 심사나 금융 판단은 다르다. "지급 가능"과 "지급 불가" 답변이 섞여 나왔을 때 어느 쪽이 맞는지 판정해 줄 테스트가 없다. 다수결을 하면 되지 않나 싶기도 한데, 모델이 같은 방향으로 틀리는 경우에는 다수결이 오히려 틀린 답을 굳혀 버린다. 실제로 시도들이 독립이 아닌 경우가 많다는 게 이 계산 전체의 약점이기도 하다.
실무에서 보는 순서
채점기가 있는 일(코드·형식 검증)은 여러 번 생성하는 전략이 통한다. 채점기가 없는 일(판단·심사)은 여러 번 생성하는 것보다, 잘못된 판단을 검증하고 차단하는 장치를 먼저 만드는 게 낫다.
계산으로만 봐도 그렇다. 단계 사이에 "이 결과가 다음 단계로 넘어가도 되는가"를 확인하는 검증을 끼워 넣고, 걸리면 그 단계만 다시 시키면 각 단계의 실질 성공률이 올라간다. 그게 곱셈으로 누적되니까 차이가 생각보다 크다. 위젯에서 95%를 99%로 올려 보면 무슨 말인지 바로 보인다. 모델을 더 좋은 걸로 바꾸는 것보다 이쪽이 싸게 먹히는 경우도 꽤 있을 것 같다.
벤치마크 숫자는 이 계산과 조금 다르다
마지막으로 짚어 둘 것. 위 계산은 전부 "매 시도의 성공률이 같고 서로 독립"이라는 가정 위에 있다. 실제 LLM 벤치마크의 Pass@k는 이렇게 계산하지 않는 경우가 많다.
Codex 논문(HumanEval)에서 쓴 방식은 문제마다 n개(k보다 많이)를 생성하고 그중 c개가 맞았을 때, "n개 중 k개를 뽑았는데 전부 오답일 확률"을 조합으로 구해서 1에서 빼는 식이다.
pass@k = 1 − C(n−c, k) / C(n, k)문제마다 난이도가 다르니까 문제별로 이 값을 구해서 평균을 낸다. 그래서 "평균 Pass@1이 60%인 모델"의 Pass@10을 1 − 0.4¹⁰로 계산하면 실제보다 꽤 높게 나온다. 어려운 문제는 열 번을 돌려도 계속 틀리기 때문이다. 위젯의 숫자는 감을 잡는 용도로 보고, 벤치마크 표의 숫자와 그대로 비교하지는 않는 게 좋겠다.
아직 정리가 안 된 부분도 있다. 에이전트 운영 지표로 pass^k를 쓴다면 k를 몇으로 잡아야 할까? 업무마다 다를 것 같은데, 아직 기준을 못 정했다. 이건 실제로 돌려 보면서 다시 정리해 보려고 한다.
참고자료
- Evaluating Large Language Models Trained on Code (Chen et al., 2021) — Pass@k 비편향 추정식이 나온 Codex 논문
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (Yao et al., 2024) — 에이전트 일관성 지표로 pass^k를 쓴 논문