🤖 AI

Towards Evaluation Engineering: An Empirical Study of ML Evaluation Harnesses in the Wild

본 논문은 57 개의 머신러닝 평가 하네스에 대한 실증 연구를 제시하여, 스펙 지정 단계를 운영상의 주요 문제 원인으로 규명하고, 16,560 건의 문제를 근본 원인에 따라 분류하여 구현되지 않은 기능, 문서화 부재, 그리고 누락된 입력 유효성 검사가 문제의 60% 이상을 차지함을 드러내며, 평가 공학을 별도의 소프트웨어 공학 분야로 취급하기 위한 기반을 마련한다.

원저자: Zhimin Zhao, Zehao Wang, Abdul Ali Bangash, Bram Adams, Ahmed E. Hassan

게시일 2026-05-26

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Zhimin Zhao, Zehao Wang, Abdul Ali Bangash, Bram Adams, Ahmed E. Hassan

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 새로운 레시피를 평가하려는 셰프라고 상상해 보세요. 당신은 재료 (데이터), 레시피 카드 (모델), 그리고 어떤 요리를 '훌륭한' 것으로 만드는지에 대한 규칙 목록 (지표) 을 가지고 있습니다. 하지만 음식을 맛보기 전에, 요리를 할 부엌, 조리 시간을 추적할 타이머, 그리고 결과를 기록할 점수판이 필요합니다.

인공지능 (AI) 세계에서는 이 '부엌'을 **평가 하네스 (Evaluation Harness)**라고 부릅니다. 이는 실제로 테스트를 실행하고, 데이터를 로드하며, 점수를 계산하고, AI 모델이 잘 수행하고 있는지 알려주는 소프트웨어 도구입니다.

이 논문은 57 가지 다른 'AI 부엌'이 어떻게 작동하는지, 어디에서 고장 나는지, 그리고 왜 사람들이 그것들에 대해 좌절하는지 살펴보기 위한 대규모 검사와 같습니다. 연구자들은 이 새로운 분야를 **평가 공학 (Evaluation Engineering)**이라고 부릅니다.

다음은 그들의 발견 사항을 간단한 비유로 정리한 것입니다:

1. 5 단계 부엌 워크플로우

연구자들은 모든 AI 평가 부엌이 생산 라인처럼 5 가지 특정 단계를 거친다는 것을 발견했습니다:

프로비저닝 (부엌 세팅): 가스레인지, 냄비, 재료를 준비합니다. 여기에는 소프트웨어 설치와 계정 로그인이 포함됩니다.
명세 (레시피 작성): 정확히 무엇을 요리할지, 어떤 재료를 사용할지 결정합니다. 여기서 AI 모델과 테스트 데이터를 로드합니다.
실행 (음식 조리): AI 모델을 실제로 실행하여 답변을 생성합니다.
평가 (시식 및 점수 매기기): 정답과 답변을 비교하고 점수를 계산합니다.
보고 (메뉴 제공): 차트나 보고서로 최종 결과를 보여줍니다.

큰 놀라움: 대부분의 부엌은 '조리 (실행)'에는 뛰어나지만 '제공 (보고)'에는 형편없습니다. 어제보다 오늘 음식 맛이 떨어졌는지 알려주는 자동 경보 시스템이 있는 부엌은 매우 드뭅니다.

2. 문제가 발생하는 곳 (근본 원인)

팀은 사용자들로부터 16,000 건 이상의 불만 (이슈라고 함) 을 조사했습니다. 그들은 문제들이 보통 수학이 잘못되었거나 코드가 극적으로 충돌하기 때문이 아니라는 것을 발견했습니다. 대신, 문제들은 대부분 관료주의적이고 누락된 부분에서 비롯됩니다.

지침이 누락되었거나 상자에 '빨간 벽돌 포함'이라고 적혀 있지만 실제로는 파란 벽돌만 들어있는 레고 세트를 조립하려는 것이라고 생각해 보세요.

부엌이 실패하는 상위 3 가지 이유는 다음과 같습니다:

기능 누락 (24%): 도구가 특정 작업을 수행할 것이라고 약속했습니다 (예: 특정 유형의 데이터 처리). 하지만 개발자들은 실제로 그 부분을 만들지 않았습니다. 스티어링 휠은 있지만 엔진이 없는 차와 같습니다.
나쁜 지침 (20%): 도구는 작동하지만 매뉴얼이 없거나, 구식이거나, 혼란스럽습니다. 사용자들이 어떻게 사용하는지 파악할 수 없습니다.
안전 점검 부재 (17%): 도구가 재료가 신선한지 확인하지 않습니다. 나쁜 데이터를 입력하면 멈추지 않고 쓰레기를 요리하여 쓰레기 같은 점수를 제공합니다.

