LLM Evals 로 실험 개선하기 — 깔때기 구조 vs 분기 구조

A/B 실험 조직에서 LLM 자동 평가(evals)를 실험의 대체물로 볼지 앞단 선별 도구로 볼지에 대한 논쟁을 다룬다. Spotify의 답은 둘을 분기(fork)가 아니라 깔때기(funnel)로 엮는 것이다. 평가로 유망 후보를 거르고 실험으로 검증한 뒤 그 결과로 다시 평가를 보정한다.

핵심 포인트

Spotify에서 A/B 테스트의 약 12%만 긍정적 결과로 출시되고, 64%는 회귀 방지·가설 정제 같은 유효한 학습을 남기며, 출시된 것의 42%는 2차 지표 악화로 롤백된다.
관련성·톤·의도 부합 같은 정성 차원은 대규모로 평가하기 어렵고 인간 주석은 비싸고 느려 LLM judge가 필요하다.
평가만으로 결론 내리면 위험하다. Opus 4.5에서 Qodo 코딩 평가는 개선을 못 봤지만 통제 실험에서는 장기 작업 성능 향상이 확인됐다.
핵심 원칙은 오프라인·온라인 신호 보정 없는 평가는 증거가 아니라 의견이라는 것이다.

상세 정리

문제 정의: 정성 품질을 사람이 일일이 채점하기엔 규모가 크고, 최적화하지 않는 가디언 메트릭 모니터링도 부족했다.
잘못된 프레이밍: 평가를 실험의 대체물로 쓰는 evals vs experiments 이분법이 함정이며, 평가 점수와 실제 사용자 성과가 어긋날 수 있다.
1단계 Verification: LLM judge가 품질 기준 준수 여부를 확인하고 사용자에게 안 맞는 추천 같은 신뢰 위반 콘텐츠를 플래그한다.
2단계 Validation: 실제 실험으로 사용자 반응과 비즈니스 결과를 측정하고 세션 길이·크래시율·유지율 같은 2차 메트릭을 함께 본다.
3단계 Calibration: A/B 결과로 평가 정확도를 조정해 평가가 선호한 버전이 실제로 성과가 좋은지 확인하고, 평가와 실험의 격차가 크면 진단 신호로 삼는다.
실전 사례: 한 팀이 안 맞는 추천을 잡는 LLM judge를 만들자 사람이 못 본 패턴까지 드러났고, 이를 제품 수정으로 연결한 뒤 같은 judge로 출시 후 위반 감소를 검증했다.
이중 보정 계층: 순위 점수·정밀도·재현율 같은 기존 정량 메트릭과 LLM judge 점수를 모두 온라인 결과에 지속적으로 맞춰 검증한다.
한계 1: 평가는 실제 관심 결과의 프록시라 점수가 결과를 추적할 때만 유효하고 시간이 지나며 드리프트할 수 있다.
한계 2: 신뢰 침식으로 인한 이탈 같은 지연·장기 효과는 구조적으로 평가가 못 잡아 실험이 필요하다.
운영 지침: 빠른 방향성 테스트는 반복·데이터 수집용, 엄밀한 실험은 출시 결정용으로 나누고 모든 변경에 같은 수준의 증거를 요구하지 않는다.

왜 읽나LLM 품질 평가와 온라인 실험을 함께 운영하는 데이터 과학자·ML 실무자에게 평가와 실험의 역할 분담과 보정 루프 설계 지침을 준다.

Spotify Engineering 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

LLM Evals 로 실험 개선하기 — 깔때기 구조 vs 분기 구조

이 글과 비슷한

에이전틱 SDLC를 QA 엔지니어링 마인드셋으로 구축하기

보안 업무를 위한 AI 에이전트 플랫폼 「SAGE」 개발기 1편: 판단은 사람에게 남기는 설계

실리콘투의 사내 지식 MCP 게이트웨이 구축기