Agent Lab Journal

Guides

...

평가 엔지니어링 (Evaluation engineering)

테스트 대상인 LLM Judge: 직접 점수 매기기 (Direct Scoring) vs 쌍체 비교 (Pairwise Comparison)

중급 · 60분 소요 · 재현 가능한 평가 프로토콜 (Reproducible evaluation protocol)

자동 평가자 (Automatic judge)는 품질과 아무런 관련이 없는 특성임에도 불구하고, 일관되게 첫 번째 답변을 선호하거나, 더 긴 답변을 선호하거나, 혹은 자신의 모델 제품군(model family)이 생성한 답변을 선호할 수 있습니다. 이 가이드는 평가자(judge) 자체를 평가되어야 할 하나의 도구로 취급합니다. 여러분은 직접 점수 매기기 (direct scoring)와 쌍체 비교 (pairwise comparison)를 비교하고, 인간의 결정과의 일치도를 측정하며, 위치 편향 (positional bias)을 드러내기 위해 별도의 답변 교체 (answer-swap) 실험을 수행하게 됩니다.

여러분이 생성하게 될 결과물

결과물은 단일 리더보드 수치가 아닙니다. 다음과 같은 내용을 포함하는 증거 패키지(evidence package)입니다:

• 고정된 평가 루브릭 (evaluation rubric) 하에서 모든 후보 답변에 대한 직접 점수 (direct score).

• 명시적인 무승부 (tie) 옵션을 포함하여, 동일한 답변 쌍에 대한 쌍체 선호도 (pairwise preference).

• 자동 평가자와 독립적으로 수집된 인간 참조 판단 (human reference judgments).

• 각 자동화 전략과 인간 참조 간의 일치도 측정 (agreement measurements).

• 답변을 교체한 후 모든 쌍을 다시 판단하는 전용 위치 편향 테스트 (position-bias test).

• 실패 로그 (failure logs), 잘못된 출력 횟수 (invalid-output counts), 불확실성 구간 (uncertainty intervals), 그리고 모든 요약을 재현할 수 있는 충분한 원시 데이터 (raw data).

이 프로토콜은 데이터 생성, 판단, 분석을 의도적으로 분리합니다. 어떤 모델이나 서빙 플랫폼을 사용해도 무방하지만, 저장된 기록은 반드시 아래의 스키마 (schemas)를 따라야 합니다. 이를 통해 공유 자격 증명이나 특정 벤더가 필요하지 않으면서도 실험의 재현성을 유지할 수 있습니다.

왜 평가자(judge) 자체에 대한 시험이 필요한가

LLM judge는 작업(task), 후보 답변(candidate answer), 그리고 평가 지침(evaluation instructions)을 점수나 선호도로 변환합니다. 이는 반복적인 전문가 검토보다 빠르고 저렴하기 때문에 매력적입니다. 그러나 그 출력값은 정답(ground truth)이 아니라 또 다른 모델의 예측값입니다.

여러 가지 무관한 요인들이 설득력 있지만 오해를 불러일으키는 결과를 만들어낼 수 있습니다:

• 순서 (Order): 심사 모델(judge)이 답변 A가 먼저 나타났다는 이유로, 혹은 답변 B가 마지막에 나타났다는 이유로 선호할 수 있습니다.

• 길이 (Length): 상세함, 반복, 그리고 자신감 있는 문체가 완전성이나 정확성으로 오인될 수 있습니다.

• 자기 선호 (Self-preference): 심사 모델이 자신의 모델 제품군(model family)과 관련된 어구, 구조 또는 관습을 선호할 수 있습니다.

• 척도 드리프트 (Scale drift): 한 기록에서의 "4"가 실행 과정의 나중에 나타나는 "4"와 동일한 기준을 나타내지 않을 수 있습니다.

• 루브릭 누출 (Rubric leakage): 심사 모델이 답변이 실제로 루브릭(rubric)을 충족하는지 확인하지 않고, 루브릭에 명시된 가시적인 키워드에 보상을 줄 수 있습니다.

• 작업 지름길 (Task shortcuts): 근본적인 주장을 검증하기 어려울 때, 스타일이나 표면적 형태가 품질의 대리 지표(proxy)가 될 수 있습니다.

따라서 올바른 질문은 "어떤 전략이 더 깨끗한 수치를 만들어내는가?"가 아닙니다. 질문은 "어떤 전략이 허용 가능한 안정성과 알려진 실패 모드(failure modes)를 가지면서, 이 작업과 관련된 인간의 결정을 가장 잘 재현하는가?"가 되어야 합니다.

두 가지 전략

전략 1: 직접 점수 매기기 (Direct scoring)

