Build Evals That Actually Matter - Nick Ung & Akshay Sharma, Lyft

한 줄 핵심

Lyft는 고객지원 AI 에이전트의 품질을 실제로 끌어올리려면, 오프라인 시뮬레이션·LLM judge·통계적 검증·에러 분석·배포 후 회귀 감지를 하나의 평가 루프로 묶어야 하며, 너무 쉬운 평가나 일반적인 점수는 실무에 거의 도움이 되지 않는다고 주장한다.

시간별 요약

0:05
이 영상은 Lyft의 고객지원 AI 에이전트를 기준으로, 개발 단계부터 운영 단계까지 이어지는 평가 체계를 어떻게 설계해야 하는지 설명한다. 핵심은 오프라인 평가로 출시 기준을 만들고, 온라인 평가로 회귀를 감지하며, 그 결과를 다시 개발에 반영하는 닫힌 루프를 만드는 데 있다.
2:02
에이전트 평가는 머신러닝 모델 평가와 비슷하지만, 고객지원처럼 다회차 대화가 중요한 경우에는 사용자 LLM과 에이전트를 상호작용시키는 시뮬레이션이 필요하다. 실제 사용자 데이터를 테스트 데이터로 쓰지 말고, 생산 트래픽을 반영한 합성 데이터와 LLM judge, 그리고 필요한 경우 결정론적 규칙을 함께 써서 출시 전에 충분한 성능을 검증해야 한다.
11:02
합성 데이터는 단순히 LLM에게 테스트 질문을 많이 생성시키는 방식으로는 부족하며, 실제 생산 로그 샘플과 다양한 엣지 케이스 변형을 섞어야 한다. 특히 Lyft처럼 실제 사용자는 짧고 감정적이며 비협조적인 경우가 많기 때문에, 사용자 LLM을 실제 사용자 말투로 미세조정하고 persona를 주입해야 평가가 너무 쉽게 치우치지 않는다.
17:00
LLM as a judge는 범용 점수보다 태스크 성공·실패를 기준으로 한 액션 가능한 기준이어야 한다. 평범한 helpfulness, naturalness 같은 점수는 해석이 어렵기 때문에, 도메인 전문가와 함께 교육 루브릭처럼 비즈니스 목표에 직접 연결된 binary metric을 만들고, 이를 인간 라벨과 비교해 precision과 recall으로 검증해야 한다.
23:00
평가 기준은 고정된 진리가 아니라 데이터와 함께 진화해야 하며, 평가자도 반드시 검증 대상이 되어야 한다. 또한 점수는 표본 수와 함께 confidence interval로 해석해야 하고, raw trace 분석, annotation queue, 주기적 error analysis loop를 통해 실패 모드를 찾아 context, harness, 필요하면 model learning으로 개선해야 한다.
31:01
평가의 최종 목적은 숫자를 만드는 것이 아니라 실제 에이전트 성능을 개선하는 데 있다. 그래서 Lyft는 eval harness를 config-driven, 재사용 가능, 병렬 실행 가능하게 만들고, 로컬 개발·pre-commit·CI/CD·회귀 테스트까지 연결해 평가를 일회성 점검이 아니라 지속적인 개발 인프라로 만들려 한다.

실무 인사이트

실무에서는 범용 LLM 점수보다, 배포 여부를 결정하는 binary gate와 직접 연결된 평가 지표를 먼저 설계해야 한다.
오프라인 평가가 너무 높은 정확도를 보이면 성공이 아니라 경고 신호일 수 있으며, 실제 사용자 말투와 행동을 반영하도록 사용자 시뮬레이터를 더 어렵게 만들어야 한다.
평가 체계는 모델 성능만 보는 도구가 아니라, context engineering과 harness engineering을 개선하는 피드백 루프로 운영해야 한다.