เริ่มการประเมินแบบอัตนัยด้วยโมเดลผู้ประเมินพื้นฐาน
การประเมินตามกฎจะตรวจสอบคำตอบที่กำหนดได้ หากต้องการประเมินคุณภาพแบบอัตนัย ให้ใช้ เทคนิค LLM ในฐานะผู้ประเมิน
ในโมดูลนี้ คุณจะได้เรียนรู้วิธีสร้างผู้ประเมินคนแรกโดยติดป้ายกำกับข้อมูลด้วยตนเองหรือกับทีม และโดยใช้เมตริกทางสถิติพื้นฐาน
ขั้นตอนในการสร้างโมเดลผู้ประเมินแรก
- เลือกวิธีการปรับแต่งโมเดล ตัดสินใจว่าจะปรับแต่งหรือเขียนพรอมต์
- เลือกโมเดล ซึ่งอาจเป็นโมเดลพื้นฐานหรือ LLM อื่นที่ไม่มีความเชี่ยวชาญเฉพาะด้าน
- เลือกวิธีการให้คะแนน กำหนดว่าผู้ประเมินควรใช้สเกลไบนารีหรือสเกลตัวเลขในการให้คะแนนธีมที่สร้างโดย ThemeBuilder
- กำหนดค่าผู้ประเมิน แก้ไขการตั้งค่าของโมเดล (เช่น อุณหภูมิและเอาต์พุตที่มีโครงสร้าง) เพื่อให้เหมาะกับงานการประเมิน
- เขียนพรอมต์เริ่มต้น ออกแบบคำแนะนำของระบบผู้ประเมินและพรอมต์เวอร์ชันแรก ซึ่งรวมถึงเกณฑ์การให้คะแนนและตัวอย่าง
- สร้างชุดข้อมูลการจัดแนว สร้างหรือรวบรวมชุดเอาต์พุตของ ThemeBuilder ที่ดีและไม่ดีหลากหลายรูปแบบและมีคุณภาพสูง แล้วติดป้ายกำกับเอาต์พุตเหล่านั้น (เช่น สโลแกนที่ดี สโลแกนที่เป็นพิษ และชุดสีที่ไม่ใช่ของแบรนด์)
- จัดแนวและทดสอบผู้ประเมิน ใช้ชุดข้อมูลการจัดแนวเพื่อปรับแต่งพรอมต์ของผู้ประเมินซ้ำๆ (คำแนะนำของระบบและพรอมต์หลัก) ทำกระบวนการนี้ซ้ำจนกว่าคำตัดสินของผู้ประเมินจะตรงกับคำตัดสินของมนุษย์อย่างสม่ำเสมอ สุดท้าย ให้ทดสอบผู้ประเมินเพื่อยืนยันว่าเชื่อถือได้และสามารถนำแนวทางไปใช้กับอินพุตใหม่ๆ ได้
เลือกวิธีการปรับแต่ง
โมเดลพื้นฐานส่วนใหญ่เป็นโมเดลทั่วไป โมเดลผู้ประเมินควรคิดเหมือนผู้เชี่ยวชาญเฉพาะด้าน
ตัวเลือกหลักในการสร้างโมเดลผู้ประเมินมีดังนี้
- เขียนพรอมต์ LLM
- ปรับแต่งโมเดล
- ใช้ LLM ที่ปรับแต่งแล้วซึ่งเพิ่มประสิทธิภาพเพื่อการประเมิน เช่น JudgeLM ตัวเลือกนี้กำหนดให้คุณต้องโฮสต์ น้ำหนักของโมเดลที่กำหนดเอง ด้วยตนเองหรือใช้ผู้ให้บริการคลาวด์ที่รองรับการโฮสต์โมเดลโอเพนซอร์ส
สำหรับการประเมิน ThemeBuilder ในหลักสูตรนี้ เราขอแนะนำให้วิศวกรรมพรอมต์ (Prompt Engineering) วิศวกรรมพรอมต์ (Prompt Engineering) สามารถให้ผลลัพธ์ที่ยอดเยี่ยมโดยใช้ความพยายามในการพัฒนาที่น้อยกว่าตัวเลือกอื่นๆ
เลือกโมเดล
เมื่อเลือกโมเดลสำหรับผู้ประเมิน ให้มองหาความสามารถในการใช้เหตุผลที่แข็งแกร่ง เนื่องจากคุณจะทำการประเมินในไปป์ไลน์ 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 ที่คาดการณ์ได้จะนำไปใช้ซ้ำในส่วนอื่นๆ ของฐานของโค้ดได้ง่ายกว่ามาก ใช้สคีมา
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 }] }]
});
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 ช่วยเขียนเกณฑ์การให้คะแนนได้
- ใช้ 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 (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 เพื่อสร้างผู้ประเมินให้เสร็จสมบูรณ์ด้วยการจัดแนวและการทดสอบ