LLM-as-a-Judge 평가 방식 완벽 가이드

올해 초 AI 제품에는 평가(evals)가 필요합니다라는 글을 쓴 적이 있습니다. 이후 "LLM-as-a-Judge는 어떻게 시작하면 되나요?"라는 질문을 많이 받았습니다. 이 가이드는 30개 이상의 기업에서 평가 시스템을 구축하며 직접 체득한 노하우를 정리한 것입니다.

문제: 데이터에 파묻히는 AI 팀들

몇 주를 투자해 AI 시스템을 구축했는데, 정작 제대로 작동하는지조차 모르겠다는 경험을 해보신 적 있으신가요? 혼자만의 고민이 아닙니다. LLM으로 AI 출력을 평가할 때 같은 실수를 반복하는 팀을 수없이 봐왔습니다.

1. 지표가 너무 많음: 관리할 수 없을 만큼 많은 측정 항목을 만듦.
2. 자의적인 점수 체계: 여러 차원에 걸쳐 보정 없이 1~5점 같은 척도를 적용. 3점과 4점의 차이가 뭔지 아무도 모르고, 평가자마다 해석이 다름.
3. 도메인 전문가 배제: 해당 분야를 깊이 이해하는 사람을 참여시키지 않음.
4. 검증되지 않은 지표: 사용자나 비즈니스에 실제로 중요한 것을 반영하지 못하는 측정 항목을 사용.

결과는? 신뢰할 수도, 활용할 수도 없는 지표 더미에 파묻혀 진행이 멈춥니다. 모두가 지칩니다.

예를 들어, 아래와 같은 대시보드를 심심치 않게 봅니다:

1~5점 척도로 여러 점수를 추적하고 있다면, 평가 프로세스에 문제가 있다는 신호입니다(이유는 뒤에서 설명합니다). 이 글에서는 이런 함정을 피하는 방법을 알려드리겠습니다. 핵심은 제가 "Critique Shadowing"이라고 부르는 기법입니다. 단계별로 살펴보겠습니다.

1단계: 핵심 도메인 전문가 찾기

대부분의 조직에는 AI 제품의 성패를 좌우하는 핵심 인물이 한두 명 있습니다. 깊은 도메인 전문성을 갖추었거나 타깃 사용자를 대표하는 사람들입니다. 이 핵심 도메인 전문가(Principal Domain Expert)를 초기에 파악하고 참여시키는 것이 매우 중요합니다.

적합한 도메인 전문가를 찾는 것이 왜 중요할까요?

• 기준을 세우는 사람: 이 사람은 기술적으로 허용 가능한 수준을 정의할 뿐 아니라, 실제로 사용자가 원하는 것을 만들고 있는지 판단하는 데 도움을 줍니다.

• 암묵적 기대를 포착: 전문가를 참여시키면 본인도 명확히 표현하지 못했던 선호와 기대가 드러납니다. 평가 과정을 통해 "합격 수준"의 AI 인터랙션이 어떤 모습인지 함께 구체화할 수 있습니다.

• 일관된 판단 기준: 조직 내에서 AI 성능에 대한 의견이 분분할 수 있습니다. 핵심 전문가에 집중하면 가장 중요한 기준에 맞춰 일관된 평가를 할 수 있습니다.

• 주인의식 부여: 전문가가 참여하면 AI 개발에 대한 주인의식이 생깁니다. 직접 만드는 데 기여했기에 투자감을 느끼고, 결과적으로 AI를 승인할 가능성이 높아집니다.

핵심 도메인 전문가의 예시:

• 정신건강 AI 어시스턴트를 위한 심리학자
• 법률 문서 분석 AI를 위한 변호사
• 고객 지원 챗봇을 위한 고객서비스 책임자
• 교육용 AI 도구를 위한 수석 교사 또는 교육과정 개발자

많은 개발자가 스스로 도메인 전문가 역할을 하거나, 편의상 상사 같은 대리인을 세우곤 합니다. 이는 실패의 지름길입니다. 무엇이 합격인지에 대해 사람마다 의견이 다르고, 모두를 만족시킬 수는 없습니다. 중요한 것은 핵심 도메인 전문가가 만족하느냐입니다.

기억하세요: 도메인 전문가의 시간을 많이 빼앗을 필요는 없습니다. 효율적으로 진행하는 방법은 뒤에서 설명하겠습니다. 다만, 전문가의 참여는 AI 성공에 절대적으로 중요합니다.

다음 단계

전문가를 찾았다면, 이제 적절한 데이터를 제공하여 검토받아야 합니다. 다음 단계에서 그 방법을 알아보겠습니다.

2단계: 데이터셋 만들기

핵심 도메인 전문가가 합류했다면, 다음은 AI가 실제로 마주할 문제들을 담은 데이터셋을 구축하는 것입니다. 데이터셋이 다양하고, 프로덕션 환경에서 발생할 인터랙션 유형을 고루 반영하는 것이 중요합니다.

다양한 데이터셋이 중요한 이유

• 포괄적 테스트: 다양한 상황에서 AI를 평가할 수 있습니다.
• 현실적 인터랙션: 실제 사용자 행동을 반영해 평가의 적합성을 높입니다.
• 약점 발견: AI가 취약하거나 오류를 낼 수 있는 영역을 식별합니다.

데이터셋 구조화를 위한 차원(Dimension)

사용 사례에 적합한 차원을 정의해야 합니다. 예를 들어, B2C 애플리케이션에서 제가 자주 사용하는 차원은 다음과 같습니다:

1. 기능(Features): AI 제품의 개별 기능.
2. 시나리오(Scenarios): AI가 마주하여 처리해야 하는 상황이나 문제.
3. 페르소나(Personas): 고유한 특성과 요구를 가진 대표 사용자 프로필.

