이 글은 1부: 데이터도 정답도 없다에서 이어집니다. 1부에서는 Tinder의 AI-enabled Discovery 기능에서, “당신은 왜 이 사람과 잘 맞을까요?”라는 질문에 답하는 설명을 만들기 위한 정책 수립 과정을 다뤘습니다. 이번 글에서는 그 정책을 실제 평가 시스템으로 바꾸는 방법을 다룹니다.

들어가며

지난 글에서 Tinder와 MGAI 팀이 합작한 Tinder AI-enabled Discovery 서비스의 “소개팅 주선자” 모듈을 소개했습니다. 즉 LLM을 활용해 “당신은 이래서 이 사람과 잘 맞습니다”를 설득하는 문장을 만들어내는 모듈이죠. 예를 들어 자전거와 술을 좋아하는 유저 A를 따릉이를 좋아하는 B 유저에게 소개할 때 “A는 자전거를 좋아해요!”라고 소개합니다. 위스키를 좋아하는 C 유저에게 소개할 때는 “A는 술을 즐겨요”라고 소개하고요.

이런 LLM 모델을 만들기 위해선 엄밀한 “설명 정책”이 필요합니다. 정책에는 제품적 의사결정 (어느 상황에서 어떤 설명이 좋은지), 그리고 기술적 의사결정 (LLM이 잘 이해할 수 있는지)을 잘 녹여내야 합니다. 두 조건을 모두 만족하는 정책을 만드려면 반복 평가 과정을 통해 다듬어야 하고, PM과 MLE의 끈끈한 협력 과정이 필요함을 지난 1부에서 설명 드렸습니다.

이런 깔끔한 설명 정책을 확보하면, 사람은 LLM이 생성한 설명의 pass/fail 여부를 충분히 일관되게 판단할 수 있습니다. 정책만 제대로 익혔다면, 전문 평가자로서 모델의 성능을 일관된 기준으로 평가하는 능력을 얻는 것입니다. 그리고 일관된 평가를 바탕으로 모델의 성능을 정량화 하고, 모델 배포를 결정할 수 있습니다.

그러나 모델은 한번 배포되고 끝이 아닙니다. 배포된 모델이 잘 동작하는지 지속적으로 모니터링 해야 합니다. 또한 문제가 발견되면 모델을 재학습하고, 배포할만한 수준인지 평가해야 합니다. 그때마다 전문 평가자가 나설 순 없습니다. 왜냐하면 전문가의 시간은 큰 비용입니다. 또한 전문가도 사람인지라 실수할 가능성이 있습니다. 그래서 결국 평가가 모델 개선 사이클의 병목이 됩니다.

1

하지만 안심하십시오. 다행히도 우리는 LLM의 시대에 살고 있습니다. 올바른 정책이 세워져 있다면 품질을 일관되게 평가할 수 있는 자동화된 평가자, 즉 LLM-as-a-Judge를 만들 수 있습니다. LLM Judge는 인간 전문가를 대신해 수 만 건의 설명 문장을 빠르고 정확하게 평가할 수 있습니다. 다만 인간 전문가와 LLM Judge 간의 높은 평가 일치율을 만들기는 쉽지 않습니다. 단순히 LLM Judge Prompt에 설명 정책을 넣는다고 LLM Judge가 인간 전문가 수준의 안정된 평가를 보여주지 않기 때문입니다.

여러분이 직접 LLM Judge를 만든다면 어떤 방식으로 만드실 건가요? 만든 Judge는 어떻게 평가하면 좋을까요? 그리고 LLM Judge는 자동화된 평가를 넘어서서 어디에 활용될 수 있을까요? 이 글에서는 하이퍼커넥트 MGAI팀이 LLM Judge를 잘 만들고 사용하는 과정에서 얻은 꿀팁을 소개합니다. 1부에서와 마찬가지로 여러 예시와 함께 프롬프트를 개선하는 과정을 소개합니다. 이 팁들을 여러분의 프로젝트에 적용한다면, 낮은 가격으로, 빠른 시간 안에, 인간 평가자와 높은 일치율을 보이는 LLM Judge를 만드실 수 있습니다. 여러분의 LLM Product는 LLM Judge의 도움으로 빠르게 개선될 것입니다.

