LLM 시스템에서 가장 흔한 실수는 “이전보다 좋아진 것 같다”는 vibe로 변경 결정을 내리는 것이다. 프롬프트 한 줄 바꾸고 두세 개 테스트해본 뒤 좋아 보이면 배포한다. 그런데 그 변경이 다른 30개 케이스에서 어떻게 작동하는지는 아무도 모른다. Evals 없이 운영하는 LLM 시스템은 사실상 눈을 감고 운전하는 것이다.
근거
“How important evals are to the team is a major differentiator between folks rushing out hot garbage and those seriously building products in the space.”
Yan이 제안하는 해법은 **EDD(Eval Driven Development)**다. TDD처럼 들리지만 의미가 다르다. TDD는 “먼저 실패하는 테스트를 쓰고 통과시켜라”이고, EDD는 “먼저 작업별 eval set을 모으고, 모든 변경을 그 eval로 측정하라”다. MMLU 같은 학술 벤치마크는 무시하고 자기 작업 데이터로 만들라는 게 핵심이다. 학술 벤치마크는 구현 방식에 따라 같은 모델도 점수가 크게 달라지고, 무엇보다 내 제품과 무관하다.
이 사고방식을 0004_Wikis에도 적용해야 한다. “이 위키 시스템이 잘 작동한다”를 무엇으로 측정할 것인가? 후보 — clipping → 노트 변환 정확도, 노트 간 평균 링크 수, 일주일 후 재발견 성공률. 측정 지표가 없으면 파이프라인을 “개선”한다고 해도 그게 진짜 개선인지 확인할 길이 없다.
또 하나의 함정 — LLM-as-judge를 쓸 때 self-enhancement bias를 조심해야 한다. GPT-4는 자기 답을 10% 더 좋게 평가하고, Claude-v1은 25% 더 좋게 평가한다. 같은 모델 패밀리로 평가하지 않는 것이 기본 원칙.
연결된 생각
- 20260508-demo-to-product-gap-7-patterns — Evals는 7패턴 중 가장 기초
- 20260508-guardrails-defensive-ux-for-trust — Evals는 성능, Guardrails는 신뢰 — 둘 다 필요
출처
📎 클리핑 · eugeneyan.com