기능, 시나리오, 페르소나 예시

기능

시나리오

시나리오는 AI가 처리해야 하는 상황을 말합니다(AI 응답의 결과가 아니라 상황 자체에 초점).

페르소나

이 분류 체계가 만능은 아닙니다

이 분류 체계(기능, 시나리오, 페르소나)가 모든 경우에 적용되는 것은 아닙니다. 예를 들어, 사용자가 AI와 직접 상호작용하지 않는 경우라면 페르소나가 무의미할 수 있습니다. 핵심은 자신의 사용 사례에 맞는 차원을 설정하고, 이를 포괄하는 데이터를 생성하는 것입니다. 첫 번째 평가 라운드를 거친 뒤 차원을 다듬어 나가게 될 것입니다.

데이터 생성

데이터셋을 구축하는 방법은 크게 두 가지입니다:

• 기존 데이터 활용: AI 시스템에서 수집된 실제 사용자 인터랙션이나 행동 데이터를 샘플링.
• 합성 데이터 생성: LLM을 활용해 다양한 기능, 시나리오, 페르소나를 아우르는 현실적인 사용자 입력을 생성.

실제로는 포괄적인 커버리지를 확보하기 위해 두 방법을 병행하는 경우가 많습니다. 합성 데이터가 실제 데이터만큼 좋지는 않지만, 좋은 출발점이 됩니다. 또한 LLM은 사용자 입력만 생성하는 데 사용하며, LLM 응답이나 내부 시스템 동작을 생성하는 데 쓰지는 않습니다.

기존 데이터든 합성 데이터든, 앞서 정의한 차원을 고루 커버하는 것이 중요합니다.

시스템 정보 반영

테스트 데이터를 만들 때는 적절한 곳에 API와 데이터베이스를 활용하세요. 이렇게 하면 데이터가 현실적이 되고 의도한 시나리오가 올바르게 트리거됩니다. 때로는 이 정보를 가져오기 위해 간단한 프로그램을 작성해야 할 수도 있습니다. 아래 예시의 "가정(Assumptions)" 컬럼이 바로 이것을 의미합니다.

사용자 입력 생성을 위한 LLM 프롬프트 예시

아래는 기능, 시나리오, 페르소나의 다양한 조합에 대해 LLM으로 합성 사용자 입력을 생성하는 프롬프트 예시입니다:

합성 데이터 생성 절차

합성 데이터를 생성할 때는 사용자 입력만 만들면 됩니다. 이 입력을 AI 시스템에 넣어 AI의 응답을 생성합니다. 이때 모든 것을 로그로 남겨야 평가가 가능합니다. 정리하면 다음과 같습니다:

1. 사용자 입력 생성: LLM 프롬프트를 사용해 현실적인 사용자 입력을 만듭니다.
2. AI 시스템에 입력: 생성된 사용자 인터랙션을 현재 AI 시스템에 넣습니다.
3. AI 응답 수집: AI의 응답을 기록하여 완전한 인터랙션을 구성합니다.
4. 인터랙션 정리: 사용자 입력, AI 응답, 관련 메타데이터를 테이블로 저장합니다.

데이터는 얼마나 생성해야 할까요?

정답은 없습니다. 최소한 각 차원의 조합(이 예시에서는 기능, 시나리오, 페르소나)별로 예시가 있어야 합니다. 그 후에는 새로운 실패 유형이 더 이상 나오지 않을 때까지 계속 생성하면 됩니다. 생성하는 데이터 양은 사용 사례에 따라 크게 달라집니다.

합성 데이터가 정말 효과가 있을까요?

합성 데이터에 회의적일 수도 있습니다. 실제 데이터가 아닌데 좋은 대체재가 될 수 있을까? 경험상, 놀라울 정도로 잘 작동합니다. 제가 좋아하는 AI 제품 중 하나인 Hex도 합성 데이터를 평가에 활용하고 있습니다:

"LLM은 사용자 프롬프트의 우수하고 다양한 예시를 생성하는 데 놀라울 만큼 뛰어납니다. 이는 애플리케이션 기능에 활용할 수 있고, 교묘하게도 평가 구축에도 쓸 수 있습니다. '거대 언어 뱀이 자기 꼬리를 삼키는 것' 같다고요? 저도 처음엔 그만큼 놀랐습니다! 제가 할 수 있는 말은: 실제로 작동하니, 일단 배포하세요." Bryan Bischof, Hex AI 엔지니어링 리드

다음 단계

데이터셋이 준비되었다면, 이제 가장 중요한 단계입니다: 핵심 도메인 전문가에게 인터랙션을 평가받는 것입니다.

3단계: 도메인 전문가에게 비평과 함께 합격/불합격 판정을 받기

도메인 전문가가 집중해야 할 질문은 하나입니다: "AI가 원하는 결과를 달성했는가?" 복잡한 점수 척도나 다수의 지표는 필요 없습니다. 명확한 합격 또는 불합격 판정이면 됩니다. 이 판정과 함께 도메인 전문가는 판단 근거를 설명하는 비평(critique)을 작성해야 합니다.

단순한 합격/불합격 판정이 왜 중요할까요?

• 명확성과 집중: 이진 판정은 진짜 중요한 것이 무엇인지 생각하게 만듭니다. 평가를 단 하나의 핵심 질문으로 단순화합니다.

• 실행 가능한 인사이트: 합격/불합격 판정은 해석하고 대응하기 쉽습니다. AI가 사용자의 요구를 충족하는지 빠르게 파악할 수 있습니다.

