Evaluation and Measurement

“무엇이 작동했는지 어떻게 아는가” — 그리고 “그것을 아는 장치 자체는 누가 검증하는가”

개요

데이터·ML·AI 시스템에서 측정 장치가 시스템의 일부다. A/B 테스트, 오프라인 eval, LLM judge, 데이터 품질 체크는 전부 “이게 작동했는가” 에 답하려는 서로 다른 도구인데, 각각이 조용히 틀릴 수 있고 그때 아무도 알려주지 않는다.

이 토픽은 세 층을 묶는다:

① 무엇을 재는가        효과 측정 (인과·증분·다중 검정)
② 어떻게 재는가        eval 설계 (오프라인/온라인, 라벨/추론, 벤치마크)
③ 재는 장치를 검증     judge 정렬·드리프트·인간 불일치 밴드

핵심 명제:

자동 평가를 도입하는 것은 그에 대한 책임을 위임하는 것과 같지 않다. 아무도 감사하지 않는 자동 평가자는 자신이 내리는 결정에 대해 아무 보증도 제공하지 않는다.

1. 오프라인 정렬은 필요하지만 절대 충분하지 않다

가장 반복되는 실수다. “우리 rater와 일치한다”는 “사용자에게 도움이 된다”가 아니다.

Netflix가 추천 설명(recommendation explanation)에서 이것을 명시적으로 분리했다 — judge를 정렬시킨 뒤에도 약 한 달간 설명 vs 설명 없음 온라인 A/B를 별도로 돌렸다.

오프라인 rater 일치는 이 설명들이 작동하는 데 필요했지만 회원에게 도움이 됨을 보이기에는 결코 충분하지 않았다. 온라인 A/B 테스트만이 judge 정렬 설명이 품질 준수를 넘어 진짜 유용함을 확립할 수 있었다.

층위	답하는 질문	답하지 못하는 것
오프라인 eval	우리 기준에 맞는가	기준이 옳은가
judge 정렬	사람과 같은 판정인가	그 판정이 가치를 만드는가
온라인 A/B	행동이 바뀌었는가	왜 바뀌었는가
인과 추론	그 변화가 우리 때문인가	—

→ A-B Testing and Experimentation, LLM Evaluation, Causal Inference

2. 답이 아니라 경로를 평가하라

세 개의 독립된 사례가 같은 결론에 도달했다.

Ramp (Consensus Engineering) — 처음엔 답이 맞았는지 봤지만, trace를 읽는 것이 출력을 보는 것보다 훨씬 도움이 됐다. 맞은 실행은 도메인 문서를 찾았고, 틀린 실행은 문서를 건너뛰고 틀린 테이블과 지표를 골랐다.

불완전한 과정으로 도달한 올바른 숫자는 blessed path로 생산된 올바른 숫자만큼 가치 있지 않다 — 그리고 다음 모델 릴리스에서 깨질 가능성이 훨씬 높다.

Netflix (LLM-as-Judge) — “맞는 답, 틀린 이유” 는 라벨 일치 지표에 전혀 나타나지 않는다. 대시보드는 완벽해 보이는데, judge를 critic으로 쓰는 순간 오도하는 피드백을 준다.

Instacart (Agentic ML Modeling) — 에이전트가 held-out 평가 세트를 훔쳐봤다. 답은 훌륭했고 과정이 무효였다.

실천

trace를 정규화하라 — READ_DOMAIN_DOC, VIEW_DASHBOARD, READ_SEMANTIC_VIEW, EXECUTE_SQL, SYNTHESIZE_ANSWER
답과 증거를 둘 다 assert — 답은 canonical 쿼리 출력, 증거는 신뢰하는 경로
주변 시스템을 스냅샷 — 모델, 프롬프트, 도구, 코드, 평가 코퍼스, 당시 지식의 해시

assert same_metric_definition(results)
assert values_within_tolerance(results, relative=0.00001)
assert same_authorization_outcome(results)
assert required_evidence_used(results)   # ← 경로 검증

→ Consensus Engineering, LLM-as-Judge, Agentic ML Modeling

3. 정확도 eval에서 재현성 eval로

전통적 eval은 “어느 모델이 정확한가” 를 묻는다. consensus divergence rate는 질문을 뒤집는다:

어떤 model × interface가 최고인지의 테스트가 아니라, 우리 지침이 어떤 model × interface든 같은 답을 얻을 만큼 명확한지의 테스트다. 모델이 틀린 적은 없다고 가정하라 — 당신의 컨텍스트가 덜 명세되었을 뿐이다.

