-min.jpg)
LLM 심판(Judge)에 대해 자주 묻는 7가지 질문
LLM-as-a-Judge는 AI 시스템의 응답을 평가할 때 사람 대신 대형 언어 모델(LLM)을 활용하는 기법입니다. 이 글에서는 평가 척도 설계, 심판 LLM 선택, 신뢰성 검증 방법 등 실무에서 자주 받는 7가지 질문에 대한 답변을 다룹니다. 핵심은 LLM 심판이 "만능 도구"가 아니라 인간의 판단을 확장하는 도구이며, 각 사용 사례에 맞게 신중히 설계하고 검증해야 한다는 것입니다.
1. 어떤 평가 척도를 사용해야 할까? 📊
일부 LLM 심판 구현에서는 0~100점이나 1~10점 같은 숫자 척도를 사용하기도 합니다. 편리해 보이지만, 실제로는 잘 작동하지 않는 경우가 많아요. LLM은 임의의 숫자 척도에서 일관된 점수를 매기도록 보정되어 있지 않기 때문에, 거의 비슷한 응답이 어떤 때는 "7점", 다른 때는 "9점"을 받을 수 있습니다.
이진 분류(Pass/Fail)나 명확하게 정의된 몇 가지 범주를 사용하는 것을 권장합니다. 여러 범주를 사용할 때도 1~10 같은 모호한 숫자 범위 대신, 질적 차이를 명확히 설명하는 이름이 붙은 카테고리를 만드세요.
예를 들어, 이상적인 정답과 시스템이 생성한 새 답변 사이의 "정확성"을 평가한다고 해봅시다. 단순히 "정확성을 1~10점으로 평가해줘"라고 요청하면 안 됩니다. 이런 표현은 사람에게도, LLM에게도 큰 의미가 없어요. 대신 프롬프트 안에서 "정확하다"가 여러분의 사용 사례에서 실제로 무엇을 의미하는지 정의하세요.
고려할 점들:
- 누락, 추가, 모순 같은 특정 유형의 차이가 중요한가요?
- 어떤 변경은 허용되나요? (예: 참조 답변이 약어를 사용하고 새 응답이 전체 단어로 풀어썼다면 차이로 볼 것인가?)
이런 규칙들을 명확히 하면 다음과 같은 범주 체계를 만들 수 있습니다:
- 완전히 정확함 (정의한 기준 내에서)
- 정확하지만 불완전함
- 모순됨
각 범주에 대한 명확한 정의가 있으면 LLM이 평가 기준을 훨씬 정확하게 적용할 수 있습니다.
평가 설정을 테스트하는 간단한 경험 법칙: 사람이 여러분의 평가 프롬프트를 일관되게 적용할 수 있나요? 그렇지 않다면, 가능해질 때까지 다시 작성하세요. 그 다음에 LLM이 얼마나 잘 수행하는지 테스트하세요.
숫자 척도가 실패하는 이유도 바로 이것입니다: 사람들도 "6점"과 "7점" 중 무엇이 맞는지 종종 의견이 다르고, 같은 모호함이 LLM 심판도 혼란스럽게 만듭니다.
2. 심판을 만들려면 어디서부터 시작해야 할까? 🚀
실제로 무엇을 평가하고 싶은지 결정하는 것부터 시작하세요.
의미 있는 LLM 심판 기준을 얻으려면 먼저 직접 출력물에 라벨을 붙여봐야 합니다. 실제 로그나 샘플 생성물을 살펴보면서 시스템 출력의 품질을 평가하세요. 이 과정에서 반복되는 오류 유형, 엣지 케이스, 그리고 "좋음"과 "나쁨"의 실제 모습을 파악할 수 있습니다.
핵심은 간단합니다: 심판을 만들기 전에 먼저 심판이 되어보세요.
아직 실제 데이터가 없다면 합성 입력 예시를 준비할 수 있습니다. LLM에게 사용 사례에 맞는 현실적인 입력(예: 사용자 질문이나 RAG 시스템용 질문-답변 쌍)을 생성하도록 요청하는 것이죠. 이 과정은 사용자가 누구이고 무엇을 물어볼지에 대한 가정을 표현하는 데 도움이 됩니다.
수동 라벨링과 주석 작업을 하는 사람은 해당 도메인이나 제품을 깊이 이해해야 합니다. 법률 초안, 의료 조언, 금융 분석 같은 전문 분야라면 해당 분야 전문가가 검토 과정에 직접 참여해야 할 수 있어요.
먼저 출력물을 Pass/Fail/Unclear로 라벨링하고 무엇이 잘 되고 안 되는지 자유 형식 메모를 추가하세요. 그런 다음 이 메모들을 분석해서 반복되는 패턴을 찾고, 정확성, 명확성, 톤, 사실적 정확도 같은 구조화된 평가 범주로 만듭니다.
평가 기준과 가이드라인이 다른 사람이 일관되게 적용할 수 있을 만큼 명확해지면 – 그때가 LLM 심판으로 변환할 좋은 시점입니다.
핵심 요점: 평가는 인간의 판단을 대체하는 것이 아니라 확장하는 것입니다.
좋은 LLM 심판은 전문가들이 이미 알고 있는 것을 포착하고, 그 직관을 반복 가능한 자동화된 프로세스로 변환합니다. 플러그 앤 플레이 메트릭이 아니라, 데이터와 제품을 이해하는 것에서 시작하는 분석적 설계 작업입니다.
3. 심판으로 어떤 LLM을 사용해야 할까? 🤖
메인 LLM 제품을 선택할 때와 같은 방식으로 결정할 수 있습니다. 대부분의 평가 작업은 본질적으로 개방형 분류이므로, 거의 모든 범용 LLM이 심판 역할을 할 수 있어요.
일반적으로 가능한 가장 능력 있는 모델을 사용하는 것이 좋지만, 항상 작업에 따라 다릅니다. 대량의 데이터를 평가해야 한다면 더 간단한 체크에는 작은 모델을 사용해서 비용과 속도의 균형을 맞출 수 있습니다.
비교적 단순한 평가 작업:
- 감정 분석
- 주제 감지
- 거부/거절 감지
- 특정 용어 포함 여부나 형식 확인
이런 작업들은 더 작고 저렴한 모델로도 잘 처리할 수 있습니다.
더 복잡한 작업:
- 다중 턴 대화 분석
- 답변과 컨텍스트 비교
- 상세한 콘텐츠 관리 가이드 따르기
이런 경우에는 긴 컨텍스트 윈도우를 가진 더 크고 능력 있는 LLM 사용이 정당화됩니다.
4. 메인 제품과 같은 LLM을 심판으로 사용해도 될까? 🔄
일부 실무자들은 같은 LLM을 생성과 평가 모두에 사용하면 자기 출력에 편향될 수 있다고 생각해서 피하려 합니다.
LLM 심판의 편향에 대한 연구를 접할 수 있지만, 이것이 보통 무엇을 의미하는지 이해하는 것이 중요합니다. 그런 연구들은 대부분 개방형 쌍별 비교에 초점을 맞춥니다 – 모델이 같은 입력에 대한 두 응답 중 어느 것이 "더 나은지" 결정하는 상황이죠. 이런 나란히 비교 설정에서는 LLM이 같은 모델 계열이 생성한 답변이나 특정 장황한 스타일의 글을 선호할 수 있다는 것이 관찰되었습니다.
하지만 실제로 제품 평가용 LLM 심판을 만들 때 사용 사례는 보통 훨씬 더 좁고 구체적입니다. 두 응답을 비교하는 게 아니라, 특정 생성물에 대해 타겟팅된 질문을 하는 것이죠:
- 대화 중 사용자가 좌절감을 표현했나요?
- 작업이 성공적으로 완료되었나요?
- 답변이 정의된 안전 요구사항을 충족하나요?
- 응답이 참조의 모든 핵심 포인트를 다루나요?
이런 것들은 스타일 선호나 모델 계열 편향이 들어갈 여지가 거의 없는 구체적이고 경계가 명확한 체크입니다. 이런 경우, 판단의 품질은 어떤 모델 계열이 출력을 생성했는지보다 평가 프롬프트의 명확성과 모델의 능력에 훨씬 더 의존합니다.
따라서 네, 같은 LLM을 생성기와 심판 모두로 사용할 수 있습니다. 단지 평가를 위한 별도의 명확한 프롬프트를 작성하면 됩니다.
그렇긴 해도, 때로는 다른 모델(또는 여러 모델)을 사용하는 것이 도움이 됩니다. 예를 들어 평가 기준이 아직 잘 정의되지 않았거나, 이메일이 "전문적"으로 들리는지 또는 마케팅 텍스트가 "젊은 청중에게 맞는지" 같은 모호한 작업일 때요.
이런 초기 단계에서는 LLM 배심원(jury)을 실험해볼 수 있습니다 – 여러 모델이 판단을 제공하고 이를 집계하는 방식이죠. 이렇게 하면 불일치를 발견하고 메인 심판을 확정하기 전에 기준을 보정하는 데 도움이 됩니다.
또한 안전, 규정 준수, 민감한 콘텐츠 평가 같은 고위험 평가에서 일종의 "세컨드 오피니언"으로 여러 심판을 사용할 수도 있습니다.
5. LLM 심판을 어떻게 신뢰할 수 있을까? ✅
LLM 심판은 고정된 모델이나 보편적인 메트릭이 아닙니다. 특정 사용 사례를 위해 구현하는 기법이기 때문에 맹목적으로 신뢰해서는 안 됩니다. 신뢰성은 전적으로 심판이 어떻게 구축되었는지와 작업의 복잡성에 달려 있어요.
각 심판은 고유한 프롬프트, 모델, 평가 기준, 그리고 적용되는 출력 유형을 가집니다. 따라서 "LLM 심판이 작동한다" 또는 "작동하지 않는다"고 일반적으로 주장하는 것은 의미가 없습니다. 중요한 것은 여러분의 심판이 여러분의 작업에 작동하는지입니다.
미니 분류기를 만드는 것으로 생각할 수 있습니다.
먼저 감지하고 싶은 것을 정의합니다 – 예를 들어, 참조 대비 답변이 정확한지, 또는 안전이나 규정 준수 정의를 충족하는지. 그런 다음 클래스를 예측할 LLM 프롬프트를 사용해 "분류기"를 만듭니다.
이 분류기의 목표가 인간의 판단을 복제하는 것이므로, 기존 예측 ML 모델을 평가하는 것과 같은 방식으로 신뢰성을 평가해야 합니다 – 모델의 판단을 이상적인 인간 판단과 비교하는 것이죠.
간단한 프로세스:
- 심판이 적용할 것과 같은 기준으로 작은 데이터셋에 수동으로 라벨을 붙입니다.
- 같은 데이터셋에 LLM 심판을 실행합니다.
- 정확도(Accuracy), 정밀도(Precision), 재현율(Recall) 같은 표준 메트릭을 사용해 결과를 비교합니다 – 어떤 유형의 오류가 가장 중요한지에 따라 선택하세요.
예를 들어, 목표가 모든 안전하지 않은 응답을 잡는 것이라면, 일부 오탐(false positives)이 있더라도 재현율을 우선시할 수 있습니다. 또한 LLM 심판과 인간 주석자 간의 일치도나 상관관계를 측정할 수도 있습니다.
메인 제품 프롬프트와 마찬가지로, 심판도 반복하고 다듬어야 합니다. 문구, 예시, 출력 형식의 작은 변경이 결과를 눈에 띄게 바꿀 수 있어요. 라벨링된 데이터셋을 사용해 프롬프트 문구를 최적화해 심판을 자동 튜닝할 수도 있습니다.
핵심 요점: LLM 심판이 맞다고 가정하지 말고 – 측정하세요.
6. 좋은 평가 프롬프트는 어떻게 작성할까? ✍️
평가 프롬프트도 결국 LLM을 위한 또 다른 지시사항입니다. 그래서 대부분의 고전적인 프롬프트 작성 원칙이 적용됩니다.
좋은 프롬프트를 작성하는 것은 인턴에게 업무를 위임하는 것과 같습니다 – 필요한 모든 맥락과 명확한 지시를 제공해야 해요. 특히 "완전성"이나 "안전성" 같은 모호한 기준의 경우 이런 기대를 명시적으로 만들어야 합니다. 예시가 많은 도움이 됩니다.
예를 들어, "조언이 얼마나 완전한가요?" 대신, 여러분의 맥락에서 "완전하다"가 무엇을 의미하는지 정의하세요:
- 실행 가능한 계획을 포함하나요?
- 최소 하나의 출처를 참조하나요?
- 사용자의 요청을 요약하나요?
불확실한 경우에 대한 처리 지침도 프롬프트에 직접 포함할 수 있습니다. 예를 들어, 경계선상의 응답을 놓치기보다 플래그하는 것을 선호한다면: "확실하지 않으면, 조심하는 쪽으로 판단하고 응답을 '불완전'으로 표시하세요"라는 지시를 추가하세요.
과거에는 판단 프롬프트에 few-shot 예시를 직접 포함하는 것이 자주 권장되었습니다. 더 새롭고 능력 있는 모델에서는 예시를 더 선택적으로 사용하는 것이 좋을 때가 많습니다 – 여러 입력-출력 쌍으로 프롬프트를 채우기보다 특정하고 잠재적으로 혼란스러운 경우를 설명하는 데 사용하세요.
마지막으로, (non-reasoning) LLM이 최종 라벨만 반환하지 않고 단계별 추론을 수행하도록 장려하는 것이 도움이 됩니다. 본질적으로 최종 답변을 제공하기 전에 chain-of-thought 접근법을 적용하는 것이죠.
이렇게 하면 판단의 품질과 나중에 검토하는 사람들을 위한 결과의 해석 가능성 모두가 향상됩니다.
7. 내 사용 사례에 어떤 메트릭을 선택해야 할까? 🎯
많은 팀들이 LLM 제품의 품질을 평가하기 위해 기성 LLM 평가 메트릭을 요청하며 – 미리 정의된 옵션 목록에서 골라 쓰기를 희망합니다.
하지만 기성 LLM 심판 사용은 신중하게 접근해야 합니다. 다른 사람의 평가 체계를 복사하는 것은 필요한 인사이트를 거의 제공하지 않습니다. 작업이 극도로 표준화되어 있지 않는 한(보편적인 콘텐츠 관리 정책처럼) 완벽하게 맞지 않을 거예요.
또한 모든 기준이 여러분의 사용 사례에 진정으로 관련 있는 것은 아닙니다. 예를 들어, 유창성(fluency)이나 일관성(coherence)은 현대 LLM에서는 거의 문제가 되지 않습니다 – 대부분 이미 매우 다듬어져 있거든요. 이런 메트릭을 적용해도 제품에 대해 별로 알 수 없고, "항상 테스트를 통과"하지만 더 중요한 차원에서는 실패하는 거짓된 안전감을 만들 수 있습니다.
동시에, 더 작은 로컬 모델로 작업한다면 유창성을 확인하는 것이 평가 기준으로 완전히 합리적일 수 있습니다. 하지만 그 경우에도 기성 메트릭을 빌려오기보다 자신만의 유창성 정의를 공식화하거나 조정하는 것이 좋을 때가 많습니다.
궁극적으로, 최고의 평가는 맥락을 인식하고 – 여러분의 제품과 목표에 맞춤화되어야 하며 – 차별적이어서 의미 있는 차이를 강조할 수 있어야 합니다.
의미 있는 맞춤 메트릭을 설계하는 두 가지 방법
1. 상향식(Bottom-up) 접근법
개방형 시스템과 실험적 또는 프로덕션 품질 평가에 가장 일반적인 접근법입니다. 자신의 데이터를 분석하는 것부터 시작하세요 – 실제 출력(테스트나 프로덕션에서)을 수집하고, 수동으로 검토하고, 라벨을 붙이고, 반복되는 실패 유형을 찾습니다. 그런 다음 이 인사이트를 사실적 정확도, 명확성, 톤, 작업 완료 성공 같은 구체적인 기준으로 변환합니다.
노력이 들지만 가장 풍부한 신호를 제공합니다. 종종 예상치 못한 문제들 – 모호한 답변, 환각, 도움이 되지 않는 문구 – 을 발견하고 이를 명확한 평가 기준으로 공식화할 수 있습니다.
여러 메트릭을 사용하더라도 각 심판이 실행된 후 결과를 프로그래밍 방식으로 결합할 수 있습니다. 예를 들어, 핵심 체크 중 하나라도 실패하면(불완전, 부정확, 또는 관련 없음) 응답을 "실패"로 플래그하거나, 긍정적 점수를 합산해 전체 품질 등급을 산출하는 식이죠.
2. 하향식(Top-down) 접근법
작업과 위험에 대한 이해를 바탕으로 논리적으로 체크를 정의하는 것부터 시작합니다.
이 방법은 좁은 예측 작업(검색의 랭킹이나 분류)에 잘 맞습니다. 정확도, 정밀도, 재현율, NDCG 같은 표준 메트릭이 의미 있는 경우죠 – 메트릭을 재발명할 필요 없이 데이터셋만 설계하면 됩니다.
또한 안전이나 적대적 테스트 같은 위험 중심 평가에도 적합합니다. 위험 분석부터 시작하세요: 시스템에서 무엇이 잘못될 수 있나요?
예를 들어, 챗봇이 안전하지 않은 조언을 하거나 경쟁 제품을 추천할 가능성이 있다면, 이런 위험을 조사하기 위한 타겟 테스트 케이스를 설계하고 – 의료 조언을 요청하거나 경쟁사 비교를 하는 것처럼 – 이를 플래그할 특정 평가자(예: 안전 또는 규정 준수 심판)를 붙일 수 있습니다.
요약: 시스템의 목표와 위험에 맞는 메트릭을 선택하거나 설계하세요. 좋은 메트릭은 복사하는 것이 아니라 – 여러분의 제품에서 성공과 실패가 실제로 어떤 모습인지를 반영하도록 구축하는 것입니다.
마치며 💡
LLM-as-a-Judge는 인간 라벨링에 대한 확장 가능한 대안입니다. RAG나 AI 에이전트 같은 복잡한 AI 시스템을 개발한다면, 여러분의 기준과 선호에 맞춘 작업별 평가가 필요합니다.
핵심은 LLM 심판이 "만능 해결책"이 아니라는 점입니다. 각 사용 사례에 맞게 신중하게 설계하고, 인간 판단과 비교해 검증하며, 지속적으로 개선해야 합니다. 평가는 인간의 판단을 대체하는 것이 아니라 확장하는 것이라는 점을 항상 기억하세요.
좋은 평가 시스템을 만드는 것은 결국 여러분의 제품과 데이터를 깊이 이해하는 것에서 시작됩니다. 🚀