Lyft에서 1~2년간 고객지원 AI 에이전트(멀티 에이전트 시스템)를 구축해온 데이터 사이언스 매니저 Nick Ung과 팀원 Ashe가 AI Engineer 컨퍼런스에서 발표한 세션. "실제로 중요한(actually matters) eval을 어떻게 만들고 스케일하는가"를 오프라인 평가 → LLM judge 설계 → judge 검증 → 에러 분석 루프 → eval harness 로드맵 순으로 전개한다.
계층 1 — 핵심 주장
- 평가 점수는 반드시 무언가를 게이팅(launch gate)해야 의미가 있다. 점수만 떠다니고 아무도 그걸 배포 결정에 쓰지 않으면 그 LLM judge는 가치가 없다.
- 너무 쉬운 eval은 위험하다. User LLM이 너무 친절하고 참을성 있게 말하면 90% 같은 비현실적으로 높은 통과율이 나오는데, 이는 프로덕션 신뢰성에 대해 아무것도 말해주지 않는다.
- LLM judge는 범용 지표가 아니라 비즈니스 성패에 직결된 binary pass/fail 기준으로 설계해야 actionable하다.
- Judge 자체도 전통적 ML 분류기처럼 검증해야 한다 — 사람이 라벨링한 데이터로 train/dev/test를 나누고 precision/recall을 측정.
- Eval 기준은 고정되지 않는다. 데이터를 계속 보면서 criteria가 drift하는 것을 인정하고 judge를 모델 관찰과 함께 지속적으로 co-develop해야 한다.
계층 2 — 주요 섹션별 내용
1. 전체 파이프라인: 개발 단계 vs 프로덕션 단계
에이전트 개발 단계(컨텍스트 관리, RAG 파이프라인, 툴 정의, 에이전틱 그래프, 시스템 프롬프트 작성)가 끝나면, 프로덕션에 내보내기 전 오프라인 평가를 거쳐야 한다. Nick은 이를 "ML 모델을 프로덕션에 내보내기 전 오프라인 평가를 거치는 것과 동일한 원리"라고 설명한다. 프로덕션에 배포된 이후에는 트레이싱 도구로 실행을 추적하고, 온라인 grader가 실사용자 응대 품질을 채점하며, human-in-the-loop 에러 분석을 통해 인사이트를 다시 개발팀에 피드백하는 온라인 평가 파이프라인이 이어진다.
핵심 원칙: 라이브 유저를 AI 에이전트의 테스트 데이터로 쓰지 않는다.
2. Eval이 실패하는 3가지 흔한 이유
- Grader의 점수가 의미 있게 게이팅하지 않음 (launch gate 부재)
- LLM judge가 너무 노이즈가 많고 제너릭해서 아무도 신뢰하지 않거나 actionable하지 않다고 느낌
- 프로덕션에서 회귀(regression)가 발생했을 때 이를 잡아내고 책임자를 지정하는 명확한 메커니즘이 없음
3. 오프라인 시뮬레이터 (Tau-bench에서 영감)
Sierra AI의 Tau-bench 논문에서 영감을 받아, AI 에이전트(LangGraph 기반)와 user LLM이 상호작용해 멀티턴 트레이스를 생성하는 오프라인 시뮬레이터를 구축했다. User LLM 시뮬레이션은 세 가지로 정의된다:
- User intent: 이 상호작용이 나타내야 하는 의도
- User data point / world state: 예를 들어 "수년간 운행해온 럭셔리 드라이버" 같은 배경
- User persona: 예) 리워드 시스템에 불만인 충성 장기 고객
시뮬레이션에서 나온 멀티턴 궤적은 LLM judge와 결정론적(deterministic) 평가자(전통적 유닛 테스트처럼 코드 assertion으로 작성된 규칙 — 예: "이 상호작용에서 컨세션을 지급해야 하는가"를 툴 콜과 비교)로 함께 채점된다.
4. 합성 데이터의 함정
"LLM에게 테스트 쿼리 50개를 만들어달라고 프롬프트하는 것"은 프로덕션과 동떨어진 데이터셋을 만든다. Lyft가 취한 접근:
- 실제 프로덕션 데이터에서 샘플링해 오프라인 데이터셋을 구성
- 다양한 골든 패스/엣지 케이스를 커버하도록 기준을 변형(mutate)
5. "너무 친절한 User LLM" 문제와 파인튜닝
프론티어 랩 LLM은 도움을 주는 어시스턴트로 훈련되어 있어서, 실제로 짜증나고 참을성 없는 고객지원 문의자 역할을 잘 재현하지 못한다. 초기 오프라인 평가는 90% 통과율이 나왔는데, 이는 실제 유저 verbatim(참을성 없고 좌절한 짧은 문장)과 달리 LLM 유저가 지나치게 장황하고 침착하게 문제를 설명했기 때문이다.
해결책: Lyft 실제 유저 verbatim 데이터로 user LLM을 파인튜닝. 이후 평가 점수는 떨어졌지만, 이는 진짜 프로덕션 난이도를 반영한 결과다. Nick은 "eval이 너무 쉬우면 에이전트가 실제로 얼마나 잘 작동할지에 대한 진짜 인사이트를 주지 못한다"고 강조한다. 추가로 바이패서(무조건 상담원 연결 원함), 환불 추구자, AI 회의론자 등 페르소나를 정의해 시뮬레이션 현실성을 강화했다. Microsoft의 유사 논문(UserAlign 계열)도 동일하게 user 모델을 파인튜닝한 뒤 점수가 낮아지는 현상을 확인했다고 언급한다.
6. LLM Judge 설계: 제너릭 지표의 함정
DeepEval 같은 사전정의 지표(tool usage appropriateness, response helpfulness, conversation naturalness, completeness, toxicity, bias, fairness, conciseness 등)로 시작했지만 문제는 이 지표들이 actionable하지 않다는 것. "response helpfulness가 0.5면 무엇을 고쳐야 하나?"라는 질문에 답할 수 없었다. 이런 사전정의 지표는 baseline으로만 쓰고, 핵심 eval 지표로는 쓰지 않아야 한다.
7. Actionable LLM Judge 만들기
도메인 전문가와 긴밀히 협업해 task success/failure의 binary outcome으로 eval을 프레이밍한다. Binary outcome은 LLM judge를 일관되게 캘리브레이션하고 훈련하기 쉽다. 예시로 소개된 "education rubric"은 AI 에이전트가 유저를 교육하려는 시도가 과도한지(너무 여러 번 시도 후 에스컬레이션 안 함) 또는 과소한지(교육 기회 없이 너무 빨리 에스컬레이션)를 pass/fail로 판정한다.
8. Judge 검증: 분류기처럼 취급하기
Judge를 전통적 ML 분류기처럼 다룬다:
- 모든 메트릭/태스크에 대해 binary output 정의
- 사람이 라벨링한 ~100개 예제를 pass/fail로 라벨링
- 이를 train/dev/test로 분할 (단, 전통 ML 학습과 비율이 다름 — 모델 가중치를 학습하는 게 아니라 judge의 프롬프트를 informing하는 데 데이터를 씀. train에서 few-shot 예제를 뽑아 judge 프롬프트에 넣고, dev로 프롬프트/하네스를 반복 개선하고, test로 dev에 오버핏하지 않았는지 최종 검증)
- 사람 라벨 ground truth 대비 precision/recall을 산출해 judge의 실제 성능 리포트를 만듦
9. Criteria drift와 "validator를 검증하기"
평가 기준은 미리 완벽하게 정의하고 고정할 수 없다. 데이터를 보고 결과를 채점하는 과정에서 평가 기준 자체를 발견하게 되고, 새로운 데이터를 볼수록 품질에 대한 감각도 진화한다. 따라서 평가는 모델 관찰과 분리될 수 없으며, judge를 테스트하고 precision/recall을 계산할 때 모델과 함께 co-develop되어야 한다.
10. 통계적 엄밀함
Alignment rate를 단순 point estimate로만 리포트하면 오해를 낳는다. 신뢰구간, 캘리브레이션, 적절한 샘플링을 더하면 같은 숫자가 훨씬 의미 있어진다. 예시: 두 evaluator가 각각 84%, 88%를 기록했고 샘플이 50개라면, 이 4%p 차이가 통계적으로 유의미한지 알 수 없다 — 50개로는 부족하다. 배포 결정처럼 중요한 순간에는 반드시 신뢰구간을 확보해야 하며, 통계적 엄밀함은 정말 중요한 순간을 위해 아껴 쓴다("every score needs an interval").
11. Eval 안티패턴과 "데이터를 보지 않는 것"의 위험
발표에서 관찰된 eval 안티패턴 리스트를 제시하며, 그중 가장 강조한 것은 데이터를 무시하는 것이 가장 흔하고 근본적인 실수라는 점이다. 데이터를 보지 않으면 의미 있는 기준/라벨을 만들 수 없고, 라벨이 없으면 judge를 평가할 수 없으며, judge를 평가하지 않으면 에이전틱 파이프라인이 제대로 작동하는지 알 수 없다 — 이는 모든 것의 기초다.
12. 에러 분석 루프 (지속 반복 프로세스)
1회성 감사가 아니라 주기적으로(주간/격주) 반복 실행되는 루프:
- Raw trace를 깊이 파고들기
- 실패 모드를 정확히 짚어내기
- 결정을 바꾸는 지표만 남기고 노이즈 제거 (비즈니스/기능 요구사항에 묶인 지표만 우선순위화)
- 새로운 가설(premise)을 세워 재평가
- 반복
13. 트레이싱과 어노테이션 큐
Langsmith, Langfuse 같은 도구로 트레이스를 로깅한다. 각 트레이스는 전체 그래프 실행(어떤 노드가 실행됐는지, LLM이 무엇을 봤는지, 어떤 툴이 호출됐는지, 토큰 사용량, 레이턴시)을 캡처하며 메타데이터로 보강할 수 있다. 어노테이션 큐는 도메인 전문가가 raw JSON 트레이스를 직접 보지 않고도 쉬운 UI에서 라벨링/피드백을 남길 수 있게 하며, 이 데이터는 오프라인 평가 데이터셋이나 judge의 precision/recall 계산에 재사용된다.
14. 평가 루프 닫기: 3가지 지속 학습 축
- 모델 학습(Model learning): 포스트 트레이닝으로 실제 모델 가중치 업데이트, 커스텀 LLM 학습
- 컨텍스트 학습(Context learning): 에이전트가 보는 정보 개선 (문서, 유저 메모리, 툴 출력 등)
- 하네스 학습(Harness learning): 시스템 프롬프트, 툴 스키마, 컨트롤 플로우 라우팅, 재시도 로직 등 개선
에러 분석에서 나온 인사이트가 실제로 프롬프트 개선, 지식 베이스 업데이트, 컨텍스트 관리 전략 튜닝, 실패 모드 식별로 이어져 에이전트 개선의 실제 동력이 된다.
15. 향후 계획
- 현재 오프라인 시뮬레이터는 여러 노트북과 분석 레포에 흩어진 "scattered script" 상태 → 체계적인 config 기반 eval harness로 표준화 (task/dataset/persona/LM adapter/evaluator를 primitive로 정의, YAML config로 엔지니어 아닌 분석가·데이터 사이언티스트도 기여 가능)
- 수천~수만 개 예제를 다루기 위한 병렬성/처리량 확보
- Config를 한 번 정의하면 로컬 개발, 프롬프트 튜닝 시 즉시 피드백, pre-commit hook, CI/CD 회귀 테스트/승인 테스트 등 여러 지점에서 반복 실행 가능하게 설계
- 실제 유저 시그널을 축적해 **리워드 모델링 문제로 프레이밍하고 강화학습(post-training)**을 통해 고객지원 태스크별 모델을 파인튜닝하는 방향도 검토 중
계층 3 — 인사이트 / 시사점
- 점수를 만들기 전에 "이 점수가 무엇을 게이팅하는가"부터 정의하라. 게이팅하지 않는 지표는 만들 필요가 없다.
- User simulator가 너무 친절하면 그 eval은 무용지물이다. 실제 유저 톤(짜증, 조급함, 짧은 문장)을 반영하도록 파인튜닝하거나 최소한 페르소나를 명시적으로 설계해야 한다. 통과율이 이상하게 높으면(90%+) 먼저 의심할 것.
- LLM judge는 범용 지표(helpfulness, toxicity 등) 대신 binary pass/fail rubric으로 설계하라. 도메인 전문가와 함께 "성공/실패 기준"을 명문화하는 것이 핵심.
- Judge도 검증 대상이다. 100개 정도 사람 라벨로 train/dev/test를 나누고 precision/recall을 재는 것을 생략하지 마라. "judge를 만들었다"와 "judge가 신뢰할 만하다"는 다른 이야기다.
- 작은 gain은 착시일 수 있다. n=50에 4%p 차이 같은 숫자를 그대로 배포 결정에 쓰지 말고, 신뢰구간으로 통계적 유의성을 확인하라.
- 에러 분석은 1회성 감사가 아니라 반복 가능한 주기적 루프로 설계하라. 트레이싱 + 어노테이션 큐 인프라를 먼저 갖추는 게 우선이다.
- Eval harness를 config(YAML) 기반으로 만들면 비엔지니어(분석가·DS)도 eval suite에 기여할 수 있다 — 이는 조직 전체의 eval 커버리지를 늘리는 실용적 방법이다.
- 평가 개선 인사이트는 모델 재학습뿐 아니라 컨텍스트 개선, 하네스(프롬프트/툴 스키마/라우팅) 개선으로도 이어질 수 있다는 점을 기억할 것 — 모든 문제를 파인튜닝으로 풀 필요는 없다.
계층 4 — 원문 발언 인용
- "The scores that we create needs to be meaningfully gating something... If your LLM as a judge is just floating out there — there's a score but no one is really using that score as a meaningful gate — then that LLM as a judge is not valuable."
- "Our first attempt at our offline evaluation gave us 90% pass rate or accuracy rate right — this almost sounds too good to be true, and I think it indeed is too good to be true."
- "If you have an eval that's too easy, that doesn't give you any real production insights into how your AI agent is actually going to perform."
- "Eval should be framed around a task success or failure, and a binary outcome is very easy to calibrate and train LLM judges that can consistently score your agentic trajectory."
- "Ignoring the data is one of the most important things which we shouldn't do... it acts as the foundation for meaningful evaluations. If you don't look at the data, you won't be able to create meaningful criteria or labels."
- "Every score needs an interval."
- "This loop is something which runs continuously. It's not a one-off audit."
- "We cannot define the criteria beforehand and then evaluate agents against them. Our criteria should also be evolving as and when we see more examples."
발표자: Nick Ung (Data Science Manager, Lyft, 6년차) · Ashe (Lyft, 4년차) 세션: AI Engineer World's Fair — Online Track 대상 시스템: Lyft 고객지원 멀티 AI 에이전트