grep

AI/ML

LLM as a Judge를 활용한 CodeBuddy 성능 평가

benedict.lee, diana.jung카카오

2025년 3월 7일

원문에서 보기 ↗

들어가며

최근 AI 모델의 성능을 비롯해 다양한 유형의 콘텐츠나 응답을 평가하는 방법으로 LLM as a Judge 접근법이 활발히 논의되고 있습니다. 카카오의 AI 코드 리뷰 서비스인 CodeBuddy 역시 이 방식을 활용해 사용 중인 LLM의 성능을 평가했습니다.

LLM as a Judge를 적용함으로써, 규모가 크고 복잡한 PR 기반 코드 리뷰 태스크의 성능 평가를 수행할 수 있었으며, 평가 과정에서 사람의 개입 없이 다양한 모델과 복잡한 태스크를 신속하고 일관되게 평가할 수 있다는 점을 확인했습니다. 하지만 여러 차례 모델 튜닝과 성능 평가를 진행하는 과정에서 LLM as a Judge 활용 시 고려해야 할 점, 편향(Bias) 등의 한계도 발견되었습니다.

이번 글에서는 LLM as a Judge의 개념과 실제 활용 경험을 공유하고자 합니다.

LLM as a Judge

LLM as a Judge는 LLM을 활용해 응답의 정확성, 일관성, 창의성 등 다양한 측면을 평가하는 방법입니다. 이 방식의 가장 큰 장점은 사람의 개입 없이 자동 평가가 가능하다는 점이며, 주관성을 최소화하면서 일관된 평가 기준을 유지할 수 있다는 점입니다.

뛰어난 성능의 최신 LLM을 평가자로 활용하면 인간의 선호도와 유사한 수준의 결과를 얻을 수 있어, 확장 가능하고 설명 가능한 평가 방식으로 주목받고 있습니다. 물론 Chatbot Arena와 같은 인간 평가 방식이 더 정확할 수 있지만, 사람을 동원한 평가는 시간과 비용이 많이 들고 확장성이 제한된다는 단점이 있습니다. 또한, 단순한 질의응답(Q&A) 수준이 아닌 복잡한 태스크의 경우, 사람이 직접 평가하는 것이 쉽지 않습니다.

CodeBuddy는 GitHub PR(Pull Request) 기반의 코드 리뷰 태스크를 평가하는 과정에서 LLM as a Judge 방식을 적극적으로 활용했습니다. PR의 프롬프트 크기는 수천~수만 토큰에 달하며, 핵심 컨텍스트도 코드 패치(diff) 형태로 제공되기 때문에 사람이 일일이 확인하며 평가하는 것은 매우 어려운 작업입니다. 게다가 PR의 개발 언어나 도메인에 대한 전문성이 부족한 경우, 평가의 정확도가 떨어질 가능성이 큽니다.

이러한 한계를 극복하기 위해 CodeBuddy는 LLM을 활용하여 코드 리뷰 태스크의 성능을 평가했고, 이를 통해 복잡한 코드 변경 사항을 보다 효율적으로 분석하고 비교할 수 있었습니다.

LLM as a Judge 유형

LLM을 평가자로 활용할 때 자주 사용되는 접근 방식으로 Pointwise, Pairwise, Listwise 세 가지가 있습니다.

Pointwise

개별 응답이나 텍스트를 독립적으로 평가하는 방식입니다. 각 응답을 개별적으로 검토하기 때문에 평가 기준을 명확하게 설정할 수 있으며, 특정 품질 요소(예: 정확성, 완성도 등)를 정밀하게 측정하는 데 유용합니다.

예시 1: 단순 선택

평가 질문 : “이 응답이 질문에 대해 정확한 정보를 제공하는가?”

선택지 : 예 (True), 아니오 (False)

예시 2: 점수 부여

평가 질문 : “다음 응답의 정확성을 평가해 주세요.”

평가 기준:

Pairwise

두 개의 후보 응답을 동시에 비교하여 어느 쪽이 더 우수한지 평가하는 방식입니다. 상대적인 우열을 판단하는 데 효과적이며, 다수의 비교를 거치면서 통계적 신뢰도를 높일 수 있습니다.

예시

평가 질문:

“다음 두 응답 중 질문에 대해 더 적절한 정보를 제공하는 것은 무엇인가요? 품질이 비슷하다면 동점을 선택하세요.”

선택지:

Listwise

