ทดสอบ Prompt แบบเป็นระบบก่อนใช้กับงานจริง

วิธีทำ eval ให้ prompt ตั้งแต่กำหนดเกณฑ์ความสำเร็จ สร้างชุดทดสอบ เลือกวิธีให้คะแนน ไปจนถึงทดสอบซ้ำทุกครั้งที่แก้ prompt

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

Prompt Evaluation คืออะไร

Prompt evaluation หรือ eval คือการวัดคุณภาพ prompt ด้วยชุดทดสอบที่กำหนดไว้ล่วงหน้า มีเกณฑ์ชัดเจน และรันซ้ำได้ทุกครั้งที่แก้ เหมือน unit test ของงานซอฟต์แวร์ คู่มือ Prompting ของ OpenAI แนะนำให้มอง prompt เป็นโค้ดของแอป และรัน prompt test กับ evaluation case ทุกครั้งที่เผยแพร่

ขั้นที่ 1: กำหนดเกณฑ์ความสำเร็จ

เอกสาร "Define success criteria and build evaluations" ของ Anthropic ระบุว่าเกณฑ์ที่ดีควร

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

Anthropic ยังระบุว่างานส่วนใหญ่ต้องวัดหลายมิติ เช่น ความถูกต้อง ความสม่ำเสมอ น้ำเสียง การรักษาข้อมูลส่วนบุคคล ความเร็ว และต้นทุน

ขั้นที่ 2: สร้างชุดทดสอบ

สะท้อนงานจริง รวม edge case

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

ปริมาณสำคัญ

Anthropic แนะนำว่า คำถามจำนวนมากที่ให้คะแนนอัตโนมัติแม้สัญญาณจะต่ำกว่าเล็กน้อย ดีกว่าคำถามไม่กี่ข้อที่คนตรวจเองอย่างละเอียด

ขั้นที่ 3: เลือกวิธีให้คะแนน

• ตรวจด้วยโค้ด: เช่น exact match สำหรับงานจัดหมวด เร็วและแม่นที่สุด ใช้ได้ดีเมื่อผลลัพธ์เป็น Structured Output
• วัดความใกล้เคียง: เช่น cosine similarity เพื่อดูว่าคำถามที่ถามต่างกันแต่ความหมายเดียวกันได้คำตอบที่สอดคล้องกันไหม หรือ ROUGE-L สำหรับงานสรุป
• ใช้ LLM เป็นกรรมการ: ให้โมเดลให้คะแนน 1 ถึง 5 ตามเกณฑ์ หรือตอบใช่/ไม่ใช่ Anthropic แนะนำให้ใช้โมเดลคนละตัวกับที่สร้างคำตอบ
• คนตรวจ: ยืดหยุ่นที่สุดแต่ช้าและแพง ใช้กับตัวอย่างสุ่มหรือกรณีสำคัญ

ขั้นที่ 4: รันซ้ำเมื่อมีอะไรเปลี่ยน

Eval มีค่าเมื่อรันสม่ำเสมอ ควรรันชุดทดสอบทั้งหมดทุกครั้งที่

• แก้ถ้อยคำใน prompt แม้เพียงประโยคเดียว
• เปลี่ยนโมเดลหรือเวอร์ชันของโมเดล
• เปลี่ยนข้อมูลอ้างอิง เช่น ตารางราคาหรือนโยบาย
• เพิ่มหรือแก้เครื่องมือที่ AI เรียกใช้

ตัวอย่าง: ระบบจัดหมวดรีวิวร้านอาหาร

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

ถ้าวัดไม่ได้ว่าดีขึ้น คุณก็ไม่รู้ว่าแก้ prompt แล้วดีขึ้นจริงหรือแค่รู้สึกไปเอง

ข้อควรระวัง

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

เริ่มต้นยังไง

1. เขียนเกณฑ์ความสำเร็จ 2 ถึง 3 ข้อที่วัดเป็นตัวเลขได้
2. รวบรวมอินพุตจริง 30 ถึง 50 ชิ้น พร้อมคำตอบที่ถูก และใส่ edge case อย่างน้อยหนึ่งในห้า
3. เขียนสคริปต์หรือใช้สเปรดชีตรันทุกเคสแล้วให้คะแนนอัตโนมัติเท่าที่ทำได้
4. บันทึกคะแนนของแต่ละเวอร์ชัน prompt และรันซ้ำทุกครั้งที่แก้หรือเปลี่ยนโมเดล

การทดสอบ prompt อย่างเป็นระบบเริ่มจาก System Prompt ที่ออกแบบดี และเป็นทักษะที่ทีมสร้างผลิตภัณฑ์ AI ต้องการ ถ้าคุณอยากรู้ว่าทักษะ AI ของคุณอยู่ระดับไหน ลองทำ แบบทดสอบบน Plants.work