Data Eng Wiki

Eval-driven Development at Airbnb

12 min read

Eval-driven development: Lessons from evaluating GenAI at scale

Author: Rohit Girme 외 (Airbnb) | Source: Medium (Airbnb Engineering) | Published: 2026-07-29

한 줄 요약

“의심스러우면 데이터를 봐라” — 프로토타입을 100개 예시에 돌리고 출력과 trace를 직접 읽어 실수를 분류하고 eval을 만드는 이 한 가지 습관이 어떤 프레임워크나 도구보다 제품 품질에 더 기여한다.

핵심 주장/내용

  • GenAI가 깨뜨리는 소프트웨어 테스팅의 가정: LLM 출력은 비결정적이고 “correct”는 주관적이다. 판단이 많이 개입되므로 AI를 평가하려면 종종 AI가 필요하고, 그것이 자체 실패 모드를 도입한다. 게다가 LLM과의 단일 상호작용이 검색·추론·툴 콜·생성을 연쇄시킬 수 있고 각각이 독립적으로 실패할 수 있다
  • 의도적 전략 없이 생기는 3가지: 거짓 확신(일반적 “helpfulness” 지표가 잘 나와서 출시했는데 사람들이 실제로 겪는 실패 모드를 포착하지 못함), 탐지되지 않은 회귀(프롬프트 변경이 측정하지 않던 차원을 미묘하게 저하), 낭비된 노력(결과와 상관없는 지표를 위한 확장 eval 파이프라인 구축). 전체 프로젝트 노력의 유의미한 몫을 평가에 쓸 것을 예상하라 — 불필요한 오버헤드가 아니라 실제로 동작하는 제품을 만드는 방법이다
  • The One Rule — 의심스러우면 데이터를 봐라. 프로토타입을 만들고 100개 예시(합성이어도 괜찮다)에 돌린 다음 출력을 읽어라. trace를 읽고 모델의 실수를 찾아라. 분류하고 eval을 만들어라. 이 한 습관이 이 문서의 어떤 프레임워크·도구·방법론보다 제품 품질에 더 기여한다
  • EDD의 5원칙 (TDD의 GenAI 판. 모든 실패를 미리 예측하는 대신 나타나는 대로 발견·인코딩·지속 테스트하는 인프라와 습관을 만든다. 이해관계자가 “good”이 무엇인지 외재화하도록 강제해 제품 로드맵을 형성하기도 한다):
    1. 목표와 게이트를 미리 정의 — 무엇을 최적화하는가? 출시 전 무엇이 참이어야 하는가? (데이터 탐색 과정에서 발견할 수도 있다)
    2. 실제 에러가 지표를 이끌게 하라 — 관측된 실패에 근거해 교차기능 파트너와 공동 개발하라. 진공 상태에서 발명하지 마라
    3. evaluator 집합을 작고 날카롭게 — 잘 보정된 35개가 노이즈 많은 2030개를 이긴다. 각각이 하나의 특정 correctness 차원을 겨냥해야 한다
    4. 의사결정자를 지정하라 — correctness가 무엇인지는 팀 논의여야 하지만 때때로 사람들이 동의하지 않는다. 무엇이 좋고 나쁜 시스템 동작인지 최종 판단할 사람을 포함시켜라
    5. 지속적으로 협업하라 — 제품 파트너가 정기적으로 “X가 Y보다 나은가 나쁜가?”, “이 출력의 무엇이 실제로 잘못됐나?”에 답하게 하라
  • 3계층 평가 방법: 
    Layer 1: 프로그래매틱 체크 (빠르고 저비용 — 명백한 실패 포착)
