Aligning LLM-as-a-Judge with Human Preferences

🖼️ 인포그래픽

Aligning LLM-as-a-Judge with Human Preferences 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangSmith는 사람이 수정한 LLM-as-a-Judge 평가 결과를 few-shot 예시로 축적해, 별도의 반복적인 프롬프트 엔지니어링 없이 평가기를 인간 선호에 점진적으로 맞추는 self-improving evaluator를 소개한다.

📌 핵심 요약

생성형 LLM 애플리케이션은 자연어 출력을 만들기 때문에 간결성, 정확성, 독성 여부 같은 품질을 전통적인 단위 테스트나 하드코딩 규칙으로 평가하기 어렵다.
LLM-as-a-Judge는 별도의 LLM에 생성 결과와 필요한 맥락을 전달해 평가하게 하는 방식으로, RAG 환각 탐지, RAG 정답성 판단, 부적절한 답변 탐지 등에 활용된다.
이 방식이 가능한 이유는 평가 시점의 LLM이 정답 같은 추가 정보를 받을 수 있고, 올바른 답을 직접 생성하는 것보다 이미 나온 답의 적절성을 판단하는 일이 더 단순하기 때문이다.
하지만 LLM-as-a-Judge도 평가 프롬프트를 잘 설계해야 하므로, 제대로 된 평가 시스템을 구축하려는 팀에게 또 다른 프롬프트 엔지니어링 부담이 된다.
LangSmith의 self-improving evaluator는 사용자가 앱 안에서 평가 피드백을 수정하면 이를 few-shot 예시로 저장하고 다음 평가 프롬프트에 반영해, 시간이 지날수록 평가가 인간 선호와 더 잘 맞도록 만든다.

🧩 주요 포인트

생성형 LLM 애플리케이션은 자연어 출력을 만들기 때문에 간결성, 정확성, 독성 여부 같은 품질을 전통적인 단위 테스트나 하드코딩 규칙으로 평가하기 어렵다.
LLM-as-a-Judge는 별도의 LLM에 생성 결과와 필요한 맥락을 전달해 평가하게 하는 방식으로, RAG 환각 탐지, RAG 정답성 판단, 부적절한 답변 탐지 등에 활용된다.
이 방식이 가능한 이유는 평가 시점의 LLM이 정답 같은 추가 정보를 받을 수 있고, 올바른 답을 직접 생성하는 것보다 이미 나온 답의 적절성을 판단하는 일이 더 단순하기 때문이다.
하지만 LLM-as-a-Judge도 평가 프롬프트를 잘 설계해야 하므로, 제대로 된 평가 시스템을 구축하려는 팀에게 또 다른 프롬프트 엔지니어링 부담이 된다.
LangSmith의 self-improving evaluator는 사용자가 앱 안에서 평가 피드백을 수정하면 이를 few-shot 예시로 저장하고 다음 평가 프롬프트에 반영해, 시간이 지날수록 평가가 인간 선호와 더 잘 맞도록 만든다.

🧠 상세 정리

1. 생성형 LLM 평가의 근본 문제

글은 평가를 LLM 애플리케이션을 지속적으로 개선하기 위한 과정으로 정의하며, 그러려면 성능을 측정할 방법이 필요하다고 설명한다. 그러나 LLM 애플리케이션의 출력은 대개 자연어이기 때문에, 일반적인 프로그램처럼 고정된 규칙이나 단위 테스트로 품질을 판정하기 어렵다. 예를 들어 답변이 간결한지, 기준 답변에 비추어 정확한지 같은 속성은 전통적인 테스트 조건으로 표현하기가 까다롭다. 특히 분류나 개체명 인식처럼 표준 ML 지표가 있는 작업과 달리, 실제 애플리케이션에서 흔한 생성형 작업에는 널리 합의된 좋은 평가 지표가 많지 않다는 점이 출발점으로 제시된다.

2. LLM-as-a-Judge의 부상과 사용 맥락

이런 한계 때문에 별도의 LLM을 평가자로 사용하는 LLM-as-a-Judge 방식이 널리 쓰이고 있다고 글은 설명한다. 이 방식은 애플리케이션이 만든 출력과 필요한 추가 정보를 평가용 LLM에 전달한 뒤, 해당 출력이 기준에 맞는지 점수화하거나 판단하게 하는 구조다. LangSmith는 특정 평가 지표를 강제하지 않으며, 실제로 많은 팀이 자기 상황에 맞는 커스텀 지표를 정의한다고 말한다. 글에서 언급된 대표 사례는 온라인 평가에서 RAG 환각을 탐지하는 일, 오프라인 평가에서 RAG 답변의 정답성을 확인하는 일, 그리고 온라인·오프라인 양쪽에서 독성 또는 부적절한 답변을 찾아내는 일이다.