LLM-as-a-Judge

LLM-as-a-Judge란, LLM이 평가자가 되어 생성 결과의 품질을 자동으로 평가하는 시스템입니다. 단순히 점수만 예측하는 것이 아니라, 사람처럼 이유를 들고 판단을 내리도록 하여 LLM의 강력한 추론 능력을 최대한 활용할 수 있습니다. 사람이 직접 설명의 품질을 매번 평가하려면 많은 시간과 비용이 들지만, LLM-as-a-Judge를 활용하면 평가를 자동화할 수 있어 빠르고 효율적인 반복 실험이 가능합니다.

LLM Judge를 만들기 위해서 먼저 문헌조사를 진행했습니다. 문헌 조사1를 통해 LLM-as-a-Judge의 rule of thumb 뿐만 아니라, LLM Judge가 가질 수 있는 bias, Judge 자체를 평가하는 방법 등을 파악하였습니다. 가장 기본적으로 LLM Judge 구현을 위해서는 평가 방식, 평가 척도, 평가 기준이라는 세 가지 핵심 요소를 정해야 합니다.

평가 방식에는 두 가지가 존재합니다. 하나는 Pointwise evaluation으로, 각 후보를 독립적으로 평가하여 절대적인 점수나 이분법적인 평가(pass/fail)를 내리는 방식입니다. 다른 하나는 Pairwise evaluation으로, 두 후보를 상대적으로 비교하여 어느 쪽이 더 우수한지 판단하는 방식입니다. 예를 들어, A 모델과 B 모델을 비교할 때, Pointwise 평가 방식은 각각의 모델이 생성한 출력물에 대해 독립적인 평가를 진행하고 그 결과의 평균 점수를 비교하여 모델의 성능을 판단합니다. 반면, Pairwise 평가 방식은 동일한 입력에 대해 두 모델의 출력을 직접 비교하여, 어떤 모델이 더 나은 출력을 생성했는지를 Win rate와 같은 방식으로 평가합니다.

평가 척도에는 Pass/Fail로 평가하는 Binary evaluation, 단계적 점수를 부여하는 Likert scoring(1~5, 1~10 등), 그리고 연속적인 Real-valued scoring(0.0~1.0 등)의 방식이 있습니다. 예를 들어, Binary 방식은 간단히 “합격(pass) 또는 불합격(fail)”으로 평가하며, Likert scoring 방식은 사용자가 제공한 설명의 품질을 “매우 나쁨(1점)부터 매우 좋음(5점 또는 10점)”까지 단계적으로 평가하는 방식입니다.

평가 기준에는, 단일 기준(Single-aspect)을 중심으로 한 평가, 그리고 여러가지 기준(Multi-criteria)을 동시에 고려한 평가가 존재합니다. 예를 들어, Multi-criteria 방식은 “정보 정확성”, “문장 자연스러움”, “정책 적합성” 등 여러 측면을 동시에 평가하는 반면, Single-aspect 방식은 오로지 “정책 적합성”과 같은 한 가지 기준만을 평가합니다.

2

우리는 이제 설명 모듈의 LLM Judge를 만들어야 합니다. 우리 상황에선 세 가지 옵션에 대해 어떤 선택을 하면 좋을까요?

우선 Pointwise 평가 방식이 더 적합하다고 판단했습니다. 왜냐하면 우리는 단일 모델을 반복적으로 개선하는 과정을 거치고 있기 때문입니다. 이 경우, 각 버전의 절대적인 성능 수준을 개별적으로 평가하는 것이 모델 개선의 효과를 정량적으로 확인하는 데 더 유리합니다. 특히, 제한된 인프라 환경에서 소형 모델을 사용하는 경우, 매 버전이 항상 더 우수한 출력을 내지 않을 수 있으므로, 상대적인 비교보다는 Pointwise 평가를 통해 각 모델의 성능이 실제로 일정 수준을 충족하는지를 명확히 판단할 수 있다는 장점이 있습니다.

또한 우리는 평가 척도로 Binary evaluation를 선택했습니다. 앞서 1부에서 다룬 것처럼, 평가 기준을 이분법적으로 단순화하면 평가자의 인지적 부담을 줄일 수 있으며, 이 점은 인간 평가자뿐 아니라 LLM에도 동일하게 적용됩니다. 실제로 Huang et al., 2024은 LLM이 세밀한 Likert 척도보다 Binary 평가에서 인간 평가자와 훨씬 더 높은 일치율을 보인다고 보고했습니다.

