- เมื่อ ทำงานร่วมกับ LLM อย่าง Claude หรือ Codex เป็นเวลานาน ความเหนื่อยล้าจะสะสมจนทำให้ประสิทธิภาพการทำงานลดลงอย่างรวดเร็ว
- คุณภาพของพรอมป์ต์ที่ลดลงเพราะความล้า จะทำให้คุณภาพของผลลัพธ์แย่ลง และยิ่งคอยตัดจังหวะหรือแก้โมเดลกลางคันมากเท่าไร ประสิทธิภาพก็ยิ่งแย่ลง
- ปัญหาวงจรฟีดแบ็กที่ช้าและคอนเท็กซ์ที่ใหญ่เกินไป ทำให้การทดลองซ้ำทำได้ยาก และลดประสิทธิภาพของงาน
- แนวทางที่ได้ผลคือการรักษา ความสนุกในการเขียนพรอมป์ต์และความชัดเจนของเป้าหมาย เอาไว้ พร้อมนิยามวงจรที่ช้านั้นให้เป็นปัญหาที่ต้องปรับปรุง
- หัวใจสำคัญของการใช้ LLM คือ ฟีดแบ็กที่รวดเร็วและการกำหนดเกณฑ์ความสำเร็จที่ชัดเจน ซึ่งช่วยลดเวลาในการดีบักและให้ผลลัพธ์ที่ฉลาดกว่าขึ้น
ความเหนื่อยล้าและความเร็วในการทดลองที่ช้า
- เมื่อ ความเหนื่อยล้าทางจิตใจ สะสม คุณภาพของพรอมป์ต์จะลดลง และส่งผลให้คุณภาพของคำตอบจาก LLM ลดลงตามไปด้วย
- ในสภาวะที่เหนื่อยล้า มักส่งพรอมป์ต์โดยตกหล่นคอนเท็กซ์สำคัญไป และเมื่อแก้ไขหรือหยุดกลางคันซ้ำ ๆ ผลลัพธ์ก็จะยิ่งแย่ลง
- ใน Claude Code หรือ Codex การ ‘แทรกแซงระหว่างทาง’ แบบนี้จะทำลายความสม่ำเสมอและนำไปสู่ผลลัพธ์ที่แย่กว่าเดิม
- มีการชี้ว่า ความช้าของวงจรฟีดแบ็ก คือปัญหาสำคัญ
- ในงานที่ใช้เวลานาน เช่น การพาร์สไฟล์ขนาดใหญ่ การรันใหม่ทุกครั้งจะช้า ทำให้รอบการทดลองยาวขึ้น
- เมื่อคอนเท็กซ์ใกล้เต็ม โมเดลอาจ ‘ทื่อขึ้น’ หรือสะท้อนผลการทดลองล่าสุดได้ไม่ดีพอ
เส้นทางสู่การทำงานร่วมกับ AI อย่างมีประสิทธิภาพ
- ต้องหลีกเลี่ยง วงจรอุบาทว์จากพรอมป์ต์ที่แย่ (‘doom-loop psychosis’)
- หากการเขียนพรอมป์ต์ไม่สนุก หรือเริ่มป้อนคำสั่งสั้น ๆ แบบขอไปทีซ้ำ ๆ นั่นคือสัญญาณว่าควรพัก
- การคาดหวังให้ AI มาเติมช่องโหว่ให้ทั้งที่ยังคิดปัญหาไม่รอบด้าน เป็นกับดักที่อันตราย
- พรอมป์ต์ที่มีเป้าหมายชัดเจนและมาพร้อมความมั่นใจ คือกุญแจสู่ความสำเร็จ
- พรอมป์ต์ที่เขียนโดยมองภาพผลลัพธ์ที่ต้องการไว้อย่างชัดเจน มักนำไปสู่คำตอบที่มีคุณภาพสูง
- ตรงกันข้าม หากเขียนด้วยความไม่แน่ใจหรือความเร่งรีบ ผลลัพธ์ก็มักไม่น่าพอใจ
นิยามวงจรฟีดแบ็กที่ช้าให้เป็นปัญหา
- ควร ตั้งให้ความเร็วของวงจรฟีดแบ็กเองเป็นเป้าหมายในการปรับปรุง
- ตัวอย่างเช่น เมื่อต้องจัดการปัญหาการพาร์ส อาจระบุเป้าหมายให้เวลาของลูปลดลงเหลือไม่เกิน 5 นาที และขอให้สามารถจำลองกรณีที่ล้มเหลวได้อย่างรวดเร็ว
- นี่เป็นแนวทางที่คล้ายกับ การพัฒนาแบบขับเคลื่อนด้วยการทดสอบ (TDD) ซึ่งช่วยเพิ่มความเร็วของการทดลองซ้ำ
- การระบุเกณฑ์ความสำเร็จอย่างชัดเจน จะดึงประสิทธิภาพของ LLM ออกมาได้สูงสุด
- หากให้เงื่อนไขที่เฉพาะเจาะจงอย่าง “จำลองกรณีล้มเหลวให้ได้ภายใน 5 นาที” LLM จะปรับเส้นทางของโค้ดให้เหมาะสมและตัดส่วนที่ไม่จำเป็นออก
- เมื่อมีวงจรฟีดแบ็กที่รวดเร็วแบบนี้ การใช้คอนเท็กซ์จะลดลง และโมเดลจะทำงานได้ ‘ฉลาดขึ้น’
บทสรุป
- ความเหนื่อยล้าจากการทำงานกับ LLM หลายครั้งอาจไม่ใช่ ปัญหาทางเทคนิค แต่เป็น ‘ปัญหาเรื่องทักษะ (skill issue)’
- ความเหนื่อยล้าทางการรับรู้และการโยนภาระการคิดออกไป (cognitive outsourcing) คือกับดักที่ทำให้ประสิทธิภาพลดลง
- ควรทำต่อก็ต่อเมื่อกระบวนการเขียนพรอมป์ต์ยังสนุก และมั่นใจได้ว่าผลลัพธ์จะทำให้พอใจมากกว่า 95%
- หากเริ่มรู้สึกว่า การดำเนินไปอย่างเชื่องช้าและคอนเท็กซ์ล้นเกิน เป็นปัญหา ก็ควรยกระดับสิ่งนั้นให้เป็นโจทย์ที่ต้องแก้ และออกแบบ โครงสร้างการทำซ้ำที่เร็วขึ้น ร่วมกับ LLM
ยังไม่มีความคิดเห็น