Claude Architect · บทเรียน

เหตุผลที่ตัวอย่าง 2-4 รายการได้ผล

มีมากพอสำหรับกำหนดรูปแบบ และน้อยพอที่จะยังใช้ได้ทั่วไป

บทเรียน 1 จาก 413 ขั้นตอน

เหตุผลที่ตัวอย่าง 2-4 รายการได้ผล เป็นบทเรียน Claude Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Claude Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน

แนวคิดหลัก

การเขียนพรอมต์แบบไม่กี่ช็อตได้ผลเพราะ Claude สรุปเป็นกฎทั่วไป จากตัวอย่าง ไม่ได้เพียงจดจำแล้วทำซ้ำ แผ่นสรุปสำหรับการสอบระบุจำนวนไว้อย่างชัดเจนว่าให้ใช้ ตัวอย่างที่มุ่งเป้า 2-4 ตัวอย่างต่อความกำกวมหนึ่งประเด็น

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

ตัวอย่างสอนกฎ ไม่ใช่ตารางค้นหา

เมื่อแสดงตัวอย่าง 2-4 ตัวอย่างให้ Claude คุณกำลังสาธิต กฎ ว่ารูปแบบข้อมูลนำเข้านี้จะเปลี่ยนเป็นรูปแบบข้อมูลส่งออกนั้น โมเดลอนุมานรูปแบบพื้นฐานและนำไปใช้กับข้อมูลนำเข้าใหม่ที่ไม่เคยเห็นมาก่อน

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

system = (
    "Classify each support message as: billing, technical, or other.\n"
    "Examples:\n"
    "Message: 'My card was charged twice' -> billing\n"
    "Message: 'The app crashes on login' -> technical\n"
    "Message: 'Do you have a dark mode?' -> other"
)
# 3 examples set the mapping rule; Claude generalizes to new messages.

ทำไมจึงไม่ใช้ตัวอย่างเลย

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

ตัวอย่างที่เลือกมาอย่างดีเพียงหนึ่งตัวอย่างช่วยขจัดความกำกวมที่ร้อยแก้วหนึ่งย่อหน้าไม่อาจทำได้ นี่คือขีดล่างของช่วง 2-4 ตัวอย่าง กล่าวคือต้องมีการสาธิตอย่างน้อยสองสามรายการต่อการตัดสินใจที่กำกวมหนึ่งเรื่อง

ทำไมจึงไม่ใช้ตัวอย่างเดียว

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

ตัวอย่างที่สองและสามช่วยให้ Claude วิเคราะห์จากหลายมุม ว่าอะไรเปลี่ยนแปลงจริงและอะไรคงเดิม โครงสร้างที่ใช้ร่วมกันจะกลายเป็นสัญญาณ ส่วนความแตกต่างที่ไม่สำคัญจะกลายเป็นเสียงรบกวนที่ควรละเว้น

# One example: model may copy the exact tone/length.
# Two+ examples reveal what is INVARIANT (the JSON shape)
# versus INCIDENTAL (the specific values).
examples = [
    {"review": "Loved it, fast shipping!", "out": {"sentiment": "positive"}},
    {"review": "Broke after a day.",       "out": {"sentiment": "negative"}},
]
# The constant is the {"sentiment": ...} schema, not the wording.

ทำไมจึงไม่ใช้ตัวอย่าง 20 ตัวอย่าง

หากตัวอย่างไม่กี่ตัวอย่างมีประโยชน์ แล้วทำไมไม่ใส่ตัวอย่างให้เต็มพรอมต์ มีเหตุผลอยู่สองประการ

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

จำนวน 2-4 ตัวอย่างทำให้การสาธิตคมชัดและพรอมต์กระชับ

รักษาความทั่วไป: ครอบคลุมการตัดสินใจ ไม่ใช่ทุกกรณี

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

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

หนึ่งชุดต่อความกำกวมหนึ่งประเด็น

อ่านถ้อยคำในแผ่นสรุปอย่างละเอียด: ตัวอย่าง 2-4 ตัวอย่างต่อความกำกวมหนึ่งประเด็น จำนวนที่กำหนดใช้กับจุดสับสนแต่ละจุด ไม่ใช่กับพรอมต์ทั้งหมด

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

# Ambiguity 1: category boundary (3 examples)
# Ambiguity 2: date normalization (2 examples)
# Each ambiguity gets its own small, targeted set.
prompt = f"""
Category examples:
  'refund my order' -> billing
  'page is blank'   -> technical
  'how do I export' -> other
Date examples:
  'next Tuesday' -> 2026-06-16
  '06/10'        -> 2026-06-10
Now process: {user_message}
"""

เลือกตัวอย่างที่แสดงขอบเขตให้เห็นชัด

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

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

การเขียนพรอมต์แบบไม่กี่ช็อตร่วมกับข้อมูลส่งออกที่มีแบบแผน

