공개 벤치마크가 부족한 세 가지 상황

MMLU, HELM, BIG-Bench는 일반적인 능력을 측정합니다. 다음 세 가지 상황에서는 커스텀 벤치마크 (Custom Benchmarks)가 필요합니다:

사례 1: 도메인이 너무 전문적인 경우

자동차 딜러의 서비스 지식 베이스 Q&A 시스템은 "2023년형 VW Magotan B8의 DSG 변속기 보증 기간은 얼마인가요?"와 같은 질문을 받습니다. 이를 다루는 공개 벤치마크는 없습니다. 도메인 전문 지식, 고객의 표현 방식, 답변 형식이 모두 기업 특화적이기 때문입니다.

사례 2: 데이터를 조직 외부로 유출할 수 없는 경우

의료, 금융, 정부 시나리오에는 제3자 평가 플랫폼에 업로드할 수 없는 민감한 정보가 포함되어 있습니다. 벤치마크는 내부적으로 구축되고 실행되어야 합니다.

사례 3: 지속적인 품질 모니터링

공개 벤치마크는 정적입니다. 한 번 실행하면 끝납니다. 커스텀 벤치마크는 새로운 질문을 추가하고, 정책이 변경될 때 정답 (Ground Truth)을 업데이트하며, 모델이나 지식 베이스가 업데이트될 때마다 품질 변화 (Quality Delta)를 추적합니다.

구축 워크플로우 (Construction Workflow)

1단계: 평가 시나리오 정의

질문을 단 하나라도 작성하기 전에, 이 벤치마크가 어떤 사용자 의도 (User Intents)를 다룰지 결정하십시오. 모든 것을 다 다루려고 하지 마세요.

기업용 문서 Q&A를 위한 실질적인 시나리오 분류 예시:

# eval_scenarios.yaml
scenarios:
  - id: S01
...

실용적인 벤치마크는 48개의 시나리오를 다루며, 각 시나리오당 1020개의 질문을 포함하여 총 50~150개로 구성됩니다. 너무 적으면 통계적 유의성이 부족하고, 너무 많으면 구축 비용이 높아집니다.

2단계: 질문 생성

방법 A: 수동 작성 (가장 정확함, 비용 가장 높음)

장점: 실제 사용자의 표현 방식 사용, 데이터 오염 (Data Contamination) 위험 없음
단점: 느림, 도메인 전문가의 검토 필요
대상: 고보안 시나리오, 50개 미만의 질문

방법 B: LLM 생성 + 인간 검토 (권장)

