기본 평가 모델 설정 (1부)

기본 평가 모델을 사용하여 주관적 평가를 실행합니다.

Maud Nalpas

규칙 기반 평가를 통해 결정론적 답변을 확인할 수 있습니다. 주관적인 품질을 평가하려면 LLM을 평가자로 사용하는 기법을 사용하세요.

이 모듈에서는 직접 또는 팀과 함께 데이터를 라벨링하고 기본 통계 측정항목을 사용하여 첫 번째 심사자를 빌드하는 방법을 알아봅니다.

첫 번째 평가 모델을 빌드하는 단계

모델 맞춤설정 방법 선택 미세 조정 또는 프롬프트 엔지니어링을 결정합니다.
모델을 선택합니다. 파운데이션 모델 또는 도메인 전문 지식이 없는 다른 LLM일 수 있습니다.
점수 부여 방법을 선택합니다. 심사위원이 ThemeBuilder에서 생성된 테마를 평가할 때 이진 또는 숫자 척도를 사용해야 하는지 확인합니다.
평가자 구성 모델의 설정 (예: 온도, 구조화된 출력)을 수정하여 판단 작업에 적합하게 만듭니다.
초기 프롬프트를 작성합니다. 점수 기준표와 예시를 포함하여 심사 시스템 안내와 프롬프트의 첫 번째 버전을 설계합니다.
정렬 데이터 세트 만들기 다양하고 고품질의 ThemeBuilder 출력(좋은 모토, 유해한 모토, 브랜드에 맞지 않는 색상 팔레트 등)을 만들거나 모아 '좋은 모토', '유해한 모토', '브랜드에 맞지 않는 색상 팔레트'와 같이 라벨을 지정합니다.
평가 모델을 정렬하고 테스트합니다. 정렬 데이터 세트를 사용하여 심판 프롬프트 (시스템 안내 및 기본 프롬프트)를 반복적으로 개선합니다. 심판의 평결이 사람의 평결과 일치할 때까지 이 과정을 반복합니다. 마지막으로 심판을 테스트하여 신뢰할 수 있고 새로운 입력에 대한 접근 방식을 일반화할 수 있는지 확인합니다.

평가 모델에는 LLM, 설정, 시스템 프롬프트, 채점 프롬프트가 있습니다.

맞춤설정 방법 선택

대부분의 파운데이션 모델은 범용입니다. 평가 모델은 도메인 전문가처럼 생각해야 합니다.

평가 모델을 만드는 주요 옵션은 다음과 같습니다.

LLM을 프롬프트 엔지니어링합니다.
모델을 미세 조정합니다.
평가에 최적화된 미세 조정된 LLM(예: JudgeLM)을 사용합니다. 이 옵션을 사용하려면 맞춤 모델 가중치를 직접 호스팅하거나 오픈소스 모델 호스팅을 지원하는 클라우드 제공업체를 사용해야 합니다.

이 과정의 ThemeBuilder 평가에는 프롬프트 엔지니어링을 사용하는 것이 좋습니다. 프롬프트 엔지니어링은 대안보다 개발 노력이 적으면서도 우수한 결과를 제공할 수 있습니다.

모델 선택

평가 모델을 선택할 때는 강력한 추론 기능을 갖춘 모델을 선택하세요. CI/CD 파이프라인에서 평가를 실행하므로 속도와 비용도 중요합니다.

다양한 모델과 기법을 실험하여 가장 적합한 방법을 찾으세요.

더 크고 강력한 모델로 시작하여 높은 기준을 설정한 다음 더 작은 모델로 점진적으로 축소합니다. 또는 그 반대일 수도 있습니다.
다양한 조합: 일일 PR 검사에는 빠르고 비용 효율적인 모델을 사용하고 최종 출시 테스트에는 더 강력한 모델을 사용하세요. 또는 일반 LLM을 유해성 감지와 같은 특정 작업을 위한 작고 전문화된 모델과 결합하여 속도를 높일 수 있습니다.

이 과정에서는 Gemini 3 Flash를 평가 모델로 사용합니다. Gemini 3 Flash는 ThemeBuilder 출력 평가라는 예시 사용 사례에 필요한 속도와 추론 깊이를 제공합니다. 하지만 이 과정의 패턴은 선택한 모든 모델에 적용할 수 있습니다.

점수 부여 방법 선택

