กลับไปที่บล็อก

ผังการตัดสินใจแสดงขั้นตอน: เริ่มด้วย zero-shot ประเมินผลลัพธ์ แล้วค่อยเพิ่มตัวอย่างเฉพาะเมื่อจำเป็น 
ภาพประกอบแสดงการ์ดตัวอย่างถูกเพิ่มเข้าไปในพรอมต์ ผลตอบแทนลดลงหลังตัวอย่างไม่กี่ชิ้นแรก
Few-Shot vs. Zero-Shot Prompting: เลือกใช้แบบไหนเมื่อไหร่
คู่มือใช้งานจริงสำหรับเลือกวิธีเขียนพรอมต์ให้เหมาะกับงาน พร้อมตัวอย่างคัดลอกไปใช้ได้ทันทีและกรอบการตัดสินใจที่เข้าใจง่าย

คุณวางพรอมต์ลงใน ChatGPT ผลลัพธ์ที่ได้... ก็โอเคอยู่ แต่คุณเคยเห็นคนอื่นได้ผลลัพธ์ที่ดีกว่ามากเพียงเพราะใส่ "ตัวอย่าง" เข้าไปในพรอมต์ คุณควรทำแบบนั้นไหม ใส่กี่ตัวอย่างดี และมันสำคัญจริงหรือเปล่าสำหรับงานของคุณ
คำถามพวกนี้ผุดขึ้นมาตลอด แถมศัพท์เฉพาะก็ไม่ช่วยอะไรเลย คำว่า "zero-shot" "few-shot" "one-shot" ฟังเหมือนศัพท์ในวงการถ่ายภาพมากกว่าคำแนะนำใช้งานจริง บทความนี้จะตัดทอนศัพท์ที่ทำให้สับสนออก และให้กรอบการตัดสินใจที่ชัดเจนว่าควรใช้วิธีไหน พร้อมพรอมต์เต็ม ๆ ที่คุณคัดลอกไปทดสอบเองได้
Zero-shot prompting คืออะไรกันแน่
Zero-shot prompting คือการสั่งงาน AI โดยไม่ให้ดูตัวอย่างของสิ่งที่คุณต้องการเลย คุณแค่อธิบายว่าอยากได้อะไร แล้วโมเดลก็จะคิดวิธีทำเองจากข้อมูลที่ถูกฝึกมา
นี่คือพรอมต์ zero-shot สำหรับสรุปการประชุม:
Summarize the following meeting notes into 3-5 bullet points covering the key decisions made.
Meeting notes:
{{meeting_notes}}
แค่นั้นเอง ไม่มีตัวอย่างของบทสรุปที่ "ดี" ไม่มีตัวอย่างอินพุตและเอาต์พุต คุณกำลังเชื่อใจให้โมเดลเข้าใจเองว่าบทสรุปหน้าตาเป็นยังไง และคำว่า "key decisions" หมายถึงอะไร สำหรับงานหลายประเภท วิธีนี้ก็ใช้ได้ผลดีอย่างน่าประหลาดใจ
Few-shot prompting คืออะไรกันแน่
Few-shot prompting คือการใส่ตัวอย่าง 2-5 ตัวอย่างในพรอมต์เพื่อแสดงรูปแบบที่คุณอยากให้ AI ทำตาม พูดง่าย ๆ ก็คือคุณกำลังบอกว่า "นี่คือวิธีที่ฉันอยากให้คุณจัดการเรื่องนี้" ก่อนที่จะมอบหมายงานจริง
นี่คืองานสรุปการประชุมเดียวกัน แต่มีตัวอย่างประกอบ:
Summarize meeting notes into 3-5 bullet points covering key decisions.
Example 1:
Input: "Team discussed Q3 targets. Sarah proposed increasing the sales goal by 15%. Mark disagreed, suggested 10% was more realistic given current pipeline. Team voted and agreed on 12%. Also decided to postpone the website redesign until Q4."
Output:
- Agreed on 12% sales goal increase for Q3 (compromise between 15% and 10% proposals)
- Postponed website redesign to Q4
Example 2:
Input: "Budget review meeting. Current spending is 8% over forecast. CFO recommended cutting travel budget by 50% and freezing new hires for 60 days. CEO approved both measures effective immediately."
Output:
- Cut travel budget by 50% (effective immediately)
- 60-day hiring freeze approved
- Response to 8% budget overrun
Now summarize this:
{{meeting_notes}}
สังเกตความแตกต่างดี ๆ ตัวอย่างเหล่านี้บอกโมเดลอย่างชัดเจนว่าคุณอยากได้รูปแบบไหน (bullet points พร้อมบริบทในวงเล็บ) ระดับรายละเอียดแค่ไหน และจะจัดการกับการตัดสินใจหลายเรื่องในคราวเดียวยังไง โมเดลเรียนรู้สิ่งที่คุณชอบ จากบริบทในพรอมต์เลย ไม่ต้อง fine-tune ใด ๆ
ความแตกต่างหลักแบบเห็นภาพชัด
นี่คือวิธีเปรียบเทียบสองแนวทางในแง่ที่สำคัญที่สุด:
- ความเร็ว: zero-shot เร็วกว่า เพราะมีโทเคนให้ประมวลผลน้อยกว่า ตอบกลับจึงไวกว่า
- ค่าใช้จ่าย: zero-shot ถูกกว่า เพราะคุณจ่ายตามจำนวนโทเคน และตัวอย่างที่ใส่เข้าไปก็เพิ่มค่าใช้จ่ายขึ้นเรื่อย ๆ
- ความพยายามในการตั้งค่า: zero-shot แทบไม่ต้องเตรียมอะไรเลย ส่วน few-shot ต้องไปหาหรือสร้างตัวอย่างที่ดี
- ความแม่นยำกับงานง่าย ๆ: ใกล้เคียงกัน โมเดลรุ่นใหม่ ๆ จัดการกับคำขอตรงไปตรงมาได้ดีทั้งสองแบบ
- ความแม่นยำกับงานซับซ้อนหรือเฉพาะทาง: few-shot มักชนะ เมื่อต้องการรูปแบบเฉพาะหรือศัพท์เฉพาะวงการ ตัวอย่างจะสร้างความแตกต่างที่วัดผลได้จริง
ข้อแลกเปลี่ยนชัดเจน: zero-shot ง่ายกว่าและถูกกว่า แต่ few-shot ให้คุณคุมผลลัพธ์ได้มากกว่า คำถามคือเมื่อไหร่ที่การคุมเพิ่มเติมนั้นคุ้มค่า
เมื่อไหร่ที่ zero-shot ใช้ได้ดีที่สุด
Zero-shot prompting จะโดดเด่นเมื่องานนั้นเป็นสิ่งที่โมเดล "เข้าใจ" อยู่แล้วจากข้อมูลที่ถูกฝึกมา รวมถึง:
คำถามความรู้ทั่วไป: การถามคำอธิบาย คำจำกัดความ หรือข้อเท็จจริง โมเดลรู้ดีว่าคำอธิบายที่ดีหน้าตาเป็นยังไง
ระดมความคิดเชิงสร้างสรรค์: สร้างไอเดีย เขียนร่างแรก หรือคิดทางเลือกต่าง ๆ ในกรณีนี้คุณ อยากได้ ความหลากหลาย ไม่ใช่ความสม่ำเสมอตามรูปแบบ
สรุปเนื้อหามาตรฐาน: ย่อบทความ อีเมล หรือเอกสาร เมื่อไม่ต้องการรูปแบบเฉพาะ
การแปลภาษา: แปลข้อความระหว่างภาษาที่โมเดลเคยถูกฝึกมา
การจำแนกประเภทแบบง่าย: จัดสิ่งของเข้าหมวดหมู่ทั่วไป (บวก/ลบ ด่วน/ไม่ด่วน) เมื่อหมวดหมู่นั้นเข้าใจได้ในตัวอยู่แล้ว
ระดมความคิดเชิงสร้างสรรค์: สร้างไอเดีย เขียนร่างแรก หรือคิดทางเลือกต่าง ๆ ในกรณีนี้คุณ อยากได้ ความหลากหลาย ไม่ใช่ความสม่ำเสมอตามรูปแบบ
สรุปเนื้อหามาตรฐาน: ย่อบทความ อีเมล หรือเอกสาร เมื่อไม่ต้องการรูปแบบเฉพาะ
การแปลภาษา: แปลข้อความระหว่างภาษาที่โมเดลเคยถูกฝึกมา
การจำแนกประเภทแบบง่าย: จัดสิ่งของเข้าหมวดหมู่ทั่วไป (บวก/ลบ ด่วน/ไม่ด่วน) เมื่อหมวดหมู่นั้นเข้าใจได้ในตัวอยู่แล้ว
หลักง่าย ๆ คือ: ถ้าคุณอธิบายสิ่งที่อยากได้เป็นภาษาธรรมดา และคนทั่วไปจะเข้าใจได้โดยไม่ต้องเห็นตัวอย่าง zero-shot ก็น่าจะใช้ได้