QUESTION_GEN_PROMPT = """다음 문서를 바탕으로 {n}개의 테스트 질문을 생성하세요.

요구사항:
...

생성 후, 사람은 다음 두 가지 작업을 수행합니다:

1. 명백한 오류 필터링 (모호함, 문법 오류, 중복)
2. 20% 샘플 검사: 지식 베이스에 실제로 답변이 포함되어 있는지 확인

방법 C: 프로덕션 로그에서 추출 (가장 실제에 가까움)

시스템이 라이브 상태라면, 실제 사용자 쿼리가 가장 가치 있는 소스입니다. 이는 사용자들이 실제로 묻는 질문들입니다.

def sample_from_production_logs(logs, n=100):
    unique_queries = deduplicate(logs)
    # 시나리오 유형별 층화 추출 (Stratified sample)
...

3단계: 정답 (Ground Truth) 준비

정답(Ground truth)의 품질은 평가의 신뢰성을 직접적으로 결정합니다.

취약한 정답 (너무 모호함):

질문: 환불 정책이 무엇인가요?
정답: 환불이 가능합니다.

강력한 정답 (구체적이며 문서 내용과 일치함):

질문: 환불 정책이 무엇인가요?
정답: 구매 후 7일 이내에는 전액 환불 가능. 7~30일 사이에는 50% 환불.
      30일 이후에는 환불 불가. 주문 상세 페이지를 통해 신청하십시오;
...

정답 작성 규칙:

• 문서에서 직접 인용할 것 — 의역하거나 요약하지 마세요.
• 구체적인 숫자와 고유명사를 포함할 것 (이들은 충실도 (Faithfulness) 평가가 확인하는 앵커 역할을 합니다).
• 정답이 여러 개인 경우, 모두 포함하세요.
• 경계 테스트 (Boundary tests)를 위해, "이 정보는 지식 베이스에 없습니다"라고 작성하세요.

4단계: 난이도 층화 (Difficulty Stratification)

층화 (Stratification)는 시스템이 어디에서 무너지는지를 보여주며, 단일 통과율보다 더 높은 진단적 가치를 제공합니다.

세 가지 난이도 수준:

쉬움 (거의 완벽한 점수를 받아야 함):
  답변이 단일 문서의 단일 문단에 존재함
  예시: 질문과 답변이 동일한 청크 (chunk)에 있음; 직접적인 검색 (direct retrieval) 성공
...

난이도 조정 방법:

먼저 모든 질문을 시스템에 실행한 다음, 실제 통과율을 기반으로 난이도를 할당하세요. 직관에 따라 난이도를 할당하지 마세요.

def calibrate_difficulty(eval_results: list[dict]) -> list[dict]:
    for result in eval_results:
        score = result["avg_score"]
...

5단계: 버전 관리 (Version Control)

평가 세트에 버전 관리가 필요한 이유는 다음과 같습니다:

1. 표준 드리프트 (Standard drift) 방지: 누군가 조용히 정답 (ground_truth)을 수정하면 ("이건 틀렸으니 업데이트하자"), 과거 데이터와 비교가 불가능해집니다.
2. 데이터셋 진화 추적: 어떤 질문이 추가되거나 삭제되었는지, 그리고 그 이유는 무엇인지 추적합니다.
3. 롤백 (Rollback) 가능: 과거의 성능을 검증하기 위해 이전 시스템에 대해 이전 평가 세트를 실행할 수 있습니다.

# eval_dataset_v1.2.yaml
metadata:
  version: "1.2.0"
...

버전 번호 규칙 (Version number rules):

MAJOR: 시나리오 분류 체계(taxonomy) 변경 (카테고리 삭제 등)
MINOR: 새로운 질문 추가 또는 정답 (ground_truth) 업데이트
PATCH: 메타데이터, 주석, 포맷팅 변경 — 평가 결과에는 영향 없음

평가 세트 품질 체크리스트 (Evaluation Set Quality Checklist)

질문 품질 (Question quality):
  □ 모든 질문에 단일하고 명확한 정답이 있는가?
  □ 질문의 표현이 다양하며, 모두 "X는 무엇인가?" 식은 아닌가?
...

요약 (Summary)

1. 공개 벤치마크는 일반적인 능력을 테스트하고, 커스텀 벤치마크는 비즈니스 시나리오를 테스트합니다: 기업용 Q&A 시스템에 MMLU를 실행하는 것은 유용한 정보를 전혀 주지 못합니다. 50~150개의 도메인 특화 질문이 실제 품질을 반영합니다.
2. 난이도 계층화 (Difficulty stratification)는 단일 통과율보다 더 높은 진단 가치를 제공합니다: 전체 85%의 통과율은 쉬운(Easy) 질문들로 인해 부풀려질 수 있습니다. 어려운(Hard) 질문의 통과율은 시스템이 실제로 어디에서 무너지는지를 보여줍니다.
3. 평가 세트에는 버전 관리가 필요합니다: 버전을 추적하지 않고 정답 (ground_truth)을 변경하면 과거 데이터와의 비교가 무의미해집니다.

실제 기업급 워크플로우에서 검증된 AI 에이전트와 기술의 큐레이션 마켓플레이스인 PrimeSkills를 확인해 보세요. 거품 없이, 실제로 작동하는 것들만 모았습니다.

저의 홈페이지에서 더 유용한 지식과 흥미로운 제품들을 찾아보세요.