הגדרה של מודל שופט בסיסי (חלק 1)

הפעלת הערכות סובייקטיביות באמצעות מודל שופט בסיסי.

Maud Nalpas

הערכות מבוססות-כללים יכולות לבדוק תשובות דטרמיניסטיות. כדי להעריך איכויות סובייקטיביות, אפשר להשתמש בטכניקה של מודל שפה גדול כשופט.

במודול הזה תלמדו איך לבנות שופט ראשון על ידי תיוג נתונים בעצמכם או עם הצוות ועל ידי שימוש במדדים סטטיסטיים בסיסיים.

השלבים ליצירת מודל שופט ראשון

1. בוחרים שיטה להתאמה אישית של המודל. מחליטים אם רוצים לבצע התאמה עדינה או הנדסת הנחיות.
2. בוחרים מודל. יכול להיות שזה מודל בסיסי או מודל LLM אחר ללא מומחיות בתחום.
3. בוחרים שיטת ניקוד. קובעים אם השופט צריך להשתמש בסולם בינארי או בסולם מספרי כדי לתת ציון לעיצובים שנוצרו באמצעות ThemeBuilder.
4. מגדירים את השופט. לשנות את ההגדרות של המודל (כמו רמת אקראיות ופלט מובנה) כדי להתאים אותו למשימות שיפוט.
5. כותבים את ההנחיה הראשונית. תכנון גרסה ראשונה של ההנחיות וההנחיה למערכת השופטים, כולל קריטריון להערכה ודוגמאות.
6. יצירת מערך נתונים להתאמה. יוצרים או מרכיבים קבוצה מגוונת ואיכותית של תוצאות טובות ורעות מ-ThemeBuilder, ומסמנים אותן בהתאם (למשל, מוטו טוב, מוטו רע ופלטת צבעים לא מתאימה למותג).
7. התאמה ובדיקה של השופט. משתמשים במערך הנתונים של ההתאמה כדי לשפר באופן איטרטיבי את ההנחיה לשופט (הוראות המערכת וההנחיה הראשית). חוזרים על התהליך הזה עד שההחלטות של השופט יהיו זהות להחלטות של בני האדם. לבסוף, בודקים את השופט כדי לוודא שהוא אמין ויכול להכליל את הגישה שלו לקלטים חדשים.

בחירת שיטת התאמה אישית

רוב מודלי הבסיס הם מודלים כלליים. מודל שמשמש כשופט צריך לחשוב כמו מומחה בתחום מסוים.

האפשרויות העיקריות ליצירת מודל שופט כוללות:

1. הנדסת הנחיות ל-LLM.
2. כוונון עדין של מודל.
3. משתמשים במודל שפה גדול (LLM) שעבר כוונון עדין ואופטימיזציה להערכות, למשל, JudgeLM. כדי להשתמש באפשרות הזו, צריך לארח משקלים של מודלים בהתאמה אישית בעצמכם או להשתמש בספק שירותי ענן שתומך באירוח של מודלים בקוד פתוח.

כדי להפיק את המרב מההערכות של ThemeBuilder בקורס הזה, מומלץ להשתמש בהנדסת הנחיות. הנדסת הנחיות יכולה להניב תוצאות מצוינות עם פחות מאמץ פיתוח מאשר החלופות.

בחירת מודל

כשבוחרים מודל לשופט, חשוב לחפש יכולות חשיבה רציונלית חזקות. בנוסף, מכיוון שתריצו הערכות בצינור עיבוד הנתונים של CI/CD, המהירות והעלות הן גם גורמים חשובים.

כדאי להתנסות במודלים שונים ובטכניקות שונות כדי למצוא את מה שהכי מתאים לכם.

• כדאי להתחיל עם מודל גדול וחזק יותר כדי להציב רף גבוה, ואז להקטין את המודל בהדרגה למודלים קטנים יותר. או להיפך.
• שילוב של מודלים: אפשר להשתמש במודל מהיר וחסכוני לבדיקות יומיות של בקשות למשיכת קוד, ובמודל מתקדם יותר לבדיקות הסופיות של הגרסה. אפשר גם לשלב בין מודל LLM כללי לבין מודל קטן וייעודי למשימות ספציפיות, כמו זיהוי רעילות, כדי להגביר את המהירות.

בקורס הזה נעשה שימוש ב-Gemini 3 Flash כמודל השופט. ‫Gemini 3 Flash מציע את המהירות ואת עומק החשיבה שנדרשים לתרחיש השימוש לדוגמה של הערכת התוצאות של ThemeBuilder. עם זאת, אפשר להשתמש בדפוסים שבקורס הזה בכל מודל שתבחרו.

בחירת שיטת ניקוד

אפשר לתת ציון לפלט סובייקטיבי באמצעות תוויות בינאריות PASS ו-FAIL, או באמצעות ציון מספרי, למשל "בסולם של 1 עד 5, עד כמה הסיסמה הזו תואמת למותג?".

מומלץ להשתמש בתוויות בינאריות.

אמנם ציון מספרי (1-10) עשוי להיראות אינטואיטיבי, אבל מחקרים מראים שמודלים גדולים של שפה (LLM) (ובני אדם) נוטים לקבץ את הציונים שלהם באמצע או להגדיל את הציונים כדי להיות מנומסים. תוויות בינאריות או קטגוריות כמו PASS ו-FAIL בדרך כלל מניבות תוצאות טובות יותר, כי הן מחייבות את המודל לקבל החלטה ברורה. אצל בני אדם, התופעה הזו נקראת השפעת הדירוג.

הגדרת השופט

כדי לעזור לשופט ליצור פלט עקבי ומובנה, כדאי להשתמש בפרמטרים ובהוראות.

• הגדרת הוראות מערכת: הגדרת אישיות מומחה קפדנית לשופט.
• הגדרת רמת אקראיות או רמת החשיבה: השופט צריך להיות עקבי. אם אתם משתמשים במודל חשיבה רציונלית כמו Gemini Flash, שנדרשת לו מידה מסוימת של אקראיות כדי לעבור בין שלבים לוגיים, השאירו את רמת האקראיות בערך ברירת המחדל, אבל הגדירו את thinking_level לערך HIGH. אם משתמשים במודל אחר, מגדירים את רמת האקראיות לערך 0 או לערך קרוב ל-0. בכל מקרה, כדאי להשתמש בטכניקת שרשרת המחשבות, כדי שהמודל יחשוב לפני שיקבל החלטה לגבי שיפוט.
• מבנה הפלט של השופט: הרבה יותר קל לעשות שימוש חוזר באובייקט JSON צפוי בשאר בסיס הקוד. משתמשים בסכימת EvalResult שדורשת label (PASS או FAIL) ומחרוזת rationale.

בדוגמה של 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 }] }]
});

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.