• 기대 기준의 명확화: 도메인 전문가가 인터랙션의 합격/불합격을 결정해야 하면, 자신의 기대를 명확하게 표현할 수밖에 없습니다. 이 과정에서 AI가 어떻게 동작해야 하는지에 대한 미묘한 뉘앙스와 암묵적 가정이 드러납니다.

• 리소스의 효율적 활용: 특히 초기 단계에서 평가 프로세스를 관리 가능한 수준으로 유지합니다. 아직 의미를 확보하지 못한 세부 지표에 매몰되는 것을 방지합니다.

비평의 역할

이진 합격/불합격 판정과 함께 LLM 생성 출력에 대한 상세한 비평을 작성하는 것이 중요합니다. 이 비평은 다음과 같은 역할을 합니다:

• 뉘앙스 포착: 비평을 통해 대체로 정확하지만 개선이 필요한 부분을 기록할 수 있습니다.

• 개선 방향 제시: 상세한 피드백이 AI를 어떻게 향상시킬 수 있는지 구체적인 인사이트를 제공합니다.

• 단순함과 깊이의 균형: 합격/불합격이 명확한 판정을 내리는 한편, 비평은 그 판정의 근거를 이해하는 데 필요한 깊이를 제공합니다.

왜 비평을 작성해야 할까요?

실무에서 도메인 전문가가 모든 판단 기준을 완전히 내재화하고 있지는 않습니다. 합격/불합격을 결정하고 그 이유를 설명하도록 하면, 기대 기준이 명확해지고 AI를 개선하는 데 귀중한 지침이 됩니다.

"하지만 우리 문제는 복잡한데요!" 단순하게 시작하면 정말 중요한 것에 집중할 수 있습니다. 필요하다면 나중에 복잡도를 높이면 됩니다.

좋은 비평의 예시

단순한 합격/불합격 판정과 상세한 비평이 실제로 어떻게 작동하는지 보여드리겠습니다. 아래 표는 AI 어시스턴트와의 사용자 인터랙션 예시입니다. 합격과 불합격 사례를 모두 포함하며, AI가 해당 판정을 받은 이유를 비평으로 설명합니다. 심각한 문제가 있음에도 합격한 경우에는 비평에서 해당 사항을 지적하면서 전체적으로 합격인 이유를 명시하고, 불합격인 경우에는 실패의 핵심 요소를 설명합니다.

이 예시들은 AI가 "합격"과 "불합격" 판정을 각각 받는 경우를 보여줍니다. 비평에서는:

• 합격인 경우, 개선이 필요한 중요한 측면이 있더라도 AI가 사용자의 핵심 요구를 충족한 이유를 설명합니다. 개선 영역을 짚어주되 전체적으로 합격인 근거를 명시합니다.

• 불합격인 경우, 실패의 핵심 요인을 식별하고 AI가 사용자의 주요 목적을 달성하지 못했거나 사용자 경험·보안 등 중요한 요소를 해친 이유를 설명합니다.

가장 중요한 것은, 비평이 LLM 심판의 few-shot 프롬프트에 활용할 수 있을 만큼 충분히 상세해야 한다는 점입니다. 즉, 신입사원이 읽어도 이해할 수 있을 정도로 작성해야 합니다. 너무 간결하게 쓰는 것이 흔한 실수입니다.

참고로, 위의 사용자 인터랙션 예시는 간결성을 위해 단순화한 것입니다. 실제로는 도메인 전문가가 판단을 내리기 위해 더 많은 맥락을 제공해야 할 수 있습니다. 이 부분은 뒤에서 더 다루겠습니다.

초기에는 이진 합격/불합격 판정에서 벗어나지 마세요

흔한 실수 중 하나가 이진 합격/불합격 판정에서 벗어나는 것입니다. 앞서 본 대시보드를 다시 살펴봅시다:

평가가 LLM이 1~5점(또는 다른 척도)으로 매기는 다수의 지표로 구성되어 있다면, 잘못된 방향으로 가고 있는 것입니다. 그 이유를 살펴보겠습니다.

1. 실행으로 이어지지 않음: 3점이나 4점을 받아도 어떻게 해야 할지 알 수 없습니다. 이 점수가 2점보다 왜 나은지 바로 와닿지 않습니다. "이 인터랙션은 ~때문에 합격했다", "이 인터랙션은 ~때문에 불합격했다"라고 말할 수 있어야 합니다.
2. 대부분의 경우, 이런 지표는 실제로 중요하지 않습니다. 도메인 전문가의 판정 데이터를 분석해보면, 이러한 종류의 지표와 상관관계가 없는 경우가 대부분입니다. 도메인 전문가에게 이진 판정을 맡기면 진짜 중요한 것이 무엇인지 알아낼 수 있습니다.

이것이 많은 평가 프레임워크에 기본 탑재된 범용 지표를 싫어하는 이유입니다. 사람들을 잘못된 방향으로 이끄는 경우가 많습니다.

합격/불합격 판정에 대한 흔한 반론:

• "경영진이 이 8개 차원이 중요하다고 해서 전부 평가해야 합니다."
• "인터랙션이 왜 합격이고 왜 불합격인지 설명할 수 있어야 합니다."

8가지를 1~5점으로 측정해야 한다고 주장하는 사람은 자신이 무엇을 찾고 있는지 모르고 있다고 장담할 수 있습니다. 그저 추측일 뿐입니다. 도메인 전문가가 주도하여 비평과 함께 합격/불합격 판정을 내리도록 해야 진짜 중요한 것을 파악할 수 있습니다. 여기서는 소신을 지키세요.

도메인 전문가가 쉽게 데이터를 검토할 수 있게 하세요

마지막으로, 데이터 검토 과정의 모든 마찰을 제거해야 합니다. 이에 대해 이전에 쓴 글이 있습니다. 때로는 스프레드시트만으로 충분합니다. 도메인 전문가에게 가장 편한 방식이 무엇인지 판단해야 합니다. 경험상, 사용자 인터랙션을 이해하는 데 도움이 되는 추가 컨텍스트를 자주 제공해야 했습니다:

• 위치, 구독 등급 등 사용자 메타데이터
• 현재 시각, 재고 수준 등 시스템 관련 추가 컨텍스트
• AI 응답의 정확성을 확인할 수 있는 리소스(예: 데이터베이스 검색 기능 등)

이 모든 데이터를 한 화면에 표시하여 도메인 전문가가 번거로움 없이 검토할 수 있어야 합니다. 그래서 데이터 검토용 간단한 웹 앱을 만드는 것을 추천합니다.

예시는 몇 개나 필요할까요?

필요한 예시 수는 과제의 복잡도에 따라 다릅니다. 제 경험칙은 약 30개부터 시작하여, 새로운 실패 유형이 더 이상 나오지 않을 때까지 계속하는 것입니다. 그 이후에는 새로운 인사이트가 나오지 않을 때까지 진행합니다.

다음으로, 이 데이터를 활용해 LLM 심판을 구축하는 방법을 알아보겠습니다.

4단계: 오류 수정

데이터를 살펴보면 AI 시스템에서 오류를 발견할 가능성이 높습니다. LLM 심판 구축에 바로 뛰어들기보다, 먼저 명백한 오류를 수정하세요. LLM-as-a-Judge의 목적 자체가 이런 오류를 찾는 것이므로, 미리 발견하는 것은 전혀 문제가 없습니다!

이전 글에서 설명한 Level 1 평가를 이미 구축했다면 광범위한 오류는 없어야 합니다. 하지만 가끔 빠져나가는 오류가 있을 수 있습니다. 광범위한 오류를 발견하면 수정한 뒤 3단계로 돌아가세요. 시스템이 안정되었다고 느낄 때까지 반복합니다.

5단계: LLM 심판을 반복적으로 구축하기

비평의 숨겨진 힘

데이터를 보기 전에 좋은 심판 프롬프트를 작성할 수는 없습니다. Shankar 등의 논문 "Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences"에서 이를 잘 요약하고 있습니다:

출력을 채점하려면 평가 기준을 외재화하고 정의해야 하지만, 채점하는 과정 자체가 그 기준을 정의하는 데 도움을 줍니다. 우리는 이를 기준 변동(criteria drift)이라 부르며, 이는 사람이 LLM 출력을 직접 평가하기 전에 평가 기준을 완전히 확정하는 것이 불가능함을 시사합니다.

전문가 예시로 시작하기

실제 LLM 심판 구축 사례를 공유하겠습니다. Honeycomb의 Query Assistant 기능 구축을 도울 때, AI가 좋은 쿼리를 생성하는지 평가할 방법이 필요했습니다. 아래는 도메인 전문가 Phillip의 비평을 few-shot 예시로 포함한 LLM 심판 프롬프트입니다:

You are a Honeycomb query evaluator with advanced capabilities to judge if a query is good or not.
You understand the nuances of the Honeycomb query language, including what is likely to be
most useful from an analytics perspective. 

Here is information about the Honeycomb query language:
{{query_language_info}}

Here are some guidelines for evaluating queries:
{{guidelines}}

Example evaluations:

<examples>

<example-1>
<nlq>show me traces where ip is 10.0.2.90</nlq>
<query>
{
  "breakdowns": ["trace.trace_id"],
  "calculations": [{"op": "COUNT"}],
  "filters": [{"column": "net.host.ip", "op": "=", "value": "10.0.2.90"}]
}
</query>
<critique>
{
  "critique": "The query correctly filters for traces with an IP address of 10.0.2.90 
   and counts the occurrences of those traces, grouped by trace.trace_id. The response 
   is good as it meets the requirement of showing traces from a specific IP address 
   without additional complexities.",
  "outcome": "good"
}
</critique>
</example-1>

<example-2>
<nlq>show me slowest trace</nlq>
<query>
{
  "calculations": [{"column": "duration_ms", "op": "MAX"}],
  "orders": [{"column": "duration_ms", "op": "MAX", "order": "descending"}],
  "limit": 1
}
</query>
<critique>
{
  "critique": "While the query attempts to find the slowest trace using MAX(duration_ms) 
   and ordering correctly, it fails to group by trace.trace_id. Without this grouping, 
   the query only shows the MAX(duration_ms) measurement over time, not the actual 
   slowest trace.",
  "outcome": "bad"
}
</critique>
</example-2>

<example-3>
<nlq>count window-hash where window-hash exists per hour</nlq>
<query>
{
  "breakdowns": ["window-hash"],
  "calculations": [{"op": "COUNT"}],
  "filters": [{"column": "window-hash", "op": "exists"}],
  "time_range": 3600
}
</query>
<critique>
{
  "critique": "While the query correctly counts window-hash occurrences, the time_range 
   of 3600 seconds (1 hour) is insufficient for per-hour analysis. When we say 'per hour', 
   we need a time_range of at least 36000 seconds to show meaningful hourly patterns.",
  "outcome": "bad"
}
</critique>
</example-3>

</examples>

For the following query, first write a detailed critique explaining your reasoning,
then provide a pass/fail judgment in the same format as above.

<nlq>{{user_input}}</nlq>
<query>
{{generated_query}}
</query>
<critique>

각 예시에 포함된 내용을 살펴보면:

1. <nlq> 태그 안의 자연어 쿼리(NLQ)
2. <query> 태그 안의 생성된 쿼리
3. <critique> 태그 안의 비평과 판정 결과