마지막으로, 평가 기준 측면에서는 단일 기준 평가 방식을 선택했습니다. 여러 기준(Multi-aspect)을 동시에 사용할 경우, 기준 간 우선순위를 정하기 어렵고 평가 결과 해석이 복잡해질 수 있습니다. 예를 들어, 새로운 모델이 정보 정확성에서는 개선되었지만 문장 자연스러움에서는 저하되었다면, 과연 모델이 전반적으로 향상되었다고 볼 수 있을지 판단이 모호해집니다. 이러한 상황은 개선을 위한 명확한 방향 설정에 혼란을 초래할 수 있습니다. 따라서 우리는 “정책 적합성”이라는 명확한 단일 기준만을 적용함으로써, 평가 과정을 단순화하고, 각 결과에 대해 명확한 액션 아이템을 도출할 수 있도록 설계했습니다.

아마 눈치채셨겠지만, 이는 1부에서 저희가 채택했던 전문가 평가 방식과 동일한 구조입니다. 사실 처음부터 평가 방식을 단순하게 설정한 이유는, 장기적으로 LLM-as-a-Judge를 구축하려는 계획의 일환이었습니다. 평가자의 인지적 부담을 줄이고, 평가의 일관성을 높이며, 명확한 액션 아이템을 도출할 수 있도록 평가 체계를 설계한 것입니다. 결과적으로, 이러한 전략적 선택은 사람과 LLM 모두가 쉽게 이해하고 일관성 있게 적용할 수 있는 강력한 평가 프레임워크로 이어졌습니다.

3

이제 LLM Judge의 평가 방식/척도/기준을 정했으니, 실제 구현을 해보겠습니다.

우리가 원하는 이상적인 LLM Judge는 인간 평가 전문가와 동일한 방식으로 평가할 수 있어야 합니다. 왜냐하면 그래야 인간 전문가를 대체할 수 있기 때문입니다. 인간 평가 전문가는 입력으로 사용자 쌍의 정보와 생성된 설명 문구를 받습니다. 그리고 각 설명이 정책을 만족하는지(pass/fail)를 판단합니다. 그리고 상세한 이유(critique)를 제공합니다. 그래서 우리는 LLM Judge도 똑같은 입력/행동/출력을 가지도록 설계했습니다.

그리고 LLM이 잘 만들어졌는지 평가할 수 있어야 합니다. 평가를 위해 여러 문장에 대해 인간 평가자와 LLM Judge의 평가(pass/fail)를 비교하고, 일치율(agreement)이 얼마인지 정량적으로 평가합니다. 우리가 원하는 수준은 agreement 85%입니다. 왜냐하면 내부 실험 결과 인간 평가 전문가 간의 agreement는 80% 후반에서 90% 초반이었기 때문입니다. 마찬가지로 LLM-as-a-Judge가 이정도 수준에 도달 할 수 있다면 충분히 안심하고 사용할 수 있습니다.

이제 높은 agreement를 달성하는 LLM Judge를 만드려면 어떻게 해야 될까요? 잘 알려진 프롬프팅 방식을 활용해보겠습니다.

[Role]
당신은 AI 언어 모델로서 Judge의 역할을 수행합니다.  
당신의 임무는 데이팅 앱에서 추천된 유저와 추천받은 유저 사이에 생성된 설명을 평가하는 것입니다.  
당신은 각 설명이 명시된 평가 기준에 부합하는지 판단하고, 이에 대한 자세한 critique을 제공한 후,
최종적으로 Pass 또는 Fail 평가를 내려야 합니다.

{... 정책 문서 ...}

[Format]
주어진 설명 문장에 대해 다음과 같은 형식으로 output 하세요.

{
  "critique": "어떤 이유로 최종 평가를 내렸는지 서술",
  "evaluation": "최종 평가 (Pass 또는 Fail)"
}

[Examples]
Input: 
추천 받는 유저:
(자기소개) 나는 양키스의 big fan!
(관심사) 야구, 치킨, ...
...