เมื่อไหร่ที่ few-shot คุ้มกับโทเคนที่เพิ่มขึ้น
Few-shot prompting จะคุ้มค่าเมื่อผลลัพธ์ต้องเป็นไปตามรูปแบบที่โมเดลเดาเองจากคำสั่งไม่ได้:
รูปแบบเฉพาะตัว: เมื่อต้องการผลลัพธ์ในโครงสร้างที่กำหนด เช่น JSON ที่มีฟิลด์เฉพาะ ตารางที่มีคอลัมน์ตามต้องการ หรือ bullet points แบบเฉพาะ ตัวอย่างแสดงรูปแบบได้ชัดกว่าคำอธิบายเสมอ
หมวดหมู่การจำแนกของคุณเอง: ถ้าคุณกำลังจัดอีเมลลูกค้าเข้าหมวดหมู่อย่าง "billing-question" "feature-request" "bug-report" และ "general-inquiry" การให้ตัวอย่างของแต่ละหมวดจะช่วยให้โมเดลเข้าใจคำจำกัดความของคุณ
โทนเสียงหรือสไตล์ของแบรนด์: อยากให้ AI เขียนแบบเดียวกับคอนเทนต์เดิมของบริษัท ก็ให้ดูตัวอย่าง 2-3 ชิ้นที่เป็นเสียงนั้น คำสั่งแบบ "เขียนให้ดูเป็นมืออาชีพแต่เป็นกันเอง" คลุมเครือเกินไป ตัวอย่างจะให้ความเฉพาะเจาะจง
ศัพท์เฉพาะของอุตสาหกรรม: ถ้าวงการคุณใช้ศัพท์หรือตัวย่อที่ต่างจากความหมายทั่วไป ตัวอย่างจะช่วยสอนบริบทของคุณให้โมเดล
กรณียกเว้นและความละเอียดอ่อน: การจับประชด การล้อ หรือความแตกต่างเล็ก ๆ ที่ทำให้ zero-shot สะดุด งานวิจัยแสดงว่า few-shot prompting ปรับปรุงการจัดการ กรณียกเว้นเรื่องอารมณ์ เช่น การปฏิเสธและการประชดได้อย่างมีนัยสำคัญ
หมวดหมู่การจำแนกของคุณเอง: ถ้าคุณกำลังจัดอีเมลลูกค้าเข้าหมวดหมู่อย่าง "billing-question" "feature-request" "bug-report" และ "general-inquiry" การให้ตัวอย่างของแต่ละหมวดจะช่วยให้โมเดลเข้าใจคำจำกัดความของคุณ
โทนเสียงหรือสไตล์ของแบรนด์: อยากให้ AI เขียนแบบเดียวกับคอนเทนต์เดิมของบริษัท ก็ให้ดูตัวอย่าง 2-3 ชิ้นที่เป็นเสียงนั้น คำสั่งแบบ "เขียนให้ดูเป็นมืออาชีพแต่เป็นกันเอง" คลุมเครือเกินไป ตัวอย่างจะให้ความเฉพาะเจาะจง
ศัพท์เฉพาะของอุตสาหกรรม: ถ้าวงการคุณใช้ศัพท์หรือตัวย่อที่ต่างจากความหมายทั่วไป ตัวอย่างจะช่วยสอนบริบทของคุณให้โมเดล
กรณียกเว้นและความละเอียดอ่อน: การจับประชด การล้อ หรือความแตกต่างเล็ก ๆ ที่ทำให้ zero-shot สะดุด งานวิจัยแสดงว่า few-shot prompting ปรับปรุงการจัดการ กรณียกเว้นเรื่องอารมณ์ เช่น การปฏิเสธและการประชดได้อย่างมีนัยสำคัญ
งานวิจัยชิ้นหนึ่งพบว่าในการจำแนกอารมณ์จากทวีต few-shot prompting ที่ใช้ตัวอย่างเพียง 20-50 ชิ้นให้ผลใกล้เคียงกับโมเดลที่ fine-tune ด้วยข้อมูล 10,000+ ตัวอย่าง นั่นแหละพลังของตัวอย่างที่เลือกมาดี
ถ้าคุณเริ่มสะสมไลบรารีของพรอมต์แบบ few-shot สำหรับงานต่าง ๆ เครื่องมืออย่าง PromptNest ช่วยให้คุณเก็บพรอมต์พร้อมตัวแปรอย่าง
{{meeting_notes}} ได้ในตัว เติมข้อมูลตอนคัดลอก แล้วได้พรอมต์เต็มพร้อมวางใช้งานได้ทันทีเวิร์กโฟลว์แบบ "เริ่ม zero ก่อน อัปเกรดเมื่อจำเป็น"
นี่คือแนวทางใช้งานจริงที่ประหยัดทั้งเวลาและโทเคน:
ขั้นที่ 1: ลอง zero-shot ก่อน เขียนพรอมต์ที่ชัดเจนอธิบายสิ่งที่ต้องการ ระบุงานให้เจาะจง แต่ยังไม่ต้องใส่ตัวอย่าง
ขั้นที่ 2: ประเมินผลลัพธ์ ได้สิ่งที่ต้องการไหม ถ้าใช่ จบแค่นี้ ถ้าไม่ ลองหาว่า อะไรไม่ใช่ รูปแบบหรือเปล่า โทนเสียง รายละเอียดที่หายไป หรือเข้าใจงานผิดไปเลย
ขั้นที่ 3: ใส่ตัวอย่างแบบเจาะจง สร้างตัวอย่าง 2-3 ชิ้นที่แสดงสิ่งที่โมเดลทำผิดพลาดโดยเฉพาะ ถ้ารูปแบบเพี้ยน ก็แสดงรูปแบบที่ถูกต้อง ถ้าโทนเสียงไม่ใช่ ก็แสดงโทนที่ใช่
ขั้นที่ 2: ประเมินผลลัพธ์ ได้สิ่งที่ต้องการไหม ถ้าใช่ จบแค่นี้ ถ้าไม่ ลองหาว่า อะไรไม่ใช่ รูปแบบหรือเปล่า โทนเสียง รายละเอียดที่หายไป หรือเข้าใจงานผิดไปเลย
ขั้นที่ 3: ใส่ตัวอย่างแบบเจาะจง สร้างตัวอย่าง 2-3 ชิ้นที่แสดงสิ่งที่โมเดลทำผิดพลาดโดยเฉพาะ ถ้ารูปแบบเพี้ยน ก็แสดงรูปแบบที่ถูกต้อง ถ้าโทนเสียงไม่ใช่ ก็แสดงโทนที่ใช่
เวิร์กโฟลว์แบบนี้สำคัญเพราะคุณไม่ได้เดาว่าต้องใช้ตัวอย่างหรือไม่ คุณกำลังตอบโจทย์ช่องโหว่ที่เห็นจริง บางครั้งแค่เพิ่ม "Let's think step by step" ลงในพรอมต์ zero-shot ก็แก้ปัญหาการให้เหตุผลได้โดยไม่ต้องใช้ตัวอย่างเลย งานวิจัยยืนยัน ว่า zero-shot chain-of-thought มักทำงานเหนือกว่า few-shot ในงานที่ต้องใช้เหตุผล
ต้องการตัวอย่างจริง ๆ กี่ตัวอย่าง
งานวิจัยชี้ตรงกันว่าจุดที่ลงตัวสำหรับงานทั่วไปคือ 2-5 ตัวอย่าง ข้อมูลแสดงให้เห็นว่า:
- ตัวอย่าง 2-3 ตัวแรกให้ผลในการเพิ่มความแม่นยำมากที่สุด
- ผลตอบแทนลดลงอย่างชัดเจนหลังตัวอย่างที่ 4-5
- ตัวอย่างที่มากเกินไปอาจ ทำให้ ผลลัพธ์แย่ลงเพราะสร้างรูปแบบที่ขัดแย้งกัน
- คุณภาพของตัวอย่างสำคัญกว่าปริมาณ — ตัวอย่างที่ดีเยี่ยมสามชิ้นเอาชนะตัวอย่างกลาง ๆ สิบชิ้นได้
มีอีกข้อค้นพบที่สำคัญเรื่องลำดับของตัวอย่าง: งานวิจัยแสดงว่า ลำดับของตัวอย่างมีผลต่อผลลัพธ์ การเรียงลำดับที่เหมาะสมบางครั้งสร้างความแตกต่างระหว่างผลที่ดีกับผลที่ย่ำแย่ ถ้าพรอมต์ few-shot ของคุณยังทำงานได้ไม่ดี ลองสลับลำดับตัวอย่างก่อนเพิ่มจำนวน