여러 후보 응답을 동시에 제시하고, 전체 순위를 매기거나 점수를 부여하는 방식입니다. 평가자가 여러 응답을 한 번에 검토할 수 있어, 전반적인 품질 비교와 순위 결정이 용이합니다.

예시 1: Listwise 최우수 응답 선택

평가 질문: “다음 응답 중 가장 우수한 것을 선택하고, 그 이유를 설명해 주세요.”

선택:

예시 2: Listwise 점수 부여 및 순위 정렬

평가 질문: “각 응답의 전반적인 품질을 평가하고, 가장 우수한 순서대로 정렬해 주세요.”

평가 결과:

이러한 세 가지 방식은 각각 장단점이 있으며, 평가 목적과 상황에 맞게 적절히 활용될 수 있습니다.

LLM as a Judge 평가 방법

앞서 소개한 평가 유형에 따라 단순 선택(True/False, Win/Loss/Tie, Best One), 점수 부여(Scoring), 순위 부여(Ordering) 등의 방식을 주로 사용합니다. 또한, 평가 목적에 따라 여러 방법을 혼합하여 활용할 수도 있습니다.

그뿐만 아니라, LLM 평가자가 평가 이유를 설명(Explanation)하도록 유도하는 프롬프트를 구성할 수도 있습니다. 평가 이유를 함께 제공하면, LLM이 선택한 답변이나 부여한 점수에 대한 근거를 명확하게 확인할 수 있어 평가의 투명성과 신뢰성을 높이는 데 도움이 됩니다. 이는 특히 중요한 의사 결정이 필요한 평가에서 더욱 유용하게 활용될 수 있습니다.

LLM as a Judge 제약사항

LLM as a Judge 방식은 인간의 개입 없이 신속하고 확장 가능하게 평가를 수행할 수 있다는 장점이 있지만, 몇 가지 한계점도 존재합니다. 그중 대표적인 문제는 편향(Bias)입니다.

Self(Self-enhancement) bias

자기(자기 강화) 편향은 LLM 평가에서 흔히 발생하는 편향 중 하나로, 모델이 자신(또는 패밀리 모델)이 생성한 응답을 더 선호하는 경향을 의미합니다.

예를 들어, Pairwise 평가에서 두 개의 후보 응답(GPT-4o, Claude 3.5 Sonnet)을 비교할 때, GPT-4o가 평가자 모델로 설정되면 자신의 응답을 더 높은 점수로 평가하는 경향이 나타날 수 있습니다. 이러한 현상을 방지하기 위해 평가 과정에서는 모델명을 익명 처리하지만, 실험 결과에 따르면 익명화된 상태에서도 자기 편향이 지속적으로 발생하는 것이 확인되었습니다.

아래 실험에서는 동일한 평가 프롬프트를 사용하여 GPT-4o와 Claude-3.5-Sonnet을 각각 평가자로 설정했을 때의 결과를 비교했습니다.

실험 1. GPT-4o(0513) vs. Qwen2-72B-Instruct 모델 평가 표

평가 태스크평가자 모델GPT-4o 승률Qwen2 승률무승부
설명 (Describe)GPT-4o91%9%-
설명 (Describe)Claude-3.5-Sonnet73%27%-
리뷰 (Review)GPT-4o62%35%3%
리뷰 (Review)Claude-3.5-Sonnet46%52%2%
개선 (Improve)GPT-4o80%20%-
개선 (Improve)Claude-3.5-Sonnet70%30%-

실험 2. GPT-4o(0513) vs. Qwen2-72B-Instruct-CodeBuddy-V1 모델 평가 표

평가 태스크평가자 모델GPT-4o 승률Qwen2 승률무승부
설명 (Describe)GPT-4o74%24%2%
설명 (Describe)Claude-3.5-Sonnet35%65%-
리뷰 (Review)GPT-4o59%22%19%
리뷰 (Review)Claude-3.5-Sonnet51%34%15%
개선 (Improve)GPT-4o86%14%-
개선 (Improve)Claude-3.5-Sonnet70%30%-

위 실험에서 알 수 있듯이, GPT-4o가 평가자로 설정된 경우 자신의 응답을 더 높은 비율로 선택하는 경향이 나타났습니다. 반면, Claude-3.5-Sonnet를 평가자 모델로 평가 시 보다 균형 잡힌 결과가 나타났습니다.

이러한 자기 편향은 LLM as a Judge의 공정성을 저해하는 요소 중 하나이며, 완전히 제거하기는 어렵습니다. 따라서 평가 결과를 해석할 때 모델의 편향을 고려하는 것이 중요하며, 이를 완화하기 위한 추가적인 연구와 개선이 필요합니다.

