Kwangmin Kim - LLM-as-a-Judge 평가 프롬프트 템플릿 설계

1 이론에서 실무로: 평가 프롬프트 설계의 실제

Part B에서 우리는 LLM-as-a-Judge가 왜 작동하는지, 얼마나 신뢰할 만한지를 살펴봤다. 이제 핵심 질문이 남았다: 실제로 어떻게 사용하는가?

판사 역할을 하는 LLM에게 단순히 “이 답변이 좋은지 평가해줘”라고 하면 될까? 아니다. 평가 프롬프트 자체를 정교하게 설계해야 한다. 좋은 평가 프롬프트는 일관되고, 명확하고, 포괄적인 평가를 이끌어낸다. 나쁜 평가 프롬프트는 편향되고, 모호하고, 재현 불가능한 결과를 낳는다.

이번 파트에서는 실제 사용되는 평가 프롬프트 템플릿들을 살펴보고, 그 설계 원칙과 실무 적용 방법을 구체적으로 다룬다.

2 LMSYS 논문의 원본 평가 프롬프트

MT-Bench 연구에서 사용된 원본 프롬프트를 먼저 살펴보자. 이것이 많은 후속 연구와 실무 적용의 기초가 되었다.

2.1 원본 프롬프트 전문

Please act as an impartial judge and evaluate the quality of the response 
provided by an AI assistant to the user question displayed below. 

Your evaluation should consider factors such as the helpfulness, relevance, 
accuracy, depth, creativity, and level of detail of the response. 

Begin your evaluation by providing a short explanation. Be as objective as 
possible. After providing your explanation, you must rate the response on a 
scale of 1 to 10 by strictly following this format.

이 프롬프트는 겉보기에 단순해 보이지만, 각 요소가 신중하게 설계되었다.

2.2 설계 원칙 1: 명확한 역할 부여

“Please act as an impartial judge”

왜 “impartial(공정한)” 이라는 단어를 사용했을까? 연구팀은 여러 실험을 통해 이 단어가 중요하다는 것을 발견했다. 역할 지시 없이 평가를 요청하면, 모델이 지나치게 관대하거나 또는 지나치게 엄격한 평가를 내릴 수 있다. “공정한 판사” 역할을 명시하면, 모델이 더 균형 잡힌 평가를 한다.

이는 프롬프트 엔지니어링의 일반 원칙과도 일치한다: 역할을 부여하면 모델이 그 역할에 맞는 톤, 스타일, 판단 기준을 적용한다. “당신은 수학 선생님입니다”라고 하면 교육적으로, “당신은 코드 리뷰어입니다”라고 하면 비판적으로 접근한다.

실무 팁: 평가 목적에 맞게 역할을 조정할 수 있다. 예를 들어:
- “당신은 초보자를 위한 교육 콘텐츠를 평가하는 교육학 전문가입니다” → 명확성과 이해 가능성에 높은 가중치
- “당신은 기술 문서의 정확성을 평가하는 시니어 엔지니어입니다” → 정확성과 완성도에 높은 가중치

2.3 설계 원칙 2: 다차원 평가 기준

“helpfulness, relevance, accuracy, depth, creativity, and level of detail”

6가지 차원을 명시했다. 이것이 중요한 이유:

포괄성: 단일 차원(예: 정확성만)으로는 품질을 완전히 포착할 수 없다. 정확하지만 도움이 되지 않는 답변, 자세하지만 관련성이 없는 답변이 존재한다.
명시성: 평가 기준을 명시하지 않으면 모델이 자체적인 기준을 적용한다. 그 기준이 당신의 의도와 다를 수 있다. 명시하면 일관성이 높아진다.
해석 가능성: 나중에 “왜 이 답변이 높은 점수를 받았는가?”를 추적할 수 있다. “정확도는 높지만 창의성이 낮았다”처럼 구체적으로 이해할 수 있다.

그런데 왜 하필 이 6가지 차원일까? 연구팀은 다양한 차원 조합을 실험했고, 이 6가지가 가장 일반적이고 포괄적이라는 것을 발견했다. 하지만 이것이 유일한 정답은 아니다. 사용 사례에 따라 다른 차원을 추가하거나 제거할 수 있다.

사용 사례별 차원 조정 예시:

고객 지원 챗봇 평가:
- Empathy (공감): 사용자의 감정을 이해하고 적절히 반응하는가?
- Actionability (실행 가능성): 구체적인 해결 방법을 제시하는가?
- Politeness (정중함): 예의 바른 표현을 사용하는가?
- Efficiency (효율성): 불필요한 정보 없이 핵심만 전달하는가?

창작 글쓰기 평가:
- Originality (독창성): 진부한 표현을 피하고 참신한가?
- Emotional Impact (감정적 영향력): 독자의 감정을 움직이는가?
- Narrative Flow (서사 흐름): 이야기가 자연스럽게 전개되는가?

기술 문서 평가:
- Completeness (완전성): 필요한 모든 정보를 포함하는가?
- Reproducibility (재현 가능성): 독자가 지시를 따라 할 수 있는가?
- Technical Accuracy (기술적 정확성): 전문 용어와 개념이 정확한가?

2.4 설계 원칙 3: 사고 과정 유도

“Begin your evaluation by providing a short explanation”

왜 점수만 달라고 하지 않고, 먼저 설명을 요구할까? 이것은 Chain-of-Thought (CoT) 프롬프팅 기법의 적용이다.

연구에 따르면, LLM이 결론을 내리기 전에 추론 과정을 먼저 표현하도록 하면 더 정확하고 일관된 결과를 낸다. 평가에서도 마찬가지다. 모델이 “이 답변은 8점이다”라고 바로 말하는 것보다, “이 답변은 정확한 정보를 제공하지만, 초보자가 이해하기에는 너무 전문적이다. 따라서…”처럼 이유를 먼저 설명하면, 더 신중한 평가가 나온다.

추가 이점:
- 감사 가능성(Auditability): 평가 이유를 추적할 수 있다
- 편향 감지: 설명을 보면 모델이 어떤 요소에 편향되었는지 알 수 있다
- 개선 가능성: 평가 논리를 이해하면 프롬프트를 개선할 방향을 알 수 있다

2.5 설계 원칙 4: 엄격한 출력 형식

“you must rate the response on a scale of 1 to 10 by strictly following this format”

“strictly following this format”이라는 표현에 주목하자. 왜 이렇게 강조할까?

LLM은 때때로 지시를 “유연하게” 해석한다. “1-10으로 평가하라”고 하면:
- “8-9점 정도입니다” (범위로 답함)
- “8.5점” (소수점 사용)
- “8점입니다만, 맥락에 따라 7점일 수도…” (모호한 답변)

이런 출력은 자동화된 파싱을 어렵게 만든다. 수백 개의 평가를 처리할 때, 각각을 수동으로 해석할 수 없다. 따라서 “엄격하게” 형식을 지킬 것을 요구한다.

실무에서는 더 나아가 출력 형식을 예시로 보여주는 것이 좋다:

You must provide your rating in exactly this format:
Rating: [[8]]

Do not include any text after the rating. Do not explain the rating again after providing the number.

대괄호 [[]]를 사용하는 것은 정규식(regex)으로 파싱하기 쉽게 만드는 패턴이다. 코드에서 \[\[(\d+)\]\] 같은 패턴으로 점수를 추출할 수 있다.

2.6 설계 원칙 5: 객관성 강조

“Be as objective as possible”

이것은 모델에게 개인적 선호나 스타일 편향을 최소화하라고 지시한다. 완벽한 객관성은 불가능하지만, 명시적으로 요구하면 모델이 더 중립적인 평가를 시도한다.

실험적으로, 이 문구가 없을 때와 있을 때를 비교하면:
- 없을 때: “저는 개인적으로 더 간결한 답변을 선호합니다”
- 있을 때: “답변의 길이는 적절하며, 필요한 정보를 모두 포함합니다”

3 Azure AI의 정교한 평가 템플릿

LMSYS의 기본 템플릿을 넘어, 실무에서 사용되는 더 정교한 템플릿을 살펴보자. PDF 슬라이드 13-14에 나온 Azure AI 스타일의 템플릿이다.

3.1 구조화된 XML 기반 템플릿

You're an evaluator for the prompts and answers provided by a generative AI model. 

Consider the input prompt in the <input> tags, 
the output answer in the <output> tags, 
the prompt evaluation criteria in the <prompt_criteria> tags, 
and the answer evaluation criteria in the <answer_criteria> tags.

<input>
{{input}}
</input>

<output>
{{output}}
</output>

<prompt_criteria>
- The prompt should be clear, direct, and detailed.
- The question, task, or goal should be well explained and be grammatically correct.
- The prompt is better if containing examples.
- The prompt is better if specifies a role or sets a context.
- The prompt is better if provides details about the format and tone of the expected answer.
</prompt_criteria>

