Automatic Prompt Engineer (APE) ช่วยให้โมเดลภาษาเขียน ทดสอบ และเลือกพรอมต์ (prompt) ที่ดีที่สุดสำหรับงานที่กำหนด เปลี่ยนจากศิลปะแห่งการลองผิดลองถูกที่เคยเป็นมา ให้กลายเป็นการค้นหาที่ขับเคลื่อนด้วยข้อมูลและทำซ้ำได้

ทำไมการเขียนพรอมต์ถึงกลายเป็นคอขวด

Prompt engineering หรือการสร้างถ้อยคำที่แม่นยำเพื่อสั่งการโมเดล เป็นสิ่งที่ผสมผสานระหว่างสัญชาตญาณและโชคชะตามาอย่างยาวนาน ผู้ใช้งานมักจะปรับคำตรงนั้น เปลี่ยนวลีตรงนี้ รันโมเดล แล้วก็หยุดเมื่อผลลัพธ์ที่ได้ "รู้สึกว่าใช่" วิธีการแบบนี้ใช้เวลานาน พึ่งพาจินตนาการของผู้เขียน และจำกัดประสิทธิภาพ ในขั้นตอนการใช้งานจริง (production) สิ่งนี้หมายถึงวงจรการทำงานที่ยาวขึ้น ผลลัพธ์ที่ไม่เสถียร และต้นทุนแฝงที่จะปรากฏขึ้นหลังจากเปิดใช้งานไปแล้วเท่านั้น

เวิร์กโฟลว์ 3 ขั้นตอนของ APE

APE มองว่าการสร้างพรอมต์คือปัญหาการค้นหา (search problem) โดยผู้ใช้จะป้อนชุดตัวอย่าง input-output จำนวนเล็กน้อย จากนั้นระบบจะดำเนินการผ่าน 3 ขั้นตอนอัตโนมัติ:

  1. Propose (เสนอ) – โมเดลจะสแกนตัวอย่างและสร้างชุดคำสั่งที่เป็นไปได้ออกมา เช่น “จงคืนค่าที่เป็นคำตรงข้าม” หรือ “จงเขียนคำที่มีความหมายตรงกันข้าม”
  2. Score (ให้คะแนน) – ระบบจะนำคำสั่งแต่ละชุดไปทดสอบกับชุดตัวอย่างอื่นที่โมเดลยังไม่เคยเห็น และนับจำนวนคำตอบที่ตรงกับผลลัพธ์ที่คาดหวัง เพื่อให้ได้ตัวเลขความแม่นยำดิบ โดยไม่มีการใช้ดุลยพินิจของมนุษย์ในขั้นตอนนี้
  3. Select (เลือก) – คำสั่งที่มีความแม่นยำสูงสุดจะกลายเป็นพรอมต์สุดท้าย

กระบวนการนี้สามารถทำซ้ำได้ พรอมต์ที่ชนะจะกลายเป็นเมล็ดพันธุ์ (seed) ใหม่ และโมเดลจะเสนอรูปแบบที่หลากหลายขึ้น จากรายงานการทดสอบ พบว่าคำสั่งทั่วไปที่ได้คะแนน 83% ถูกปรับปรุงจนกลายเป็นเวอร์ชันที่ทำคะแนนได้ถึง 100% ในชุดทดสอบ

สิ่งที่ทำให้แนวทางนี้เหนือกว่าการใช้มนุษย์

  • Coverage (ความครอบคลุม) – LLM สามารถสร้างทางเลือกในการใช้ถ้อยคำได้หลายสิบแบบภายในไม่กี่วินาที ซึ่งมากกว่าที่มนุษย์จะทดสอบได้มาก
  • Objectivity (ความเที่ยงธรรม) – การเลือกขึ้นอยู่กับความแม่นยำที่วัดผลได้ ไม่ใช่ความสละสลวยของถ้อยคำ คำสั่งที่ดูเหมือนตำราอาจพ่ายแพ้ให้กับคำสั่งที่สั้นกระชับและฟังดูแปลกๆ แต่โมเดลเข้าใจได้ดีกว่า

เนื่องจากเกณฑ์การให้คะแนนมาจากผู้ใช้—ซึ่งมักจะเป็นการตรวจสอบความถูกต้องแบบตรงตัว (exact-match) หรือการทำ unit test—ระบบจึงสามารถปรับจูนให้เข้ากับความต้องการในขั้นตอนถัดไป (downstream) ได้ทุกรูปแบบ ตั้งแต่การสร้างโค้ดไปจนถึงการวิเคราะห์ความรู้สึก (sentiment analysis)

ราคาที่ต้องจ่ายสำหรับการทำงานอัตโนมัติ

สิ่งที่ต้องแลกมาคือพลังการประมวลผล (compute) การให้คะแนนผู้สมัครแต่ละรายต้องมีการเรียกใช้โมเดลหลายครั้ง ดังนั้นในช่วงการพัฒนาจะมีการใช้ API ในปริมาณที่สังเกตเห็นได้ แต่ APE มองว่าค่าใช้จ่ายนั้นเป็นการลงทุนเพียงครั้งเดียว เมื่อระบุพรอมต์ที่เหมาะสมที่สุดได้แล้ว คุณสามารถนำกลับมาใช้ใหม่ได้ตลอดไปโดยไม่มีค่าใช้จ่ายเพิ่มเติม

นอกจากนี้ยังมีเงื่อนไขเบื้องต้นสองประการที่จำกัดการนำไปใช้งาน:

  • Labeled examples (ตัวอย่างที่มีการระบุคำตอบ) – ระบบต้องการชุดข้อมูล input และ output ที่ถูกต้องซึ่งเป็นตัวแทนของข้อมูลจริง
  • Scoring function (ฟังก์ชันการให้คะแนน) – ผู้ใช้ต้องกำหนดว่า "ความถูกต้อง" สำหรับงานของตนคืออะไร ไม่ว่าจะเป็นการจับคู่ข้อความที่ตรงกันเป๊ะ การยอมรับค่าความคลาดเคลื่อนของตัวเลข หรือตัวตรวจสอบ (validator) ที่กำหนดขึ้นเอง

จุดที่แนวคิดนี้อาจเกิดปัญหา

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

สิ่งที่ควรติดตามต่อไป

เครื่องมือนี้เสนอทางเลือกใหม่: เพียงป้อนตัวอย่างไม่กี่อย่าง ปล่อยให้โมเดลทำงานซ้ำไปเรื่อยๆ และรับพรอมต์ที่ระบบจัดอันดับไว้สูงสุดจากการทดลองทั้งหมด คุณสามารถดูเดโมได้ที่ลิงก์ในประกาศต้นฉบับ และมีชุมชนแห่งการเรียนรู้รวมตัวกันอยู่ใน Telegram

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