LLM 평가로 더 나은 실험하기 — 포크가 아닌 퍼널 | Spotify Engineering (새 탭에서 열림)
LLM 평가(evals)는 실험을 대체하는 도구가 아니라, 실험 전에 유망한 후보를 걸러내고 실험 후 판단 기준을 보정하는 퍼널의 일부다. Evals는 출력의 품질과 의도 부합 여부를 검증하지만, 실제 사용자의 행동과 사업 성과까지 검증하지는 못한다. 따라서 오프라인 평가와 온라인 A/B 테스트를 반복적으로 연결해야 실험 성공률과 평가 모델의 신뢰도를 함께 높일 수 있다. ## Evals와 실험의 역할 차이 - **Evals는 검증(verification)**을 담당한다. - 출력이 관련성, 일관성, 어조, 의도 부합성 등 정해진 품질 기준을 만족하는지 평가한다. - 대규모 데이터에서 사람의 수작업 평가보다 빠르고 저렴하게 후보를 비교할 수 있다. - **실험은 검증(validation)**을 담당한다. - 실제 사용자가 변경된 결과에 어떻게 반응하는지 확인한다. - 개선된 출력이 참여도, 유지율, 매출 등 실제 사업 성과로 이어지는지 측정한다. - 따라서 관계는 “eval 또는 실험”이라는 분기가 아니라, **eval로 후보를 좁힌 뒤 실험으로 사업 효과를 확인하는 퍼널**이어야 한다. - Spotify의 사례에서도 A/B 테스트 중 긍정적인 결과로 출시되는 비율은 약 12%지만, 약 64%는 회귀를 발견하거나 가설을 수정하는 등 유효한 학습을 제공한다. ## Evals가 제공하지만 제공하지 못하는 것 - LLM judge는 다음과 같은 품질 문제를 대규모로 탐지할 수 있다. - 사용자 의도와 맞지 않는 추천 - 신뢰를 훼손하는 콘텐츠 - 응답의 관련성, coherence, 어조 문제 - 평가 과정에서 팀이 예상하지 못한 문제 패턴을 발견할 수 있다. - 예를 들어 부적절한 추천이 특정 사용자군이나 상황에서 반복된다는 사실을 찾아낼 수 있다. - 발견된 패턴은 제품 개선 가설이 된다. - 같은 judge를 수정 후에도 사용하면 문제가 실제로 줄었는지 확인할 수 있다. - 문제가 되는 평가 항목의 발생 빈도가 감소하면 구현 품질이 개선된 것으로 볼 수 있다. - 그러나 eval만으로는 다음을 알 수 없다. - 사용자의 장기 참여도가 높아졌는지 - 이탈이나 churn이 줄었는지 - 시스템 전체에서 예상치 못한 부작용이 발생했는지 - Spotify에서는 출시된 실험의 약 42%가 세션 길이, 충돌률, 유지율 등 **최적화 대상이 아니었던 보조 지표의 회귀** 때문에 되돌려졌다. 이런 문제는 오프라인 eval에서 포착되지 않을 수 있으므로 온라인 실험과 가드레일 지표가 필요하다. ## 두 단계의 보정과 평가 드리프트 - Evals는 실제 성과를 직접 측정하는 것이 아니라, 성과를 대신하는 **프록시 점수**다. - 기존의 정량 지표(랭킹 점수, precision, recall) 위에 LLM judge라는 또 하나의 보정 계층이 추가된다. - 두 계층 모두 실제 온라인 결과와 비교해 보정해야 한다. - judge가 더 높은 점수를 준 변형이 실제로 더 나은 사용자 경험을 제공하는가? - judge가 실질적 가치가 아닌 표면적 문체나 특정 패턴을 보상하고 있지는 않은가? - 평가 기준은 시간이 지나면서 드리프트할 수 있다. - 모델, 사용자 행동, 콘텐츠 유형, 제품 목표가 바뀌면 기존 judge의 점수와 실제 성과의 관계가 약해질 수 있다. - Qodo의 코딩 eval에서는 Anthropic의 Opus 4.5가 개선되지 않은 것처럼 보였지만, 실제로는 긴 작업에서 성능이 크게 향상된 사례가 있었다. - 반대로 eval 점수는 좋아졌지만 실제 사용자 성과가 개선되지 않는 경우도 가능하다. - 따라서 오프라인 점수와 온라인 결과를 지속적으로 비교해야 eval이 단순한 의견이 아니라 신뢰할 수 있는 증거가 된다. ## 실험 전후를 연결하는 피드백 루프 - **실험 전** - 여러 후보를 LLM eval로 평가한다. - 품질 기준을 충족하지 못하는 후보를 제거한다. - 남은 후보에 실험 리소스를 집중해 실험의 적중률을 높인다. - **실험 중** - 주요 사업 지표뿐 아니라 최적화하지 않은 가드레일 지표도 관찰한다. - 세션 길이, 오류율, 충돌률, 유지율처럼 회귀 가능성이 있는 지표를 함께 확인한다. - **실험 후** - A/B 테스트에 사용된 실제 데이터에 eval을 다시 적용한다. - judge가 선호한 변형이 실제 사용자 성과도 개선했는지 비교한다. - eval 점수와 실험 결과 사이의 차이를 다음 평가 기준을 개선하는 신호로 활용한다. - 결과가 어느 쪽이든 학습이 발생한다. - eval과 사용자 성과가 함께 개선되면 judge가 가치 있는 품질 요소를 측정하고 있다는 뜻이다. - eval만 개선되고 사용자 성과가 그대로라면 judge가 사업 성과와 무관한 요소를 측정하고 있다는 뜻이다. ## 상황에 따른 실험 강도 - 모든 변경에 동일한 수준의 증거를 요구할 필요는 없다. - 빠른 반복 단계에서는 방향성을 파악하기 위한 간단한 테스트를 사용할 수 있다. - 출시 결정이나 영향 범위가 큰 변경에는 충분한 표본, 장기 지표, 가드레일을 포함한 엄격한 실험이 필요하다. - 시스템이 복잡할수록 실험을 생략해 발생하는 대규모 회귀 위험이 커진다. 실무적으로는 LLM eval을 **후보 선별과 품질 진단**에 사용하고, 최종 출시는 반드시 사용자 대상 실험과 가드레일 지표로 판단하는 방식이 권장된다. 실험 결과를 다시 eval 보정에 반영하면 시간이 지날수록 더 정확한 평가 체계를 구축할 수 있다.