루프: 이사회 지표 → 모든 인터페이스 × 모델 조합으로 질문 → 서로 다른 답이 몇 개인지 센다 → >1이면 모든 trace를 읽고 수정 → 반복. C-suite가 주간으로 보는 것에 대해서는 0이어야 한다.

이 프레이밍의 힘: 실패가 모델 탓이 아니라 우리 명세 탓으로 재귀속되므로, 개선 작업이 “더 나은 모델을 기다린다”에서 “문서와 정의를 쓴다”로 옮겨간다.

새 모델이 너무 자주 나와 다음 frontier가 문제를 풀어주기를 바라기 쉽지만, 진전은 컨텍스트가 빠진 harness에 frontier 토큰을 태우는 게 아니라 eval의 “failure taxonomy”를 만들고 태워 없애는 것으로 이룬다.

→ Consensus Engineering, LLM Evaluation

4. ⭐ 임계를 고정값이 아니라 인간 불일치로

이 묶음에서 가장 이전 가능한 아이디어다.

judge가 얼마나 정확해야 하는가? “90% 일치” 같은 고정 임계는 그 주 데이터가 얼마나 어려웠는지를 무시한다.

Netflix의 해법 — 그 주 rater들의 spread를 밴드로 쓴다:

매주 약 300개를 뽑되 judge의 결정(served/revised/dropped)에 걸쳐 층화하고 드리프트가 가장 일어나기 쉬운 신규 항목에 가중. 층화를 주마다 고정해 주 간 비교 가능하게
최소 3명 패널, 다수 라벨이 ground truth
judge와 각 rater를 같은 다수 라벨에 대해 점수화 → judge가 평균 rater보다 2σ 아래보다 나쁘지 않을 것

어려운 주는 인간 불일치를 넓히고 그와 함께 밴드도 넓어지므로, judge가 사람들도 느낀 난이도로 벌받지 않는다.

같은 발상이 다른 곳에도 있다 — Project Lighthouse가 익명화 품질 임계를 ML 분류 문제로 재프레이밍해 “이 지표 값들이 실제로 통계적으로 유효한 결과를 예측하는가” 를 합성 데이터로 학습·검증했다. 임계를 직관이 아니라 경험적으로 정당화한다는 점에서 같다.

→ LLM-as-Judge, Privacy-Preserving Analytics, Human-in-the-Loop Labeling

5. 드리프트 탐지 ≠ 기준 검토

두 개의 다른 실패를 잡는 두 개의 다른 장치가 필요하다.

장치	잡는 것	놓치는 것
드리프트 탐지	judge가 현재 rubric에서 벗어남	rubric 자체가 틀렸을 때
지속적 인간 리뷰	rubric이 좁거나 불완전함	통계적 미세 이동

주간 리뷰가 judge-rater 일치에 전혀 나타나지 않은 문제들을 잡았다:

정확한 속성을 쓰면서도 유사도를 과장
모호한 형용사 하나가 기술적으로 rubric을 만족시키면서 거의 아무것도 말하지 않음
참조 자체가 부적절 — 속성이 맞아도 사용자에게 이상하게 착지
모든 기준을 만족하면서 일반적 “word soup”

드리프트 탐지는 judge를 현재 rubric에 정렬시킨다. 지속적 인간 리뷰는 rubric을 실제로 작동하는 것에 정렬시킨다. 둘 다 필요하다.

⚠️ 재튜닝된 rubric은 자동으로 라이브에 가지 않는다 — 사람이 읽고 서명하고, 즉시 롤백을 위해 이전 버전을 보관한다.

6. 효과를 어떻게 분해하는가

“개선했다”가 무엇을 뜻하는지가 대개 가장 어렵다.

도구	쓰는 상황	주의
A/B 테스트	무작위 배정이 가능할 때	power·사전 등록·품질
propensity score matching	노출이 무작위가 아닐 때	관측된 교란만 다룬다
exposure / selection / targeting 분해	추천 효과를 나눌 때	세 성분이 상쇄될 수 있다
diversion ratio	잠식(cannibalization) 을 볼 때	총량 지표는 이걸 숨긴다
DoubleML / ATE·CATE	A/B 불가 관찰 데이터	placebo test 필수
NDCG / Recall@k	랭킹 오프라인	사용자 가치의 대리일 뿐

추천에서 특히 중요한 구분: 클릭이 늘어난 것이 새 수요를 만든 것인지 기존 수요를 옮긴 것인지. → Recommendation Impact Measurement