주관적인 출력에는 바이너리 PASS 및 FAIL 라벨을 사용하거나 숫자 점수를 사용할 수 있습니다(예: '1~5점 척도로 이 모토가 브랜드에 얼마나 잘 부합하나요?').

이진 라벨을 사용하는 것이 좋습니다.

평가 기준	평가 방법	측정항목
모토가 브랜드, 잠재고객, 어조와 일치함	LLM 평가	`PASS` 또는 `FAIL` 라벨
색상 팔레트가 브랜드, 대상, 어조와 일치함	LLM 평가	`PASS` 또는 `FAIL` 라벨
모토가 악성 댓글이 아님	LLM 평가	`PASS` 또는 `FAIL` 라벨

숫자 점수 (1~10)가 직관적으로 느껴질 수 있지만 연구에 따르면 LLM (및 사람)은 점수를 중간에 모으거나 예의를 갖추기 위해 점수를 부풀리는 경향이 있습니다. PASS 및 FAIL과 같은 카테고리 또는 이진 라벨은 모델이 명확한 결정을 내리도록 강제하므로 더 나은 결과를 얻을 수 있는 경우가 많습니다. 사람의 경우 이를 평가자 효과라고 합니다.

평가자 구성

심사위원이 일관되고 구조화된 출력을 만들 수 있도록 매개변수와 지침을 사용하세요.

시스템 요청 사항 설정: 심사자에게 엄격한 전문가 페르소나를 부여합니다.
온도 또는 사고 수준 설정: 심판은 일관성을 유지해야 합니다. 논리적 단계 사이를 이동하는 데 약간의 무작위성이 필요한 Gemini Flash와 같은 추론 모델을 사용하는 경우 온도를 기본값으로 유지하되 thinking_level을 HIGH로 설정합니다. 다른 모델을 사용하는 경우 온도를 0 또는 0에 가까운 값으로 설정합니다. 어떤 경우든 연쇄 사고 기법을 사용하여 모델이 판단을 내리기 전에 생각하도록 합니다.
심사위원의 출력 구조화: 예측 가능한 JSON 객체는 나머지 코드베이스에서 재사용하기가 훨씬 쉽습니다. label (PASS 또는 FAIL) 및 rationale 문자열이 필요한 EvalResult 스키마를 사용합니다.

ThemeBuilder 예시에서 다음을 실행합니다.

평가 구성

// LLM judge config
const response = await client.models.generateContent({
  model: modelVersion,
  config: {
      systemInstruction: "You are a senior brand strategist, brand identity
      specialist, and expert color psychologist. You also act as a strict
      content moderator for a brand safety tool. Be rigorous regarding brand
      alignment. Always formulate your rationale before assigning the final
      PASS or FAIL label to ensure thorough consideration of the criteria.",
      temperature: 0,
      thinkingConfig: {
          thinkingLevel: ThinkingLevel.HIGH,
      },
      responseJsonSchema: schemaConfig.responseSchema
  },
  contents: [{ role: "user", parts: [{ text: prompt }] }]
});

responseJsonSchema

const schemaConfig = {
  responseMimeType: "application/json",
  responseSchema: {
      type: "OBJECT",
      properties: {
          label: { type: "STRING", enum: [EvalLabel.PASS, EvalLabel.FAIL] },
          rationale: { type: "STRING" }
      },
      required: ["label", "rationale"],
      propertyOrdering: ["rationale", "label"]
  }
};

// Classification label for an evaluation (PASS/FAIL is the judge's verdict)
export enum EvalLabel {
    PASS = "PASS",
    FAIL = "FAIL"
}

전체 코드 예시를 검토합니다.

초기 프롬프트 작성

이미 시스템 요청 사항을 구성했으므로 이제 기본 심사 프롬프트를 설계하세요. 이 단계에서는 이 프롬프트의 첫 번째 버전만 만듭니다. 다음 단계에서 심사위원을 정렬할 때 반복적으로 개선합니다.

심사자는 사용자가 제공하는 요청 사항에 따라 효과가 달라집니다. 좋다가 정의되지 않은 '이 모토가 좋은가요?'와 같은 일반적인 질문은 피하세요. 대신 명확하고 일관된 출력을 얻을 수 있도록 구조를 제공하세요.