위 프롬프트에서는 예시 비평이 고정되어 있습니다. 심화 방법으로, 평가 대상 항목에 따라 예시를 동적으로 포함시킬 수도 있습니다. 자세한 내용은 Continual In-Context Learning에 관한 이 글을 참고하세요.

도메인 전문가와 수렴할 때까지 프롬프트를 반복 개선

이 사례에서는 로우테크 방식으로 프롬프트를 반복 개선했습니다. Phillip에게 다음 정보가 담긴 스프레드시트를 보냈습니다:

1. NLQ
2. 생성된 쿼리
3. 비평
4. 판정 결과(합격 또는 불합격)

Phillip은 자신의 비평을 담은 스프레드시트를 별도로 작성했습니다. 이를 바탕으로 프롬프트를 반복 개선했습니다. 스프레드시트는 다음과 같았습니다:

시간에 따른 일치율도 추적하여 프롬프트가 올바른 방향으로 수렴하고 있는지 확인했습니다.

단 세 번의 반복으로 LLM과 Phillip 사이에 90% 이상의 일치율을 달성했습니다. 물론 과제의 복잡도에 따라 결과는 다를 수 있습니다. 예를 들어, Swyx는 유사한 과정을 수백 번 수행했는데, 이는 고품질 추천으로 큰 인기를 얻고 있는 뉴스 큐레이션 서비스 AI News를 위한 것이었습니다. 이 과정을 통해 확보한 AI 품질 덕분에 이 제품은 많은 호평을 받았습니다.

LLM 심판 프롬프트를 최적화하는 방법

저는 보통 프롬프트를 수동으로 조정합니다. DSPy 같은 프롬프트 최적화 도구에서는 좋은 결과를 얻지 못했습니다. 하지만 지인인 Eugene Yan이 최근 ALIGN Eval이라는 유망한 도구를 출시했습니다. 단순하면서 효과적이라 마음에 듭니다. 또한 앞서 언급한 Continual In-Context Learning 방식도 올바르게 적용하면 효과적입니다.

드물게 심판을 파인튜닝하기도 하지만, 선호하는 방법은 아닙니다. 이에 대해서는 FAQ 섹션에서 더 다루겠습니다.

프로세스의 인간적 측면

이 과정에서 예상치 못한 일이 일어났습니다. Honeycomb의 도메인 전문가 Phillip Carter는 LLM의 비평을 검토하면서 자신의 평가 기준을 더 명확하게 정리할 수 있었다고 합니다.

"LLM이 추론을 분해하는 방식을 보면서, 내가 특정 엣지 케이스를 평가할 때 일관성이 없었다는 것을 깨달았습니다."

이것은 반복적으로 관찰되는 패턴입니다. LLM 심판을 구축하는 과정 자체가 평가 기준을 표준화하는 데 도움이 됩니다.

더 나아가, 이 과정이 도메인 전문가에게 데이터를 꼼꼼히 살펴보도록 강제하기 때문에, 항상 제품, AI 역량, 사용자 요구에 대한 새로운 인사이트를 발견하게 됩니다. 이렇게 얻는 부수적 효과가 LLM 심판 자체를 만드는 것보다 더 가치 있는 경우가 많습니다!

평가는 얼마나 자주 해야 할까요?

정기적으로, 그리고 중요한 변경이 있을 때마다 이 인간 검토를 수행합니다. 예를 들어, 모델을 업데이트하면 다시 진행합니다. 지나치게 과학적으로 접근하지는 않고, 최선의 판단에 의존합니다. 또한 처음 두 번의 반복 이후에는 무작위 샘플링보다 오류에 집중하는 편입니다. 예를 들어, 오류를 발견하면 같은 오류를 유발할 것 같은 예시를 더 찾아봅니다. 물론 무작위 샘플링도 항상 병행합니다.

이 방법이 효과가 없다면?

이 과정이 실패하는 경우를 봤습니다:

• AI 범위가 과도한 경우: 예 - SaaS 제품에서 "무엇이든 해줄게요"를 약속하는 챗봇.
• 프로세스를 올바르게 따르지 않은 경우: 핵심 도메인 전문가를 참여시키지 않거나, 제대로 된 비평을 작성하지 않는 등.
• 정렬 기대치가 비현실적이거나 달성 불가능한 경우.

이 각각의 경우에, 억지로 정렬을 시도하기보다 근본 원인을 해결하려고 합니다. 때로는 원하는 수준의 정렬을 달성하지 못해 사람 어노테이션에 더 의존해야 할 수도 있습니다. 하지만 여기서 설명한 프로세스를 따르고 나면, LLM 심판을 얼마나 신뢰할 수 있는지 이해하는 데 도움이 되는 지표를 갖게 됩니다.

LLM 심판 프롬프트에서 흔히 보는 실수

제가 본 LLM 심판 프롬프트의 실수는 대부분 좋은 예시를 제공하지 않는 것과 관련됩니다:

1. 비평을 아예 포함하지 않음.
2. 지나치게 간결한 비평을 작성.
3. 외부 컨텍스트를 포함하지 않음. 예시에는 사용자 메타데이터, 시스템 정보 등 실제 평가에 사용하는 것과 동일한 정보가 포함되어야 합니다.
4. 예시의 다양성 부족. 심판이 다양한 입력에서 제대로 작동하려면 충분히 다양한 예시가 필요합니다.

때로는 필요한 모든 것을 프롬프트에 넣기 어려워 예시 구성에 창의적인 접근이 필요할 수 있습니다. 하지만 컨텍스트 윈도우의 확장과 프롬프트 캐싱 덕분에 이 문제는 점점 줄어들고 있습니다.

6단계: 오류 분석 수행