<answer_criteria>
- The answers should be correct, well structured, and technically complete.
- The answers should not have any hallucinations, made up content, or toxic content.
- The answer should be grammatically correct.
- The answer should be fully aligned with the question or instruction in the prompt.
</answer_criteria>

이 템플릿은 여러 개선점을 포함한다.

3.2 개선점 1: XML 태그로 구조화

왜 XML 태그를 사용할까? 여러 이점이 있다:

명확한 경계: 어디까지가 입력이고, 어디까지가 출력인지 모호함이 없다. 특히 평가할 텍스트 자체에 따옴표나 특수 문자가 있을 때 유용하다.
파싱 용이성: 프로그래밍적으로 각 섹션을 추출하기 쉽다. BeautifulSoup이나 xml.etree 같은 라이브러리로 간단히 파싱할 수 있다.
확장 가능성: 새로운 정보를 추가하고 싶으면 새 태그를 추가하면 된다. 예를 들어 <context> 태그로 대화 이력을 추가하거나, <user_profile> 태그로 사용자 특성을 추가할 수 있다.
LLM 친화성: 최신 LLM들은 XML 구조를 잘 이해한다. 학습 데이터에 많은 XML 문서가 포함되어 있기 때문이다.

3.3 개선점 2: 프롬프트 자체도 평가

흥미롭게도 이 템플릿은 답변뿐만 아니라 프롬프트도 평가한다. 이것은 매우 실용적인 접근이다.

나쁜 답변의 원인은 두 가지다:
1. 모델의 능력 부족
2. 프롬프트가 불명확하거나 불완전함

만약 프롬프트가 애매하다면, 모델이 좋은 답변을 내놓기 어렵다. 예를 들어:

나쁜 프롬프트: “파이썬 코드 짜줘”
→ 무엇을 하는 코드? 어떤 입출력? 어느 수준의 사용자?

좋은 프롬프트: “파이썬 초보자를 위해, CSV 파일을 읽어서 평균값을 계산하는 코드를 작성해줘. 주석을 포함하고, pandas 라이브러리를 사용해.”
→ 명확한 목표, 대상 사용자, 기술 스택, 출력 형식

프롬프트를 평가하면:
- 프롬프트 작성자에게 피드백을 줄 수 있다
- 프롬프트 자체를 개선하는 방향을 찾을 수 있다
- 답변의 품질 문제가 프롬프트 때문인지 모델 때문인지 구분할 수 있다

3.4 개선점 3: Hallucination에 대한 명시적 경고

“The answers should not have any hallucinations, made up content”

이것은 매우 중요한 기준이다. Hallucination(환각)은 생성형 AI의 가장 큰 위험 중 하나다. 모델이 그럴듯하게 들리지만 완전히 틀린 정보를 자신있게 말하는 현상.

예를 들어:
- 존재하지 않는 책이나 논문을 인용
- 잘못된 날짜나 통계를 제시
- 실제로는 없는 API 함수를 제안

평가 기준에 이를 명시하면, 판사 모델이 사실 확인에 더 주의를 기울인다. 물론 판사 모델도 완벽하지 않지만, 명시적으로 경고하면 더 신중해진다.

실무 팁: Hallucination 평가를 강화하려면 외부 지식 소스를 활용할 수 있다. 예를 들어:
- 검색 엔진으로 주요 사실을 확인
- 지식 베이스(knowledge base)와 대조
- 여러 모델의 답변을 교차 검증

3.5 개선점 4: JSON 구조화된 출력 요구

Respond only with a JSON having:
- An 'answer-score' key with the score number you evaluated the answer with.
- A 'prompt-score' key with the score number you evaluated the prompt with.
- A 'justification' key with a justification for the two evaluations you provided 
  to the answer and the prompt; make sure to explicitly include any errors or 
  hallucinations in this part.
- An 'input' key with the content of the <input> tags.
- An 'output' key with the content of the <output> tags.
- A 'prompt-recommendations' key with recommendations for improving the prompt 
  based on the evaluations performed.

Skip any preamble or any other text apart from the JSON in your answer.

이것은 매우 실용적인 설계다. JSON 출력을 요구하는 이유:

자동화: 프로그래밍적으로 파싱하기 매우 쉽다. Python의 json.loads()로 한 줄이면 된다.
구조 보장: 필요한 모든 필드가 있는지 자동으로 확인할 수 있다. 필드가 빠지면 즉시 감지된다.
데이터베이스 저장: JSON은 대부분의 데이터베이스(MongoDB, PostgreSQL의 JSONB 등)에 직접 저장할 수 있다.
대시보드 연동: JSON 데이터를 시각화 도구로 바로 보낼 수 있다. Grafana, Tableau 등이 JSON을 네이티브로 지원한다.

“Skip any preamble”의 중요성:

LLM은 종종 친절하게(?) 부연 설명을 추가한다:

물론이죠! 평가 결과를 JSON 형식으로 제공하겠습니다:

{
  "answer-score": 8,
  ...
}

이상으로 평가를 마치겠습니다.

이런 추가 텍스트는 JSON 파싱을 방해한다. “오직 JSON만”을 출력하라고 명시하면 이 문제를 줄일 수 있다. 물론 100% 보장되지는 않으므로, 코드에서 JSON 추출 로직을 견고하게 작성해야 한다:

import re
import json

def extract_json(text):
    # 중괄호로 시작하는 첫 번째 JSON 객체 찾기
    match = re.search(r'\{.*\}', text, re.DOTALL)
    if match:
        try:
            return json.loads(match.group(0))
        except json.JSONDecodeError:
            return None
    return None

3.6 개선점 5: 실행 가능한 권장사항 요구

“A ‘prompt-recommendations’ key with recommendations for improving the prompt”

이것이 이 템플릿의 가장 강력한 부분이다. 단순히 점수를 매기는 것을 넘어, 어떻게 개선할 것인지를 제안한다.

예를 들어:

평가 결과:

{
  "prompt-score": 65,
  "answer-score": 70,
  "justification": "프롬프트가 너무 모호하여 모델이 명확한 답변을 제공하기 어려웠음. 
                   답변은 일부 유용한 정보를 포함하지만 불완전함.",
  "prompt-recommendations": [
    "대상 사용자의 기술 수준을 명시하세요 (예: 초보자, 중급자)",
    "구체적인 사용 사례나 맥락을 제공하세요",
    "원하는 출력 형식을 명확히 하세요 (예: 코드, 설명, 단계별 가이드)"
  ]
}

이런 권장사항은 프롬프트 엔지니어에게 즉시 실행 가능한 개선 방향을 제공한다. “점수가 낮다”는 것만 아는 것과, “이렇게 고치면 된다”를 아는 것은 큰 차이다.

4 HuggingFace의 실용적 간소화 버전

때로는 복잡한 것보다 단순한 것이 더 효과적이다. HuggingFace 커뮤니티에서 인기 있는 간소화된 템플릿을 보자 (슬라이드 15).

JUDGE_PROMPT = """
You will be given a user_question and system_answer couple. 
Your task is to provide a 'total rating' scoring how well the system_answer 
answers the user concerns expressed in the user_question.

Give your answer as a float on a scale of 0 to 10, where 0 means that the 
system_answer is not helpful at all, and 10 means that the answer completely 
and helpfully addresses the question.

Provide your feedback as follows:

Feedback::: 
Total rating: (your rating, as a float between 0 and 10)

Now here are the question and answer.

Question: {question}
Answer: {answer}

Feedback:::
Total rating:
"""

4.1 단순함의 장점

이 템플릿은 Azure 버전보다 훨씬 짧고 간단하다. 장점:

빠른 실행: 토큰 수가 적어서 API 호출이 더 빠르고 저렴하다
이해 용이성: 팀원 누구나 쉽게 이해하고 수정할 수 있다
적용 장벽 낮음: 복잡한 설정 없이 바로 사용할 수 있다

4.2 언제 단순한 버전을 쓸까?

단순 버전이 적합한 경우:
- 빠른 프로토타이핑 단계
- 큰 규모의 평가 (수만 건 이상, 비용이 중요)
- 일반적인 품질 체크 (세부 진단보다는 전반적 수준 파악)
- 실시간 평가가 필요한 경우

복잡한 버전이 필요한 경우:
- 상세한 진단이 필요할 때
- 프롬프트 개선 방향을 찾을 때
- 다차원 평가가 필요할 때
- 감사(audit) 목적으로 평가 근거를 남겨야 할 때

4.3 0-10 점수 체계의 의미

왜 1-10이 아니라 0-10일까? 그리고 왜 float(소수점)을 허용할까?