직접 점수 매기기에서 심사 모델은 한 번에 하나의 답변만 보고, 정확성(correctness) 15점, 관련성(relevance) 15점과 같은 기준 점수(criterion scores)를 부여합니다. 그런 다음 가중치가 적용된 총점을 계산할 수 있습니다.

직접 점수 매기기는 절대적인 임계값(threshold), 기준 수준의 진단(criterion-level diagnostics), 또는 두 개 이상의 후보가 필요할 때 유용합니다. 또한 운영 규칙을 표현하기 쉽습니다. 예를 들어, "정확성이 3 미만인 모든 답변은 거부한다"와 같은 규칙입니다.

주된 약점은 보정(calibration)입니다. 점수가 상단에 몰리거나, 배치(batch) 간에 드리프트가 발생하거나, 척도 레이블에 대한 심사 모델의 해석에 따라 달라질 수 있습니다. 심사 모델이 이를 재현할 수 없는 경우에도 1점 차이가 의미 있게 보일 수 있습니다.

전략 2: 쌍체 비교 (Pairwise comparison)

쌍체 비교에서 심사 모델은 동일한 작업에 대한 두 개의 답변을 보고 A, B, 또는 무승부(tie)를 선택합니다. 이 결정은 상대적입니다: 어떤 답변이 루브릭을 더 잘 충족하는가?

쌍체 비교(Pairwise decisions)는 안정적인 절대적 척도(absolute scale)를 유지해야 하는 부담을 줄여주는 경우가 많습니다. 하지만 제시 순서(presentation order), 장황함(verbosity), 공통된 오류, 또는 인지 가능한 모델 스타일(model style)에 의해 여전히 편향될 수 있습니다. 또한 많은 후보군에 대해 많은 비교가 필요할 경우 비용이 많이 발생하게 됩니다.

      각 전략이 드러내는 것과 숨기는 것

          속성
...

구체적인 사례: 두 개의 지원 답변 시스템

Alpha와 Beta라는 두 시스템이 동일한 내부 지원 질문 세트에 답변한다고 가정해 봅시다. 이 실험은 어떤 판정 전략이 훈련된 인간 검토자(human reviewers)와 더 잘 일치하는지를 묻습니다.

분석 단위는 정확히 두 개의 후보 답변을 가진 하나의 작업(task)입니다:

{
  "item_id": "support_0042",
  "task": "만료된 API 키를 안전하게 회전하는 방법을 설명하세요.",
...

대상 워크로드(workload)에서 실제 항목을 사용하십시오. 평가만을 위해 작성된 편리한 예시들로 데이터셋을 채우지 마십시오. 하나의 답변이 누락되었거나, 손상되었거나, 다른 작업 버전에서 생성된 레코드는 제거하십시오.

첫 번째 연구에서는 중요한 작업 카테고리와 알려진 에지 케이스(edge cases)를 커버할 수 있을 만큼 충분한 항목을 목표로 하십시오. 단순히 원하는 유의성(significance) 결과를 얻기 위해 최종 개수를 선택하지 마십시오. 판정기(judge)를 실행하기 전에 샘플링 규칙을 기록하십시오.

고정된 루브릭 (Fixed rubric)

인간과 자동 판정기(automatic judge)가 동일한 근거에 적용할 수 있는 기준을 사용하십시오:

• 정확성 (Correctness): 주장이 제공된 작업 및 참조 컨텍스트(reference context)와 일치함.

• 관련성 (Relevance): 답변이 사용자의 실제 요청을 다룸.

• 완전성 (Completeness): 필요한 조치, 주의 사항 및 결과가 포함됨.

• 안전성 (Safety): 답변이 위험하거나, 승인되지 않았거나, 되돌릴 수 없는 지침을 피함.

• 명확성 (Clarity): 불필요한 반복 없이 답변을 이해할 수 있음.

스타일은 작업 품질보다 하위 개념으로 유지하십시오. 작업에서 명시적으로 길이 제한을 지정하지 않는 한 길이는 기준이 아닙니다. 정확하고 간결한 답변이 더 긴 답변을 이길 수 있도록 허용해야 합니다.

모델을 호출하기 전에 실험을 설계하십시오

1. 평가 단위 고정 (Freeze the evaluation unit)

보관이 허용되는 불변의 항목 식별자 (item identifier), 정확한 작업 텍스트 (task text), 승인된 컨텍스트 (context), 두 답변 모두, 시스템 식별자 (system identifiers), 그리고 생성 메타데이터 (generation metadata)를 저장하십시오. 작업과 답변을 해싱 (Hashing)하면 실행 간의 우발적인 편집을 감지하는 데 도움이 될 수 있습니다.

2. 개발 항목과 평가 항목 분리 (Separate development and evaluation items)

프롬프트 (prompts), 파서 (parsers), 그리고 스키마 (schemas)를 수정하기 위해 작은 규모의 개발 세트 (development set)를 사용하십시오. 프로토콜 (protocol)이 확정되면, 이를 별도의 평가 세트 (evaluation set)에서 실행하십시오. 평가 실패를 확인한 후 프롬프트를 반복적으로 변경하는 것은 평가 세트를 개발 세트로 변질시킵니다.

3. 익명성 유지 (Blind identities)

블라인드 평가 (blind evaluation)를 적용하십시오: 제품 및 모델 이름을 중립적인 라벨 (labels)로 교체합니다. 생성 시스템을 드러내는 문구가 사용자에게 보이는 답변의 일부가 아니라면 제거하십시오. 일반적인 스타일 차이는 다시 작성하지 마십시오. 이는 실제 출력의 일부이기 때문입니다.

4. 동점 상황 사전 정의 (Predefine ties)

동점 (tie)은 루브릭 (rubric)에 따라 어느 답변도 유의미하게 더 낫지 않음을 의미해야 합니다. 이는 파서의 폴백 (parser fallback)이나 불확실성에 대한 도피처가 되어서는 안 됩니다. 결과를 확인하기 전에 작은 직접 점수 (direct-score) 차이를 동점으로 처리할지 여부를 결정하십시오.

5. 독립적인 무작위화 (Randomize independently)

기록된 랜덤 시드 (random seed)를 사용하여 첫 번째 쌍체 비교 (pairwise) 단계에서 어떤 시스템이 A로 나타날지 결정하십시오. 모든 항목에 대해 Alpha를 첫 번째에 배치하지 마십시오. 그 후 스왑 단계 (swap pass)에서 첫 번째 단계의 정확한 순서를 뒤집어야 합니다.

6. 판사(Judge) 설정 고정 (Fix the judge configuration)

판사 식별자 (judge identifier), 노출된 경우 모델 버전 (model version), 프롬프트 버전 (prompt version), 디코딩 설정 (decoding settings), 응답 형식 (response format), 재시도 규칙 (retry rule), 타임아웃 (timeout), 그리고 실행 날짜를 기록하십시오. 낮은 무작위성 (randomness)은 재현성 (repeatability)을 향상시킬 수 있지만, 체계적 편향 (systematic bias)을 제거하지는 못합니다.

데이터 파일 (Data files)

단순한 디렉토리 구조로도 충분합니다:

evaluation/
├── items.jsonl
├── human_labels.csv
...

프로토콜 파일 (protocol file)은 실행 중에 변경되어서는 안 되는 결정 사항들을 캡처합니다:

study_id: support-alpha-beta-v1
item_id_field: item_id
rubric_version: support-rubric-v1
...

위의 숫자들은 설정 예시일 뿐, 최적의 값이라고 주장하는 것이 아닙니다. 평가를 시작하기 전에 귀하의 작업에 적합한 값을 선택하고 문서화하십시오.

Judge 프롬프트 및 출력 계약 (Output Contracts)

직접 점수 매기기 (Direct-scoring) 프롬프트

당신은 하나의 후보 답변을 평가하고 있습니다.

아래의 TASK, REFERENCE CONTEXT, RUBRIC, ANSWER만을 사용하십시오.
...

가능하다면 Judge Alpha와 Beta를 별도의 호출로 분리하십시오. 두 답변을 하나의 "직접" 프롬프트에 넣으면 작업이 암묵적인 비교(implicit comparison)로 변질될 수 있습니다. 단일 답변 호출이 실행되는 순서를 무작위화하고, 다른 답변의 점수를 노출하지 마십시오.

쌍체 비교 (Pairwise) 프롬프트

당신은 동일한 작업에 대한 두 개의 후보 답변을 비교하고 있습니다.

RUBRIC을 더 잘 충족하는 답변을 선택하십시오.
...

추론 코드(Reason codes)는 진단에 유용하지만, 자유 형식의 설명(free-form explanations)을 점수화된 결과값으로 사용하지 마십시오. 선택된 레이블이 불안정할 때도 설명은 그럴듯해 보일 수 있습니다.

인간 참조 데이터(Human Reference) 구축

인간 평가가 자동으로 정답이 되는 것은 아닙니다. 검토자(Reviewer)는 Judge와 동일한 작업, 컨텍스트, RUBRIC을 가져야 하며, 평가 세트에 포함되지 않은 학습 예시(training examples)도 필요합니다.

• 비용이 허용하는 한 최소 두 명의 독립적인 검토자를 배정하십시오.
• 시스템의 정체성과 자동 Judge의 출력값을 숨기십시오.
• 자동 실행과는 별도로 답변 순서를 무작위화하십시오.
• 만약 해당 점수들을 비교할 예정이라면, A, B 또는 무승부(tie) 및 기준 점수(criterion scores)를 요청하십시오.
• 토론을 하기 전에 초기 독립적 결정을 기록하십시오.
• 원래의 레이블을 삭제하지 말고, 서면 규칙에 따라 의견 불일치를 판정(Adjudicate)하십시오.

압축된 인간 레이블 파일은 다음과 같은 형태일 수 있습니다:

item_id,reviewer_id,alpha_score,beta_score,preference,is_adjudicated
support_0042,r01,4.2,3.4,ALPHA,false
support_0042,r02,4.0,3.8,ALPHA,false
...

판정된 라벨(adjudicated labels)을 참조값으로 사용하기 전에, 초기 검토자들 사이의 일치도(agreement)를 측정하십시오. 만약 인간이 루브릭(rubric)을 일관되게 적용할 수 없다면, 판정된 라벨과의 자동 일치도는 측정 프로세스의 품질을 과장할 수 있습니다.

4가지 필수 패스(passes) 실행

• Direct Alpha: 모든 Alpha 답변을 독립적으로 채점합니다.

• Direct Beta: 모든 Beta 답변을 독립적으로 채점합니다.

• Pairwise original: 기록된 무작위 A/B 제시 순서에 따라 판단합니다.

• Pairwise swapped: A와 B를 교체하고, 다른 모든 필드는 변경하지 않은 상태에서 다시 판단합니다.

첫 번째 쌍체 비교(pairwise) 결정 내용을 스왑(swap) 호출로 전달하지 마십시오. 이전 답변을 유지하는 대화형 세션(conversational sessions)을 피하십시오. 각 판단은 깨끗한 컨텍스트(clean context)에서 시작되어야 합니다.

제공자 중립적인 러너(provider-neutral runner)는 다음 작업을 수행해야 합니다:

for item in items:
    direct_alpha = judge_direct(item.task, item.context, item.answer_alpha)
    direct_beta  = judge_direct(item.task, item.context, item.answer_beta)
...

기록을 수락하기 전에 JSON 타입, 필수 키(required keys), 허용된 라벨, 점수 범위 및 중복 식별자를 검증하십시오. 형식이 잘못된 응답은 별도로 저장하십시오. 재시도(retry) 시에는 반드시 동일한 입력값과 문서화된 재시도 정책을 사용해야 합니다.

두 전략을 동일한 결정 공간(decision space)으로 정규화

직접 채점(direct scoring)은 숫자를 생성하고 쌍체 평가(pairwise evaluation)는 라벨을 생성하기 때문에, 이들의 일치도를 공정하게 비교할 수 없습니다. 두 방식 모두를 시스템 수준의 선호도인 ALPHA, BETA 또는 TIE로 변환하십시오.

직접 채점의 경우, 먼저 각 답변에 대한 가중치 합계(weighted total)를 계산합니다. 모든 기준의 가중치가 동일하다면:

direct_total = (
    correctness +
    relevance +
...

그 다음, 미리 정의된 타이 마진(tie margin)을 적용합니다:

difference = alpha_total - beta_total

if difference > tie_margin:
...

기록된 제시 순서를 사용하여 쌍체 A/B 라벨을 시스템 식별자로 다시 매핑하십시오. 원시 문자 A를 인간 라벨인 Alpha와 직접 비교해서는 안 됩니다.

인간과의 일치도 측정

완전 일치 (Exact agreement)

평가자 간 일치도 (Inter-rater agreement)는 자동화된 전략과 인간 참조(human reference)가 동일한 라벨을 선택한 유효 항목의 비율에서 시작됩니다:

exact agreement = matching labels / jointly valid labels

이때 분자와 분모를 모두 보고하십시오. 대상 항목의 수 없이 퍼센트(%)만 보고할 경우, 제외된 항목들이 숨겨질 수 있습니다.

혼동 행렬 (Confusion matrix)

인간 라벨과 판사(judge) 라벨을 위한 3×3 표를 작성합니다. 이를 통해 불일치가 무승부(ties)에 집중되어 있는지, 특정 시스템이 체계적으로 선호되는지, 혹은 판사가 인간의 명확한 결정을 뒤집는지 확인할 수 있습니다.

우연을 보정한 일치도 (Chance-corrected agreement)

하나의 자동화된 라벨을 하나의 최종 인간 라벨과 비교할 때, Cohen’s kappa는 완전 일치(exact agreement)를 보완할 수 있습니다. 이는 관찰된 라벨 빈도로부터 예상되는 일치도를 조정합니다:

kappa = (observed_agreement - expected_agreement)
        / (1 - expected_agreement)