คู่มือไล่แก้ Prompt ที่พังจากโมเดลเก่า ฉบับวิศวกร Anthropic

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

ปมนี้คือสิ่งที่ Margot van Laar ในตำแหน่ง Applied AI Engineer จาก Anthropic ประจำลอนดอน หยิบมาแกะให้ผู้ฟังดูแบบสด ๆ ทีละขั้น บนเวทีปิดท้ายของงาน Code with Claude ในเซสชันที่ชื่อว่า 'The Prompting Playbook' โดยคุณ Margot บอกว่าการเขียน Prompt คือหนึ่งในทักษะแรก ๆ ที่วิศวกรต้องเรียนรู้ตั้งแต่วันที่เริ่มทำงานกับ Large Language Model และจนถึงวันนี้มันก็ยังเป็นทักษะที่สำคัญที่สุดอย่างหนึ่งในการสร้างระบบ AI ที่ใช้งานได้จริง

คุณ Margot เล่าว่างานเขียน Prompt ในชีวิตจริงมักวนอยู่กับสองสถานการณ์ หนึ่งคือการดูแล Prompt เดิมที่อยู่ในโปรดักชันมานาน แล้ววันดีคืนดีต้องย้ายโมเดลหรือปรับสถาปัตยกรรม จนมันเริ่มทำงานเพี้ยนโดยไม่รู้สาเหตุ สองคือการสร้างงานใหม่ในแบบที่ให้ AI ทำงานเป็นเอเจนต์อัตโนมัติ (Agentic) จากศูนย์ ที่ต้องปั้น Prompt ขึ้นมาตั้งแต่บรรทัดแรก และแทนที่จะไล่บอกเป็นข้อ ๆ ว่าอะไรควรทำหรือไม่ควรทำ คุณ Margot เลือกพาเดินผ่านตัวอย่างจริงที่หยิบแรงบันดาลใจมาจาก Prompt ของลูกค้า Anthropic ที่สร้างงานอยู่บน Claude

ตัวอย่างที่ยกมาคือ Prompt ของแชตบอตดูแลลูกค้า (Customer support bot) ให้กับบริษัทโทรคมนาคมสมมติชื่อ Meridian Mobile ซึ่งเป็นเวอร์ชันย่อส่วนของ Prompt จริงที่มักจะยาวและซับซ้อนกว่านี้มาก แต่สะท้อนปัญหาคลาสสิกที่หลายทีมเจอได้ดี ลองนึกถึง Prompt ที่มีหลายคนช่วยกันเขียน ช่วยกันต่อเติม ไม่มีเจ้าของชัดเจน ครอบคลุมทั้งนโยบาย โทนการพูด ขั้นตอนการทำงาน แถมยังมีแพตช์ที่เคยแปะไว้แก้ปัญหาของโมเดลรุ่นก่อน ๆ ปนกันมั่วไปหมด พอย้ายมาโมเดลใหม่ปุ๊บ เทสต์เคสจำนวนหนึ่งก็พังทันที

ย้ายไปโมเดลที่เก่งกว่า แต่ทำไมงานกลับพัง

คุณ Margot อธิบายว่า เวลาย้ายไปโมเดลใหม่แล้วระบบทำงานแย่ลง มันเกิดได้จากสองสาเหตุที่ต่างกันคนละเรื่อง สาเหตุแรกคือโมเดลใหม่ 'เก่งพอ' แต่มันแสดงพฤติกรรมต่างไปจากเดิม กรณีนี้เราจูน Prompt เพื่อดึงพฤติกรรมที่ต้องการกลับมาได้ ส่วนสาเหตุที่สองคือโมเดลที่ย้ายไปนั้นความสามารถไม่ถึง ซึ่งไม่ว่าจะเขียน Prompt เก่งแค่ไหนก็แก้ไม่ได้

ปัญหาคือถ้าไม่มีเครื่องมือวัด เราจะแยกสองกรณีนี้ออกจากกันไม่ได้เลย และนี่คือเหตุผลที่ทุกอย่างต้องเริ่มต้นจากจุดเดียวกัน นั่นคือชุดทดสอบประเมินผล หรือที่วิศวกรเรียกกันสั้น ๆ ว่า Eval (Evaluation) เพราะ Eval คือสิ่งที่ให้ความเข้มงวดกับเรา ทำให้รู้ว่าการแก้ Prompt แต่ละครั้งนั้น 'สัมพันธ์กับผลงานที่ดีขึ้นจริงหรือไม่' ไม่ใช่แค่รู้สึกว่าน่าจะดีขึ้น