LLM 심판을 만들었다면, 사용자-AI 인터랙션 데이터와 LLM의 판정 결과를 확보한 상태입니다. 도메인 전문가와 LLM 심판 간의 일치율이 허용 가능한 수준이라면, 이 심판을 실제 또는 합성 인터랙션에 적용할 수 있습니다. 이후 데이터의 다양한 차원별로 오류율을 계산합니다. 편향된 결과를 방지하기 위해 반드시 학습에 사용하지 않은 새로운 데이터로 오류를 측정해야 합니다.

예를 들어, 데이터를 페르소나, 시나리오, 기능 등으로 세분화했다면, 분석 결과는 다음과 같을 수 있습니다:

주요 차원별 오류율

트레이스 분류

오류가 어디에 있는지 파악했으면, 이제 오류 분석을 통해 근본 원인을 찾을 차례입니다. 제가 선호하는 방법은 각 유형의 오류 예시를 직접 살펴보며 수작업으로 분류하는 것입니다. 스프레드시트를 활용하는 것을 추천합니다. 예를 들어, "주문 추적 > 결과 없음 > 신규 사용자" 조합의 트레이스는 다음과 같을 수 있습니다:

{
 "user_input": "Where's my order #ABC123?",
 "function_calls": [
   {
     "name": "search_order_database",
     "args": {"order_id": "ABC123"},
     "result": {
       "status": "not_found",
       "valid_patterns": ["XXX-XXX-XXX"]
     }
   },
   {
     "name": "retrieve_context",
     "result": {
       "relevant_docs": [
         "Order numbers follow format XXX-XXX-XXX",
         "New users should check confirmation email"
       ]
     }
   }
 ],
 "llm_intermediate_steps": [
   {
     "thought": "User is new and order format is invalid",
     "action": "Generate help message with format info"
   }
 ],
 "final_response": "I cannot find that order #. Please check the number and try again."
}

이 경우, 오류를 다음과 같이 분류할 수 있습니다: Missing User Education. 시스템이 신규 사용자 컨텍스트와 형식 정보를 가져왔지만 응답에 포함시키지 못했으므로, 프롬프트를 개선할 여지가 있음을 시사합니다. 일정 수의 오류를 분류한 후에는 근본 원인별 오류 분포를 계산할 수 있습니다. 결과는 다음과 같을 수 있습니다:

근본 원인 분포 (실패 인터랙션 20건)

이제 어디에 노력을 집중해야 하는지 알 수 있습니다. 이 작업에 엄청난 시간이 들지 않습니다. 15분이면 상당히 많은 것을 파악할 수 있습니다. 또한 LLM을 활용해 이 분류를 도울 수도 있지만, 이는 이 글의 범위를 벗어납니다(결과를 검증하는 프로세스만 갖추면, 이 글에서 다루는 모든 과정에 LLM을 활용할 수 있습니다).

오류 분석 인터랙티브 워크스루

오류 분석은 머신러닝에서 오래전부터 사용되어 온 기법입니다. Andrew Ng의 이 영상에서 전체 과정을 인터랙티브하게 잘 설명하고 있습니다:

다시 오류 수정

오류를 파악했으면 다시 수정에 들어갑니다. 3단계로 돌아가 만족할 때까지 반복하세요. 오류를 수정할 때마다 해당 오류에 대한 테스트 케이스를 작성하는 것이 좋습니다. 테스트 스위트의 단정문(assertion)으로 처리할 수 있는 경우도 있고, 특정 실패에 대한 더 "전문화된" LLM 심판이 필요한 경우도 있습니다. 이 부분은 다음에 다루겠습니다.

이 과정을 잘하려면 데이터 리터러시가 필요합니다

데이터를 조사하는 것은 이 글에서 보여드린 것보다 실제로 훨씬 어렵습니다. 실전 경험을 통해서만 기를 수 있는 데이터 감각이 필요합니다. 통계와 데이터 분석 도구에 대한 기본적인 이해도 도움이 됩니다. 데이터 리터러시에 관한 글 중 가장 추천하는 것은 Jason Liu와 Eugene Yan의 이 글입니다.

7단계: 더 전문화된 LLM 심판 만들기 (필요 시)

AI의 문제점을 파악했다면, 더 타깃팅된 LLM 심판에 투자할 곳과 필요성을 결정할 수 있습니다. 예를 들어, AI가 출처 인용을 제대로 못하는 것을 발견했다면 이에 특화된 평가를 만들 수 있습니다. 일부 오류는 LLM 심판 없이 코드 기반 단정문만으로 처리할 수도 있습니다.

핵심은, Critique Shadowing 과정을 거치기 전에 전문 LLM 심판부터 도입하지 말라는 것입니다. 이 과정을 통해 어디에 시간을 투자해야 하는지 합리적으로 판단할 수 있습니다.

Critique Shadowing 요약

LLM-as-a-Judge를 올바르게 활용하면 AI 평가 프로세스를 효율화할 수 있습니다. 아래는 전체 과정의 시각적 표현입니다(다이어그램 아래에 프로세스 설명도 있습니다):

graph TB
    A[Start] --> B[1 Find Principal Domain Expert]
    B --> C[2 Create Dataset]
    C --> D[3 Domain Expert Reviews Data]
    D --> E{Found Errors?}
    E -->|Yes| F[4 Fix Errors]
    F --> D
    E -->|No| G[5 Build LLM Judge]
    G --> H[Test Against Domain Expert]
    H --> I{Acceptable Agreement?}
    I -->|No| J[Refine Prompt]
    J --> H
    I -->|Yes| K[6 Perform Error Analysis]
    K --> L{Critical Issues Found?}
    L -->|Yes| M[7 Fix Issues & Create Specialized Judges]
    M --> D
    L -->|No| N[Material Changes or Periodic Review?]
    N -->|Yes| C

