측정할 수 없으면 개선할 수 없다
기능을 먼저 만들지 말고, 잘 했는지 아는 법을 먼저 만들어라
측정 체계 없는 LLM 개선은 감으로 핸들을 꺾는 일이다
| eval 없이 | eval 먼저 | |
|---|---|---|
| 변경 판단 | "느낌상 좋아진 듯" | 점수로 개선/회귀 판별 |
| 반복 속도 | 매번 사람이 눈으로 확인 | 자동 회귀 게이트로 즉시 |
| 배포 안전 | 프로덕션에서 사고로 발견 | 배포 전 회귀 차단 |
싼 것부터 비싼 것까지 — 단계마다 거르고, 위로 갈수록 적게 쓴다
정확도·정규식 매칭·코드 실행·검색 메트릭(recall/precision)처럼 기계로 즉시 채점되는 것. 비용이 거의 없으니 모든 변경마다, CI에서 돌린다. 1차 회귀 게이트의 주력이다. 한계: "정답이 정해진" 태스크에만 쓸 수 있다.
요약 품질·말투·유용성·근거성처럼 정답이 하나로 안 떨어지는 것을 모델이 루브릭으로 채점한다. 강한 모델은 사람과 80~90% 일치(태스크·세팅에 따라 다름). 자동 지표가 못 잡는 영역을 메우지만 편향이 있다 — §LLM-as-Judge 참고.
전문가·실사용자의 판단. 가장 비싸고 느리니 아껴 쓴다 — 골드셋 구축, judge 보정(judge가 사람과 맞는지 검증), 분기별 품질 점검 같은 결정적 순간에. 1·2계층을 신뢰하려면 결국 여기에 닻을 내려야 한다.
정확도를 과대평가하는 경향을 알고 써야 한다
| 편향 | 증상 | 완화 |
|---|---|---|
| Position bias | 두 답을 비교할 때 앞/뒤 위치에 따라 판정이 갈림 (10~15% 수준 보고) | 순서를 바꿔 두 번 채점해 평균 · 동률 허용 |
| Verbosity bias | 길고 장황한 답을 더 좋게 점수 줌 | 길이를 통제하거나 루브릭에 간결성 명시 |
| Self-preference | 같은 계열 모델이 쓴 답을 선호 | judge와 생성 모델을 분리 · 교차 검증 |
| 과신 | 틀린 답에도 높은 확신 점수 | 사람 골드셋으로 judge 정확도를 먼저 측정 |
① 명확한 루브릭 — "좋음/나쁨"이 아니라 점수 기준을 구체적으로. ② CoT + 근거 — 점수만 말고 이유를 쓰게 하면 일관성↑. ③ 절대평가보다 쌍대비교가 대체로 안정적. ④ judge 자체를 골드셋으로 검증 — "judge가 사람과 얼마나 맞나"를 수치로 알고 시작한다. 모르면 judge 점수를 믿을 근거가 없다.
직접 다 짤 필요는 없다 — 역할별로 골라 쓴다
| 도구 | 강점 | 주로 쓰는 곳 |
|---|---|---|
| DeepEval | pytest 스타일 LLM 단위 테스트 | CI 회귀 게이트로 eval을 코드처럼 |
| Ragas | RAG 전용 지표(faithfulness·context recall 등) | 검색·근거성 평가 |
| Langfuse | 관측성(trace) + 평가 통합 | 프로덕션 로그 위에서 평가 |
| Phoenix (Arize) | 할루시네이션·드리프트 추적 | 운영 모니터링·근본원인 분석 |
| Braintrust | 평가 + 실험 로깅·비교 | 프롬프트/모델 A·B 비교 |
* 도구 지형은 빠르게 바뀝니다(2026.06 스냅샷). 역할(테스트·RAG·관측성·실험)로 고르는 관점이 도구명보다 오래 갑니다.
평가를 하는데도 틀린 결론에 이르는 길
측정 없이 몇 주 개발한 뒤, 좋아졌는지 판단할 기준이 없어 감으로 결정한다.
LLM-judge가 준 점수를 진실로 받아들인다. judge가 사람과 얼마나 맞는지는 측정한 적이 없다.
쌍대비교에서 순서만 바꿔도 결과가 뒤집히는데, 한 방향으로만 채점한다.
공개 벤치마크 점수가 높다고 우리 도메인에서도 좋을 거라 가정한다.
초기 골드셋이 실제 트래픽 분포와 멀어지는데 갱신하지 않는다(데이터 드리프트).