ไม่มี Eval ก็เหมือนไล่แก้ Prompt ในความมืด

ในตัวอย่างวันนั้น คุณ Margot ใช้ Eval แบบย่อส่วนที่มีแค่ 5 เทสต์เคส ทั้งที่ของจริงควรมีมากกว่านี้เยอะ แต่ 5 เคสนี้ถูกเลือกมาให้ครอบคลุมสามประเภทหลักที่ชุดทดสอบที่ดีต้องมี

ประเภทแรกคือ Control case ซึ่งเป็นเคสที่ต้องผ่านเสมอ เป็นโจทย์ตรงไปตรงมาที่เรารู้อยู่แล้วว่าโมเดลตอบได้สบาย ๆ ประเภทที่สองคือ Edge case ซึ่งเป็นเคสที่เราเคยเห็นโมเดลตอบพลาดมาก่อน การใส่คำสั่งสำหรับเคสพวกนี้เข้าไปก็เพื่อกันไม่ให้พฤติกรรมเดิมหลุดออกมาอีกในอนาคต และประเภทที่สามที่สำคัญมากคือ การทำให้โมเดลเข้าใจขอบเขตความสามารถของตัวเอง ว่าตรงไหนควรส่งต่อให้มนุษย์ดูแล หรือตรงไหนที่มันควรปฏิเสธคำขอไปตรง ๆ เลยด้วยซ้ำ

พอแปลงเป็นโจทย์ของ Meridian Mobile ทั้ง 5 เคสจึงหน้าตาประมาณนี้ เคสควบคุมคือคำถามง่าย ๆ อย่างแพ็กเกจพื้นฐานมีลิมิตเน็ตเท่าไหร่ ถัดมาคือเคสชายขอบที่ต้องคำนวณ เช่น การคิดค่าบริการตามสัดส่วน (proration) เวลาลูกค้าเปลี่ยนแพ็กเกจกลางเดือนแล้วบิลรอบหน้าจะออกมาเท่าไหร่ ต่อมาคือการตอบคำถามที่อยู่ในนโยบายให้แม่นยำ ตามด้วยการส่งเรื่องต่อให้เจ้าหน้าที่ที่เป็นมนุษย์ทุกครั้งที่เจอปัญหาบิลผิดพลาด และเคสสุดท้ายคือการตรวจว่าโมเดลไม่ได้หวงข้อมูลที่ตัวเองเข้าถึงได้และควรส่งให้ลูกค้า

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

ก่อนไล่จับผิดทีละจุด ต้องเก็บกวาด Prompt ให้เรียบก่อน

ในการสาธิต คุณ Margot โชว์เว็บแอปที่เขียนขึ้นเองแบบ Vibe Coding (เขียนโปรแกรมเร็ว ๆ โดยให้ AI ช่วยปั่นโค้ดให้) สำหรับกดรัน eval ทั้ง 5 เคสและส่องผลลัพธ์ได้ในที่เดียว พอรันรอบแรก เคสควบคุมผ่านตามคาด แต่เคสอื่น ๆ ทำได้ค่อนข้างแย่ ทว่าก่อนจะซูมเข้าไปดูจุดที่พัง คุณ Margot เลือกทำความสะอาด Prompt แบบรวม ๆ ก่อน เพราะแค่อ่านผ่าน ๆ ก็เจอความผิดปกติหลายจุดแล้ว

จุดแรกคือ Prompt ดันบอกบอตว่าตัวเองเป็นมนุษย์ ซึ่งไม่จริง จุดต่อมาคือมีเนื้อหาที่ก๊อปมาจากหน้าเว็บไซต์ตรง ๆ สังเกตได้จากการอ้างถึงภาพหลักของหน้าเว็บ (hero image) และยังมีการพูดถึงคุกกี้ (cookie) ติดมาอยู่ท้าย ๆ ซึ่งเป็นข้อมูลส่วนเกินที่ต้องเอาออก แถมคำสั่งทั้งหมดยังถูกยัดรวมอยู่ในย่อหน้าก้อนเดียว ทั้งส่วนที่เป็นการให้เหตุผล ส่วนที่เป็นบทบาท และคำสั่งสำคัญ ปนกันจนแยกไม่ออกว่าอันไหนคือนโยบาย อันไหนคือไกด์ไลน์ อันไหนคือโทนการพูด