추천 된 유저:
(자기소개) Go 양키스. 이번 주말에 양키스 경기 보러 갈래?
(관심사) 야구, 자전거, ...
...

설명: 둘 다 양키스를 좋아해요.

Output:
{
    "critique": "둘 다 자기소개에 양키스를 좋아한다는 점이 명시되어있네요. 흔하지 않고 좋습니다.", 
    "evaluation": "Pass"
}

[Input]
추천 받는 유저: {유저 A 정보}

추천 된 유저: {유저 B 정보}

설명: {생성된 설명}

프롬프트를 구성하는 요소는 다음과 같습니다.

  • Role: LLM에게 Judge라는 역할을 부여해줍니다.
  • Format: LLM의 출력 형식을 지정해줍니다. Judge가 critique을 통해 이유를 먼저 설명하고, 이를 이용하여 최종적으로 평가를 내리게 하여 Chain-of-Thought을 활용할 수 있도록 하였습니다.
  • Examples: 인간 전문가가 평가한 실제 예시를 넣어줍니다. 이렇게 Example을 넣어주는 걸 Few-shot prompting이라고 합니다. LLM이 인간 전문가처럼 동작하도록 힌트를 주는 것입니다.
  • Input: 실제 평가의 대상인 유저 쌍의 정보와 생성된 설명이 들어가는 자리입니다.

하지만 이런 잘 알려진 프롬프팅 기법만으로는 충분히 잘 동작하지 않습니다. 해당 프로젝트에서 위와 같은 프롬프트로 만든 Judge와 이전에 진행한 인간 평가의 alignment를 정량적으로 평가해보면 agreement 60% 정도가 나옵니다. Binary evaluation임을 고려하면 상당히 낮은 수치입니다. 일견 작동할 것처럼 보이는 프롬프트가 잘 동작하지 않는 이유가 세 가지 있습니다.

첫째, 정책 문서를 그대로 넣는다고 해서 LLM이 그 내용을 잘 이해하고 평가에 정확히 활용해주진 않습니다. 우리의 정책은 본래 “좋은 문장을 생성하기 위한 가이드라인”으로, 생성자 입장에서 참고하도록 만든 것이지 평가 기준으로 정제된 문서는 아닙니다. 인간 평가자는 이 차이를 직관적으로 메우며, 예컨대 “상대 취향을 고려하라”는 문구에서 어떤 설명은 피해야 한다는 의미까지도 유추합니다. 하지만 LLM은 이런 뉘앙스를 잘 읽어내지 못하고, 정책을 기준 삼아 정확히 판단하리라 기대하기 어렵습니다. 또한 “판단의 이유를 설명하라”는 단순한 프롬프트만으론, LLM이 “자연스럽다”, “정책과 일치” 같은 모호한 표현으로 판단 근거를 대신하는 경우가 많습니다. 예를 들어, 상대가 “술을 싫어한다”는 정보가 있음에도 “상대는 술을 즐깁니다”라는 문장에 대해 단지 문장이 매끄럽다는 이유로 Pass를 내리는 식입니다. 결국 단순한 정책 입력만으로는 LLM이 일관되고 정밀한 평가를 하기 어렵습니다.

둘째, 단순히 Few-shot prompting으로 인간 평가 결과를 그대로 넣는 방식만으로는 원하는 수준의 평가 품질을 얻기 어렵습니다. 인간 평가자의 평가(critique)를 복사해 넣으면, LLM은 그 표면적인 표현만 모방하고, 그 뒤에 있는 사고 과정을 제대로 따라가지 못할 가능성이 큽니다. 즉, 인간은 여러 맥락과 직관을 바탕으로 판단을 내리지만, LLM은 그 최종 결과만 보고 그 과정을 역추론하는 데 서툽니다. 평가자가 자세히 크리틱을 작성한다고 해도, 너무 당연하게 여겨지는 부분들은 언어로 명시되지 않기 때문에 LLM 입장에서는 해석하기 어렵습니다. 예를 들어 “흔하지 않고 좋습니다” 같은 표현은 인간끼리는 쉽게 의미를 공유하지만, LLM에게는 왜 좋은지, 무엇이 흔하지 않은지 그 맥락이 빠져 있어 이해하기 어렵습니다.