자기 편향을 완화하는 가장 간단한 방법은 후보 모델과 동일한 평가자 모델을 사용하지 않는 것입니다. 또한, 단일 평가자가 아닌 다수의 평가자 모델을 활용하고 여러 번 반복 평가하여 평균을 도출하면 자기 편향을 상당 부분 완화할 수 있습니다.

Verbosity(Length) bias

장황(길이) 편향은 더 짧은 응답이 정확하고 품질이 높더라도, 더 길고 장황한 응답을 선호하는 경우를 의미합니다. 그러나 최근 LLM의 성능이 크게 향상되면서, 단순히 길기만 한 응답은 비교적 잘 걸러지는 경향을 보입니다.

뿐만 아니라 CodeBuddy 평가과정에서 더 높은 품질의 긴 응답이더라도, 태스크의 지침에서 벗어나는 경우 오히려 낮은 점수를 받는 현상도 확인되었습니다. 즉, 응답의 길이가 무조건적인 품질 지표로 작용하는 것이 아니라, 태스크에서 요구하는 지침을 정확하게 준수하는지가 더욱 중요한 평가 요소로 반영되는것을 확인 할 수 있었습니다.

장황 편향은 평가 프롬프트를 통해 충분히 방어할 수 있는 편향 중 하나입니다. 평가 기준을 명확하게 설정하고, 장황 편향을 회피하도록 가이드를 제공하면 보다 균형 잡힌 평가가 가능합니다.

아래는 코드버디에서 장황 편향을 방어하기 위해 사용한 평가 프롬프트 예시입니다.

- 답변이 길다고 해서 반드시 높은 순위를 받을 필요는 없습니다. 더 간결하면서도 주어진 태스크를 더 잘 해결할 수 있다면 더 짧은 답변이 더 좋을 수 있습니다.

Position bias

위치 편향은 평가 시 후보 응답의 순서나 배치가 평가 결과에 영향을 미치는 현상을 의미합니다. 예를 들어, Pairwise 평가에서 동일한 응답이라도 프롬프트 내에서 제시되는 순서에 따라 평가 결과가 달라질 수 있는 현상을 의미합니다. 즉, 응답의 품질 자체뿐만 아니라 프롬프트 내 위치와 순서가 평가 결과에 영향을 미치는 문제입니다.

과거 LLM의 한계로 지적된 “Lost in the middle(중간 맥락 유실)” 현상도 이와 유사한 원인에서 비롯되었을 가능성이 있습니다.

위치 편향은 단순한 무작위 변동이 아니라, 평가자 모델과 태스크 유형에 따라 특정한 패턴으로 나타날 수 있습니다. 즉, 모델이 평가하는 태스크의 성격에 따라 위치 편향이 다르게 나타날 수 있으며, 높은 일관성을 보이는 모델조차도 특정 태스크에서는 편향을 보일 수 있습니다. 이는 곧 평가자 모델이 특정 태스크에 따라 편향된 의존성을 가질 수 있음을 시사합니다.

예를 들어, GPT-4는 일부 태스크에서는 최신성(Recency)을 선호하는 경향이 있는 반면, 다른 태스크에서는 초두성(Primacy)을 선호하는 경향을 보이기도 합니다. 또한, 위치 편향은 답변 품질 차이에 영향을 받으며, 응답 간 품질 차이가 클 경우 편향이 줄어들지만, 품질이 비슷한 경우 위치 편향이 더욱 두드러지는 경향이 있습니다. (참고 논문 2)

위치 편향을 줄이기 위해 다음과 같은 방법을 적용할 수 있습니다.

이러한 방법을 활용하면 위치 편향을 줄이고 보다 신뢰도 높은 평가 결과를 확보할 수 있습니다.

LLM as a Judge in CodeBuddy

CodeBuddy는 전반적인 모델 성능 평가 및 일부 태스크에서 응답 품질을 더 높이기 위한 목적으로 LLM as a Judge를 활용하고 있습니다.

CodeBuddy Model Evaluation

코드리뷰를 위한 전반적인 모델 성능을 평가할 때 Pairwise 방식을 사용하여 두 후보 모델의 응답을 비교합니다. 평가 과정에서는 다음과 같은 방식을 적용합니다.

  1. 두 응답 중 더 나은 결과를 선택 (Win/Loss/Tie)

  2. 선택 이유를 설명 (Explanation)

  3. 각 응답에 점수를 부여 (Scoring)