7. ⚠️ 탐색량이 늘면 가짜 승자도 늘어난다

에이전트가 모델링을 하면 탐색량이 100배가 되는데, 다중 검정 문제도 100배가 된다.

에이전트는 무수한 가설을 탐색하고 거의 필연적으로 순전히 운으로 기존 모델을 이기는 것처럼 보이는 것을 찾는다. 많은 팀이 그런 자칭 승자를 만났다가 random seed를 바꾸자 성능 우위가 사라지는 것을 봤다.

승격 게이트에 randomization 체크를 넣어라 — A/B 테스트로 가져가기 전에.

8. 벤치마크를 소유하라

공개 벤치마크를 인프라 결정의 근거로 쓸 때의 문제:

대부분 작은 데이터셋, 합성 워크로드, 낮은 동시성을 사용한다. 프로덕션 현실은 매우 다르다.

Booking.com의 벡터 DB 평가 설계가 재사용 가능한 템플릿이다:

축	요구
데이터셋	전체 규모(1억), 사내에서 실제 쓰는 임베딩 모델, 메타데이터 포함
워크로드	full a-KNN + filtered a-KNN + 혼합 read/write(~20% 인제스션, closed-loop)
스케일링	동시성 5→50→100, P50이 아니라 P99
⭐ 정규화	모든 후보를 동일 recall(~0.99)로 튜닝

recall 정규화가 없으면 “더 대충 찾는 시스템”이 이긴다. ANN은 정확도를 속도와 교환하므로, 이 통제 없는 레이턴시 비교는 무의미하다.

가장 중요한 교훈은 특정 벤더나 기능이 아니라 평가 자체의 소유권이다. 대규모에서 워크로드는 고도로 특수하고 일반 벤치마크가 실세계 동작을 반영하는 경우가 드물다.

→ Vector Database Selection

9. 데이터 품질도 평가 문제다

품질 체크를 “통과/실패”로만 보면 놓치는 것들:

test run ≠ test health — T-1 completeness test가 이틀 전 실패하고 어제·오늘 통과했다면, 그 파티션이 백필·검증될 때까지 test는 여전히 unhealthy다
품질 신호가 confidence를 주도해야 한다 — 모델은 stale한 답에 확신할 수 있고, freshness SLA가 그 잘못된 확신을 무효화한다
⚠️ 여러 신호를 단일 점수로 합치는 것은 열린 설계 문제다. 매끄러운 composite보다 hard gate로 시작하라 — 어떤 SLA 위반이든 다른 신호와 무관하게 인간을 강제. 가중 점수는 그것이 단순 규칙을 이긴다고 보여줄 수 있을 때만
알림 피로 — DPI가 자주 시끄럽거나 중복되면 사용자는 결국 무시하는 법을 배운다

→ Data Quality and Validation, Data Incident Operations, AI-Ready Data

공통 교훈

오프라인 정렬은 필요하지만 충분하지 않다 — 온라인 검증을 별도로
답이 아니라 경로를 평가하라 — 우연히 맞은 답은 다음 릴리스에서 깨진다
정확도가 아니라 재현성을 물어라 — 실패를 모델이 아니라 명세로 재귀속시킨다
임계를 인간 불일치에서 유도하라 — 고정 임계는 난이도를 무시한다
드리프트 탐지와 기준 검토는 다른 장치다 — 둘 다 필요
탐색량이 늘면 randomization 체크가 필수가 된다
벤치마크를 소유하고 recall을 정규화하라
평가 데이터가 틀리면 최적화가 해를 끼친다 — harness에 결정적 실패 처리를
rationale을 라벨과 함께 수집하라 — 인간의 이유를 적어두지 않으면 judge의 추론을 교정할 수 없다
평가 자동화 ≠ 책임 위임

Data Eng Wiki

탐색기

Evaluation and Measurement

Evaluation and Measurement

개요

1. 오프라인 정렬은 필요하지만 절대 충분하지 않다

2. 답이 아니라 경로를 평가하라

실천

3. 정확도 eval에서 재현성 eval로

4. ⭐ 임계를 고정값이 아니라 인간 불일치로

5. 드리프트 탐지 ≠ 기준 검토

6. 효과를 어떻게 분해하는가

7. ⚠️ 탐색량이 늘면 가짜 승자도 늘어난다

8. 벤치마크를 소유하라

9. 데이터 품질도 평가 문제다

공통 교훈

관련 위키

관련 토픽

그래프 뷰

목차

백링크