ทางแก้ที่คุณ Margot เลือกใช้คือเติมโครงสร้างเข้าไปด้วยแท็ก XML (Extensible Markup Language) เพื่อแยกส่วนบทบาทของบอต แยกไกด์ไลน์ทั่วไป แยกนโยบาย และแยกโทนการพูดออกจากกันให้ชัด พอรัน Eval ใหม่ ผลลัพธ์ก็ดีขึ้นทันทีในหลายเคส จะมีแค่เคสที่ห้าที่เป็นเรื่องฮอตสปอต (Hotspot) ที่ดูเหมือนถดถอยลงเล็กน้อย แต่คุณ Margot บอกว่ายังไม่ต้องกังวลกับมันตอนนี้ เพราะการรัน eval แต่ละรอบมีความแปรปรวน (Variance) ตามธรรมชาติอยู่แล้ว เดี๋ยวค่อยกลับมาจัดการเคสนั้นโดยเฉพาะ

บทเรียนจากขั้นนี้ตรงไปตรงมามาก แค่จัดบ้านให้ Prompt มีโครงสร้างที่ดีขึ้นและนิยามบทบาทให้ชัดขึ้น ผลงานก็ดีขึ้นได้เลย และนี่คือแนวทางที่กลับมาทำซ้ำได้ทุกช่วงของการเขียนและดูแล Prompt โดยเฉพาะเมื่อ Prompt ของคุณยิ่งยาวและซับซ้อนขึ้นเรื่อย ๆ คุณ Margot ทิ้งกฎง่าย ๆ ที่ยึดเป็นหลักไว้ว่า 'ถ้าคุณอ่าน Prompt แล้วยังแยกไม่ออกว่าอันไหนคือไกด์ไลน์ อันไหนคือนโยบาย อันไหนคือข้อมูล มีแนวโน้มสูงมากว่าโมเดลก็แยกไม่ออกเหมือนกัน'

ล็อกหน้าตาผลลัพธ์ด้วย Output Contract

ยังมีงานเก็บกวาดทั่วไปอีกอย่างที่ทำได้ก่อนจะลงรายละเอียด นั่นคือการสร้างสิ่งที่เรียกว่า Output Contract หรือข้อตกลงเรื่องรูปแบบผลลัพธ์ ซึ่งเป็นแนวทางสำคัญถ้าคุณกำลังมีปัญหาเรื่องรูปแบบเอาต์พุตไม่นิ่ง ในเคสแชตบอตดูแลลูกค้าที่ตอบด้วยภาษาคุยกันธรรมดา เรื่องนี้อาจไม่ใช่ปัญหาใหญ่ แต่มันสำคัญมากเมื่อต้องรับมือกับโครงสร้างผลลัพธ์ที่ซับซ้อนขึ้น เช่น JSON (JavaScript Object Notation) แบบซ้อนหลายชั้น

สิ่งที่คุณ Margot ทำคือเพิ่มส่วนท้าย Prompt ที่นิยามรูปแบบผลลัพธ์ให้โมเดล โดยสั่งให้ห่อคำตอบด้วยแท็ก XML แต่ประเด็นที่น่าสนใจคือ Prompt ไม่ใช่เครื่องมือที่ดีที่สุดเสมอไปในการจัดการทุกปัญหา เราปรับที่ระบบรอบ ๆ โมเดล หรือที่เรียกว่า harness ได้ด้วย โดยคุณ Margot เพิ่ม Stop Sequence เข้าไปในการเรียก Application Programming Interface (API) เพื่อให้โมเดลตรวจจับแท็กปิดของ XML แล้วหยุดสร้างข้อความต่อทันทีที่ถึงจุดนั้น

การรัน Eval รอบนี้อาจไม่เห็นผลดีขึ้นชัดเจน แต่มันคือแนวปฏิบัติที่ดีที่ควรทำติดเป็นนิสัย และจะยิ่งสำคัญเมื่อโครงสร้างผลลัพธ์ซับซ้อนขึ้น คุณ Margot เสริมว่าถ้าต้องรับมือกับโครงสร้างที่ซับซ้อนจริง ๆ ฟีเจอร์อย่าง Structured Outputs จะช่วยล็อกความสม่ำเสมอได้ในเชิงโปรแกรมมิงอย่างมีประสิทธิภาพ

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