สำหรับ รูปแบบ ของข้อมูลส่งออก ให้จับคู่ตัวอย่างสองสามตัวอย่างกับสคีมา JSON ผ่าน tool_use สคีมาจะบังคับให้มีฟิลด์ที่จำเป็นและขจัดข้อผิดพลาดทางไวยากรณ์ ส่วนตัวอย่าง 2-4 ตัวอย่างจะสอน การใช้ดุลยพินิจ ที่สคีมาไม่สามารถแสดงได้ เช่น ควรใส่ค่าใดลงในฟิลด์ใดเมื่อข้อมูลนำเข้าซับซ้อน

โปรดจำกฎของสคีมาไว้ว่า ให้ทำเครื่องหมายฟิลด์เป็น จำเป็นก็ต่อเมื่อมีอยู่เสมอ อย่ากำหนดให้ฟิลด์ที่อาจไม่มีต้องมี เพราะโมเดลจะสร้างข้อมูลขึ้นมาเอง

tools = [{
    "name": "record_ticket",
    "description": "Save a classified support ticket.",
    "input_schema": {
        "type": "object",
        "properties": {
            "category": {"enum": ["billing", "technical", "other"]},
            "priority": {"enum": ["low", "high"]},
        },
        "required": ["category"],  # priority may be absent -> not required
    },
}]
# tool_choice="any" guarantees a structured call; examples teach the judgment.

การเขียนพรอมต์แบบไม่กี่ช็อตเทียบกับการลองใหม่พร้อมผลสะท้อนกลับ

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

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

แนวทางปฏิบัติ

สำหรับพรอมต์ที่กำกวมทุกชนิด:

เขียน เกณฑ์ที่ชัดเจน ก่อน (คำสั่งคลุมเครือเป็นพื้นฐานที่อ่อนแอ)
เพิ่ม ตัวอย่าง 2-4 ตัวอย่าง ต่อความกำกวมที่เหลือ โดยเลือกจากขอบเขตการตัดสินใจ
เลือกใช้ สคีมา เมื่อปัญหาอยู่ที่รูปแบบข้อมูลส่งออก ไม่ใช่การใช้ดุลยพินิจ
หากคุณยังเพิ่มตัวอย่างต่อไป ให้หยุด แล้วแก้เกณฑ์หรือสคีมาแทน

มีมากพอที่จะกำหนดรูปแบบ และมีน้อยพอที่จะคงความทั่วไปไว้

system = """Flag a code comment ONLY when it contradicts the code.
Examples:
  Code: x = a + b   Comment: 'subtract b'  -> FLAG (contradicts)
  Code: x = a + b   Comment: 'sum a and b' -> OK
  Code: retry(3)    Comment: 'retry twice' -> FLAG (count wrong)
"""
# Explicit criterion + 3 boundary examples = consistent, general behavior.

จุดตรวจสอบ: การเลือกจำนวนตัวอย่าง

คำถามจากสถานการณ์ — เลือกคำตอบที่ดีที่สุด

ตอบคำถามในบทเรียนแบบโต้ตอบ

ทบทวน

ประเด็นสำคัญ:

ตัวอย่าง 2-4 ตัวอย่างต่อความกำกวมหนึ่งประเด็น คือจุดสมดุลที่เหมาะสม Claude สรุปเป็นกฎทั่วไปจากตัวอย่าง ไม่ได้เพียงทำซ้ำ
น้อยเกินไป (0-1 ตัวอย่าง) ระบุข้อกำหนดไม่ละเอียดพอหรือทำให้โมเดลปรับเข้ากับรายละเอียดผิวเผินมากเกินไป ส่วน มากเกินไป ทำให้จำเพาะเกินไปและสิ้นเปลืองบริบท จนความสนใจที่มีต่อส่วนกลางลดลง
เลือกตัวอย่างที่อยู่ตรง ขอบเขตการตัดสินใจ คุณภาพสำคัญกว่าปริมาณ
จับคู่ตัวอย่างกับ เกณฑ์ที่ชัดเจน และสำหรับรูปแบบข้อมูลส่งออก ให้ใช้ สคีมา JSON โดยอย่ากำหนดให้ฟิลด์ที่อาจไม่มีต้องมี
หากคุณยังเพิ่มตัวอย่างต่อไป ให้แก้ เกณฑ์หรือสคีมา แทน

เริ่มต้นได้ฟรี

เรียนรู้ Python ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส: 26
บทเรียน: 104

เริ่มเรียนฟรี ดูหลักสูตรเต็ม

คำถามที่พบบ่อย

บทเรียน “เหตุผลที่ตัวอย่าง 2-4 รายการได้ผล” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เหตุผลที่ตัวอย่าง 2-4 รายการได้ผล” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Claude Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Claude Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เหตุผลที่ตัวอย่าง 2-4 รายการได้ผล”

มีมากพอสำหรับกำหนดรูปแบบ และน้อยพอที่จะยังใช้ได้ทั่วไป คุณปฏิบัติ Claude Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Claude Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Claude Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “เหตุผลที่ตัวอย่าง 2-4 รายการได้ผล” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Claude Architect นี้ได้ไหม

ได้ บทเรียน Claude Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Claude Architect