AI 에이전트의 신뢰성(Reliability)을 어떻게 측정할 것인가?
요약
AI 에이전트의 신뢰성을 측정할 때 단일 실행 결과가 아닌 확률 분포를 기반으로 평가해야 함을 강조합니다. 통과율(pass rate), 최저점(floor), 변동성(flakiness)을 관리하여 에이전트의 안정성을 확보하는 방법론을 제시합니다.
핵심 포인트
- 단일 실행 결과는 신뢰성이 아닌 운을 측정하는 것에 불과함
- 평균값보다 최악의 상황(worst case)인 최저점 관리가 중요함
- pass@k 개념을 도입하여 반복 실행을 통한 통과율을 측정해야 함
- 온도 조절 및 출력 형식 제한을 통해 의도적으로 분산을 줄여야 함
에이전트가 평가(eval)를 통과해서 제품을 출시했습니다. 그런데 다음 날, 사용자가 거의 동일한 입력을 보냈는데 실패합니다. 바뀐 것은 아무것도 없습니다. 당신은 방금 "통과했다"는 것이 하나의 분포(distribution) 중 단 하나의 샘플일 뿐이었으며, 당신은 앞면이 나온 동전 던지기에 걸고 제품을 출시했다는 사실을 깨달았습니다.
Part 1에서는 기준을 정의했습니다. Part 2에서는 이를 측정할 평가 세트(eval set)를 구축했습니다. Part 3는 불편한 부분입니다. 에이전트는 똑같은 답변을 두 번 하지 않기 때문에, 단 한 번의 성공적인 실행(green run)은 AI 에이전트의 신뢰성(reliability)에 대해 거의 아무것도 알려주지 않습니다.
한 번의 실행은 신뢰성이 아니라 운을 측정합니다
결정론적 함수(deterministic function)는 테스트를 통과하거나 통과하지 못하거나, 영원히 그 상태를 유지합니다. 하지만 에이전트는 확률 변수(random variable)입니다. 동일한 케이스를 열 번 실행하면, 아홉 번은 통과하고 한 번은 매우 확신에 찬 오답을 내놓을 수도 있습니다. 통과를 보여주는 단 한 번의 실행은 에이전트가 훌륭하다는 증거가 아니라, 당신이 한 번 운이 좋았다는 증거일 뿐입니다. 신뢰성(Reliability)은 체크 표시가 아닙니다. 그것은 분포(distribution)이며, 당신은 그 형태를 측정해야 합니다.
한 번의 추출이 아니라 분포를 측정하세요
- 모든 케이스를 여러 번 실행하세요. 통과 또는 실패가 아니라 통과율(pass rate)을 보고하세요. 만약 어떤 케이스가 10번 중 8번 통과한다면, 그것은 80%짜리 케이스이며, 당신은 사용자가 알기 전에 이를 알고 있어야 합니다. (이것이 pass@k의 개념입니다: 단 한 번이 아니라 반복된 샘플 전체에 걸친 점수)
- 평균이 아니라 최저점(floor)에 신경 쓰세요. 95%의 평균은 괜찮게 들리지만, 나머지 5%가 환불을 요청하거나 기록을 삭제하는 실행이라면 이야기가 달라집니다. 평균은 최악의 상황(worst case)을 숨기며, 당신을 타격하는 것은 바로 그 최악의 상황입니다. 이를 명시적으로 제한하세요.
- 변동성(flakiness)과 실패(failure)를 분리하세요. 문구의 차이와 같은 어느 정도의 분산(variance)은 해롭지 않습니다. 어떤 것은 실제 오답입니다. 만약 정확한 문자열 대신 속성(property)을 기준으로 채점한다면 (Part 2), 해롭지 않은 분산은 더 이상 실패로 집계되지 않으며, 정말 중요한 실패들이 눈에 보이게 될 것입니다.
의도적으로 분산을 줄이세요
분포를 확인할 수 있게 되면, 중요한 부분에서 그 범위를 좁히십시오. 일관성이 반드시 유지되어야 하는 호출(call)에는 온도를 낮추십시오(Lower the temperature). 오류가 발생할 수 있는 경로를 줄이기 위해 출력 형식(output format)을 제한하십시오. 부적격한 실패가 사용자에게 도달하기 전에 이를 잡아낼 수 있는 가드레일(guardrail)을 추가하십시오. 이 중 그 어떤 것도 에이전트를 결정론적(deterministic)으로 만들지는 않으며, 결정론을 쫓는 것은 잘못된 목표입니다. 목표는 신뢰할 수 있을 만큼 충분히 높은 하한선(floor)을 가지면서, 분포가 충분히 좁은(tight) 상태를 만드는 것입니다.
따라서 출시 여부를 결정하는 관문(release gate)은 "평가(eval)를 통과했다"가 아닙니다. 그것은 "수많은 실행에 걸친 통과율이 기준치를 넘었으며, 최악의 경우(worst case)가 제한 범위 내에 있다"입니다. 단 한 번의 실행에서 나온 녹색 체크표시는 결정 근거가 아니라, 단지 하나의 일화(anecdote)일 뿐입니다.
Part 4에서는 에이전트의 출시 여부를 결정하는 또 다른 제약 조건인, 실제 규모(real volume)에서 발생하는 지연 시간(latency)과 비용(dollars) 측면의 비용 문제를 다룹니다.
한 번 실행해서 측정했다면 그것은 운을 측정한 것입니다. 신뢰성(Reliability)은 단 한 번의 통과가 아니라, 분포(distribution)의 형태입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기