ตั้งค่าโมเดลผู้ตัดสินพื้นฐาน (ส่วนที่ 1)

สร้างการประเมินแบบอัตนัยด้วยโมเดลผู้ประเมินพื้นฐาน

Maud Nalpas

การประเมินตามกฎจะตรวจสอบคำตอบที่กำหนดได้ หากต้องการประเมินคุณภาพแบบอัตนัย ให้ใช้ เทคนิค LLM เป็นผู้ประเมิน

ในโมดูลนี้ คุณจะได้เรียนรู้วิธีสร้างผู้ประเมินคนแรกด้วยการติดป้ายกำกับข้อมูลด้วยตนเองหรือกับทีม โดยใช้เมตริกทางสถิติพื้นฐาน

สร้างโมเดลผู้ประเมินแรก

1. เลือกวิธีการปรับแต่งโมเดล คุณสามารถปรับแต่งหรือออกแบบพรอมต์
2. เลือกโมเดล ซึ่งอาจเป็นโมเดลพื้นฐานหรือ LLM อื่นๆ ที่ไม่มีความเชี่ยวชาญเฉพาะด้าน
3. เลือกวิธีการให้คะแนน กำหนดว่าผู้ประเมินควรใช้ระดับคะแนนแบบไบนารีหรือแบบตัวเลขเพื่อให้คะแนนธีมที่สร้างโดย ThemeBuilder
4. กำหนดค่าผู้ประเมิน แก้ไขการตั้งค่าของโมเดล (เช่น อุณหภูมิและเอาต์พุตที่มีโครงสร้าง) เพื่อให้เหมาะกับงานการประเมิน
5. เขียนพรอมต์เริ่มต้น ออกแบบคำแนะนำสำหรับระบบผู้ประเมินและพรอมต์เวอร์ชันแรก ซึ่งรวมถึงเกณฑ์การให้คะแนนและตัวอย่าง
6. สร้างชุดข้อมูลการจัดแนว สร้างหรือรวบรวมชุดเอาต์พุตของ ThemeBuilder ที่หลากหลายและมีคุณภาพสูง ทั้งเอาต์พุตที่ดีและไม่ดี แล้วติดป้ายกำกับตามความเหมาะสม เช่น สโลแกนที่ดี สโลแกนที่ไม่เหมาะสม และชุดสีที่ไม่ใช่สีของแบรนด์
7. จัดแนวและทดสอบผู้ประเมิน ใช้ชุดข้อมูลการจัดแนวเพื่อปรับแต่งพรอมต์ของผู้ประเมินซ้ำๆ (คำแนะนำสำหรับระบบและพรอมต์หลัก) ทำกระบวนการนี้ซ้ำจนกว่าคำตัดสินของผู้ประเมินจะตรงกับคำตัดสินของมนุษย์อย่างสม่ำเสมอ สุดท้าย ให้ทดสอบผู้ประเมินเพื่อยืนยันความน่าเชื่อถือและความสามารถในการนำแนวทางไปใช้กับอินพุตใหม่ๆ

เลือกวิธีการปรับแต่ง

โมเดลพื้นฐานส่วนใหญ่เป็นโมเดลทั่วไป โมเดลผู้ประเมินจะทำหน้าที่เป็นผู้เชี่ยวชาญเฉพาะด้าน

ตัวเลือกหลักในการสร้างโมเดลผู้ประเมิน ได้แก่

1. ออกแบบพรอมต์สำหรับ LLM
2. ปรับแต่งโมเดล
3. ใช้ LLM ที่ปรับแต่งแล้วซึ่งเพิ่มประสิทธิภาพเพื่อการประเมิน เช่น JudgeLM ตัวเลือกนี้กำหนดให้คุณต้องโฮสต์ น้ำหนักของโมเดลที่กำหนดเอง หรือใช้ผู้ให้บริการคลาวด์ที่รองรับการโฮสต์โมเดลโอเพนซอร์ส

สำหรับการประเมิน ThemeBuilder ในหลักสูตรนี้ เราขอแนะนำวิศวกรรมพรอมต์ (Prompt Engineering) วิศวกรรมพรอมต์ (Prompt Engineering) สามารถให้ผลลัพธ์ที่ยอดเยี่ยมโดยใช้ความพยายามในการพัฒนาที่น้อยกว่าตัวเลือกอื่นๆ

เลือกโมเดล

เมื่อเลือกโมเดลสำหรับผู้ประเมิน ให้มองหาโมเดลที่มีความสามารถในการใช้เหตุผลที่แข็งแกร่ง เนื่องจากคุณทำการประเมินในไปป์ไลน์ CI/CD ความเร็วและต้นทุนจึงมีความสำคัญอย่างยิ่ง