0을 포함하는 이유:
완전히 쓸모없는 답변을 표현하기 위해. 예를 들어, 질문과 완전히 무관한 답변, 또는 유해한 내용. 1점은 “매우 나쁘지만 뭔가 시도는 했다”를 의미하고, 0점은 “아예 실패”를 의미한다.

소수점을 허용하는 이유:
미묘한 차이를 표현하기 위해. 7점과 8점 사이의 답변이 많다. 7.5점으로 표현할 수 있으면 더 세밀한 비교가 가능하다.

하지만 실무에서는 논쟁의 여지가 있다:
- 찬성: 더 정밀한 평가 가능
- 반대: 가짜 정밀도(false precision). 7.3과 7.5의 차이가 실제로 의미 있는가?

경험적으로, 대규모 평가에서는 소수점을 사용하고 나중에 반올림하는 것이 좋다. 개별 평가의 소수점은 의미 없지만, 수백 개의 평균을 내면 의미있는 차이가 나타난다.

5 평가 템플릿 설계의 핵심 원칙

지금까지 세 가지 템플릿을 살펴봤다. 이제 좋은 평가 템플릿을 설계하는 일반 원칙을 정리해보자.

5.1 원칙 1: 명확한 역할과 목표

항상 판사의 역할을 명확히 하라. 그리고 평가의 목표가 무엇인지 명시하라.

나쁜 예:
“이 답변을 평가하세요”

좋은 예:
“당신은 기술 문서의 품질을 평가하는 시니어 테크니컬 라이터입니다. 이 답변이 초보 개발자에게 얼마나 유용한지 평가하세요.”

5.2 원칙 2: 구체적이고 측정 가능한 기준

추상적인 기준은 피하라. 측정 가능한 기준을 제시하라.

나쁜 예:
“답변이 좋은지 평가하세요”

좋은 예:
“다음 기준으로 평가하세요:
- 정확성: 사실적 오류가 있는가?
- 완성도: 질문의 모든 부분에 답했는가?
- 명확성: 전문 용어를 적절히 설명했는가?”

5.3 원칙 3: 사고 과정 유도

항상 추론 과정을 먼저 요구하라. 점수만 달라고 하지 말라.

먼저 각 기준에 대해 평가하고 그 이유를 설명하세요.
그런 다음 전체 점수를 제시하세요.

5.4 원칙 4: 엄격한 출력 형식

자동화를 위해 출력 형식을 엄격하게 지정하라. 예시를 제공하라.

다음 형식을 정확히 따르세요:

Accuracy: 8/10
Clarity: 7/10
Overall: 7.5/10

형식을 변경하지 마세요.

5.5 원칙 5: 편향 완화 기법 포함

알려진 편향을 완화하는 지시를 포함하라.

- 답변의 길이가 품질을 보장하지 않습니다. 짧아도 완벽할 수 있습니다.
- 첫 번째 답변과 두 번째 답변을 공정하게 대하세요. 순서가 판단에 영향을 주어서는 안 됩니다.
- 기술 용어가 많다고 해서 더 정확한 것은 아닙니다.

5.6 원칙 6: 맥락 정보 제공

필요한 맥락을 충분히 제공하라.

<context>
사용자 수준: 프로그래밍 초보자 (6개월 경험)
사용 목적: 개인 프로젝트를 위한 학습
환경: Python 3.9, 기본 라이브러리만 사용 가능
</context>

6 실무 적용: 평가 파이프라인 구축

템플릿을 만들었다면, 이제 실제로 어떻게 사용하는지 보자.

6.1 기본 파이프라인

import openai
import json

def evaluate_response(question, answer, judge_model="gpt-4"):
    """
    LLM-as-a-Judge를 사용하여 답변을 평가한다.
    """
    eval_prompt = f"""
    당신은 공정한 AI 응답 평가자입니다.
    
    질문: {question}
    답변: {answer}
    
    다음 기준으로 평가하세요:
    1. 정확성 (0-10)
    2. 명확성 (0-10)
    3. 유용성 (0-10)
    
    JSON 형식으로 응답하세요:
    {{
      "accuracy": <점수>,
      "clarity": <점수>,
      "helpfulness": <점수>,
      "justification": "<이유>"
    }}
    """
    
    response = openai.ChatCompletion.create(
        model=judge_model,
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0  # 일관성을 위해 0으로 설정
    )
    
    # JSON 추출
    result = extract_json(response.choices[0].message.content)
    return result