이러한 방식은 단순 비교뿐만 아니라 응답의 품질을 정량적으로 분석할 수 있도록 설계되었습니다.

평가 프롬프트 구성

CodeBuddy의 모델 성능 평가를 위한 프롬프트는 다음과 같은 요소로 구성됩니다.

  1. 역할 및 목표 지정

  2. 평가할 태스크 정의

    • 태스크의 System Message, User Message
    • 태스크별 지침, 컨텍스트(PR 및 관련 정보), 출력 포맷 정의, few-shot 예시 등
    • 작게는 수천에서 많게는 수만토큰 크기

  3. 평가할 두 후보 모델의 응답

    • 후보 모델의 태스크 응답결과: Response 1, Response 2
    • 모델명은 언급하지 않음

  4. 태스크 평가 가이드라인

  5. 출력 포맷 지정

  6. 출력 예시 제공

이러한 체계적인 평가 방식을 통해 CodeBuddy는 모델 성능을 보다 정확하고 일관되게 평가할 수 있도록 설계하고 있습니다.

평가 프롬프트 예시

당신은 PR-task-evaluator입니다. 길게 작성된 Pull Request(PR) 코드 차이에 대한 두 개의 응답을 비교하고 품질을 순위 매기는 언어 모델입니다. 
평가해야 할 작업은 다음과 같습니다:

***** Start of Task *****
{{pr_task}}
***** End of Task *****

Response 1 to the task is:
***** Start of Response 1 *****
{{pr_response1}}
***** End of Response 1 *****

Response 2 to the task is:
***** Start of Response 2 *****
{{pr_response2}}
***** End of Response 2 *****

응답 평가 가이드라인:
- Thoroughly read the 'Task' part. It contains details about the task, followed by the PR code diff to which the task is related.
- Thoroughly read 'Response1' and 'Response2' parts. 
- ...

그 다음으로, 각 답변을 순위를 매깁니다. 순위 매기기 기준은 다음과 같습니다::
- How well does the response follow the specific task instructions and requirements?
- ...
- Don't necessarily rank higher a response that is longer. A shorter response might be better if it is more concise, and still addresses the task better.

출력은 다음과 같은 Pydantic 정의에 따라 $PRRankResponses 타입과 동일한 YAML 객체이어야 합니다:
=====
class PRRankRespones(BaseModel):
   which_response_was_better: Literal[0, 1, 2] = Field(description="A number indicating which response was better. 0 means both responses are equally good.")
   why: ...
   ... 	
=====

