คุณเคยพบไหมว่าพรอมต์หนึ่งเคยใช้ได้ผลดี แต่อยู่ ๆ กลับใช้ไม่ได้อีกต่อไป
คุณเคยติดอยู่ในวงจรที่ต้องคอยแก้พรอมต์ระบบเพื่อปรับปรุงผลลัพธ์ แต่ไม่ว่าจะทำอย่างไรก็ไม่ได้ผลหรือไม่
การเรียนรู้พรอมต์ระบบอาจเป็นสิ่งที่คุณต้องการพอดี
การเรียนรู้พรอมต์ระบบ (SPL) เป็นหัวข้อใหม่ที่กำลังได้รับความสนใจในชุมชน AI และในเดือนพฤษภาคม Andrej Karpathy ได้เผยแพร่แนวคิดนี้บน X จนเป็นที่รู้จักอย่างกว้างขวาง
การเรียนรู้พรอมต์ระบบช่วยแก้ข้อจำกัดของระบบ AI ที่ปรับเปลี่ยนได้ยากและเปราะบาง ซึ่งต้องพึ่งพรอมต์ระบบแบบตายตัวหรือกระบวนการปรับแต่งโมเดลที่เทอะทะ นี่เป็นอีกวิธีหนึ่งในการส่งเสริมให้ระบบ AI เรียนรู้อย่างต่อเนื่อง
ก่อนจะลงรายละเอียด เรามาทบทวนพื้นฐานบางประการเกี่ยวกับการเขียนพรอมต์กันสั้น ๆ
เมื่อพัฒนาเอเจนต์หรือโมเดลเฉพาะ เราต้องออกแบบองค์ประกอบสำคัญสองอย่างก่อน ได้แก่
พรอมต์ระบบ
พรอมต์ผู้ใช้
พรอมต์ระบบกำหนดหลักเกณฑ์พื้นฐานว่าโมเดลควรทำงานอย่างไร เมื่อเขียนขึ้นสำหรับโซลูชัน AI เฉพาะทาง พรอมต์เหล่านี้มักเริ่มต้นในลักษณะนี้
“You are an intelligent assistant. Your role is to perform <insert task here>.
You must not do (A), (B), or (C).”
ในทางตรงกันข้าม พรอมต์ผู้ใช้ มักประกอบด้วยคำถามของผู้ใช้และข้อมูลอื่นที่เกี่ยวข้อง เช่น เขตเวลาและความชอบของผู้ใช้ พรอมต์ผู้ใช้อาจมีลักษณะดังนี้
I’m in the capital city of Portugal. Can you suggest some things I can do tonight?
หลังห้องปฏิบัติการ AI รายใหญ่เปิดตัวโมเดลใหม่ เหตุการณ์พรอมต์ระบบรั่วไหลก็กลายเป็นเรื่องปกติ เพราะผู้ใช้เจลเบรกแชตบอตเพื่อให้เปิดเผยคำสั่งเบื้องหลัง ปัจจุบัน Repository ยอดนิยมบน GitHub ได้รวบรวมพรอมต์ระบบเหล่านี้ไว้ในที่เดียวเป็นจำนวนมาก พรอมต์เหล่านี้เผยให้เห็น “เคล็ดลับสำคัญ” ที่ห้องปฏิบัติการ AI พัฒนาขึ้นเรื่อย ๆ เพื่อส่งเสริมให้โมเดลทำงานอย่างเหมาะสม ตัวอย่างเช่น พรอมต์ระบบของ GPT-5 ที่รั่วไหลเมื่อไม่นานมานี้ (เปิดเผยผ่าน ChatGPT) มีความยาวประมาณ 6,000 คำ แสดงให้เห็นว่าต้องเข้ารหัสความรู้และแนวทางไว้มากเพียงใดเพื่อกำหนดพฤติกรรมของระบบ
พรอมต์ระบบที่ครอบคลุมเหล่านี้มักกล่าวถึงประเด็นสำคัญหลายด้าน เช่น
คำสั่งสำหรับการค้นหา
คำจำกัดความของเครื่องมือ
ความชอบของผู้ใช้
คำสั่งสำหรับการอ้างอิงแหล่งข้อมูล
การแก้ไขปัญหาที่ทราบแล้วแบบเร่งด่วน
ในทางปฏิบัติ นักพัฒนาระบบ AI เฉพาะทางจะทดสอบและปรับปรุงแอปพลิเคชันซ้ำ ๆ พร้อมแก้พรอมต์ระบบด้วยตนเอง โดยอาศัย การประเมิน เป็นหลักในการชี้นำกระบวนการปรับปรุงนี้
วิธีอื่นในการกำหนดพฤติกรรมของโมเดล ได้แก่
วิศวกรรมคำสั่ง ซึ่งรวมถึงการสร้างคำตอบโดยเสริมข้อมูลจากการค้นคืน (RAG) เพื่อควบคุมเนื้อหาที่ส่งให้โมเดล
การปรับแต่งโมเดล (เปลี่ยนค่าน้ำหนักพื้นฐานของโมเดลโดยตรง)
ถ้ามีวิธีอื่นในการเปลี่ยนแปลงพฤติกรรมของโมเดลล่ะ ลองจินตนาการถึงระบบที่เรียนรู้และปรับปรุงพรอมต์ระบบของตัวเองแบบไดนามิก โดยใช้ความคิด แผน และกลยุทธ์ที่เคยสร้างไว้ ระบบนี้อาจใช้ทั้งความคิดเห็นจากผู้ใช้และการประเมินแบบ LLM-as-a-judge เพื่อประเมินผลลัพธ์ของตน
ลองนึกถึงความท้าทายทางธุรกิจที่เกิดขึ้นอย่างต่อเนื่อง ซึ่งคุณต้องการทำให้เป็นระบบอัตโนมัติด้วยระบบเอเจนต์ โซลูชันที่มีประสิทธิผลต้องใช้ความสามารถด้านการให้เหตุผลที่เหนือกว่าระบบเวิร์กโฟลว์อัตโนมัติขั้นพื้นฐาน ในกรณีเช่นนี้ การเพิ่มองค์ประกอบสำหรับสร้างแผนลงในระบบ AI เป็นสิ่งจำเป็น วิธีนี้ทำให้ระบบทำงานร่วมกับเอเจนต์หลายตัวได้หลายรูปแบบตามลักษณะของงาน แต่ละขั้นตอนอาจมีคำสั่งให้เข้าถึงเอเจนต์อื่นเพื่อทำงานย่อยให้เสร็จ หรือให้ใช้ เครื่องมือ
หมายเหตุ: เครื่องมือของเอเจนต์คือฟังก์ชันภายนอก API หรือทรัพยากรใด ๆ ที่เอเจนต์ AI เรียกใช้เพื่อทำสิ่งอื่นนอกเหนือจากข้อความและดำเนินการจริงได้
คุณอาจเลือก “ตั้งต้น” พรอมต์ระบบของโมเดลด้วยแผนที่ทำตามขั้นตอนเชิงตรรกะของมนุษย์ แต่โดยทั่วไป LLM ต้องการคำแนะนำที่เฉพาะเจาะจงยิ่งขึ้นเกี่ยวกับการใช้เครื่องมือ รูปแบบผลลัพธ์ และข้อกำหนดอื่นที่เกี่ยวข้อง บางครั้งกลยุทธ์ที่เหมาะสมที่สุดอาจไม่ชัดเจน หรือคุณอาจกำลังจัดการปัญหาที่ไม่ได้รับการประเมินใหม่ เพราะก่อนหน้านี้เคยคิดว่าแก้ไขเรียบร้อยแล้ว นี่คือจุดที่การเรียนรู้พรอมต์ระบบ (SPL) เข้ามามีบทบาท
SPL ปรับปรุงพรอมต์ระบบซ้ำ ๆ โดยนำกลยุทธ์ที่เคยสร้างไว้มาใช้ เมื่อเกิดปัญหาใหม่ ระบบจะค่อย ๆ สะสมความรู้และแข็งแกร่งยิ่งขึ้น ลองนึกภาพว่าเป็นการสร้างคู่มือสำหรับแก้ปัญหาในขอบเขตงานของคุณ
SPL จะค่อย ๆ นำข้อมูลเชิงลึกจากความคิดเห็นของผู้ใช้มารวมไว้ในพรอมต์ระบบ เมื่อระบบพัฒนาขึ้น คุณอาจพบปัญหาที่เกิดซ้ำและสามารถกลั่นออกมาเป็นหลักการทั่วไปในระดับที่สูงขึ้นได้
มาดูกันอย่างละเอียดขึ้นว่ากระบวนการนี้ทำงานอย่างไรในแต่ละขั้นตอน
เริ่มจากคำถามของผู้ใช้ โดยขอให้ระบบทำงานหนึ่งอย่างที่ระบุไว้
หากระบบของคุณรองรับเพียงปัญหาเดียว คุณอาจใช้แนวทางแบบ “ละโมบ” โดยเลือกกลยุทธ์ที่ได้คะแนนสูงสุดจากการทำงานครั้งก่อน อีกทางหนึ่ง คุณสามารถส่งเสริมการสำรวจด้วยการสุ่มตัวอย่างจากการแจกแจงที่ให้น้ำหนักแก่กลยุทธ์คะแนนสูง แต่ใส่กลยุทธ์คะแนนต่ำเข้ามาเป็นครั้งคราว วิธีนี้มีประโยชน์เป็นพิเศษเมื่อคุณเพิ่งเริ่มรวบรวมกลยุทธ์
สำหรับระบบที่ออกแบบมาเพื่อรองรับชุดปัญหาหลากหลาย ให้พิจารณาเพิ่มชั้นการจัดประเภท หรือใช้ เวกเตอร์ฝังตัวและความคล้ายคลึงแบบโคไซน์ (เทคนิคเดียวกับที่มักใช้ใน RAG) เพื่อค้นหาแนวทางที่เกี่ยวข้อง วิธีนี้ช่วยให้คุณเลือกกลยุทธ์ที่เหมาะกับปัญหาเฉพาะได้ เช่น กลยุทธ์ที่ออกแบบมาสำหรับงานเขียนโค้ด
หมายเหตุ: เวกเตอร์ฝังตัวที่ใช้ร่วมกับความคล้ายคลึงแบบโคไซน์ช่วยให้เราวัดได้ว่าข้อมูลสองส่วนเกี่ยวข้องกันมากเพียงใด จึงจับคู่เอกสาร คำถาม หรือแนวคิดได้ง่ายขึ้น แม้จะใช้ถ้อยคำต่างกันก็ตาม
ตัวอย่างจุดเริ่มต้นของคลังกลยุทธ์แบบง่ายสำหรับแก้ปัญหาการเขียนโค้ด
หมายเหตุ: “กลยุทธ์ตั้งต้น” ที่แสดงในที่นี้มีไว้เป็นตัวอย่าง ในสถานการณ์การเขียนโค้ดจริง เราจะปรับปรุงกลยุทธ์เหล่านี้เพิ่มเติม ปัญหาธุรกิจเฉพาะทางจำเป็นต้องรวบรวมข้อมูลเชิงลึกเพิ่มเติมเมื่อเวลาผ่านไป
Generation_id (เรียงย้อนกลับ) | หัวข้อ | คะแนน | Strategy_text | คำอธิบาย |
|---|---|---|---|---|
4 | การเขียนโค้ด | 1 | ทำความเข้าใจปัญหา ข้อจำกัด และกรณีขอบ ออกแบบอัลกอริทึมด้วยโครงสร้างข้อมูลที่เหมาะสม ตรวจสอบแผนกับตัวอย่างและเงื่อนไขคงสภาพ เขียนโค้ดที่เป็นระเบียบและอ่านง่าย ปรับปรุงด้วยการปรับโครงสร้าง เพิ่มประสิทธิภาพ และจัดรูปแบบขั้นสุดท้าย การใช้เครื่องมือ: เมื่อใช้เครื่องมือ ให้อธิบายสั้น ๆ ว่าเหตุใดจึงจำเป็นต้องใช้ | นำองค์ประกอบที่แข็งแกร่งที่สุดจากสามกลยุทธ์ด้านล่างมาผสานรวมกัน |
3 | การเขียนโค้ด | 1 | ทำความเข้าใจปัญหา ข้อจำกัด และกรณีขอบ ออกแบบอัลกอริทึมด้วยโครงสร้างข้อมูลที่เหมาะสม ตรวจสอบแผนกับตัวอย่างและเงื่อนไขคงสภาพ เขียนโค้ดที่เป็นระเบียบและอ่านง่าย ปรับปรุงด้วยการปรับโครงสร้าง เพิ่มประสิทธิภาพ และจัดรูปแบบขั้นสุดท้าย | เป็นกลยุทธ์ที่รอบด้านมากขึ้น แต่ไม่มีคำแนะนำเกี่ยวกับการใช้เครื่องมือ |
2 | การเขียนโค้ด | -1 | ทำความเข้าใจปัญหา ข้อจำกัด และกรณีขอบ ออกแบบอัลกอริทึมด้วยข้อมูลที่เหมาะสม เขียนโค้ดที่เป็นระเบียบและอ่านง่าย การใช้เครื่องมือ: เมื่อเข้าถึงเครื่องมือ ให้สรุปสั้น ๆ ว่าเหตุใดคุณจึงใช้เครื่องมือนั้น | เป็นกลยุทธ์ที่ดีขึ้นและกล่าวถึงการใช้เครื่องมือ แต่ยังปรับปรุงได้อีก |
1 | การเขียนโค้ด | -1 | อ่านปัญหาคร่าว ๆ แก้ปัญหา สร้างการทดสอบขั้นต่ำ ส่งอะไรก็ได้ที่รันได้ | กล่าวถึงการทดสอบ แต่โดยรวมเป็นกลยุทธ์ที่อ่อนแอ |
3. หลังสุ่มตัวอย่าง N รายการแล้ว ให้นำรายการเหล่านั้นมารวมไว้ในพรอมต์ระบบ วิธีนี้ทำให้การสร้างแผนอิงกับความคิดเห็นของผู้เชี่ยวชาญที่ผ่านมา แทนที่จะปล่อยให้โมเดลสร้างแผนโดยมีคำแนะนำเพียงเล็กน้อย กระตุ้นให้โมเดล “คิดนอกกรอบ” และเพิ่มขั้นตอนเมื่อจำเป็น แทนที่จะคัดลอกกลยุทธ์ตัวอย่างทุกคำ
4. ใช้พรอมต์ระบบที่สร้างขึ้นแบบไดนามิกเพื่อสร้างกลยุทธ์ใหม่สำหรับตอบคำขอของผู้ใช้ กระบวนการนี้ควรสร้างงานเพิ่มเติมที่จะช่วยปรับปรุงผลลัพธ์สุดท้าย เป้าหมายคือความคิดสร้างสรรค์ โดยผสานจุดแข็งที่สุดของกลยุทธ์ก่อนหน้า รวมขั้นตอนที่ซ้ำซ้อน และเพิ่มขั้นตอนใหม่ที่เป็นประโยชน์เมื่อจำเป็น
หมายเหตุ: โปรดจำว่า temperature เป็นพารามิเตอร์ที่ปรับได้เพื่อให้ผลลัพธ์หลากหลายและคาดเดาได้น้อยลง ซึ่งมีประโยชน์เมื่อต้องการความคิดสร้างสรรค์ เมื่อตั้งค่า temperature มากกว่าศูนย์ แผนที่สร้างขึ้นแต่ละครั้งอาจแตกต่างกัน
5. หลังได้รับผลลัพธ์จากโมเดล ให้ผู้ประเมินที่เป็นมนุษย์หรือ LLM ที่ทำหน้าที่ตัดสินประเมินผลลัพธ์ตามเกณฑ์เฉพาะซึ่งกำหนดว่าโซลูชันที่ดีสำหรับปัญหาของคุณควรเป็นอย่างไร สำหรับ ตัวอย่างกิจกรรมในโปรตุเกส ที่กล่าวถึงก่อนหน้านี้ เกณฑ์การประเมินอาจประกอบด้วย
ความกระชับ (จำกัดคำตอบไว้เพียงหนึ่งประโยค)
ความเกี่ยวข้องของกิจกรรมที่แนะนำ
ความถูกต้องของสถานที่
6. ใช้โมเดลอีกตัวปรับปรุงกลยุทธ์ตามผลการประเมินนี้ คุณอาจเพิ่มวงจรป้อนกลับที่รับความคิดเห็นจากมนุษย์และสนับสนุนการปรับปรุงร่วมกันได้ จัดเก็บกลยุทธ์ที่ปรับปรุงแล้วไว้ในฐานข้อมูล พร้อมข้อมูลเมตาที่เหมาะสมสำหรับติดตามเวอร์ชันและการเปลี่ยนแปลง
แล้วเหตุใดจึงต้องยุ่งยากทำทั้งหมดนี้ คุณอาจตรวจสอบผลลัพธ์ด้วยตนเองแล้วปรับพรอมต์ระบบให้สอดคล้องกัน อย่างไรก็ตาม โมเดลการให้เหตุผลที่ทรงพลังสามารถปรับปรุงกลยุทธ์โดยใช้ทั้งบริบทของผลลัพธ์และความคิดเห็นจากมนุษย์ แม้มนุษย์จะมองเห็นข้อบกพร่องของแนวทางง่าย ๆ ได้ไม่ยาก แต่เมื่อเป็นระบบซับซ้อนที่รองรับชุดปัญหากว้างขึ้น การค้นหาข้อบกพร่องจะยากและน่าเบื่อหน่าย
LLM มักต้องอาศัยคำสั่งโดยละเอียดและขั้นตอนเพิ่มเติม เพื่อรวบรวมความรู้ด้านบริบทที่มนุษย์นำมาใช้แก้ปัญหาได้โดยธรรมชาติ จำนวนงานที่ต้องทำอาจเพิ่มขึ้นอย่างรวดเร็ว เมื่อระบบขยายไปสู่การรองรับชุดปัญหาที่กว้างขึ้น ตัวอย่างเช่น มนุษย์ที่แก้ปัญหาการเขียนโค้ดอาจเข้าใจโค้ดเบสโดยรอบได้โดยสัญชาตญาณ ส่วน LLM อาจต้อง “อ่าน” ไฟล์หลายไฟล์ก่อน
กรณีที่มีประโยชน์: ลองนึกว่าคุณบริหารทีมสนับสนุนลูกค้า โดยมีเอเจนต์ AI ทำหน้าที่คัดแยกทิกเก็ต เมื่อเวลาผ่านไป SPL อาจค้นพบวิธีจัดหมวดหมู่ที่ทีมของคุณไม่เคยนึกถึง ซึ่งช่วยลดอัตราการส่งต่อปัญหา
กรณีที่ไม่มีประโยชน์: หากข้อกำหนดด้านการปฏิบัติตามกฎหรือกฎระเบียบกำหนดเวิร์กโฟลว์ไว้แล้ว เช่น การรายงานทางการเงิน SPL อาจมีประโยชน์เพียงเล็กน้อย เพราะความคิดสร้างสรรค์จะกลายเป็นความเสี่ยงแทนที่จะเป็นข้อดี
กรณีที่มีประโยชน์: ในบทบาทที่เน้นการวิจัยอย่างเข้มข้น (เช่น ข่าวกรองตลาดหรือกลยุทธ์ผลิตภัณฑ์) คุณสามารถทำงานร่วมกับ AI โดยปรับปรุงแผน เพิ่มข้อมูลในผลลัพธ์ และนำสิ่งที่ปรับปรุงแล้วไปใช้ในอนาคต การโต้ตอบแต่ละครั้งช่วยเพิ่มประสิทธิผลของระบบ
กรณีที่ไม่มีประโยชน์: หากทีมของคุณใช้ AI เป็นหลักกับเวิร์กโฟลว์ที่ตรงไปตรงมาและต้องการข้อมูลจากมนุษย์เพียงเล็กน้อย (เช่น การประมวลผลใบแจ้งหนี้) ภาระในการทำงานร่วมกันอาจมากกว่าประโยชน์ที่ได้รับ
กรณีที่มีประโยชน์: สมมติว่าคุณขยายธุรกิจไปยังภูมิภาคใหม่ และจู่ ๆ AI ต้องตอบข้อสงสัยเกี่ยวกับภาษีท้องถิ่น SPL ช่วยให้คุณเพิ่มกฎและหลักการคร่าว ๆ ใหม่ได้อย่างรวดเร็วเมื่อมีข้อมูลใหม่เกิดขึ้น จึงป้องกันไม่ให้เกิดข้อผิดพลาดซ้ำ
กรณีที่ไม่มีประโยชน์: หากสภาพแวดล้อมของคุณไม่เปลี่ยนแปลง เช่น การแปลงบทถอดเสียงการประชุมเป็นสรุปตามรูปแบบมาตรฐาน การปรับตัวอย่างต่อเนื่องแทบไม่มีประโยชน์
ในทางทฤษฎี ทั้งหมดนี้ฟังดูมีแนวโน้มที่ดี แต่การนำ SPL มาใช้มีความท้าทายอยู่จริง เราจะกล่าวถึงความท้าทายหลักบางประการด้านล่าง
ในช่วงแรกของการสร้างกลยุทธ์ ความคืบหน้ามักหยุดชะงัก เพราะผลลัพธ์ใหม่ไม่ต่อยอดจากผลลัพธ์ก่อนหน้า ทำให้การพัฒนาช้าลง ปัญหานี้มักเกิดจากสาเหตุหลักสองประการ
วิธีแก้: เข้ารหัสความรู้ทางธุรกิจทั้งหมดที่มีไว้ตั้งแต่ต้น เพื่อให้ระบบมีความรู้เชิงลึกสำหรับนำมาใช้
วิธีแก้: ออกแบบเกณฑ์ให้ละเอียดและให้คะแนนคำตอบหลายด้าน เช่น ความถูกต้อง ความชัดเจน และความเกี่ยวข้อง จากนั้นปรับการสุ่มตัวอย่างให้สอดคล้องกับสัญญาณเหล่านี้
หากระบบสร้างกลยุทธ์หลายร้อยรายการ แต่ได้รับความคิดเห็นเพียงเล็กน้อยจนแยกกลยุทธ์ที่ดีออกจากกลยุทธ์ที่ไม่ดีไม่ได้ การสุ่มตัวอย่างจะจัดการได้ยากอย่างรวดเร็ว คำตอบคือการคัดออก
เมื่อปรับปรุงคลังกลยุทธ์ โปรดพิจารณาสิ่งต่อไปนี้
อายุการใช้งาน: เลิกใช้กลยุทธ์เมื่อเกินกรอบเวลาหรือจำนวนรุ่นที่กำหนด
คะแนน: ใช้เกณฑ์การประเมินเพื่อกรองกลยุทธ์ที่ให้ผลลัพธ์ต่ำอย่างต่อเนื่องออก การใช้คะแนนร่วมกับอายุการใช้งานช่วยให้มั่นใจว่าคุณจะเก็บไว้เฉพาะแนวทางที่พิสูจน์คุณค่าได้เมื่อเวลาผ่านไป
การตัดสินโดย LLM: ประเมินกลยุทธ์เป็นระยะเพื่อค้นหากลยุทธ์ที่ไม่ได้เพิ่มข้อมูลเชิงลึกที่แตกต่างอีกต่อไป เนื่องจากองค์ประกอบที่มีประโยชน์น่าจะถูกรวมไว้ในเวอร์ชันใหม่แล้ว
วิธีแก้: ปฏิบัติต่อฐานข้อมูลกลยุทธ์เสมือนเป็นระบบที่มีชีวิต โดยคัดรายการออกเป็นประจำ เพื่อให้เหลือเฉพาะความรู้ที่เกี่ยวข้องและมีคุณค่าสูง
การเรียนรู้พรอมต์ระบบยังอยู่ในช่วงเริ่มต้น แต่มีศักยภาพมหาศาล ธุรกิจที่พึ่งพาเพียงพรอมต์แบบตายตัวหรือการปรับแต่งโมเดลอย่างไม่สิ้นสุด จะพบข้อจำกัดเดิม ๆ ได้แก่ ระบบที่เปราะบาง ค่าใช้จ่ายที่เพิ่มขึ้น และความพยายามที่สูญเปล่า SPL เป็นทางออกจากวงจรนี้ ด้วยการสร้างระบบที่พัฒนาขึ้นตามเวลาและเข้ารหัสหลักการระดับสูง แทนการแก้ปัญหาเฉพาะจุด
SPL ยังคงเป็นแนวทางใหม่ แต่ทิศทางชัดเจนแล้วว่า ระบบที่เรียนรู้จากตัวเองได้จะก้าวหน้ากว่าระบบที่ทำไม่ได้ ตอนนี้คือเวลาที่ควรทดลอง เริ่มจากจุดเล็ก ๆ บันทึกบทเรียน และวางรากฐานให้ระบบ AI ที่พัฒนาขึ้นทุกครั้งที่มีการโต้ตอบ