Critique Shadowing 프로세스는 피드백 루프를 가진 반복적 과정입니다. 단계별로 정리하면 다음과 같습니다:

1. 핵심 도메인 전문가 찾기
2. 데이터셋 만들기
   • 사용 사례를 커버하는 다양한 예시 생성
   • 실제 또는 합성 사용자 인터랙션 포함
3. 도메인 전문가의 데이터 검토
   • 전문가가 합격/불합격 판정
   • 전문가가 판단 근거를 설명하는 상세 비평 작성
4. 오류 수정 (발견 시)
   • 검토 과정에서 발견된 문제 해결
   • 수정 사항을 전문가 검토로 검증
   • 오류가 발견되면 3단계로 복귀
5. LLM 심판 구축
   • 전문가 예시를 활용한 프롬프트 작성
   • 전문가 판정과 비교 테스트
   • 일치율이 만족할 만한 수준이 될 때까지 프롬프트 개선
6. 오류 분석 수행
   • 다양한 차원별 오류율 계산
   • 패턴 및 근본 원인 식별
   • 오류 수정 후 필요하면 3단계로 복귀
   • 필요 시 전문 심판 생성

이 프로세스는 영원히 끝나지 않습니다. 정기적으로, 또는 중요한 변경이 있을 때마다 반복됩니다.

결국, 가치를 만든 것은 심판이 아니었습니다

이 프로세스의 진짜 가치는 데이터를 직접 들여다보고 꼼꼼히 분석하는 것에 있습니다. AI 심판이 유용한 도구이긴 하지만, 결과를 이끌어내는 것은 이 과정 자체입니다. 솔직히 말하면, LLM 심판 만들기는 사람들이 자기 데이터를 꼼꼼히 살펴보게 만드는 일종의 "트릭"이라고 할 수 있습니다!

맞습니다. 진짜 비즈니스 가치는 데이터를 직접 보는 데서 나옵니다. 뭐, 결과가 좋으면 된 거죠.

정말 이게 다 필요한가요?

와, 정말 할 일이 많아 보이죠! 이게 다 필요할까요? 상황에 따라 다릅니다. 이 과정을 축약할 수 있는 경우도 있습니다. 예를 들어:

1. 본인이 도메인 전문가인 개인 개발자인 경우.
2. 이미 사용할 수 있는 테스트 데이터가 있는 경우 (트윗 등).
3. 데이터를 살펴보는 비용이 크지 않은 경우 (몇 시간이면 충분히 수동 검토 가능).

이런 상황에서는 바로 3단계와 유사한 방식으로 데이터를 살펴보기 시작하면 됩니다. 또한 데이터를 보는 비용이 크지 않으므로, 처음에는 심판 없이 오류 분석만 해도 충분할 수 있습니다. 학습한 내용을 주요 모델에 바로 반영할 수 있습니다. 이 예시가 전부는 아니지만, 자신의 상황에 맞게 프로세스를 적용하는 방법에 대한 감을 잡는 데 도움이 될 것입니다.

하지만 데이터를 직접 보는 과정을 완전히 생략해서는 안 됩니다! 이것이야말로 대부분의 사람들이 건너뛰는 바로 그 단계입니다. 그런 사람이 되지 마세요.

FAQ

이 주제에 대해 많은 질문을 받았습니다. 가장 자주 받는 질문에 대한 답변을 정리했습니다:

좋은 심판 LLM이 있으면, 그걸 실제 서비스에도 쓰면 되는 거 아닌가요?

효과적인 심판은 평가 대상보다 더 큰 모델이나 더 많은 연산(긴 프롬프트, 체인 오브 소트(chain-of-thought) 등)을 사용하는 경우가 많습니다.

하지만 가장 강력한 LLM의 비용이 부담이 되지 않고 지연 시간도 문제가 없다면, 노력을 투자하는 방향을 다르게 고려할 수 있습니다. 이 경우 전문 LLM 심판, 코드 기반 단정문, A/B 테스트에 더 집중하는 것이 합리적일 수 있습니다. 다만 전문 심판을 도입하기 전에, 데이터를 살펴보고 LLM 출력을 비평하는 과정은 반드시 거쳐야 합니다.

심판 모델을 파인튜닝하는 것을 추천하나요?

LLM 심판을 파인튜닝하는 것은 선호하지 않습니다. 그 노력이라면 차라리 실제 서비스 LLM을 파인튜닝하는 데 쓰겠습니다. 다만 가드레일이나 기타 특수 심판의 파인튜닝은 유용할 수 있습니다(특히 소형 분류기인 경우).

관련하여, LLM 심판을 활용해 주요 모델의 파인튜닝 데이터를 큐레이션하고 변환할 수도 있습니다. 예를 들어 심판을 다음과 같이 활용할 수 있습니다:

• 파인튜닝에 부적합한 예시 제거.
• 비평을 참고하여 더 높은 품질의 출력 생성.
• 비평을 활용한 고품질 체인 오브 소트 시뮬레이션.

LLM 심판을 파인튜닝 데이터 향상에 활용하는 것은 대형 LLM을 소형 모델로 증류(distill)할 때 특히 매력적입니다. 파인튜닝에 대한 자세한 내용은 이 리소스를 참고하세요.

범용 LLM 심판의 문제점은 무엇인가요?

엄밀히 잘못된 것은 없습니다. 다만 많은 사람들이 이에 현혹되는 것이 문제입니다. 규율 있게 접근하면 자신의 데이터에 적용하여 의미 있는 정보를 제공하는지 확인할 수 있습니다. 하지만 경험상 이런 도구들은 가치보다 혼란을 초래하는 경우가 더 많았습니다.

LLM 심판을 어떻게 평가하나요?