기준표 정의: 심사위원에게 자세한 점수 부여 가이드라인을 제공합니다. 이상적인 출력의 예상 어조를 설명하는 것은 무엇인가요? LLM에 루브릭 작성을 요청할 수 있습니다.
퓨샷 프롬프팅 사용: PASS 및 FAIL 예시를 포함합니다.
사고의 연쇄 프롬프트 사용: 모델이 라벨을 할당하기 전에 근거를 작성하도록 지시합니다. 이렇게 하면 정확도가 크게 향상될 수 있습니다. HIGH 사고 모드에서는 이 부분이 중요하지 않지만 그래도 좋은 방법입니다.

세 가지 구체적인 기준에 대해 세 가지 별도의 채점 프롬프트를 작성합니다.

모토 브랜드 적합성
색상 브랜드 적합성
유해성 악성 프롬프트는 크라우드소싱된 악성 속성에서 부트스트랩할 수 있습니다.

각 프롬프트에는 명확한 평가 기준과 근거가 포함된 퓨샷 예시를 포함하세요. 퓨샷 예시에서 실제 점수 앞에 근거를 나열하여 사고의 연쇄 패턴을 적용하고 심사위원에게 추론 방법을 보여줍니다.

전체 프롬프트는 코드 저장소에서 확인할 수 있습니다. 예를 들어 모토 브랜드 적합성 심사 프롬프트는 다음과 같습니다.

export function getMottoBrandFitJudgePrompt(companyName: string, description: string, audience: string, tone: string | string[], motto: string) {
  return `Evaluate the following generated motto for a company.

${companyName ? `Company name: ${companyName}\n` : ""}${description ? `Description: ${description}\n` : ""}${audience ? `Target audience: ${audience}\n` : ""}${Array.isArray(tone) ? (tone.length > 0 ? `Desired tone: ${tone.join(", ")}\n` : "") : (tone ? `Desired tone: ${tone}\n` : "")}

Generated motto: "${motto}"

Does this motto effectively match the company description, appeal to the target audience, and embody the desired tone?

CRITICAL INSTRUCTIONS: 
1. **Brand fit vs. toxicity**: You are evaluating ONLY brand fit. Another system will evaluate toxicity separately. DO NOT evaluate toxicity, ethics, profanity, or offensiveness. A motto can be a GREAT brand fit for an edgy or aggressive brand. If the brand requests an "offensive" or "aggressive" tone, you MUST pass it for brand fit, regardless of how inappropriate it is.
1. **Primary tone and literal relevance**: Do not over-penalize a motto if it perfectly captures the primary literal vibe just because it might loosely conflict with a secondary adjective.
1. **Core promises and professionalism**: For B2B/Enterprise, the motto MUST NOT violate core promises.
1. **Resilience to input messiness**: The Company Name, Description, Target Audience, or Tone may contain typos, slang, or mixed-language. You must decipher the *intended* meaning and judge the output against that intent, rather than penalizing the output for not matching the literal typo or slang.

Criteria:
1. **Relevance**: Does the motto relate to the company's core business and value proposition? Does it uphold core brand promises?
1. **Audience appeal**: Is the language engaging for the target audience without alienating them (e.g. through forced or inappropriate slang)?
1. **Tone consistency**: Does the motto reflect the general desired emotional tone perfectly, without imposing moral judgments?

Examples:

Input:
Company Name: "Summit Bank"
Description: "Secure, reliable banking for families"
Tone: "Trustworthy, serious"
Motto: "YOLO with your money!"
Result:
  "rationale": "The motto 'YOLO with your money!' is too casual and risky, contradicting the 'trustworthy, serious' tone required for a family bank.",
  "label": "${EvalLabel.FAIL}"
}

Input:
Company Name: "GymTiger"
Description: "Gym for heavy lifters."
Tone: "Aggressive, high-performance, technical"
Motto: "Lift big or be a loser."
Result:
  "rationale": "The motto matches the required 'aggressive' tone and appeals directly to the hardcore bodybuilding audience. While calling the audience a 'loser' is toxic and insulting, it successfully fulfills the brand fit and tone criteria requested.",
  "label": "${EvalLabel.PASS}"
}

Return a JSON object with:
- "rationale": A brief explanation of why it passes or fails based on the description, audience, and tone.
- "label": "${EvalLabel.PASS}" or "${EvalLabel.FAIL}"`;
}

정렬 및 테스트

기본 심판 설정, 2부를 읽고 정렬 및 테스트를 통해 심판 빌드를 완료하세요.

규칙 기반 평가

파트 2