จุดพังที่ 1: เมื่อ AI หวงข้อมูลที่ถืออยู่ในมือ

เคสแรกคือคำถามว่า 'แพ็กเกจไม่อั้นของฉันมีเน็ตฮอตสปอตเท่าไหร่' สิ่งที่เราอยากให้โมเดลทำคือบอกจำนวนเน็ตฮอตสปอตที่ลูกค้าคนนั้นมีไปตรง ๆ ความยากของเคสนี้คือลูกค้ารายนี้อยู่บนแพ็กเกจรุ่นเก่าที่ยังใช้สิทธิ์เดิม (Grandfathered plan) ทำให้นโยบายปัจจุบันใช้กับลูกค้ารายนี้ไม่ได้ ในข้อมูลลูกค้าที่ป้อนให้ Prompt ระบุชัดว่าลูกค้ารายนี้มีเน็ตฮอตสปอตอยู่ 5 GB แต่เป็นแพ็กเกจรุ่นเก่า

สิ่งที่โมเดลตอบกลับไปคือ แพ็กเกจไม่อั้นทั่วไปได้ฮอตสปอต 4 GB แต่เนื่องจากคุณอยู่บนแพ็กเกจรุ่นเก่า กรุณาไปตรวจสอบเองที่หน้าบัญชีของคุณ พูดง่าย ๆ คือมันโยนคำถามกลับไปให้ลูกค้าแทนที่จะตอบ ทั้งที่ตัวเองถือคำตอบอยู่ในมือ

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

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

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

จุดพังที่ 2: เลิกสั่งให้ AI คิดเลขในใจให้แม่น

เคสถัดมาคือการคำนวณค่าบริการตามสัดส่วน ลูกค้าถามว่า 'ถ้าวันนี้ฉันอัปเกรดไปแพ็กเกจ 30 GB บิลรอบหน้าจะเป็นเท่าไหร่' สิ่งที่เราอยากได้คือให้โมเดลคำนวณออกมาเป๊ะ ๆ ว่าบิลรอบหน้าจะเป็นเท่าไหร่ ไม่ใช่ตอบแบบคลุมเครือเหมือนที่มันทำอยู่ พอดูคำตอบที่โมเดลส่งกลับมา จะเห็นว่ามันพยายามไล่เหตุผลและคิดเลขในหัวไปเรื่อย ๆ แต่ไม่เคยให้ตัวเลขที่เป็นคำตอบจริง ๆ กับลูกค้า ซึ่งเชื่อถือไม่ได้เลย

ย้อนไปดู Prompt ก็พบว่าคำสั่งที่ให้ไว้คือ 'ห้ามตอบลูกค้าแบบคลุมเครือเด็ดขาด สำคัญมาก ให้คำนวณยอดตามสัดส่วนให้ถูกต้องเสมอ' ปัญหาคือการสั่งให้โมเดลทำงานให้ดีนั้นไม่ได้ช่วยอะไร ถ้าเราไม่ได้ให้ความสามารถที่จะทำงานนั้นได้ดีกับมันจริง ๆ สิ่งที่เราอยากเลี่ยงคือการปล่อยให้โมเดลคิดเลขในใจ ทางแก้ของคุณ Margot จึงเป็นการยื่นเครื่องมือให้มันใช้ โดยเขียนใน Prompt ว่าทุกครั้งที่ต้องคำนวณ ให้ใช้เครื่องมือคำนวณค่าตามสัดส่วน (Calculate Proration Tool)

การจะใส่เครื่องมือนี้เข้าไปต้องทำสามขั้น ขั้นแรกคือประกาศเครื่องมือเข้าไปใน API เพื่อบอกโมเดลว่ามีเครื่องมือนี้ให้ใช้ ขั้นที่สองคือนิยามสคีมาของเครื่องมือ (Tool schema) ที่บอกว่าเครื่องมือนี้ทำอะไรและควรใช้เมื่อไหร่ และขั้นสุดท้ายคือลงมือเขียนตัวเครื่องมือจริง ๆ ซึ่งก็คือสูตรคณิตศาสตร์เบื้องหลังการคำนวณนั้น พอรัน eval ใหม่ คราวนี้ทุกเคสที่เกี่ยวข้องก็ผ่านหมด

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

