เมื่อคุณสร้างพรอมต์สำหรับแอปพลิเคชันจริง สิ่งที่ต้องแลกมาที่สำคัญคือการรักษาสมดุลระหว่างความกระชับกับประสิทธิภาพ เมื่อปัจจัยทั้งหมดเท่ากัน พรอมต์ที่กระชับจะ เร็วกว่า ถูกกว่า และดูแลรักษาง่ายกว่าพรอมต์ที่ยาวกว่า ซึ่งมีความเกี่ยวข้องเป็นอย่างยิ่งในสภาพแวดล้อมเว็บที่เวลาในการตอบสนองและขีดจำกัดโทเค็นมีความสำคัญ อย่างไรก็ตาม หากพรอมต์ของคุณมีข้อมูลน้อยเกินไป โมเดลอาจขาดบริบท คำสั่ง หรือตัวอย่างในการสร้างผลลัพธ์คุณภาพสูง
การพัฒนาที่ขับเคลื่อนด้วยการประเมิน (EDD) ช่วยให้คุณตรวจสอบและเพิ่มประสิทธิภาพการแลกเปลี่ยนนี้ได้อย่างเป็นระบบ โดยมีกระบวนการที่ทำซ้ำและทดสอบได้เพื่อปรับปรุงเอาต์พุตทีละเล็กทีละน้อยอย่างมั่นใจ จับข้อผิดพลาด และปรับลักษณะการทำงานของโมเดลให้สอดคล้องกับความคาดหวังของผู้ใช้และผลิตภัณฑ์เมื่อเวลาผ่านไป
ซึ่งเปรียบได้กับการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) ที่ปรับให้เข้ากับความไม่แน่นอนของ AI การประเมิน AI ไม่สามารถฮาร์ดโค้ดได้เนื่องจากเอาต์พุตทั้งที่รูปแบบถูกต้องและไม่ถูกต้องอาจมีรูปแบบที่ไม่คาดคิด ซึ่งแตกต่างจากการทดสอบหน่วยที่กำหนด
นอกจากนี้ EDD ยังช่วยสนับสนุนความพยายามในการค้นหาของคุณด้วย การเขียนการทดสอบช่วยให้เห็นพฤติกรรมของฟีเจอร์ได้ชัดเจนขึ้น เช่นเดียวกับการกำหนดเกณฑ์การประเมินและการตรวจสอบเอาต์พุตของโมเดลจะบังคับให้คุณเผชิญกับความไม่ชัดเจน และค่อยๆ เพิ่มรายละเอียดและโครงสร้างให้กับงานที่ไม่มีที่สิ้นสุดหรืองานที่ไม่คุ้นเคย
ระบุปัญหา
คุณสามารถระบุปัญหาในลักษณะของสัญญา API ได้ ซึ่งรวมถึงประเภทอินพุต รูปแบบเอาต์พุต และข้อจำกัดเพิ่มเติม เช่น
- ประเภทอินพุต: ฉบับร่างของบล็อกโพสต์
- รูปแบบเอาต์พุต: อาร์เรย์ JSON ที่มีชื่อโพสต์ 3 รายการ
- ข้อจำกัด: มีอักขระน้อยกว่า 128 ตัว ใช้โทนที่เป็นมิตร
จากนั้นรวบรวมตัวอย่างอินพุต คุณต้องรวมทั้งตัวอย่างที่สมบูรณ์แบบและอินพุตจริงที่อาจไม่สมบูรณ์เพื่อให้มั่นใจว่าข้อมูลมีความหลากหลาย พิจารณาถึงรูปแบบต่างๆ และกรณีที่พบได้ยาก เช่น โพสต์ที่มีอีโมจิ โครงสร้างที่ซ้อนกัน และข้อมูลโค้ดจำนวนมาก
เริ่มต้นข้อมูลพื้นฐาน
เขียนพรอมต์แรก คุณสามารถเริ่มต้นด้วยการเรียนรู้แบบศูนย์ช็อตและระบุสิ่งต่อไปนี้
- คำสั่งที่ชัดเจน
- รูปแบบเอาต์พุต
- ตัวยึดตำแหน่งสำหรับตัวแปรอินพุต
คุณจะเพิ่มความซับซ้อนและทำงานร่วมกับคอมโพเนนต์อื่นๆ รวมถึงเทคนิคการแจ้งขั้นสูงเมื่อประเมินและเพิ่มประสิทธิภาพ ก่อนอื่นเราต้องตั้งค่า ระบบการประเมินเพื่อนำความพยายามในการเพิ่มประสิทธิภาพไปในทิศทางที่ถูกต้อง
สร้างระบบการประเมิน
ใน TDD คุณจะเริ่มเขียนการทดสอบเมื่อทราบข้อกำหนด Generative AI ไม่มีเอาต์พุตที่ชัดเจนให้ทดสอบ คุณจึงต้องพยายามมากขึ้นในการสร้างลูปการประเมิน
คุณอาจต้องใช้เครื่องมือวัดผลหลายอย่างเพื่อประเมินอย่างมีประสิทธิภาพ
กำหนดเมตริกการประเมิน
เมตริกการประเมินอาจเป็นแบบดีเทอร์มินิสติก เช่น คุณอาจตรวจสอบว่าโมเดลแสดงผล JSON ที่ถูกต้องหรือแสดงผลจำนวนรายการที่ถูกต้องหรือไม่
อย่างไรก็ตาม คุณควรใช้เวลาส่วนใหญ่ไปกับการระบุและปรับแต่งเมตริกเชิงอัตวิสัยหรือเชิงคุณภาพ เช่น ความชัดเจน ประโยชน์ใช้สอย น้ำเสียง หรือความคิดสร้างสรรค์ คุณอาจเริ่มต้นด้วยเป้าหมายกว้างๆ แต่ในไม่ช้าก็พบปัญหาที่ซับซ้อนมากขึ้น
เช่น หากเครื่องมือสร้างชื่อใช้คำหรือรูปแบบบางอย่างมากเกินไป อาจทำให้ผลลัพธ์ซ้ำซากและดูเหมือนหุ่นยนต์ ในกรณีดังกล่าว คุณจะต้องกำหนดเมตริกใหม่เพื่อกระตุ้นให้เกิดความหลากหลาย และไม่สนับสนุนให้ใช้โครงสร้างหรือคีย์เวิร์ดที่ใช้บ่อยเกินไป เมื่อเวลาผ่านไป เมตริกหลักจะมีความเสถียรและคุณจะติดตามการปรับปรุงได้
กระบวนการนี้จะได้รับประโยชน์จากผู้เชี่ยวชาญที่เข้าใจว่าดีในโดเมนของแอปพลิเคชันของคุณมีลักษณะอย่างไร และสามารถตรวจพบโหมดความล้มเหลวที่ซับซ้อนได้ เช่น หากคุณกำลังพัฒนาผู้ช่วยด้านการเขียน ให้จับคู่กับผู้ผลิตเนื้อหาหรือบรรณาธิการ เพื่อให้การประเมินสอดคล้องกับมุมมองของพวกเขา
เลือกกรรมการ
เกณฑ์การประเมินที่แตกต่างกันต้องใช้ผู้ประเมินที่แตกต่างกัน ดังนี้
- การตรวจสอบตามโค้ดเหมาะสําหรับเอาต์พุตที่กําหนดหรืออิงตามกฎ เช่น คุณอาจสแกนชื่อเพื่อหาคำที่ต้องการหลีกเลี่ยง ตรวจสอบจำนวนอักขระ หรือตรวจสอบโครงสร้าง JSON ซึ่งรวดเร็ว ทำซ้ำได้ และเหมาะ สำหรับองค์ประกอบ UI ที่มีเอาต์พุตคงที่ เช่น ปุ่มหรือช่องในแบบฟอร์ม
- ความคิดเห็นจากเจ้าหน้าที่มีความสำคัญต่อการประเมินคุณภาพที่มีลักษณะเป็นอัตวิสัยมากขึ้น ซึ่งรวมถึงน้ำเสียง ความชัดเจน หรือประโยชน์ โดยเฉพาะในช่วงแรก การตรวจสอบเอาต์พุตของโมเดลด้วยตนเอง (หรือกับผู้เชี่ยวชาญเฉพาะด้าน) จะช่วยให้เกิดการทำซ้ำอย่างรวดเร็ว อย่างไรก็ตาม วิธีนี้ปรับขนาดได้ไม่ดี เมื่อเปิดตัวแอปพลิเคชันแล้ว คุณยังรวบรวมสัญญาณในแอปได้ด้วย เช่น การให้คะแนนเป็นดาว แต่สัญญาณเหล่านี้มัก จะมีความผันผวนและขาดความแตกต่างที่จำเป็นสำหรับการเพิ่มประสิทธิภาพที่แม่นยำ
- LLM ในฐานะกรรมการเป็นวิธีที่ปรับขนาดได้ในการ ประเมินเกณฑ์อัตนัยโดยใช้โมเดล AI อื่นเพื่อให้คะแนนหรือวิจารณ์ เอาต์พุต ซึ่งเร็วกว่าการตรวจสอบจากเจ้าหน้าที่ แต่ก็มีข้อควรระวังเช่นกัน กล่าวคือ ในการใช้งานแบบง่ายๆ อาจทำให้เกิดการคงอยู่และแม้แต่การเสริมอคติและช่องว่างด้านความรู้ ของโมเดล
ให้ความสำคัญกับคุณภาพมากกว่าปริมาณ ในแมชชีนเลิร์นนิงและ AI เชิงคาดการณ์แบบคลาสสิก แนวทางปฏิบัติทั่วไปคือการใช้การจัดหาข้อมูลจากมวลชนเพื่อประกอบคำอธิบายประกอบข้อมูล สำหรับ Generative AI ผู้ใส่คำอธิบายประกอบที่มาจากฝูงชนมักขาดบริบทของโดเมน การประเมินที่มีคุณภาพสูงและมีบริบทที่สมบูรณ์ มีความสำคัญมากกว่าขนาด
ประเมินและเพิ่มประสิทธิภาพ
ยิ่งทดสอบและปรับแต่งพรอมต์ได้เร็วเท่าไร คุณก็จะยิ่งได้ผลลัพธ์ที่สอดคล้องกับความคาดหวังของผู้ใช้เร็วเท่านั้น คุณต้องสร้างนิสัยในการ เพิ่มประสิทธิภาพอย่างต่อเนื่อง ลองปรับปรุง ประเมิน และลองทำอย่างอื่น
เมื่อใช้งานจริงแล้ว ให้สังเกตและประเมินพฤติกรรมของผู้ใช้ และระบบ AI ต่อไป จากนั้นวิเคราะห์และเปลี่ยนข้อมูลนี้เป็น ขั้นตอนการเพิ่มประสิทธิภาพ
ทำให้ไปป์ไลน์การประเมินเป็นไปโดยอัตโนมัติ
หากต้องการลดอุปสรรคในการเพิ่มประสิทธิภาพ คุณต้องมีโครงสร้างพื้นฐานด้านการปฏิบัติงานที่ทำงานอัตโนมัติในการประเมิน ติดตามการเปลี่ยนแปลง และเชื่อมต่อการพัฒนาเข้ากับการใช้งานจริง ซึ่งมักเรียกว่า LLMOps แม้ว่าจะมีแพลตฟอร์มที่ช่วยในการทำงานอัตโนมัติ แต่คุณควรออกแบบเวิร์กโฟลว์ที่เหมาะสมก่อนที่จะใช้โซลูชันของบุคคลที่สาม
โดยองค์ประกอบสำคัญที่ควรพิจารณามีดังนี้
- การควบคุมเวอร์ชัน: จัดเก็บพรอมต์ เมตริกการประเมิน และอินพุตการทดสอบในระบบควบคุมเวอร์ชัน ถือว่าไฟล์เหล่านี้เป็นโค้ดเพื่อให้มั่นใจว่าสามารถทำซ้ำได้และมีประวัติการเปลี่ยนแปลงที่ชัดเจน
- การประเมินแบบกลุ่มอัตโนมัติ: ใช้เวิร์กโฟลว์ (เช่น GitHub Actions) เพื่อเรียกใช้ การประเมินการอัปเดตพรอมต์แต่ละรายการและสร้างรายงานการเปรียบเทียบ
- CI/CD สำหรับพรอมต์: ควบคุมการติดตั้งใช้งานด้วยการตรวจสอบอัตโนมัติ เช่น การทดสอบที่กำหนดได้ คะแนน LLM ในฐานะผู้พิพากษา หรือการป้องกัน และบล็อกการผสาน เมื่อคุณภาพลดลง
- การบันทึกและการสังเกตการณ์ในเวอร์ชันที่ใช้งานจริง: บันทึกอินพุต เอาต์พุต ข้อผิดพลาด เวลาในการตอบสนอง และการใช้โทเค็น ตรวจสอบการเปลี่ยนแปลง รูปแบบที่ไม่คาดคิด หรือการเพิ่มขึ้น ของความล้มเหลว
- การนำเข้าความคิดเห็น: รวบรวมสัญญาณของผู้ใช้ (ชอบ เขียนใหม่ ละทิ้ง) และเปลี่ยนปัญหาที่เกิดขึ้นซ้ำๆ ให้เป็นกรณีทดสอบใหม่
- การติดตามการทดสอบ: ติดตามเวอร์ชันพรอมต์ การกำหนดค่าโมเดล และ ผลการประเมิน
ทำการเปลี่ยนแปลงเล็กๆ น้อยๆ ที่ตรงเป้าหมาย
โดยปกติแล้ว การปรับแต่งพรอมต์จะเริ่มต้นด้วยการปรับปรุงภาษาของพรอมต์ ซึ่งอาจหมายถึงการทำให้คำสั่งมีความเฉพาะเจาะจงมากขึ้น ชี้แจงเจตนา หรือขจัดความคลุมเครือ
ระวังอย่าให้โมเดลมีความซับซ้อนมากเกินไป ข้อผิดพลาดที่พบบ่อยคือการเพิ่มกฎที่แคบเกินไปเพื่อ แก้ไขปัญหาโมเดล ตัวอย่างเช่น หากเครื่องมือสร้างชื่อสร้างชื่อที่ขึ้นต้นด้วยคำแนะนำที่ครอบคลุมอยู่เรื่อยๆ คุณอาจอยากห้ามใช้คำนี้อย่างชัดเจน แต่ให้สรุปปัญหาและปรับคำสั่งระดับสูงกว่าแทน ซึ่งอาจหมายความว่าคุณเน้นความเป็นต้นฉบับ ความหลากหลาย หรือรูปแบบบรรณาธิการที่เฉพาะเจาะจง เพื่อให้โมเดลเรียนรู้ค่ากำหนดพื้นฐานแทนที่จะเป็นข้อยกเว้นเพียงรายการเดียว
อีกแนวทางหนึ่งคือการทดลองใช้เทคนิคการแจ้งเพิ่มเติมและรวมความพยายามเหล่านี้เข้าด้วยกัน เมื่อเลือกเทคนิค ให้ถามตัวเองว่างานนี้ควรแก้ด้วย การเปรียบเทียบ (Few-Shot), การให้เหตุผลแบบทีละขั้นตอน (Chain-of-Thought) หรือ การปรับแต่งแบบวนซ้ำ (Self-Reflection)
เมื่อระบบเข้าสู่การใช้งานจริง ฟลายวีล EDD ไม่ควรช้าลง หากมีอะไรเกิดขึ้น ก็ควรจะเร่งให้เร็วขึ้น หากระบบประมวลผลและบันทึกข้อมูลที่ผู้ใช้ป้อน ข้อมูลเหล่านี้ควรกลายเป็นแหล่งข้อมูลเชิงลึกที่มีค่ามากที่สุด เพิ่มรูปแบบที่เกิดซ้ำ ลงในชุดการประเมิน และระบุและใช้ขั้นตอนการเพิ่มประสิทธิภาพที่ดีที่สุดถัดไปอย่างต่อเนื่อง
สิ่งที่ได้เรียนรู้
การพัฒนาพรอมต์ที่อิงตามการประเมินจะช่วยให้คุณมีวิธีที่มีโครงสร้างในการรับมือกับความไม่แน่นอนของ AI การกำหนดปัญหาอย่างชัดเจน การสร้างระบบการประเมินที่ปรับแต่งแล้ว และการทำซ้ำผ่านการปรับปรุงเล็กๆ ที่ตรงเป้าหมายจะช่วยให้คุณสร้างวงจรความคิดเห็นที่ปรับปรุงเอาต์พุตของโมเดลได้อย่างต่อเนื่อง
แหล่งข้อมูล
หากต้องการใช้ LLM เป็นผู้ตรวจสอบ เราขอแนะนำให้อ่านข้อมูลต่อไปนี้
- เปรียบเทียบความสามารถของ LLM กับการสรุป
- อ่านคำแนะนำของ Hamel Husain เกี่ยวกับการใช้ LLM เป็นผู้ตรวจสอบ
- อ่านเอกสาร A Survey on LLM-as-a-Judge
หากสนใจปรับปรุงพรอมต์เพิ่มเติม โปรดอ่านข้อมูลเพิ่มเติมเกี่ยวกับการพัฒนาที่รับรู้บริบท ซึ่งวิศวกรแมชชีนเลิร์นนิงจะทำได้ดีที่สุด
ทดสอบความเข้าใจ
เป้าหมายหลักของการพัฒนาที่ขับเคลื่อนด้วยการประเมินคืออะไร
เหตุใดจึงควรใช้โมเดลขนาดใหญ่ขึ้นเพื่อประเมินระบบฝั่งไคลเอ็นต์
ข้อควรระวังที่อาจเกิดขึ้นจากการใช้ LLM เป็นผู้ตัดสินในการประเมินคืออะไร
คอมโพเนนต์ใดเป็นส่วนหนึ่งของไปป์ไลน์การประเมินอัตโนมัติที่แนะนำ
เมื่อเลือกผู้พิพากษาสำหรับระบบการประเมิน ข้อจำกัดหลักของการใช้ความคิดเห็นจากมนุษย์คืออะไร