3. 평가용 LLM이 작동할 수 있는 이유

글은 LLM이 애초에 답을 생성한다면 왜 또 다른 LLM이 그 답을 평가할 수 있는지에 대해 두 가지 이유를 든다. 첫째, 평가 단계의 LLM은 생성 시점의 LLM이 갖지 못했던 정보를 받을 수 있다. 예컨대 RAG 정답성을 판단할 때는 정답 또는 기준 답변을 평가자에게 제공하고, 생성된 답변과 비교하게 만들 수 있다. 둘째, 올바른 답을 처음부터 생성하는 것보다 이미 생성된 답이 맞는지 판단하는 일이 LLM에게 더 쉬운 과제일 수 있다. 글은 이런 작업의 단순화가 LLM-as-a-Judge를 실용적인 평가 방식으로 만든다고 설명한다.

4. 새로운 문제: 평가자 프롬프트 엔지니어링

LLM-as-a-Judge는 유용하지만, 글은 이 방식이 곧바로 문제를 해결하는 것은 아니라고 강조한다. 생성 모델의 프롬프트를 설계하듯 평가자 역할을 하는 LLM의 프롬프트도 다시 조정해야 하기 때문이다. 평가 기준을 어떻게 설명할지, 어떤 정보를 넣을지, 어떤 형식으로 판단하게 할지에 따라 결과가 달라질 수 있으므로 이는 또 다른 시간 소모적인 프롬프트 엔지니어링 과제가 된다. 글은 이 부담이 팀들이 제대로 된 평가 시스템을 빠르게 구축하는 데 방해가 될 수 있다고 보고, LangSmith가 이 평가 과정을 더 간소화하려 했다고 설명한다.

5. 연구적 동기: few-shot 학습과 인간 선호 정렬

LangSmith의 접근은 두 가지 연구적·실무적 관찰에서 출발한다. 첫째, 언어 모델은 few-shot 학습에 능숙해 올바른 예시를 주면 그 행동을 모방하는 경향이 있다. 글은 이 방식이 고객들의 LLM 애플리케이션에서도 널리 쓰이며, 특히 지시문만으로 원하는 행동을 설명하기 어렵거나 특정 출력 형식이 필요한 경우 효과적이라고 설명한다. 둘째, Shreya Shankar의 Berkeley 논문인 “Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences”가 같은 문제를 다루며, 인간 피드백을 수집해 LLM 평가를 인간 선호에 맞추는 방향에 동기를 제공했다고 말한다.

6. LangSmith의 self-improving evaluator 흐름

LangSmith의 self-improving evaluator는 사용자가 온라인 또는 오프라인 평가용 LLM-as-a-Judge를 설정하는 것에서 시작된다. 초기 설정은 최소화되어 있으며, 사용자는 few-shot 예시가 프롬프트 안에 어떤 형식으로 들어갈지도 지정할 수 있다. 이후 평가용 LLM은 정확성, 관련성 또는 사용자가 정한 기준에 따라 생성 결과에 피드백을 남기고, 사용자는 LangSmith 인터페이스 안에서 그 피드백을 직접 수정할 수 있다. 이 수정 사항은 few-shot 예시로 자동 저장되며, 필요하면 수정 이유에 대한 설명도 함께 남길 수 있다. 다음 평가 실행 때 LangSmith는 저장된 예시와 선택적으로 설명을 프롬프트에 포함해, 평가자가 시간이 지날수록 팀의 기준과 선호를 더 잘 반영하도록 만든다.

🧾 핵심 주장 / 시사점

LLM-as-a-Judge의 핵심 가치는 완전한 자동 정답 생성이 아니라, 추가 정보와 단순화된 판단 과제를 활용해 자연어 출력 평가를 실용화하는 데 있다.
LangSmith의 접근은 평가 품질 개선을 별도의 프롬프트 수정 작업이 아니라 사용자가 실제 평가를 검토하고 고치는 자연스러운 워크플로 안에 넣는다는 점이 중요하다.
few-shot 예시로 축적되는 인간 수정은 팀이나 애플리케이션마다 다른 평가 기준을 반영할 수 있어, 범용 지표가 부족한 생성형 AI 평가 문제에 맞는 운영 방식으로 제시된다.