마지막으로, 정책이 너무 길고 상세하면 LLM이 평가 과정에서 중요한 디테일을 놓치는 경향이 있습니다. LLM은 입력의 모든 세부 사항을 균일하게 주의 깊게 읽고 판단하는 대신, 자칫 몇 가지 눈에 띄는 정보에만 집중하거나 나머지를 간과할 수 있습니다. 예를 들어, 정책에서 민감한 정보를 피하라고 명시했더라도, 그 부분이 긴 정책 문서의 중간에 들어있다면 LLM이 그 항목을 제대로 인지하지 못하고 실수로 민감한 정보를 통과시키는 평가를 내릴 수 있습니다.

또한 우리가 문헌조사에서 파악했던 Judge의 일관성과 alignment를 높이기 위한 여러가지 방법들은 대체로 likert scoring이나 real-valued scoring에서 일관성을 높이기 위한 기법들이나 Judge를 Fine-tuning 하는 내용이 많았습니다. 하지만 우리의 경우 binary evaluation을 진행하기 때문에 전자의 기법들이 작동하지 않았고, 정책이 자주 바뀌는 우리의 환경에서 Fine-tuning이 적절하지 않다고 판단하였습니다.

그럼 뭘 고쳐야 하는데요?

위의 어려움들을 개선하기 위해, 프롬프팅 방식을 여러 단계로 나누어 점진적으로 개선했습니다. 단순한 프롬프트에서 시작하여, 최종적으로 LLM-as-a-Judge가 전문가 수준의 평가를 수행하기까지 어떤 개선을 거쳤는지 살펴보겠습니다.

(1) Policy decomposition (checklist)

앞서 말씀드린 것처럼, LLM은 전문가와 같이 정책의 세세한 부분을 모두 검토하는 추론을 쉽게 수행하지 못합니다. 따라서 사람에게 주어진 정책 문서를 LLM의 추론 방식에 알맞게 수정하는 작업이 필수적이었습니다. 단순히 정책 전체를 보여주는 방식에서, 각 기준을 명확한 항목(checklist)으로 나누어 제공함으로써 LLM이 각 항목을 별도로 판단하도록 개선했습니다.

예를 들어, 기존 정책이 “추천 받는 유저의 프로필에 있는 일치하는 상대의 흔하지 않으며, 민감하지 않은 흥미여야 합니다.” 이라는 문장이라고 생각해봅시다. LLM은 이 문장을 보고, (1) 두 유저의 프로필도 보고, (2) 해당 내용이 흔하지 않는 내용인지, (3) 그리고 민감하지 않은지 여부도 판단해야 합니다. LLM은 이런 복잡한 인스트럭션이 있을 때 “대체로는” 잘하지만, 우리가 원하는 것처럼 항상 일관적으로 모든 정책을 검토해주지 않습니다.

4

따라서, 우리는 이러한 복잡한 문장을 다음과 같이 분해하였습니다.

아래 체크리스트를 따라 주어진 설명을 평가하세요

...

- 기준 1: 설명이 추천 된 유저의 프로필에 명시되어 있는가?
- 기준 2: 추천 받은 유저의 프로필 정보와 일치하는가?
- 기준 3: 해당 정보가 흔한 흥미 (게임하기, 영화보기, 요리하기, ...) 에 포함되지는 않는가?
- 기준 4: 생성된 설명이 6th-grade 수준으로 읽기 쉽고 자연스러운가?
- 기준 5: 민감하거나 제한된 정보 (예: drug usage, 흡연 여부 등) 가 포함되지는 않았는가?
...

이는 정책 항목들을 step-by-step으로 하나하나 분류할 수 있도록 단순화해주는 역할을 합니다. 이를 통해서, LLM은 각 step마다 이진 (binary) 판단만을 할 수 있도록 합니다. 이렇게 instruction을 분해 (decompose)하는 것이 평가의 주관성을 줄여주고, 인지적 부하를 덜어준다는 연구 결과들[1, 2]이 있습니다. 최종적으로는 이러한 checklist의 판단을 종합하여 결론을 내릴 수 있도록 합니다. 모든 체크리스트를 통과했다면 합격! 하나라도 탈락했다면 불합격으로 말이죠.