จุดพังที่ 3: บอกแค่ข้อเสีย AI ก็เลือกทางผิด

เคสสุดท้ายที่ยังพังอยู่คือเรื่องบิลผิดพลาด ในสถานการณ์นี้มีข้อขัดแย้งเรื่องบิลเกิดขึ้น และสิ่งที่เราอยากให้เกิดจริง ๆ คือบอตส่งเรื่องต่อให้เจ้าหน้าที่ที่เป็นมนุษย์เข้ามาดูแล แต่สิ่งที่มันทำกลับกลายเป็นพยายามอธิบายให้ลูกค้าฟังว่าสาเหตุน่าจะมาจากอะไร และพยายามวินิจฉัยปัญหาเองทั้งหมด

พอกลับไปดู Prompt ก็เจอคำสั่งตั้งต้นที่เขียนว่า 'หลีกเลี่ยงการส่งต่อหรือโอนเรื่องให้เจ้าหน้าที่ดูแลลูกค้า (Care specialist) เว้นแต่จำเป็นจริง ๆ เพราะมีค่าใช้จ่ายราว 8 ดอลลาร์ และยังถูกนับเป็นคะแนนลบกับตัวชี้วัดการแก้จบในการติดต่อครั้งเดียว (First-contact resolution) ของทีม' ปัญหาคือคำสั่งนี้เล่าแค่ด้านเดียว เราบอกมันแค่ต้นทุนของการส่งต่อ แต่ไม่ได้บอกประโยชน์ของมัน โมเดลจึงยึดติดกับการไม่ส่งต่อจนเกินพอดีอีกแล้ว แถมยังเกิดความขัดแย้งชัด ๆ ระหว่างสิ่งที่เรานิยามไว้ใน eval ว่าอยากให้มันส่งต่อ กับสิ่งที่เราสั่งมันจริง ๆ ใน Prompt

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

ยิ่งโมเดลฉลาดขึ้น เรายิ่งต้องจำไว้ว่าต้องบอกข้อแลกเปลี่ยน (trade-off) ให้ครบทั้งสองด้าน เพราะโมเดลรุ่นใหม่เก่งขึ้นในการชั่งน้ำหนักและตัดสินใจเรื่องพวกนี้ด้วยตัวเอง ถ้าเราให้ข้อมูลแค่ครึ่งเดียว มันก็จะตัดสินใจบนข้อมูลครึ่งเดียวนั้น

สรุป Prompting Playbook ในไม่กี่บรรทัด

พอรวบทุกบทเรียนเข้าด้วยกัน คุณ Margot สรุปว่าทั้งหมดนี้วนอยู่กับสองสถานการณ์ที่คุณ Margot เจอบ่อยที่สุดในงานประจำวัน คือการดูแล Prompt เดิมที่ต้องย้ายไปโมเดลใหม่ซึ่งมีพฤติกรรมต่างออกไป กับการสร้างงานใหม่จากศูนย์ และสิ่งที่ได้เรียนรู้คือการทำตามหลักการเก็บกวาดพื้นฐานสามารถยกระดับผลงานเมื่อเทียบกับชุด eval ได้ทันที โดยมี eval เป็นเครื่องมือที่ทำให้เห็นผลกระทบของการแก้ Prompt ได้อย่างเข้มงวด

จากนั้นคือการไล่จัดการจุดที่พังทีละจุด ทั้งการเติมโครงสร้าง การเลี่ยงการเขียนรายการคำสั่งห้ามยาว ๆ (ban list) ล้วนเป็นสิ่งที่ช่วยดันให้โมเดลกลับมาทำพฤติกรรมที่ถูกต้อง และสำหรับบอตแบบ Agentic ตัวใหม่ที่สร้างขึ้นมา สิ่งที่เห็นผลคือการแยกออกเป็นระบบ Prompt สามส่วนแยกจากกัน แทนที่จะใช้ Prompt ตัวเดียวจัดการทุกอย่าง เราแยกงานที่ทำซ้ำได้ง่ายออกมาเป็นขั้นตอนชัดเจนที่โมเดลต้องทำทุกครั้ง ผลลัพธ์ที่ได้คือระบบที่ทั้งคุมง่ายและเชื่อถือได้กว่าเดิม

ที่มา: Code with Claude: The Prompting Playbook โดย Margot van Laar, Anthropic