GeekNews 상단에는 Hamel Husain 팀의 LLM Evals FAQ도 올라왔습니다. 700명 이상의 엔지니어·PM에게 LLM 평가를 교육하면서 반복적으로 나온 질문을 정리한 자료입니다. news.hada.io

여기서 가장 중요한 주장은 단순합니다.

먼저 metric을 고르는 것이 아니라 실제 실패 사례부터 분석하라는 것입니다.

권장 흐름은:

사용자 trace 수집 → 사람이 오류 기록 → failure taxonomy 구성 → 빈도 측정 → eval 작성

입니다. hamel.dev

초기에는 최소 약 100개의 실제 trace를 사람이 직접 검토하고, 반복적으로 나타나는 실패 유형을 찾는 방식을 권합니다. 이후 random sampling, stress test, outlier detection 등으로 문제 사례를 확장합니다. hamel.dev

실무 시사점

자연어 → 구조화 데이터 시스템이라면 다음과 같은 generic accuracy 하나만 두는 것보다:

  • intent 오판
  • 날짜 잘못 해석
  • 필수 정보 누락
  • 잘못된 entity 생성
  • clarification 누락
  • 잘못된 tool-call
  • 중복 작업 생성

등을 독립된 failure category로 관리하는 것이 좋습니다.

각 오류 유형마다 발생률을 추적하면 모델이나 프롬프트를 변경했을 때 무엇이 개선되고 무엇이 악화됐는지 바로 알 수 있습니다.