(2) 전문가의 직관을 LLM의 언어로 - Critique decomposition

Few-shot prompting이란, LLM에게 우리가 원하는 방식으로 동작하게 하기 위해 예시를 함께 제공하는 기법입니다. 단순히 정책이나 기준만 알려주는 것만으로는 충분하지 않습니다. 사고 과정을 함께 주지 않으면, LLM은 기준을 자의적으로 해석하거나, 허술한 논리로 판단을 내릴 수 있기 때문입니다. 예를 들어 프롬프트를 checklist 형태로 정리해주더라도, 그 항목 하나하나를 어떻게 해석하고 판단할지는 여전히 LLM의 임의성에 달려 있습니다.

따라서 핵심은 사람의 사고 과정을 구조화된 형태로, 즉 checklist 기준에 따라 분해된 critique로 제공하는 것입니다. 단순히 전문가가 쓴 평가문을 복사해 넣는 방식은 충분하지 않습니다. 실제 평가에서는 전문가가 “당연히 그렇지”라고 느껴 언어화하지 않은 판단이 많고, LLM은 그 공백을 메우지 못합니다. “흔하지 않고 좋다”는 말이 사람에게는 직관적일 수 있지만, LLM에게는 왜 흔하지 않은지, 무엇이 좋은지 설명이 빠져 있는 한 그 의미를 재현하기 어렵습니다.

이 때문에 전문가의 평가도 LLM이 해석 가능한 방식으로 정책의 세부 항목에 맞춰 명시적으로 재구성해야 합니다. 예컨대 두 유저 모두 bio에 양키스 팬이라는 정보가 있는 경우, 그냥 “양키스 팬이라니 공통 관심사네요. Pass입니다”라고 하는 대신, 다음과 같이 checklist 기준에 맞춰 전문가의 뇌를 끄집어내는 심정으로 세세히 써줘야 합니다.

[Examples]
"critique":  
  "기준 1: 추천된 유저의 자기소개에 'Go 양키스. 이번 주말에 양키스 경기 보러 갈래?'라고 명시되어 있습니다.  
   기준 2: 추천받은 유저의 자기소개에 '양키스의 big fan'임이 명시되어 있습니다.  
   기준 3: 양키스의 fan이라는 정보는 흔한 흥미 목록에 없습니다.
   기준 4: 설명이 매우 쉽고 자연스러운 표현으로 작성되었습니다.  
   기준 5: 민감하거나 제한된 정보를 포함하지 않습니다.  
   따라서 이 설명은 기준을 모두 통과했습니다."  
"evaluation": "Pass"

이처럼 checklist에 따라 전문가의 판단 근거를 구조화해서 제공해야, LLM이 실제로 인간의 평가 과정을 모방하여 일관된 critique을 남기는 것을 확인할 수 있었습니다. 결국 중요한 건 전문가가 사람에게는 너무 당연해 말로 표현하지 않았던 것까지 끌어내어, LLM이 해석 가능하도록 조목조목 언어화해주는 작업입니다. 이 과정을 통해서 LLM과 인간 판단 사이의 alignment가 실제로 높아지는 것을 확인할 수 있었습니다.

5

(3) 리마인더 추가

마지막으로, 프롬프트의 끝부분에는 LLM이 평가의 핵심 기준을 놓치지 않고 항상 기억할 수 있도록 간단한 리마인더를 추가했습니다. 물론 이미 체크리스트와 예시들이 정책을 매우 상세히 설명하고 있지만, LLM은 때로는 과부하를 겪거나, 중요하지 않은 부분에 더 많은 주의를 기울이거나, 때론 중요한 포인트를 까먹기도 합니다.

[Summary of the process]
- 평가 기준에 따라 제공된 설명을 평가하세요.
- 설명의 길이, 톤, 표현의 자연스러움, 정보 정확성 및 제한된 정보 포함 여부를 확인하세요. 특히, 민감한 정보를 포함하는지 주의하세요.
- 판단의 이유를 자세한 critique로 제공한 뒤, Pass 또는 Fail을 결정하세요.
- 모든 설명 평가 후 최종적으로 전체 설명의 적합성을 판단하세요.

