쉽게 이해하기

LLM은 프롬프트나 샘플링 설정을 조금만 바꿔도 점수가 달라집니다. 팀마다 코드가 제각각이면 논문·블로그의 수치가 서로 비교되지도 않습니다. 이 혼란을 줄이기 위해, 모두가 같은 입력과 채점 규칙으로 같은 방식으로 돌려보는 장치가 필요합니다. 평가 하니스는 바로 그 장치입니다. 경기장에서 같은 규칙으로 달리게 하듯, 정해둔 데이터셋·프롬프트·메트릭으로 모델을 자동 시험합니다. 과제(task) 정의와 모델 백엔드(hf, vLLM, API 등)를 분리해, YAML/CLI로 과제를 선택하고 배치·디바이스·샘플 수를 지정합니다. 실행 중에는 표준 로그를 남기고, 결과는 동일 포맷으로 저장되어 리더보드나 대시보드에 바로 올릴 수 있습니다.

비유와 예시

• 사내 릴리즈 전 회귀 검사: 새 프롬프트 템플릿을 적용한 모델을 하니스로 돌려 기존 버전과 같은 과제에서 점수를 비교합니다. 특정 과제 점수가 떨어지면 CI 단계에서 배포를 중단합니다.
• RAG 설정 변경 영향 파악: 검색 단계 파라미터를 바꾸고 동일 쿼리 세트로 하니스 평가를 반복합니다. 검색 품질 저하가 최종 답변 정확도에 미치는 변화를 수치로 확인합니다.
• 에이전트 행동 평가 자동화: OpenHands 스타일 워크플로로 사용자 응답을 모의(user_response_fn)하고, 에이전트의 액션 이력과 결과를 기준으로 합격/실패를 산출합니다. 같은 작업을 여러 모델 설정에 일괄 적용합니다.

한눈에 비교

하니스는 내부 실험을 일관화하고 CI에 걸기 쉬워 팀 생산성을 높이고, 리더보드는 그 결과를 대외 비교에 활용합니다.

어디서 왜 중요한가

• EleutherAI의 LM Evaluation Harness는 Open LLM Leaderboard의 실행 기반으로 쓰이며, 다양한 벤치마크에서 비교 가능한 점수를 제공합니다.
• 조직은 배포 전 평가 게이트를 도입해, 하니스 메트릭이 후퇴하면 배포를 차단합니다.
• 프롬프트 템플릿과 태스크 구성을 공개/버전 관리하면 재현성과 감사 가능성이 높아집니다.
• OpenHands 같은 프레임워크는 컨트롤러 루프를 통해 에이전트 평가를 구조화합니다.
• 금융 등 특정 도메인에서는 전용 하니스를 통해 프롬프트 정책과 평가 규칙을 표준화합니다.

자주 하는 오해

• ❌ 하니스 점수가 높으면 실사용도 항상 좋다 → ✅ 특정 데이터·메트릭 기준의 상대 비교일 뿐이며, 운영 트래픽/제약을 반영하지 못할 수 있습니다.
• ❌ 한 번 설정하면 영원히 재현된다 → ✅ 데이터·태스크·프롬프트도 버전이 필요하고 고정/기록하지 않으면 재현성이 깨집니다.
• ❌ 하니스는 연구용만 쓴다 → ✅ CI 게이트·관측과 결합해 프로덕션 회귀 차단에 실무적으로 활용됩니다.

대화에서는 이렇게

• "이번 프롬프트 리팩터링은 하니스 CI 게이트를 통과해야 배포됩니다."
• "vLLM 백엔드로 바꿔 같은 과제셋에서 돌렸는데, latency는 줄었고 정확도는 동일합니다."
• "리더보드 제출 전, 내부 harness 설정(YAML)을 freeze해서 재현 로그를 남깁시다."
• "에이전트 평가에 user_response_fn을 붙여 상호작용을 고정해야 공정 비교가 됩니다."
• "이번 실패는 think_end_token 설정 차이로 보이니, 동일화 후 다시 측정합시다."

함께 읽으면 좋은 용어

• 기초
  Benchmark — 하니스가 실행하는 표준 과제 묶음입니다.
• 기초
  Metric — 정확도·EM 등 채점 규칙으로, 정의가 다르면 점수 비교가 무의미합니다.
• 유사
  Leaderboard — 공개 비교를 위한 순위판으로, 내부 하니스 결과를 대외 공유할 때 연결됩니다.
• 심화
  RAG — 검색 설정 변화가 성능에 주는 영향을 하니스로 정량화하기 좋습니다.
• 심화
  Agent — 액션 로그와 사용자 응답 모의를 포함한 상호작용 평가를 자동화합니다.
• 심화
  Observability — 실행을 계측해 회귀 원인과 비용·지연을 추적합니다.