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

Few-Shot vs. Zero-Shot Prompting: เลือกใช้แบบไหนเมื่อไหร่

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

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 ก็น่าจะใช้ได้
ผังการตัดสินใจแสดงขั้นตอน: เริ่มด้วย zero-shot ประเมินผลลัพธ์ แล้วค่อยเพิ่มตัวอย่างเฉพาะเมื่อจำเป็น
ผังการตัดสินใจแสดงขั้นตอน: เริ่มด้วย 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 ปรับปรุงการจัดการ กรณียกเว้นเรื่องอารมณ์ เช่น การปฏิเสธและการประชดได้อย่างมีนัยสำคัญ
งานวิจัยชิ้นหนึ่งพบว่าในการจำแนกอารมณ์จากทวีต few-shot prompting ที่ใช้ตัวอย่างเพียง 20-50 ชิ้นให้ผลใกล้เคียงกับโมเดลที่ fine-tune ด้วยข้อมูล 10,000+ ตัวอย่าง นั่นแหละพลังของตัวอย่างที่เลือกมาดี
ถ้าคุณเริ่มสะสมไลบรารีของพรอมต์แบบ few-shot สำหรับงานต่าง ๆ เครื่องมืออย่าง PromptNest ช่วยให้คุณเก็บพรอมต์พร้อมตัวแปรอย่าง {{meeting_notes}} ได้ในตัว เติมข้อมูลตอนคัดลอก แล้วได้พรอมต์เต็มพร้อมวางใช้งานได้ทันที

เวิร์กโฟลว์แบบ "เริ่ม zero ก่อน อัปเกรดเมื่อจำเป็น"

นี่คือแนวทางใช้งานจริงที่ประหยัดทั้งเวลาและโทเคน:
ขั้นที่ 1: ลอง zero-shot ก่อน เขียนพรอมต์ที่ชัดเจนอธิบายสิ่งที่ต้องการ ระบุงานให้เจาะจง แต่ยังไม่ต้องใส่ตัวอย่าง

ขั้นที่ 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 ดี ๆ ที่คุณเขียนไว้สามสัปดาห์ก่อนอีกต่อไป
เริ่มแบบง่าย ๆ เพิ่มความซับซ้อนเมื่อจำเป็น เก็บสิ่งที่ใช้ได้ผลไว้ นั่นแหละคือกลยุทธ์ทั้งหมด