사람이라면 중요한 포인트를 형광펜으로 칠하거나 별표를 치는 식으로 기억할 수 있겠죠. 우리는 마치 시험 보기 직전 선생님이 “이거 꼭 나와” 하시면서 중요한 사항을 다시 한번 강조해 주시듯이, 이렇게 중요한 평가 원칙을 다시 한번 강조해줌으로써, LLM이 평가의 핵심 요소를 보다 안정적으로 참조하도록 유도할 수 있으며, 실험적으로도 평가 누락을 줄이는 데 도움이 되는 경향을 보였습니다.

6

최종적으로는 아래 프롬프트가 구성되었습니다.

[Role]
당신은 AI 언어 모델로서 Judge의 역할을 수행합니다.  
당신의 임무는 데이팅 앱에서 추천된 유저와 추천받은 유저 사이에 생성된 설명을 평가하는 것입니다.  
당신은 각 설명이 명시된 평가 기준에 부합하는지 판단하고, 이에 대한 자세한 critique을 제공한 후,
최종적으로 Pass 또는 Fail 평가를 내려야 합니다.

[Detailed guidelines]
아래 체크리스트를 따라 주어진 설명을 평가하세요
...

- 기준 1: 설명이 추천 된 유저의 프로필에 명시되어 있는가?
- 기준 2: 추천 받은 유저의 프로필 정보와 일치하는가?
- 기준 3: 생성된 설명이 6th-grade 수준으로 읽기 쉽고 자연스러운가?
- 기준 4: 민감하거나 제한된 정보 (예: drug usage, 흡연 여부 등) 가 포함되지는 않았는가?
...

[Format]
각 설명에 대해 다음과 같은 형식으로 output 하세요.

{
    "critique": "해당 Priority의 각 기준을 만족하는지 단계별로 분석",
    "evaluation": "최종 평가 (Pass 또는 Fail)"
}

...

[Examples]
Input:
추천 받는 유저:
(자기소개) 나는 양키스의 big fan!
(관심사) 야구, 치킨, ...
...

추천 된 유저:
(자기소개) Go 양키스. 이번 주말에 양키스 경기 보러 갈래?
(관심사) 야구, ...
...

설명: 둘 다 양키스를 좋아해요.

Output:
{
	"critique":  
	  "기준 1: 추천된 유저의 자기소개에 'Go 양키스. 이번 주말에 양키스 경기 보러 갈래?'라고 명시되어 있습니다.  
	   기준 2: 추천받은 유저의 자기소개에 '양키스의 big fan'임이 명시되어 있습니다.  
	   기준 3: 설명이 매우 쉽고 자연스러운 표현으로 작성되었습니다.  
	   기준 4: 민감하거나 제한된 정보를 포함하지 않습니다.  
	   따라서 이 설명은 P1의 기준을 모두 통과했습니다.",
	"evaluation": "Pass"
}
...

[Summary of the process]
- 평가 기준에 따라 제공된 설명을 평가하세요.
- 설명의 길이, 톤, 표현의 자연스러움, 정보 정확성 및 제한된 정보 포함 여부를 확인하세요. 특히, 민감한 정보를 포함하는지 주의하세요.
- 판단의 이유를 자세한 critique로 제공한 뒤, Pass 또는 Fail을 결정하세요.
- 모든 설명 평가 후 최종적으로 전체 설명의 적합성을 판단하세요.

[Input]
추천 받는 유저: {유저 A 정보}

추천 된 유저: {유저 B 정보}

설명: {생성된 설명}

이렇게 구성된 프롬프팅은 사람이 암묵적으로 수행했던 평가 과정을 논리적으로 세밀히 분해하여 LLM이 명확히 이해하고, 따라할 수 있는 형태로 제시한 결과물입니다. 특히 전문가의 평가 예시도 동일한 형식의 step-by-step 구조로 재구성하여 제공했기 때문에, LLM은 사람의 논리 구조를 훨씬 더 정확히 흡수하고, 이를 일관성 있게 적용할 수 있었습니다. 그 결과, LLM-as-a-Judge는 단순히 평가를 자동화하는 수준을 넘어 사람 수준의 논리적 판단을 일관되고 정확하게 수행할 수 있는 고급 평가 시스템으로 발전할 수 있었습니다.