3. 부엌의 다양한 유형

연구자들은 57 개의 부엌을 4 가지 '원형 (유형)'으로 그룹화했으며, 각 유형에는 고유한 두통이 있습니다:

표준화 테스트 부엌 (40%): 표준 시험 (AI 의 SAT 와 같은) 에 대해 여러 모델을 테스트하는 크고 유명한 부엌들입니다.
- 가장 큰 두통: 의존성 파손. 그들은 예고 없이 변경되거나 사라지는 외부 재료 (데이터셋) 에 의존합니다. 공급업체가 포장 방식을 바꾸면 부엌 전체가 작동을 멈춥니다.
전문 도구 (21%): 한 가지 일만 완벽하게 수행하는 작은 도구들입니다 (예: 로봇이 걸을 수 있는지 확인).
- 가장 큰 두통: 나쁜 지침. 너무 단순하기 때문에 개발자들이 설정 방법을 명확하게 설명하는 지침을 작성하는 것을 잊어버립니다.
커스텀 프로브 (21%): 코딩이나 수학 같은 특정 기술을 테스트합니다.
- 가장 큰 두통: 수학 오류. 자신만의 점수 계산 공식을 만들기 때문에 종종 수학을 잘못 계산하여, 점수는 올바르게 보이지만 실제로는 잘못된 침묵하는 오류를 초래합니다.
풀서비스 레스토랑 (17%): 모든 것을 수행하는 세련된 올인원 플랫폼들입니다.
- 가장 큰 두통: 계약 불일치. 원격 심사관과 로컬 모델과 같이 많은 다른 부분들을 연결하기 때문에, 부분들이 종종 같은 언어로 소통하지 못해 의사소통 장애가 발생합니다.

4. '침묵하는 살인자'

논문의 가장 위험한 문제는 침묵하는 점수 오류입니다.

심판이 수프를 맛보고 5 스타 등급을 매기는 상황을 상상해 보세요. 심판은 자신 있고, 점수가 인쇄되며, 모두 행복해합니다. 하지만 심판은 실제로 소금을 넣는 것을 잊어버렸고, 수프는 끔찍하게 맛이 있습니다. 도구가 충돌한 것은 아닙니다. 단지 잘못된 점수를 제공했을 뿐입니다.

논문은 많은 도구들이 점수를 잘못 계산하거나 (알고리즘 오류) 데이터가 타당한지 확인하지 못한다는 것 (검증 격차) 을 발견했습니다. 그리고 시스템에 '제 2 의 의견'이 내장되어 있지 않기 때문에, 훨씬 나중에야 사람들이 이를 알아차립니다.

5. 미래에 대한 의미

이 논문은 이러한 도구들을 단순한 '스크립트'가 아닌 진지한 공학 제품으로 취급해야 한다고 결론 내립니다.

개발자는 수학이 완벽하다고 가정하는 것을 멈추고 '안전망' (예: 점수를 인쇄하기 전에 타당한지 확인) 을 구축해야 합니다.
사용자는 점수를 맹신하는 것을 멈춰야 합니다. 도구가 '95% 정확도'라고 한다고 해서 그것이 진실이라는 뜻은 아닙니다. 작업을 다시 확인해야 합니다.
연구자는 이러한 도구들을 테스트할 새로운 방법을 개발해야 합니다. 왜냐하면 '테스트' 자체가 환각을 일으킬 수 있는 AI 일 때, 소프트웨어를 테스트하는 기존 방법은 작동하지 않기 때문입니다.

간단히 말해: 우리는 다른 기계를 테스트하기 위해 놀라운 기계를 구축했지만, 테스트를 수행하는 기계들은 종종 지침이 누락되어 있고, 논리에 구멍이 있으며, 혼란스러울 때 우리에게 알려줄 능력이 부족합니다. 이러한 '부엌'을 고치는 것은 더 나은 '셰프 (AI 모델)'를 만드는 것만큼이나 중요합니다.

기술 요약: 평가 엔지니어링을 향해: 현장의 ML 평가 하네스에 대한 실증 연구

1. 문제 제기

머신러닝 (ML) 평가는 AI 발전의 기반이 되지만, 이러한 평가를 실행하는 소프트웨어 인프라인 **평가 하네스 (evaluation harnesses)**는 소프트웨어 공학 (SE) 관점에서 제한된 관심을 받아 왔습니다. 기존 문헌은 무엇을 평가할지 (지표, 벤치마크, 능력) 에 초점을 맞추는 반면, 하네스 자체를 고유한 운영 워크플로우, 실패 모드 및 설계 트레이드오프를 가진 엔지니어링된 소프트웨어 제품으로 다루기보다는 투명한 도구로 간주합니다.

