당신의 평가(Evals)도 불안정합니다: 재현할 수 없는 통과율을 신뢰하지 마세요
대부분의 사람들은 AI 에이전트가 비결정론적(non-deterministic)이라는 사실을 알고 있습니다. 동일한 프롬프트를 보내도 결과는 매번 다르게 나옵니다.
우리는 이를 받아들였습니다. 그리고 이러한 에이전트들을 채점하기 위해 LLM을 판사(judge)로 사용하기 시작했습니다.
하지만 우리는 큰 실수를 저질렀습니다. 판사가 결정론적일 것이라고 가정했던 것입니다. 하지만 판사는 그렇지 않습니다.
당신의 평가 스위트(eval suite)는 또 다른 무작위 시스템을 채점하는 무작위 시스템일 뿐입니다. 채점자가 얼마나 흔들리는지(wobbles) 측정하지 않는다면, 그것은 품질 게이트(quality gate)가 아니라 동전 던지기에 불과합니다.
저는 고객 지원 에이전트에서 이런 일이 발생하는 것을 목격했습니다. 대시보드는 몇 주 동안 초록색(정상)을 유지했습니다. 그러다 고객 불만이 급증했습니다. 과거 응답 200개에 대해 동일한 평가를 다시 실행해 보았습니다. 그중 14개의 판결이 바뀌었습니다. 에이전트가 변한 것이 아닙니다. 판사가 마음을 바꾼 것이었습니다.
불안정한 게이트는 게이트가 없는 것보다 더 나쁩니다. 잘못된 확신을 주기 때문입니다.
평가가 실패하는 데에는 세 가지 이유가 있습니다:
- 판사 모델: 모든 LLM 판사는 변동성(variance)을 가집니다. 온도가 0이라 하더라도, 제공업체는 동일한 결과를 보장하지 않습니다. 조용히 이루어지는 모델 업데이트가 하룻밤 사이에 기준점(baseline)을 망가뜨릴 수 있습니다.
- 하네스(Harness): 실행 사이에 컨텍스트나 도구 출력이 변경되면, 판사는 다른 질문을 받게 됩니다. 입력값이 드리프트(drift)된 것입니다.
- 루브릭(Rubric): "이것이 좋은가?"와 같은 모호한 규칙은 변동성을 만듭니다. 엄격하고 구체적인 규칙은 변동성을 줄여줍니다.
불안정한 평가는 불안정한 소프트웨어 테스트처럼 취급해야 합니다. 그대로 배포하지 마세요. 격리하십시오. 그리고 불안정성 비율(flake rate)을 측정하십시오.
단일 통과율을 보고하는 것을 멈추고, 일치도(agreement)를 보고하기 시작하십시오.
각 판사 호출을 여러 번 실행하십시오. 판사가 스스로의 결과에 동의하지 못한다면, 그 판결은 신호가 아닙니다. 그것은 UNSTABLE 상태입니다.
UNSTABLE 결과는 CI/CD 파이프라인에서 일급 객체(first-class outcome)로 취급되어야 합니다. 명확하게 실패를 드러내야 합니다.
불안정한 평가를 해결하려면 두 가지가 필요합니다:
- 스코어링 레이어(Scoring layer): 안정성을 계산하여 결과를 PASS, FAIL 또는 UNSTABLE로 변환합니다.
- 트레이싱 레이어(Tracing layer): 모든 실행에 대해 로우 바이트(raw bytes), 정확한 프롬프트, 도구 출력을 확인할 수 있어야 합니다.
트레이싱이 없다면, 모델이 그저 무작위라고 생각할 것입니다. 온도를 낮추고 문제를 해결했다고 믿겠지만, 해결된 것이 아닙니다. 단지 버그를 더 조용하게 만들었을 뿐입니다.
진정한 품질을 구축하려면 다음 규칙을 따르십시오:
- 평균이 아닌 일치도를 보고하십시오.
- 파이프라인에서 UNSTABLE을 실패 상태로 만드십시오.
- 판사 모델 버전을 고정(pin)하십시오.
- 검사가 실패하면 트레이스를 읽으십시오.
재현할 수 없는 초록색 대시보드는 신호가 아닙니다. 그것은 스스로에게 들려주는 이야기일 뿐입니다.
Optional learning community: https://t.me/GyaanSetuAi