สำหรับการใช้งานทั่วไป เริ่มที่ 2 ตัวอย่างก่อน ถ้าความแม่นยำยังไม่ถึงระดับที่ต้องการ ค่อยเพิ่มตัวอย่างที่สามที่ครอบคลุมรูปแบบต่างออกไป น้อยมากที่จะต้องใช้มากกว่า 4 ตัวอย่าง
Chain-of-thought: ทางสายกลางสำหรับงานที่ต้องใช้เหตุผล
ยังมีตัวเลือกที่สามที่ใช้ได้ดีเป็นพิเศษกับงานคณิตศาสตร์ ตรรกะ และปัญหาหลายขั้นตอน นั่นคือ chain-of-thought prompting แทนที่จะแสดงตัวอย่างอินพุต-เอาต์พุต คุณขอให้โมเดล "คิดทีละขั้น"
Zero-shot chain-of-thought หน้าตาเป็นแบบนี้:
A store has 45 apples. They sell 12 in the morning and receive a shipment of 30 more. Then they sell 18 in the afternoon. How many apples do they have at closing?
Let's work through this step by step.
ประโยคง่าย ๆ อย่าง "Let's work through this step by step" จะกระตุ้นให้โมเดลแสดงเหตุผลแทนที่จะกระโดดไปคำตอบเลย สำหรับการให้เหตุผลที่ซับซ้อน วิธีนี้มักเอาชนะทั้ง zero-shot และ few-shot ได้
งานวิจัยล่าสุดจาก arXiv พบว่าสำหรับโมเดลแกร่ง ๆ อย่าง GPT-4 และ Claude นั้น zero-shot chain-of-thought มักทำได้ดีกว่า few-shot prompting ในงานที่ต้องใช้เหตุผล ตัวอย่างกลับเป็นการจำกัดความคิดของโมเดลแทนที่จะช่วยมัน
ใช้ chain-of-thought เมื่อ:
- งานต้องใช้หลายขั้นตอนของตรรกะ
- คุณต้องการให้โมเดลอธิบายเหตุผล (มีประโยชน์ในการจับข้อผิดพลาด)
- เป็นงานคณิตศาสตร์ ตรรกะการเขียนโค้ด หรือปัญหาเชิงวิเคราะห์
- คุณอยากตรวจสอบวิธีการของโมเดล ไม่ใช่แค่คำตอบ
ตัวอย่างพรอมต์เต็ม ๆ ที่คุณคัดลอกไปใช้ได้
มาดูทั้งสามแนวทางเทียบกันสำหรับงานจริง พรอมต์ทั้งหมดผ่านการทดสอบกับ GPT-4 และ Claude มาแล้ว พร้อมใช้งาน
งานที่ 1: จำแนกโทนของอีเมล
เวอร์ชัน zero-shot:
Classify the tone of this customer email as: frustrated, satisfied, neutral, or urgent.
Email:
{{email_text}}
Tone:
เวอร์ชัน few-shot (ดีกว่าสำหรับกรณียกเว้น):
Classify customer email tone as: frustrated, satisfied, neutral, or urgent.
Email: "I've been waiting 3 weeks for my order. This is ridiculous. I want a refund NOW."
Tone: frustrated
Email: "Just wanted to say thanks — the product arrived early and works great!"
Tone: satisfied
Email: "Hi, can you confirm my order shipped? Order #12345."
Tone: neutral
Email: "Our system is down and we need the replacement part TODAY or we lose the contract."
Tone: urgent
Email: {{email_text}}
Tone:
เวอร์ชัน few-shot ช่วยให้โมเดลเข้าใจคำจำกัดความของคุณโดยเฉพาะ ความแตกต่างระหว่าง "urgent" กับ "frustrated" อาจกำกวม ตัวอย่างทำให้เส้นแบ่งของคุณชัดเจนขึ้น
งานที่ 2: เขียนคำอธิบายสินค้าใหม่
เวอร์ชัน zero-shot:
Rewrite this product description to be more engaging and benefit-focused. Keep it under 100 words.
Original: {{product_description}}
Rewritten version:
เวอร์ชัน few-shot (ดีกว่าสำหรับความสม่ำเสมอของโทนแบรนด์):
Rewrite product descriptions to be engaging and benefit-focused. Match this style:
Original: "Stainless steel water bottle. 24oz capacity. Keeps drinks cold for 24 hours."
Rewritten: "Stay hydrated all day with our sleek 24oz steel bottle. Your morning coffee stays hot through your commute. Your afternoon water stays ice-cold at the gym. One bottle, endless possibilities."
Original: "Wireless earbuds. 8-hour battery. Noise cancelling."
Rewritten: "Eight hours of your favorite podcasts, uninterrupted. Our wireless earbuds block out the noise so you can focus on what matters — whether that's deep work, your workout playlist, or finally finishing that audiobook."
Original: {{product_description}}
Rewritten:
เวอร์ชัน few-shot สอนสไตล์การเขียนคอปปี้แบบเฉพาะ — เน้นประโยชน์ พูดคุยเป็นกันเอง มีกรณีใช้งานเจาะจง zero-shot จะเขียนใหม่ให้ก็จริง แต่อาจไม่ใช่ เสียง ของคุณเสมอไป
งานที่ 3: จัดโครงสร้างรายงานบั๊ก
เวอร์ชัน zero-shot:
Convert this bug report into a structured format with: Summary, Steps to Reproduce, Expected Behavior, and Actual Behavior.
Bug report: {{bug_report}}
เวอร์ชัน few-shot (ดีกว่าสำหรับรูปแบบที่สม่ำเสมอ):
Convert bug reports into structured format.
Input: "The app crashes when I try to upload a PDF. I was on the dashboard, clicked upload, selected a 5MB PDF, and it just closed. Should show the file in my uploads but instead the whole app dies."
Output:
**Summary:** App crashes when uploading PDF files
**Steps to Reproduce:**
1. Navigate to dashboard
2. Click upload button
3. Select a PDF file (tested with 5MB file)
**Expected:** File appears in uploads section
**Actual:** Application crashes/closes unexpectedly
---
Input: {{bug_report}}
Output:
สำหรับเอกสารทางเทคนิค ความสม่ำเสมอเป็นเรื่องสำคัญ เวอร์ชัน few-shot ช่วยให้รายงานบั๊กทุกฉบับเป็นโครงสร้างเดียวกันด้วยรายละเอียดระดับเดียวกัน
กรอบการตัดสินใจอย่างรวดเร็ว
เมื่อคุณเจองานใหม่ ลองถามตัวเองด้วยคำถามเหล่านี้:
1. งานนี้ตรงไปตรงมาและชัดเจนไหม → เริ่มที่ zero-shot
2. ต้องการรูปแบบเฉพาะที่โมเดลอาจเดาไม่ถูกไหม → ใช้ few-shot
3. งานเกี่ยวกับการให้เหตุผลหลายขั้นตอนหรือเปล่า → ลอง zero-shot chain-of-thought ก่อน
4. ต้องการเสียงแบรนด์ที่สม่ำเสมอหรือศัพท์เฉพาะวงการไหม → ใช้ few-shot กับตัวอย่างที่เป็นเสียงนั้น
5. zero-shot ให้ผลลัพธ์ที่ใช้ได้ 80% แล้วหรือยัง → เก็บไว้แบบนั้น ความสมบูรณ์แบบไม่คุ้มกับค่าโทเคนสามเท่า
เป้าหมายไม่ใช่การใช้เทคนิคหรูที่สุด แต่คือการได้ผลลัพธ์ที่ดีอย่างมีประสิทธิภาพ zero-shot คือค่าตั้งต้น ค่อยเพิ่มความซับซ้อนเมื่อวิธีง่าย ๆ ไม่พอใช้
นำไปใช้งานจริง
วิธีเข้าใจเรื่องนี้ดีที่สุดคือลองด้วยตัวเอง หยิบงานที่คุณทำเป็นประจำมา เช่น สรุปรายงาน ร่างอีเมล หรือจัดหมวดหมู่ฟีดแบ็ก แล้วลองทั้งสองแนวทาง สังเกตว่า zero-shot พลาดตรงไหน สังเกตว่า few-shot สร้างความแตกต่างจริง ๆ ที่ตรงไหน
เมื่อคุณเจอพรอมต์ที่ใช้ได้ดี ก็เก็บไว้ในที่ที่หาเจออีกครั้ง ถ้าคุณกำลังสร้างคลังพรอมต์ที่มีตัวอย่างและตัวแปร PromptNest เป็นแอปบน Mac ($19.99 จ่ายครั้งเดียวบน Mac App Store ไม่มีค่าสมาชิก ไม่ต้องสมัครบัญชี ทำงานในเครื่องของคุณ) ที่จัดเก็บพรอมต์ให้เป็นระเบียบ ค้นหาง่าย และเรียกใช้ได้ด้วยคีย์ลัดจากแอปไหนก็ได้ ไม่ต้องไปไล่ค้นโน้ตที่กระจัดกระจายเพื่อตามหาพรอมต์ few-shot ดี ๆ ที่คุณเขียนไว้สามสัปดาห์ก่อนอีกต่อไป
เริ่มแบบง่าย ๆ เพิ่มความซับซ้อนเมื่อจำเป็น เก็บสิ่งที่ใช้ได้ผลไว้ นั่นแหละคือกลยุทธ์ทั้งหมด