이 격차는 **평가 엔지니어링 (EvalEng)**에 대한 이해 부족을 초래합니다. 평가 엔지니어링은 하네스 설계, 의존성 관리, 채점 정확성, 결과 무결성 등 평가의 운영화에서 발생하는 SE 관련 문제를 포함합니다. 이러한 이해가 부족할 경우, 벤치마크 오염, 재현 불가능한 결과, 복잡한 인프라에서 탐지하기 어려운 침묵하는 채점 오류와 같은 문제로 인해 ML 평가의 신뢰성이 훼손됩니다.

2. 방법론

저자들은 2026 년 1 월 6 일까지 수집된 57 개의 오픈소스 평가 하네스와 19,638 개의 GitHub 이슈 (버그 리포트, 기능 요청, 사용 질문) 에 대한 대규모 실증 연구를 수행했습니다. 연구는 4 단계 방법론을 적용했습니다:

하네스 수집: 연구자들은 큐레이션된 소스 (예: Awesome Production ML List) 에서 57 개의 하네스를 식별하고 키워드 기반 GitHub 검색을 통해 범위를 확장했습니다. 포함 기준은 명시적인 평가/벤치마킹 기능, 모델 호출, 그리고 활성 유지 관리 (500 개 이상의 스타, 최근 12 개월 내 활동) 였습니다.
워크플로우 추출: 문서와 로컬 실행에 대한 반복적 오픈 카드 정렬과 상수 비교를 통해 계층적 워크플로우 모델을 도출했습니다. 이 과정은 51 번째 하네스에서 이론적 포화 상태에 도달했습니다.
이슈 마이닝: 팀은 57 개의 하네스 (59 개의 저장소에 걸친) 에서 19,638 개의 이슈를 검색했습니다.
분류: 수동 주석과 대규모 언어 모델 (LLM) 분류를 결합한 하이브리드 접근 방식을 사용했습니다.
- 수동 주석: 워크플로우 단계와 근본 원인을 위한 분류 체계를 확립하기 위해 두 명의 저자가 통계적으로 유의미한 377 개의 이슈를 수동으로 라벨링했습니다. 평가자 간 신뢰도는 높았습니다 (Cohen's $\kappa > 0.87$ ).
- LLM 보정: Claude Haiku 4.5 기반 분류기를 인간 합의 라벨에 대해 보정하여 전체 코퍼스에 적용함으로써 이슈를 워크플로우 단계 및 근본 원인 범주에 매핑했습니다.

3. 주요 기여

이 논문은 네 가지 주요 기여를 통해 EvalEng 에 대한 실증적 기반을 마련합니다:

통합 워크플로우 모델: ML 평가의 운영 수명주기를 설명하는 5 단계, 9 단계, 34 전략 모델 (Provisioning $\to$ Specification $\to$ Execution $\to$ Assessment $\to$ Reporting).
실증적 이슈 매핑: 57 개 하네스 전반에 걸친 16,560 개의 워크플로우 관련 GitHub 이슈를 분류하여 운영 마찰이 발생하는 지점을 식별합니다.
근본 원인 분류 체계: 소프트웨어 결함 (예: 알고리즘 오류) 과 기능 격차 (예: 구현되지 않은 기능) 를 구분하는 10 개 범주의 운영 과제 분류 체계.
도입 격차 식별: 불확실성 정량화 및 회귀 경고와 같은 생산 지향 기능에서 상당한 격차가 있음을 보여주는 분석.

4. 주요 결과

RQ1: 운영 워크플로우

연구는 5 단계 워크플로우를 식별했습니다:

Provisioning (환경 구성): 환경 설정 및 자격 증명 구성.
Specification (명세): 입력 (모델, 데이터셋) 및 채점 판정자 정의.
Execution (실행): 테스트 대상 시스템 (SUT) 실행.
Assessment (평가): 지표 계산 및 점수 집계.
Reporting (보고): 결과 시각화 및 회귀에 대한 경고.

결과:

오프라인 우세: 대부분의 하네스 (표준화된 LLM 스위트 40.4%, 좁은 도메인 라이브러리 21.1%) 는 정적 오프라인 워크플로우로 제한됩니다. 전체 5 단계를 모두 아우르는 것은 17.5%(풀스택 LLM 플랫폼) 에 불과합니다.
전략 격차: 설치 (git clone, Python 패키지) 는 거의 보편적이지만, 컨테이너화된 배포는 드뭅니다 (21.1%). 생산 트래픽 샘플링은 하네스의 7.0% 만 지원합니다.
보고 부족: 보고는 가장 지원이 부족한 단계입니다. 하네스의 22.8% 만 불확실성을 정량화하며, 8.8% 만 회귀 경고를 제공합니다.

RQ2: 운영 과제의 근본 원인

연구는 16,560 개의 이슈를 10 가지 근본 원인으로 분류했습니다. 상위 3 가지 원인은 전체 이슈의 **61.7%**를 차지합니다:

구현되지 않은 기능 격차 (24.3%): 필요한 기능이 누락됨.
문서 부족 (20.3%): 누락되거나 구식인 지침.
검증 격차 (17.2%): 입력/출력 검증 누락.

아키타입별 패턴:

표준화된 LLM 스위트: 이슈 수가 많음; 2 차 근본 원인은 변화하는 상류 데이터셋에 대한 의존성으로 인한 *외부 의존성 파손 (8.9%)*입니다.
작업 특화 프로브: 2 차 근본 원인은 도메인 맞춤형 채점이 참조 구현을 갖추지 못했기 때문에 발생하는 *알고리즘 오류 (11.9%)*입니다.
풀스택 플랫폼: 2 차 근본 원인은 복잡한 다중 구성 요소 통합으로 인한 *인터페이스 계약 불일치 (10.6%)*입니다.
좁은 도메인 라이브러리: *문서 부족 (31.8%)*이 기능 격차를 능가하는 주요 근본 원인입니다.

RQ3: 단계별 근본 원인 분포

근본 원인은 균일하게 분포되지 않으며 특정 단계에 집중됩니다:

Provisioning: *환경 비호환성 (16.1%)*과 *외부 의존성 파손 (20.1%)*이 우세합니다.
Specification: *구현되지 않은 기능 격차 (32.8%)*와 *문서 부족 (27.1%)*에 집중됩니다.
Assessment: *알고리즘 오류 (25.9%)*와 *검증 격차 (22.5%)*가 우세합니다.
교차적: 검증 격차는 5 단계 모두에서 10% 이상으로 나타나는 유일한 근본 원인으로, 더 나은 시맨틱 검증에 대한 체계적 필요성을 나타냅니다.

워크플로우 변화: 초기 단계의 환경 관련 문제에서 후기 단계의 채점 관련 문제로 과제가 이동합니다.

5. 중요성과 함의

이 논문은 평가 신뢰성이 지표 설계 이상의 별도의 소프트웨어 공학 문제라고 주장합니다.

개발자를 위해:
- 침묵하는 실패를 방지하기 위해 스키마 검증을 넘어 시맨틱 API 계약으로 이동하십시오 (예: 유효한 유형이지만 잘못된 시맨틱).
- 하네스 출력은 종종 독립적인 기준이 부재하므로 채점 파이프라인에 오라클 독립 검증 (예: 변태적 테스트, 차등 테스트) 을 구현하십시오.
- 아키타입별 실패 모드에 맞춘 유지보수를 수행하십시오 (예: 벤치마크 스위트는 의존성 고정, 풀스택 플랫폼은 계약 테스트).
- 워크플로우 범위, 의존성 및 알려진 과제 패턴을 선언하는 기계 가독성 명세서 문서 (모델 카드와 유사) 를 출시하십시오.
사용자를 위해:
- 특히 설계된 벤치마크 구성에서 벗어나는 경우, 독립적 검증 없이 하네스 출력을 기준 진실로 취급하지 마십시오.
- 대부분의 하네스가 불확실성 정량화를 지원하지 않으므로 실제 기능 격차와 하네스 아티팩트를 구분하기 어렵다는 점을 인식하십시오.
연구자를 위해:
- 평가 엔지니어링을 SE 연구 문제로 간주하십시오. 기존 MLOps 및 테스트 프레임워크는 평가 하네스의 고유한 제약 (예: 프롬프트 민감도, 이동하는 기준선, 정적 대 생산 트래픽 분포 변화) 을 처리할 수 있도록 구조적 조정이 필요합니다.
- 기준선이 안정적이지 않은 환경에서 회귀 임계값과 통계적 유의성을 정의하는 방법을 조사하십시오.

이 연구는 평가 신뢰성 향상을 위해 지표나 벤치마크에 대한 고립된 개선보다는 모든 단계에 걸친 워크플로우 설계에 대한 전체적 접근이 필요하다고 결론 내립니다. 제공된 워크플로우 모델과 근본 원인 분류 체계는 평가 인프라의 성숙도를 추적하기 위한 종단 연구의 기준선을 제공합니다.