에이전트가 같은 과제를 세 번 중 한 번은 해결합니다. pass@k와 반복 실행의 신뢰도는 어떻게 다르게 해석하나요?

여러 시도 중 하나라도 성공하면 되는 상황과 매번 안정적으로 성공해야 하는 상황은 다릅니다. pass@k는 k번 안에 적어도 한 번 성공할 가능성을 보고, pass^k는 k번 모두 성공하는 신뢰도를 나타내는 데 사용됩니다. 후보 여러 개 중 검증된 하나를 고르는 코딩 탐색에는 전자가 유용할 수 있지만 사용자 요청을 한 번 처리하는 운영 서비스에는 후자의 일관성 관점도 중요합니다.

숫자의 전제를 확인합니다

각 시도의 성공 확률이 p이고 서로 독립이라고 가정하면 적어도 한 번 성공할 확률은 1-(1-p)^k, 모두 성공할 확률은 p^k입니다. p=0.75, k=3이면 약 98.4%와 42.2%로 크게 다릅니다. 이 수치는 독립·동일 분포 가정의 설명 예이지 실제 에이전트의 보장값이 아닙니다. 같은 어려운 입력·도구 장애·모델 오해 때문에 실패가 상관되면 직접 반복 trial로 분포를 측정해야 합니다.

여러 후보 중 성공한 것을 선택하려면 무엇이 성공인지 판정할 검증기가 필요합니다. 최종 답변만 보고 가장 그럴듯한 후보를 고르면 oracle처럼 실제 성공을 알고 선택한 pass@k와 운영 성능이 다릅니다. 외부 예약·결제를 여러 번 시도해 하나만 성공하면 된다는 방식은 중복 효과 때문에 안전하지 않을 수 있습니다. 재시도가 허용되는 작업과 멱등성·승인 범위를 함께 봅니다.

분산과 비용을 함께 보고합니다

평가 과제마다 반복 실행하고 과제별 성공률·변동성·실패 유형을 남깁니다. 전체 평균이 높아도 특정 사용자 유형이나 도구에서 계속 실패할 수 있습니다. 표본이 작으면 불확실성이 크므로 시도 수·과제 수·예산·환경을 함께 공개하고 근거 없는 소수점 정밀도를 피합니다. 모델·프롬프트를 바꿀 때 같은 초기 환경과 예산에서 대조합니다.

재시도 횟수를 늘리면 해결률은 오를 수 있지만 비용·지연·안전 위반 노출도 늘 수 있습니다. 한 번의 성공 비용이 아니라 실패 시도를 포함한 해결 한 건당 총비용과 최대 지연을 봅니다. 안전하게 보류하거나 사용자에게 넘기는 동작도 별도 지표로 평가합니다. 최근 에이전트 평가에서 반복 신뢰도를 강조하는 이유는 시연의 한 번 성공이 실제 운영의 안정적 성공과 같지 않기 때문입니다.

실행 사례로 확인합니다

여러 과제의 평균 성공 확률을 먼저 구한 뒤 그 값에 k승을 하는 것은 과제별 모두 성공 확률을 평균한 값과 다를 수 있습니다. 쉬운 과제와 어려운 과제의 분포가 섞여 있기 때문입니다. 따라서 과제별 반복 결과를 남기고 어떤 집계 방식인지 설명합니다. 시도가 이전 시도의 피드백을 사용했다면 독립 재시도와 다른 실험입니다. 피드백·추가 예산·후보 선택 도구를 포함한 전체 절차를 평가해야 합니다. 운영에서는 재시도에 사용자가 기다리는 시간과 외부 효과의 중복 위험이 있으므로 높은 pass@k를 얻었다는 이유만으로 재시도 횟수를 계속 늘리지 않습니다. 신뢰도 지표는 실제 사용자 경험과 맞는 목적에서 선택합니다.