이러한 단계적 프롬프트 개선과 Few-shot 예시 선택의 최적화를 반복한 결과, 최종적으로는 약 84%라는 높은 agreement를 달성할 수 있었습니다. 도달한 84%라는 수치는 전문가 수준에 매우 근접한 결과라고 판단할 수 있었습니다. 앞서 언급했듯이 인간 평가자끼리의 agreement와 비슷한 수준이기 때문입니다.

평가 자동화를 넘어서

7

Judge의 성능 평가 과정에서 또 한 가지 의미 있는 발견은, 정성적으로 평가 결과를 분석하면서 정책의 추가적인 개선 방향을 찾을 수 있었다는 점입니다. 정책을 다시 명확히 하거나 세부적인 기준을 추가하면서, 정책 개선의 iteration 과정의 속도와 품질을 더욱 높일 수 있었습니다.

LLM Judge는 시스템 디버깅에도 활용되었습니다. 배포된 특정 모델 버전에서 Fail 비율이 갑자기 증가했을 때, Judge의 상세한 critique 로그를 살펴보면, 설명이 실패한 원인이 모호한 표현(vague expression) 때문인지, 잘못된 정보 오류 때문인지, 아니면 연결고리가 약하기 때문인지 구체적으로 확인할 수 있었습니다. 이러한 정보는 즉각적으로 후속 generation 모델의 개선이나 정책 문서의 보완으로 이어졌습니다. 이는 Judge가 전문가가 평가하듯이 상세한 critique을 제공해 줄 수 있도록 구현되었기에 가능하였습니다.

또한 Judge는 모델 학습 과정에서도 유용하게 활용되었습니다. LLM 학습 데이터를 정제할 때 LLM Judge를 사용하여 Fail로 판정된 bullet을 제거하거나 수정하는 방식으로 데이터 품질을 관리할 수 있었습니다. 사람이 모든 데이터를 일일이 평가하지 않아도 Judge의 평가로 일정 수준 이상의 데이터 정제가 가능해졌고, 덕분에 학습 데이터의 일관성 유지와 품질 향상 효과를 얻을 수 있었습니다.

이처럼 LLM-as-a-Judge는 단순히 사람을 대체하는 평가자 역할에서 나아가, 시스템의 성능을 지속적으로 모니터링하고 빠르게 개선 방향을 찾는 필수적인 도구로 활용할 수 있습니다.

마치며

LLM이 안정적인 평가자가 되도록 만들기는 생각보다 쉽지 않습니다. 단순히 프롬프트를 조정한다고 해결되지 않기 때문입니다. 단순히 정책을 프롬프트에 전달하거나, 예시를 추가한다고 해결되지 않았습니다. 실제로는 사람이 암묵적으로 수행하던 미묘한 판단 과정을 프롬프트에 명시적으로 풀어써주는 세심한 작업이 필요했습니다. 즉, 체계적인 정책을 바탕으로 인간 전문가의 사고를 구조화하여 LLM에게 이식하는 작업이 중요합니다.

지난 1부에서는 사람이 직접 설명의 품질을 평가하고, 그 결과를 체계적인 정책으로 정리함으로써 팀 전체가 공통된 목표와 기준을 가질 수 있도록 만드는 방법을 소개했습니다. 이어진 2부에서는, 그렇게 정립된 명확한 정책을 바탕으로 사람이 아닌 LLM이 설명의 품질을 자동으로 판단하고, 그 이유까지 제시할 수 있도록 하는 LLM-as-a-Judge 시스템의 설계와 활용 과정을 다뤘습니다.

하이퍼커넥트 MGAI 팀은 단순히 모델을 만드는 데 그치지 않습니다. 우리가 진짜 중요하게 여기는 건, 문제를 올바르게 정의하고, 그 정의를 제품 맥락에 맞게 실현 가능한 시스템으로 구현하는 것입니다. 이러한 문제 정의에서부터 실전 적용까지의 여정에 공감하시나요? MGAI 팀은 위와 같이 Tinder와 같은 Match Group의 포트폴리오와 One team으로 가치를 만들어나가고 있습니다. 함께 복잡한 문제를 풀어나갈 동료 분들을 기다립니다. 우리의 여정에 함께해 주세요!

1 해당 문헌 조사는 프로젝트 시기 이전인 2024년 상반기까지 수행하였습니다.