def extract_json(text):
    """텍스트에서 JSON 추출"""
    import re
    match = re.search(r'\{.*\}', text, re.DOTALL)
    if match:
        return json.loads(match.group(0))
    return None

6.2 배치 평가

실무에서는 수십, 수백 개의 응답을 한 번에 평가해야 한다.

import pandas as pd
from tqdm import tqdm

def batch_evaluate(test_cases, judge_model="gpt-4"):
    """
    여러 테스트 케이스를 배치로 평가한다.
    
    test_cases: [{"question": ..., "answer": ...}, ...]
    """
    results = []
    
    for case in tqdm(test_cases):
        try:
            eval_result = evaluate_response(
                case["question"], 
                case["answer"],
                judge_model
            )
            results.append({
                **case,
                **eval_result
            })
        except Exception as e:
            print(f"Error evaluating case: {e}")
            results.append({
                **case,
                "error": str(e)
            })
    
    return pd.DataFrame(results)

# 사용 예시
test_cases = [
    {
        "question": "파이썬에서 리스트를 정렬하는 방법은?",
        "answer": "sorted() 함수를 사용하면 됩니다..."
    },
    # ... 더 많은 케이스
]

results_df = batch_evaluate(test_cases)

# 결과 분석
print(results_df[['accuracy', 'clarity', 'helpfulness']].describe())

6.3 위치 편향 완화: 순서 무작위화

위에서 언급했듯이, LLM 판사는 위치 편향을 보일 수 있다. 이를 완화하는 방법:

import random

def evaluate_with_position_debiasing(question, answer_a, answer_b):
    """
    두 답변을 비교하되, 순서를 바꿔가며 여러 번 평가한다.
    """
    results = []
    
    # 순서를 바꿔가며 3번 평가
    for _ in range(3):
        # 랜덤하게 순서 결정
        if random.random() < 0.5:
            first, second = answer_a, answer_b
            is_swapped = False
        else:
            first, second = answer_b, answer_a
            is_swapped = True
        
        eval_result = compare_answers(question, first, second)
        
        # 순서를 바꿨다면 결과도 뒤집기
        if is_swapped:
            if eval_result["winner"] == "A":
                eval_result["winner"] = "B"
            elif eval_result["winner"] == "B":
                eval_result["winner"] = "A"
        
        results.append(eval_result)
    
    # 다수결로 최종 결정
    winners = [r["winner"] for r in results]
    final_winner = max(set(winners), key=winners.count)
    
    return {
        "winner": final_winner,
        "confidence": winners.count(final_winner) / len(winners),
        "individual_results": results
    }

6.4 다중 판사 활용: 앙상블 평가

하나의 판사 모델에만 의존하지 말고, 여러 모델의 평가를 종합할 수 있다.

def ensemble_evaluate(question, answer, judges=["gpt-4", "claude-3-opus", "gemini-pro"]):
    """
    여러 판사 모델의 평가를 종합한다.
    """
    evaluations = []
    
    for judge in judges:
        try:
            result = evaluate_response(question, answer, judge_model=judge)
            result["judge"] = judge
            evaluations.append(result)
        except Exception as e:
            print(f"Error with {judge}: {e}")
    
    # 평균 점수 계산
    avg_scores = {
        "accuracy": sum(e["accuracy"] for e in evaluations) / len(evaluations),
        "clarity": sum(e["clarity"] for e in evaluations) / len(evaluations),
        "helpfulness": sum(e["helpfulness"] for e in evaluations) / len(evaluations),
    }
    
    # 판사들 간 일치도 (표준편차)
    import numpy as np
    agreement = {
        "accuracy_std": np.std([e["accuracy"] for e in evaluations]),
        "clarity_std": np.std([e["clarity"] for e in evaluations]),
        "helpfulness_std": np.std([e["helpfulness"] for e in evaluations]),
    }
    
    return {
        "average_scores": avg_scores,
        "agreement": agreement,
        "individual_evaluations": evaluations
    }

표준편차가 낮다면 (예: < 1.0), 판사들이 대체로 동의한다는 의미다. 높다면 (예: > 2.0), 답변이 평가하기 애매하거나 판사들 간 관점 차이가 크다는 신호다.

7 해결되지 않은 과제들

PDF 슬라이드 16에서 연구팀이 명시한 “Unanswered Questions”를 다시 보자. 이것들은 여전히 활발한 연구 주제다.