ทดลองใช้โมเดล และเทคนิคต่างๆ เพื่อค้นหาโมเดลที่เหมาะสมที่สุด

• เริ่มต้นด้วยโมเดลขนาดใหญ่และมีประสิทธิภาพมากขึ้น เพื่อกำหนดมาตรฐานที่สูง จากนั้นค่อยๆ ลดขนาดลงไปใช้โมเดลขนาดเล็กลง หรือจะเริ่มต้นด้วยโมเดลขนาดเล็กแล้วค่อยๆ เพิ่มทรัพยากรก็ได้
• ผสมและจับคู่: ใช้โมเดลที่รวดเร็วและคุ้มค่าสำหรับการตรวจสอบ Pull Request รายวัน และใช้ โมเดลที่มีประสิทธิภาพมากขึ้นสำหรับการทดสอบการเผยแพร่ครั้งสุดท้าย หรือรวม LLM ทั่วไปกับโมเดลขนาดเล็กที่เชี่ยวชาญเฉพาะด้านสำหรับงานที่เฉพาะเจาะจง เช่น การตรวจหาเนื้อหาที่เป็นอันตราย เพื่อให้ได้ผลลัพธ์ที่รวดเร็ว

หลักสูตรนี้ใช้ Gemini 3 Flash เป็นโมเดลผู้ประเมิน Gemini 3 Flash มีความเร็วและความลึกซึ้งในการใช้เหตุผลที่จำเป็นสำหรับกรณีการใช้งานตัวอย่างในการประเมินเอาต์พุตของ ThemeBuilder อย่างไรก็ตาม คุณสามารถนำรูปแบบในหลักสูตรนี้ไปใช้กับโมเดลใดก็ได้ที่คุณเลือก

เลือกวิธีการให้คะแนน

คุณสามารถให้คะแนนเอาต์พุตแบบอัตนัยด้วยป้ายกำกับ PASS และ FAIL แบบไบนารี หรือด้วยคะแนนตัวเลข เช่น "จากระดับ 1 ถึง 5 สโลแกนนี้สอดคล้องกับแบรนด์มากน้อยเพียงใด"

เราขอแนะนำให้ใช้ป้ายกำกับแบบไบนารี

แม้ว่าคะแนนตัวเลขอาจดูสมเหตุสมผล การวิจัยแสดงให้เห็นว่า 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 ช่วยคุณเขียนเกณฑ์การให้คะแนนได้
• ใช้ Few-Shot Prompting: ใส่ตัวอย่าง PASS และ FAIL
• ใช้การออกแบบพรอมต์แบบการคิดแบบเป็นลำดับขั้นตอน: สั่งให้โมเดลเขียนเหตุผลก่อนที่จะกำหนดป้ายกำกับ เนื่องจาก วิธีนี้จะช่วยเพิ่มความแม่นยำได้อย่างมาก ในโหมดการคิด HIGH วิธีนี้ไม่สำคัญเท่าไหร่ แต่ก็ยังเป็นแนวทางปฏิบัติที่ดี

เขียนพรอมต์การให้คะแนนแยกกัน 3 รายการสำหรับเกณฑ์ที่เฉพาะเจาะจง 3 ข้อ

• ความเหมาะสมของสโลแกนกับแบรนด์
• ความเหมาะสมของสีกับแบรนด์
• เนื้อหาที่เป็นอันตราย คุณสามารถเริ่มต้นพรอมต์เนื้อหาที่เป็นอันตรายจาก แอตทริบิวต์เนื้อหาที่เป็นอันตรายที่มาจากแหล่งข้อมูลแบบคราวด์ซอร์ส

ในแต่ละพรอมต์ ให้ใส่เกณฑ์การให้คะแนน ที่ชัดเจนและตัวอย่างแบบไม่กี่ตัวอย่าง พร้อมเหตุผล ในตัวอย่างแบบไม่กี่ตัวอย่าง ให้ระบุเหตุผลก่อนคะแนนจริงเพื่อใช้รูปแบบการคิดแบบเป็นลำดับขั้นตอนและแสดงให้เห็นว่าผู้ประเมินใช้เหตุผลอย่างไร

คุณดูพรอมต์ทั้งหมดได้ในที่ เก็บโค้ด ตัวอย่างเช่น พรอมต์ผู้ประเมินความเหมาะสมของสโลแกนกับแบรนด์มีลักษณะดังนี้

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 (such as 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 เพื่อสร้างผู้ประเมินให้เสร็จสมบูรณ์ด้วยการจัดแนวและการทดสอบ