Layer 2: LLM-as-a-Judge (미묘 — 품질 이슈 포착)
Layer 3: 사람 평가 (고비용 — 엣지 케이스 검증, 스택 보정)
    • 프로그래매틱 — LLM 호출이 필요 없는 결정론적 코드 체크가 첫 필터여야 한다. 포맷 유효성(JSON/스키마, 항상), 길이·존재(항상), 키워드/정규식(안전·컴플라이언스), 고전 ML 지표(분류), 시맨틱 유사도(gold-standard 참조가 있을 때). ✅ 구조화 출력(JSON 스키마)으로 엄격한 타이핑을 보장하라. ❌ 프롬프트 지시만으로 포맷을 맞추려 하지 마라 — 다운스트림 데이터 파이프라인이 깨진다
    • LLM-as-judge (virtual judge) — 5가지 규칙: 차원당 evaluator 하나, 생성자와 다른 judge, few-shot 예시, 명시적 출력 스키마, 명확한 스코어링. rubric 설계가 중요하고 모호성이 적이다 — “제공된 설명이 읽을 만하고 우리 기준에 맞나?” 같은 건 효과가 없을 가능성이 높다. 사람이 rubric을 일관되게 적용할 수 없으면 LLM은 확실히 못 한다
    • 사람 평가 — ground truth 생성, 안전·고위험, 뉘앙스·창의성, evaluator 간 불일치 해소에 필수
  • Calibration — 보정되지 않은 virtual judge는 judge가 없는 것보다 나쁘다. 거짓 확신을 주기 때문이다:
    1. 50~100개 예시의 golden dataset 생성. 반드시 나쁜 예시를 포함해야 한다(좋은 것만이 아니라)
    2. golden set에 virtual judge 실행
    3. 일치도 측정. 목표는 80대 후반~90%대. Cohen’s kappa나 Krippendorff’s alpha로 불일치 측정 가능. (완벽한 일치는 달성 불가 — 사람끼리도 불일치한다)
    4. 불일치 분석 → 프롬프트 정제, few-shot 예시 갱신 → 목표 일치도까지 루프 재실행
    5. 실패 모드가 진화하므로 주기적으로 재보정
  • 에이전틱 시스템 평가 — 최종 출력만 평가하면 불충분하다: 올바른 최종 답이 깨진 추론 경로, 잘못된 툴 파라미터, 비효율적 궤적을 가릴 수 있다. 3계층으로 평가 — step-level(개별 툴 콜·추론 단계), trajectory-level(전체 경로가 합리적이고 효율적이었나), session-level(전체 상호작용이 사용자의 목표를 달성했나)
    • 에이전트가 일반적으로 애플리케이션 루트 아래로 trace와 span을 푸시한다는 점을 활용 — 에이전트 유형, 호출된 서브에이전트, 입출력, 호출된 툴 정보가 담긴다. 이를 관측 플랫폼이나 영구 저장소에 쓰고 DFS 등 트리 순회로 메모리에 trace를 재구성하면 특정 서브에이전트가 올바른 시점에 호출됐는지, 에이전트가 올바른 툴을 불렀는지 확인하고 특정 에이전트/서브에이전트로 평가 범위를 좁힐 수 있다
  • 실전 워크스루: ① 100개 입력을 돌려 모든 출력을 읽는다 → 15개가 소스에 없는 정책 세부를 생성(faithfulness), 8개는 맞지만 너무 장황(conciseness), 5개는 유효한 질문을 거부(over-refusal), 3개는 JSON 깨짐(format) ② JSON 유효성·길이 경계 프로그래매틱 체크 추가, faithfulness와 conciseness에 각각 virtual judge 작성(별도 프롬프트, 다른 모델, chain-of-thought), PM/SME가 실패 포함 60개 라벨링 ③ faithfulness judge가 PM과 78% 일치 — 부족하다. 분석 결과 judge가 정확한 패러프레이즈를 “unfaithful”로 벌하고 있었다. rubric 갱신 + few-shot 추가 → 88%로 상승 ④ 5,000개로 확장하고 프로덕션 모니터링 구축(라이브 비식별 트래픽 5%를 매일 샘플링, 프로그래매틱+virtual judge 실행, 플래그된 출력을 사람 리뷰로. 주간 PM 리뷰가 루프를 닫아 새 실패 모드가 새 eval을 도입)
    • 반복 시 한 번에 하나의 변수만 고정하라 — 먼저 모델을 고정하고 프롬프트를 변화, 그다음 프롬프트를 고정하고 모델을 변화, 그다음 둘 다 고정하고 서빙 설정을 변화. 각 단계에서 virtual judge 결과가 후보 풀을 좁히고, 상위 후보의 샘플로 virtual judge를 개선한다. evaluator와 후보가 서로를 날카롭게 만들며 둘 다 안정화될 때까지

주요 수치 / 사실

  • Rule of thumb: SME가 라벨링한 20~100 row로 시작하라. rubric이 견고해지고 볼륨이 병목일 때에만 확장된 어노테이션 인력으로 옮겨라
  • 전문가들이 라벨에 동의하지 않으면 멈춰라. 무엇이든 자동화하기 전에 사람의 불일치를 먼저 해결하라
  • 핵심 정리 10가지: 데이터를 봐라 / 일반적 지표를 피하라 / 50100 row로 시작해 값싸게 빨리 실패하라 / 차원당 evaluator 하나(“God evaluator” 금지) / 대규모로 신뢰하기 전 80대 후반90%대 일치도로 보정하라 / 세 방법을 계층 방어로 함께 써라 / gold set에 나쁜 예시를 포함하라 — 그것 없이는 분별력을 테스트할 수 없다 / 모델이 아니라 시스템을 평가하라(검색·툴 콜·전체 파이프라인, 에이전트는 최종 답이 아니라 궤적) / 프로덕션에서 eval을 미러링하라 / 평가는 팀 스포츠 — AI에서 성공하는 팀은 최고의 모델을 가진 팀이 아니라 최고의 커뮤니케이션과 가장 명확한 제품 비전을 가진 팀이다

관련 위키

Source: 원문 보기

그래프 뷰

백링크