최근 LLM 연구에서 중요한 변화 중 하나는 LLM을 단순히 답변을 생성하는 모델로만 보지 않는다는 점이다. 이제 LLM은 다른 모델의 답변을 평가하고, 여러 후보 중 더 나은 결과를 고르고, 때로는 학습 데이터나 reasoning path까지 선별하는 “judge” 역할을 맡고 있다. 이 흐름을 정리한 논문이 From Generation to Judgment: Opportunities and Challenges of LLM-as-a-judge다.
이 논문은 새로운 model을 제안하는 실험 논문이라기보다, 빠르게 커지고 있는 LLM-as-a-judge 연구를 체계적으로 정리한 survey다. 핵심 질문은 세 가지다.
첫째, 무엇을 평가할 것인가?
둘째, 어떻게 평가할 것인가?
셋째, LLM judge 자체는 어떻게 benchmark할 것인가?
LLM-as-a-judge란 무엇인가
LLM-as-a-judge는 말 그대로 LLM을 evaluator로 사용하는 방식이다. 예전에는 BLEU, ROUGE처럼 reference와 candidate output의 lexical overlap을 보는 metric이 많이 쓰였다. 이후 BERTScore, BARTScore 같은 model-based metric도 등장했다. 하지만 open-ended generation에서는 정답이 하나로 고정되지 않는다. 좋은 답변인지, 안전한지, 논리적으로 맞는지, 사용자의 의도에 잘 맞는지 같은 요소는 단순한 matching으로 평가하기 어렵다.
LLM-as-a-judge는 이 지점에서 등장한다. LLM에게 candidate response와 evaluation instruction을 주고, score를 매기거나, 여러 답변을 ranking하거나, 가장 좋은 candidate를 selection하게 한다. 즉, LLM을 생성기가 아니라 평가자로 활용하는 것이다.
입력 방식은 크게 두 가지다.
Point-wise는 하나의 candidate를 단독으로 평가하는 방식이다. 예를 들어 “이 답변의 helpfulness를 1점부터 5점까지 평가하라”는 식이다.
Pair-wise 또는 list-wise는 여러 candidate를 함께 보여주고 비교하게 하는 방식이다. 예를 들어 A와 B 중 어떤 답변이 더 나은지 고르게 하거나, 여러 답변을 순서대로 ranking하게 한다.
출력 방식은 score, ranking, selection으로 나뉜다. score는 정량 점수를 주는 방식이고, ranking은 candidate 간 순위를 매기는 방식이며, selection은 가장 적합한 답변이나 일부 candidate를 선택하는 방식이다.
무엇을 평가하는가: 여섯 가지 attribute
논문은 LLM-as-a-judge가 평가하는 주요 attribute를 여섯 가지로 정리한다.
첫 번째는 helpfulness다. 답변이 사용자에게 실제로 도움이 되는지, 충분히 informative한지 보는 기준이다. 특히 alignment data를 만들거나 model response quality를 평가할 때 중요하다.
두 번째는 safety & security다. 모델이 harmful content를 생성하지 않는지, malicious input이나 adversarial prompt에 부적절하게 반응하지 않는지 평가한다. safety evaluation이나 toxic prompt filtering에서 많이 쓰인다.
세 번째는 reliability다. 답변이 사실에 충실한지, hallucination이 없는지, 불확실한 내용을 과도하게 단정하지 않는지 평가한다. RAG나 long-form generation에서 특히 중요하다.
네 번째는 relevance다. 답변이 query나 context와 얼마나 관련 있는지 평가한다. conversation evaluation, search, retrieval, recommendation, RAG에서 모두 중요한 기준이다.
다섯 번째는 logic이다. reasoning step, planning, tool use, API selection, agent decision-making에서 중간 판단이 논리적으로 맞는지를 보는 기준이다.
여섯 번째는 overall quality다. 개별 attribute를 따로 평가하기보다 답변의 종합적인 품질을 평가하는 방식이다. summarization, machine translation, dialogue evaluation처럼 전체 품질 판단이 필요한 task에서 자주 쓰인다.
어떻게 평가 성능을 높이는가: tuning과 prompting
논문은 LLM judge를 더 잘 만들기 위한 방법을 크게 tuning과 prompting으로 나눈다.
1. Tuning
Tuning에서는 먼저 어떤 데이터를 쓸지가 중요하다. 가장 직접적인 방법은 manually-labeled data를 사용하는 것이다. 사람이 직접 평가한 judgment label, rationale, multi-aspect feedback을 학습하면 human-like evaluation criteria를 더 잘 따라갈 수 있다.
하지만 human annotation은 비싸고 scale이 제한된다. 그래서 synthetic feedback도 많이 활용된다. LLM이 스스로 평가 결과를 만들거나, 더 강력한 LLM이 rationale, feedback, judgment label을 생성해 judge model을 학습시키는 방식이다.
학습 방법으로는 SFT가 널리 쓰인다. pair-wise judgment data나 point-wise judgment data를 이용해 LLM이 평가 기준을 학습하게 한다. 또한 DPO, preference learning, RLVR 같은 방법도 사용된다. 특히 judgment는 본질적으로 비교와 ranking을 포함하기 때문에 preference learning과 잘 맞는다.
2. Prompting
Prompting 측면에서는 여섯 가지 전략이 정리된다.
Swapping operation은 pair-wise 평가에서 candidate의 위치를 바꿔 두 번 평가하는 방식이다. LLM judge는 A/B 위치에 민감할 수 있기 때문에, 순서를 바꿔도 같은 결론이 나오는지 확인해 positional bias를 줄인다.
Rule augmentation은 prompt 안에 evaluation rubric, principle, reference를 명시하는 방식이다. 단순히 “좋은 답변을 고르라”고 하는 것보다, 어떤 기준으로 평가해야 하는지 자세히 주는 것이다.
Multi-agent collaboration은 하나의 judge에 의존하지 않고 여러 judge의 판단을 aggregation하는 방식이다. debate, voting, mixture-of-agent, cascaded selection 같은 구조가 여기에 포함된다.
Demonstration은 few-shot example을 주는 방식이다. 사람이 평가한 예시를 prompt에 넣어 LLM judge가 평가 기준을 더 잘 따라가도록 한다.
Multi-turn interaction은 단일 답변만 보고 평가하지 않고, judge와 candidate model이 여러 차례 상호작용하면서 더 많은 정보를 드러내게 하는 방식이다. 특히 agent나 reasoning task에서 유용하다.
Comparison acceleration은 pair-wise 비교의 계산 비용을 줄이는 전략이다. candidate가 많을수록 모든 쌍을 비교하는 비용이 커지기 때문에, tournament-based approach나 baseline response를 활용해 비교를 줄인다.
LLM-as-a-judge는 어디에 쓰이는가
논문은 주요 application을 네 가지로 정리한다.
첫 번째는 evaluation이다. open-ended generation, dialogue, summarization, creative writing, reasoning task, multimodal task 등에서 model output quality를 평가한다.
두 번째는 alignment다. 강력한 LLM을 judge로 사용해 preference data를 만들고, 작은 model을 alignment하는 데 활용한다. self-judging 방식으로 자기 답변을 critique하거나 ranking해 preference data를 만들 수도 있다.
세 번째는 retrieval이다. LLM judge는 document relevance를 평가하거나, RAG에서 어떤 external knowledge를 가져와야 하는지 판단하는 역할을 한다. 단순 검색 결과 ranking을 넘어, generation에 필요한 context selection까지 담당할 수 있다.
네 번째는 reasoning이다. LLM judge는 intermediate reasoning step을 평가하고, 여러 reasoning path 중 더 나은 경로를 선택하며, tool use나 agent communication을 조정하는 controller 역할도 할 수 있다.
LLM judge 자체는 어떻게 평가할까
중요한 문제는 “LLM이 평가자로 쓸 만한가?”다. 논문은 LLM-as-a-judge benchmark를 네 가지로 구분한다.
General performance는 LLM judge의 판단이 human judgment와 얼마나 잘 맞는지 본다. Cohen’s kappa, normalized accuracy 같은 metric이 사용된다.
Bias quantification은 position bias, verbosity bias, format bias처럼 judge가 가진 편향을 측정한다.
Challenging task performance는 쉬운 평가가 아니라 모델들이 헷갈리기 쉬운 hard question이나 reasoning task에서 judge가 잘 판단하는지 본다.
Domain-specific performance는 code, medical, finance, law, mathematics, multimodal, multilingual, instruction following, LLM agent 같은 특정 domain에서 judge 성능을 평가한다.
가장 큰 문제: bias와 vulnerability
LLM-as-a-judge의 가장 큰 약점은 bias다. LLM judge는 더 긴 답변, 더 그럴듯하게 보이는 답변, 더 잘 formatting된 답변을 선호할 수 있다. 또한 자기 model이 만든 답변을 더 선호하는 egocentric bias나 preference leakage도 문제가 된다.
또 다른 문제는 vulnerability다. candidate response 안에 judge를 속이는 문구가 들어가거나, prompt injection이 포함되면 judge의 판단이 흔들릴 수 있다. 특히 high-stakes scenario에서는 이런 취약점이 매우 중요하다. medical, law, finance처럼 잘못된 평가가 큰 피해로 이어질 수 있는 영역에서는 LLM judge를 그대로 믿기 어렵다.
앞으로의 방향
논문은 앞으로의 연구 방향으로 네 가지를 강조한다.
첫째, bias의 원인을 더 깊게 분석해야 한다. 단순히 bias를 줄이는 trick을 넘어서, 왜 LLM judge가 특정 답변을 선호하는지 이해해야 한다.
둘째, inference-time scaling을 judge에도 적용할 수 있다. self-consistency, best-of-N, MCTS, long CoT reasoning 등을 활용하면 judge의 판단이 더 신중해질 수 있다. 다만 비용 증가, overthinking, adversarial attack에 대한 취약성도 함께 고려해야 한다.
셋째, 더 dynamic하고 complex한 judging strategy가 필요하다. 단순히 한 번 prompt를 던져 평가하는 방식에서 벗어나, examiner처럼 문제를 생성하고, candidate의 성능에 따라 난이도를 조절하고, multi-agent debate를 통해 판단하는 방향으로 발전할 수 있다.
넷째, Human-LLMs co-judgement가 중요하다. 모든 sample을 사람이 평가하는 것은 비효율적이지만, LLM judge가 중요한 sample이나 어려운 sample을 선별하고, 사람은 그 subset을 검토하는 방식은 현실적인 대안이 될 수 있다.
마무리
이 논문이 주는 메시지는 분명하다. LLM-as-a-judge는 단순한 자동평가 도구가 아니다. 앞으로의 LLM ecosystem에서 evaluation, alignment, retrieval, reasoning, agent decision-making을 연결하는 핵심 infrastructure가 될 가능성이 크다.
하지만 동시에 LLM judge는 완벽한 심판이 아니다. bias, vulnerability, cost, robustness 문제가 남아 있다. 따라서 LLM-as-a-judge를 사용할 때는 “LLM이 평가했으니 객관적이다”라고 받아들이기보다, 어떤 기준으로 평가했는지, 어떤 bias가 개입될 수 있는지, human validation이 필요한 지점은 어디인지 함께 설계해야 한다.
결국 중요한 것은 LLM을 judge로 쓰느냐 마느냐가 아니라, 어떤 조건에서, 어떤 기준으로, 얼마나 검증하면서 쓸 것인가다. 이 논문은 그 질문을 체계적으로 정리해 준다는 점에서 LLM evaluation을 공부하는 사람에게 좋은 출발점이 된다.
태그: LLM, LLM-as-a-judge, Evaluation, Alignment, RAG, Reasoning, Survey Paper