도메인 전문가와 LLM 심판 간의 일치율 지표를 수집합니다. 이를 통해 심판을 얼마나, 어떤 시나리오에서 신뢰할 수 있는지 알 수 있습니다. 도메인 전문가가 모든 예시를 검토할 필요는 없습니다. 신뢰할 수 있는 통계를 확보할 정도의 대표 샘플이면 충분합니다.

LLM 심판에 어떤 모델을 사용하나요?

이 글에서 설명한 유형의 심판에는 비용/지연 시간 예산 내에서 가장 강력한 모델을 사용합니다. 이 예산은 채점해야 할 예시 수에 따라 주요 모델과 다를 수 있으며, 사용 사례에 따라 크게 달라집니다.

가드레일은 어떤가요?

가드레일은 별도이지만 관련 있는 주제입니다. LLM이 유해하거나 부적절한 말/행동을 하지 못하도록 방지하는 수단입니다. 이 글은 특히 초기 단계에서 비즈니스 목표에 부합하는 심판을 만드는 것에 초점을 맞추고 있습니다.

이 방식을 따르지 않았는데도 LLM-as-a-Judge로 큰 가치를 얻고 있습니다.

충분히 가능한 이야기입니다. 이 글이 LLM-as-a-Judge를 사용하는 유일한 방법은 아닙니다. 실제로 랭킹, 분류, 모델 선택 등 다양한 창의적 방식으로 활용하는 사례를 봤습니다. 이 글은 처음 시작할 때 효과적이고, 지표 난립의 함정을 피할 수 있는 방법에 초점을 맞추고 있습니다. 다만 어떤 종류의 심판을 만들든, 데이터를 직접 살펴보는 과정은 항상 핵심입니다.

전통적 ML 기법, LLM-as-a-Judge, 사람 어노테이션 중 어떻게 선택하나요?

이 질문(그리고 다른 많은 질문)에 대한 답은: 가장 단순하면서 작동하는 방법을 선택하는 것입니다. 단순하다는 것이 항상 전통적 ML 기법을 의미하지는 않습니다. 상황에 따라 모델을 훈련·배포하는 것보다 LLM API를 분류기로 사용하는 것이 더 쉬울 수 있습니다.

소형 모델로도 심판을 만들 수 있나요?

가능합니다. 다만 저는 대형 모델만 심판에 사용해왔습니다. 이 질문의 답은 데이터(즉, 도메인 전문가와의 일치율)를 기반으로 판단해야 합니다.

LLM 모델을 업데이트할 때 일관성은 어떻게 보장하나요?

프로세스를 다시 진행하고 결과를 측정해야 합니다.

확장을 위해 사람의 개입을 어떻게 줄이나요?

도메인 전문가가 모든 예시를 채점할 필요는 없습니다. 대표 샘플이면 충분합니다. 사람을 완전히 배제할 수는 없다고 봅니다. LLM은 여전히 무언가에 정렬되어야 하며, 그 대상은 보통 사람이기 때문입니다. 평가 시스템이 정교해질수록 자연스럽게 필요한 인간 노력은 줄어듭니다.

참고 자료

이 주제를 더 깊이 학습하는 데 추천하는 자료입니다:

• Your AI Product Needs Evals: 이 글의 전편으로, LLM 기반 제품의 평가에 대한 전반적인 개요를 제공합니다.
• Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences: Shreya Shankar 등의 논문으로, LLM 평가의 어려움과 올바른 프로세스의 중요성을 잘 다루고 있습니다.
• Align Eval: Eugene Yan이 만든 도구로, 올바른 프로세스를 따라 LLM 심판을 구축할 수 있도록 도와줍니다. 함께 작성된 블로그 글도 읽어보세요.
• Evaluating the Effectiveness of LLM-Evaluators (aka LLM-as-Judge): Eugene Yan이 작성한 글로, LLM 심판의 다양한 사용 사례와 접근 방식을 훌륭하게 정리했습니다.
• Enhancing LLM-As-A-Judge with Grading Notes: Yi Liu 등의 연구로, 이 글과 매우 유사한 접근 방식을 설명하며 비평(저자들은 grading notes라 부릅니다)의 효용에 대한 또 다른 관점을 제시합니다.
• Custom LLM as a Judge to Detect Hallucinations with Braintrust: Ankur Goyal과 Shaymal Anadkt가 LLM 심판 구축의 전 과정을 보여주는 글로, 해당 사용 사례에서 분류 방식이 숫자 점수보다 더 신뢰할 수 있음을 발견했습니다(이 글의 주장과 일치).
• Techniques for Self-Improving LLM Evals: Arize의 Eric Xiao가 LLM 평가 구축에 대한 깔끔한 접근 방식과 함께 살펴볼 만한 추가 도구를 소개합니다.
• How Dosu Used LangSmith to Achieve a 30% Accuracy Improvement with No Prompt Engineering: Langchain이 동적 예시를 활용한 LLM 프롬프트 구축 방법을 소개하는 글입니다. 아이디어는 단순하지만 효과적입니다. 저도 LLM 심판을 포함한 제 사용 사례에 이를 적용하고 있습니다. 영상 워크스루도 있습니다.
• What We've Learned From A Year of Building with LLMs: LLM 활용 개발의 다양한 실전 측면을 다루며, 평가의 중요성을 강조하는 훌륭한 종합 글입니다.

소식 받기

LLM에 대해 계속 배우고 있으며, 그 과정에서 얻은 인사이트를 공유하는 것을 즐깁니다. 이 여정에 관심이 있으시다면 구독을 고려해 주세요.

구독하시면:

• LLM에 대한 최신 인사이트를 비정기적으로 이메일로 전달
• 새로운 콘텐츠 조기 접근
• 스팸 없이, 솔직한 생각과 발견만 공유