7.1 과제 1: Alignment with Human Grading

문제: 특정 도메인(예: 문서 Q&A 챗봇)에서 LLM 판사와 인간 평가자의 일치도가 충분한가?

일반적인 태스크에서는 80% 이상의 일치도가 보고되지만, 매우 전문적인 영역에서는?
- 의료 진단 보조
- 법률 문서 해석
- 고급 수학 증명

이런 영역에서는 LLM 판사가 평가할 능력이 있는지 의문이다. 판사 자신이 해당 영역을 제대로 이해하지 못하면, 평가도 신뢰할 수 없다.

현재 접근법:
- 도메인 전문가의 평가 샘플을 수집하여 LLM 판사 결과와 비교
- 일치도가 낮으면 (< 70%), 평가 기준을 더 구체화하거나 판사 프롬프트에 도메인 지식 추가
- 극단적인 경우, LLM 판사를 보조 도구로만 사용하고 최종 결정은 인간이

7.2 과제 2: Accuracy Through Examples

문제: 평가 프롬프트에 예시를 포함하면 정확도가 향상되는가?

Few-shot 프롬프팅이 생성 태스크에서 효과적이듯, 평가에서도 효과적일까?

다음은 좋은 평가의 예시입니다:

질문: "파이썬에서 파일을 읽는 방법은?"
답변: "open() 함수를 사용하세요"
평가: 3/10 - 정확하지만 너무 간략함. 예시 코드와 오류 처리가 필요함.

이제 다음을 평가하세요:
...

현재 증거:
- 혼재된 결과. 일부 연구에서는 개선을, 일부는 효과 없음을 보고
- 예시가 “anchor”로 작용하여 오히려 편향을 일으킬 수 있음
- 예시 선택이 중요: 대표성 있고 다양한 예시를 선별해야 함

7.3 과제 3: Appropriate Grade Scales

문제: 0-100 척도 vs 0-1 이진 척도 vs 1-10 척도. 어느 것이 가장 적합한가?

Azure 프레임워크: 0-100 척도 사용
- 장점: 세밀한 구분 가능
- 단점: 가짜 정밀도. 73점과 76점이 실제로 의미 있게 다른가?

LangChain: 이진 척도 (0 = 나쁨, 1 = 좋음)
- 장점: 명확한 결정. 애매함 없음
- 단점: 미묘한 차이를 포착 못함

LMSYS: 1-10 척도
- 장점: 익숙함 (학교 성적과 유사). 적당한 세분성
- 단점: 중간 지점 편향 (대부분 5-7점에 몰림)

실무 권장사항:
사용 사례에 따라 선택하되, 일관성을 유지하라. 한 프로젝트 내에서 척도를 자주 바꾸면 혼란스럽다.

7.4 과제 4: Applicability Across Use Cases

문제: 하나의 평가 프레임워크를 여러 사용 사례에 재사용할 수 있는가?

예를 들어, 고객 지원 챗봇을 평가하는 기준을 코드 생성 평가에 그대로 쓸 수 있는가? 당연히 아니다.

하지만 매번 처음부터 새로 만들 수도 없다. 재사용 가능한 “템플릿”이 필요하다.

현재 접근법:
- 코어 기준 + 도메인 특화 기준 구조
- 코어: 정확성, 명확성, 완성도 (거의 모든 태스크에 적용 가능)
- 도메인 특화: Empathy (고객 지원), Code Quality (코딩), Creativity (글쓰기)

# 기본 템플릿
CORE_CRITERIA = """
- Accuracy: 사실적으로 정확한가?
- Clarity: 이해하기 쉬운가?
- Completeness: 필요한 정보를 모두 포함하는가?
"""

# 도메인별 추가
CUSTOMER_SUPPORT_CRITERIA = CORE_CRITERIA + """
- Empathy: 사용자의 감정을 이해하고 공감하는가?
- Actionability: 구체적인 해결 방법을 제시하는가?
"""

CODE_GENERATION_CRITERIA = CORE_CRITERIA + """
- Executability: 코드가 실제로 실행되는가?
- Best Practices: 코딩 컨벤션을 따르는가?
"""

평가 템플릿은 한 번 만들고 끝이 아니다. 지속적으로 검증하고, 개선하고, 사용 사례에 맞게 조정해야 한다. 다음 파트에서는 질적 평가와 양적 평가를 통합하는 방법론을 살펴본다.