출력 예시:
```yaml
which_response_was_better: "X"
why: "Response X is better because it is more practical, and addresses the task requirements better since ..."
score_response1: ...
score_response2: ...
\```

Response (should be a valid YAML, and nothing else):
\```yaml

평가 태스크 정의 방식에 따른 평가 결과 차이

CodeBuddy의 모델 평가 과정에서 편향 문제와는 별개로, 평가 프롬프트에서 태스크 정의 방식에 따라 평가 결과가 크게 달라지는 현상이 발견되었습니다. 특히, 태스크의 System Message와 User Message를 어떻게 구성하느냐에 따라 평가 모델의 판단 방식이 달라지는 경향이 나타났습니다.

CodeBuddy의 평가 프롬프트에서는 평가할 태스크를 다음과 같이 정의합니다.

***** Start of Task *****
{{pr_task}}
***** End of Task *****

여기서 pr_task에는 평가할 태스크의 System message와 User message가 포함되며, 이를 입력하는 방식에 따라 평가 결과가 달라질 수 있습니다.

1) System과 User Message를 명확히 구분한 경우

***** Start of Task *****

### System Message
{{pr_task_system}}

### User Message
{{pr_task_user}}

***** End of Task *****

이 방식은 System message와 User message를 명확하게 구분하여 평가 프롬프트를 구성하는 방식입니다. 평가 모델이 태스크의 평가 기준을 더욱 명확하게 인식하고, 그에 맞춰 정확하게 평가하는 경향을 보였습니다. 즉, 단순히 응답을 비교하는 것이 아니라, 주어진 평가 기준을 바탕으로 보다 정밀하게 판단하는 방향으로 작동하는 것을 확인할 수 있었습니다.

2) System과 User Message를 구분하지 않은 경우

***** Start of Task *****

{{pr_task_system}}

{{pr_task_user}}

***** End of Task *****

이 방식에서는 System message와 User message가 명확히 구분되지 않고 하나의 흐름으로 인식됩니다. 이로 인해 평가 모델이 태스크의 핵심 기준을 명확히 이해하지 못하고, 두 모델의 응답을 평가할 때 대부분 무승부로 평가되어 변별력이 떨어지는 경향이 나타났습니다.

실험 1. GPT-4o vs. Qwen2.5-Coder-32B-Instruct

평가 태스크System, User 영역 구분GPT-4o 승률Qwen2.5 승률무승부
설명 (Describe)✅ 구분80%20%-
설명 (Describe)❌ 미구분16%0%84%
리뷰 (Review)✅ 구분73%27%-
리뷰 (Review)❌ 미구분21%0%79%
개선 (Improve)✅ 구분73%27%-
개선 (Improve)❌ 미구분15%0%85%

실험 2. GPT-4o vs. Qwen2.5-Coder-32B-Instruct-CodeBuddy-V2

평가 항목System, User 영역 구분GPT-4o 승률Qwen2.5 승률무승부
설명 (Describe)✅ 구분60%40%-
설명 (Describe)❌ 미구분12%1%87%
리뷰 (Review)✅ 구분54%44%2%
리뷰 (Review)❌ 미구분15%0%85%
개선 (Improve)✅ 구분79%19%2%
개선 (Improve)❌ 미구분12%1%87%

실험 결과에 따르면, System, User message를 구분하지 않고 평가를 진행할 경우, 두 모델의 평가 결과가 80% 이상 동률로 나타나는 경우가 많았으며, 응답 간 차이를 효과적으로 반영하지 못하는 문제가 확인되었습니다. 이는 평가자 모델이 응답의 실제 품질보다는 표면적인 유사성에 영향을 받아 판단할 가능성이 높아지며, 결과적으로 평가의 신뢰도를 저하시킬 수 있음을 시사합니다.

이러한 실험 결과를 바탕으로, 평가 프롬프트 설계 시 태스크의 System message와 User message를 명확히 구분하는 것이 평가 기준을 보다 정확하게 전달하고, 응답 간 차이를 정교하게 평가하는 데 중요한 요소임을 확인할 수 있었습니다.

Code Suggestion Reflect

CodeBuddy에서는 코드 개선 태스크에도 LLM as a Judge를 활용하고 있습니다.

우선, LLM에게 PR 컨텍스트를 전달하여 개선이 필요한 부분을 분석한 후, 이에 대한 코드 제안 목록을 생성합니다. 하지만 생성된 코드 제안을 그대로 사용하는 것이 아니라, 한 번 더 재평가하는 과정을 거쳐 최종 응답에 포함할지를 결정합니다. 이 과정은 RAG에서 활용되는 Re-ranking과 유사하며, 평가된 코드 제안 중 최적의 응답을 선택하는 방식으로 진행됩니다.

이 과정에서는 제안된 코드 목록 전체를 한 번에 전달하는 Listwise 평가 방식을 적용하며, Scoring(점수 부여)과 Explanation(평가 이유 설명)을 혼합하여 평가를 수행합니다. 이를 통해 개별 코드 제안의 유효성을 보다 체계적으로 검토하고, 최적의 코드 제안을 선택할 수 있도록 합니다.

Position Bias in the Evaluation of CodeBuddy Model

최근 CodeBuddy-V2 모델을 훈련 및 평가하는 과정에서, 코드 개선 태스크의 성능이 이전보다 오히려 낮아지는 현상이 발견되었습니다. 이에 대한 원인을 분석하던 중, LLM as a Judge에서 발생할 수 있는 위치 편향의 영향 가능성을 확인하게 되었으며, 이를 검증하기 위해 간단한 실험을 진행했습니다.

평가 태스크 구성

CodeBuddy 모델 평가는 다음 세 가지 태스크로 구성됩니다.

평가자 모델

평가자 모델로는 자기 편향을 방지하기 위해 GPT-4o 모델은 제외했으며, 태스크 특성상 코딩 능력이 가장 우수한 것으로 알려진 Claude-3.5-Sonnet 모델을 사용했습니다.

평가 후보 모델

응답을 비교 평가하기 위해 다음 네 개의 후보 모델을 사용했습니다.

  1. GPT-4o(2024-11-20)

  2. Qwen2.5-Coder-32B-Instruct

  3. Qwen2.5-Coder-32B-Instruct-CodeBuddy-V2

  4. DeepSeek-R1-Distill-Qwen-32B

평가 방식

평가는 Pairwise 방식으로 진행되었으며, 각 태스크별로 아래와 같은 후보 모델 쌍을 비교했습니다. 각 비교에서 A. GPT-4o를 기준 모델로 설정하여 다른 후보 모델들의 응답과 비교 평가했습니다.

또한, 위치 편향의 영향을 확인하기 위해, 후보 모델 응답의 순서를 바꿔 동일한 방식으로 추가 평가를 진행했습니다.

이러한 방식으로 후보 모델 응답의 위치를 변경하여 수차례 반복해서 평가했으며, 평가 결과가 순서에 따라 변하는지 여부를 검증했습니다.

평가 결과

실험 결과, 위치 편향 현상이 실제로 발생하고 있음이 확인되었습니다. 특히, 세 쌍의 평가 후보 모델에서 모두 위치 편향이 발견되었으며, 개선 태스크에서 가장 두드러지게 나타났습니다.

실험 1: 위치 편향 분석 (후보 모델 A vs. 후보 모델 B)

평가 태스크A 먼저 배치 A vs. BB 먼저 배치 B vs. A위치 변경에 따른 승률 차이
설명 (Describe)80% vs 20%18% vs 82%2%
리뷰 (Review)73% vs 27%24% vs 76%3%
개선 (Improve)73% vs 27%45% vs 55%18%

실험 2: 위치 편향 분석 (후보 모델 A vs. 후보 모델 C)

평가 태스크A 먼저 배치 A vs. CC 먼저 배치 C vs. A위치 변경에 따른 승률 차이
설명 (Describe)60% vs 40%40% vs 60%변화 없음
리뷰 (Review)54% vs 44% (무승부 2%)49% vs 50% (무승부 1%)5%
개선 (Improve)79% vs 19% (무승부 2%)47% vs 51% (무승부 2%)28%

실험 3: 위치 편향 분석 (후보 모델 A vs. 후보 모델 D)

평가 태스크A 먼저 배치 A vs. DD 먼저 배치 D vs. A위치 변경에 따른 승률 차이
설명 (Describe)96% vs 4%20% vs 80%16%
리뷰 (Review)93% vs 7%13% vs 87%6%
개선 (Improve)62% vs 38%59% vs 41%21%

설명 및 리뷰 태스크에서는 위치 편향의 영향이 미미했지만, 개선 태스크에서 최대 28% 차이가 발생하여 위치 편향의 영향을 크게 받는 것으로 나타났습니다.

이는 개선 태스크에서 후보 모델의 응답 품질 격차가 크지 않고, 평가자 모델이 판단하기 어려운 경우가 많았기 때문으로 해석할 수 있습니다. 또한 Claude-3.5-Sonnet 모델은 설명, 리뷰 태스크보다 개선 태스크에서 위치 편향에 더 많은 영향을 받는 것으로도 해석할 수 있습니다.

보다 정확한 검증을 위해서는 더 정교한 실험 설계와 반복 실험이 필요하지만, 간단한 실험만으로도 뚜렷한 위치 편향 현상이 존재한다는 사실을 확인할 수 있었습니다.

결론

LLM as a Judge 기법을 활용하면 LLM을 평가자로 설정하여 태스크의 성능을 효율적이고 자동화된 방식으로 평가할 수 있습니다. 특히, 사람이 직접 평가하기 어려운 길고 복잡한 태스크를 다룰 때는 필수적인 방법이기도 합니다. 그러나 자기 편향, 장황 편향, 위치 편향 등으로 인해 평가 결과의 신뢰성이 저하될 가능성이 있습니다.

LLM 평가자의 신뢰성을 높이기 위해서는 이러한 편향을 최대한 완화하는 접근이 필요합니다. 이를 위해, 다양한 평가자 모델을 활용한 평가, 반복적인 평가를 통한 평균화, 평가 프롬프트 구성 방식의 개선 등을 고려해야 합니다. CodeBuddy 모델 및 태스크 성능평가를 통해 이러한 전략이 평가 결과의 신뢰도를 높이는 데 효과적임을 확인할 수 있었습니다

LLM 평가자의 편향 문제와 관련된 보다 자세한 실험 및 연구 결과는 아래 논문들을 참고하면 더욱 구체적인 내용을 확인할 수 있습니다.

참고 논문

  1. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

  2. Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge

  3. Pride and Prejudice: LLM Amplifies Self-Bias in Self-Refinement

  4. Systematic Evaluation of LLM-as-a-Judge in LLM Alignment Tasks: Explainable Metrics and Diverse Prompt Templates

  5. Large Language Models are Effective Text Rankers with Pairwise Ranking Prompting

관련 자료