Claude Architect · บทเรียน

การทำให้เป็นทั่วไปเทียบกับการทำซ้ำ

โมเดลนำรูปแบบไปใช้กับกรณีใหม่

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

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

แนวคิดหลัก

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

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

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

การทำซ้ำเทียบกับการสรุปแบบแผน

ลองนึกภาพว่าคุณให้ Claude ดูตัวอย่างสองตัวอย่างที่จัดประเภทบัตรแจ้งปัญหาการสนับสนุนเป็น billing หรือ technical

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

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

เหตุใดการพรอมป์แบบไม่กี่ตัวอย่างจึงได้ผล

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

นี่เป็นเครื่องมือที่มีประสิทธิภาพสูงสุดสำหรับงานสี่ประเภท:

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

คุณสอนรูปแบบ ส่วนโมเดลเติมส่วนที่เหลือ

ตัวอย่างอยู่ในข้อความ

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

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

import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=256,
    system="Classify each ticket as 'billing' or 'technical'. Reply with one word.",
    messages=[
        {"role": "user", "content": "My card was charged twice."},
        {"role": "assistant", "content": "billing"},
        {"role": "user", "content": "The app crashes on launch."},
        {"role": "assistant", "content": "technical"},
        # NEW, unseen case — the model generalizes the pattern:
        {"role": "user", "content": "I was promised a refund but never received it."},
    ],
)
print(resp.content[0].text)

ครอบคลุมขอบเขตการตัดสินใจ

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

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

ตัวอย่างที่หลากหลายและกำหนดขอบเขตได้ช่วยให้สรุปแบบแผนได้ ตัวอย่างซ้ำซ้อนมีแต่จะชวนให้ทำซ้ำ

เกณฑ์ที่ชัดเจนมีประสิทธิภาพกว่าตัวอย่างที่มากขึ้น

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

รวมกฎที่คมชัดไว้ในพรอมป์ system กับตัวอย่างไม่กี่ตัวอย่างที่สาธิตกฎนั้นในกรณียาก กฎระบุเจตนา ส่วนตัวอย่างช่วยปรับเทียบการตัดสิน

system = (
    "You review code comments. "
    "Flag a comment ONLY when it contradicts the code it describes. "
    "Do not flag style, tone, or outdated-but-harmless notes."
)

messages = [
    {"role": "user", "content": "# returns the sum\ndef f(a,b): return a*b"},
    {"role": "assistant", "content": "FLAG: comment says sum, code multiplies."},
    {"role": "user", "content": "# legacy helper\ndef g(x): return x+1"},
    {"role": "assistant", "content": "OK: comment does not contradict the code."},
]

การสรุปรูปแบบผลลัพธ์ไปใช้กับกรณีใหม่

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

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

tools = [{
    "name": "record_ticket",
    "description": "Store a classified support ticket.",
    "input_schema": {
        "type": "object",
        "properties": {
            "category": {"type": "string", "enum": ["billing", "technical", "other"]},
            "priority": {"type": "string", "enum": ["low", "high"]},
        },
        "required": ["category", "priority"],
    },
}]

# tool_choice='any' guarantees the model emits structured output, not prose.
# Few-shot examples still teach HOW to choose the category.

อย่ากำหนดข้อจำกัดในสคีมามากเกินไป

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

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

"input_schema": {
    "type": "object",
    "properties": {
        "category": {"type": "string",
                     "enum": ["billing", "technical", "other"]},
        # captured only when category == 'other' — NOT required
        "other_detail": {"type": "string"},
    },
    # require only what is ALWAYS present
    "required": ["category"],
}

ตัวอย่างที่มากขึ้นไม่ได้ดีกว่าเสมอไป

คำแนะนำคือ ตัวอย่าง 2-4 ตัวอย่างต่อความกำกวมหนึ่งประเด็น ไม่ใช่ยี่สิบตัวอย่าง เหตุใดจึงจำกัดจำนวนไว้เช่นนั้น

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

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

เมื่อการพรอมป์แบบไม่กี่ตัวอย่างช่วยไม่ได้

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

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

ตัวอย่างในฐานะทรัพยากรที่นำกลับมาใช้ใหม่ได้

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

โครงการ ./CLAUDE.md หรือไฟล์ .claude/rules/ (แชร์ผ่าน VCS) เพื่อให้เพื่อนร่วมทีมได้รับพฤติกรรมที่ปรับเทียบแบบเดียวกัน
ไฟล์กฎที่จำกัดตามเส้นทางจะโหลดตัวอย่างเฉพาะเมื่อแก้ไขไฟล์ที่ตรงกัน ช่วยประหยัดบริบทเมื่อเทียบกับพรอมป์ขนาดใหญ่ก้อนเดียว

คัดสรรครั้งเดียว แล้วแบบแผนจะสรุปไปใช้กับอินพุตในอนาคตทุกแบบ

---
paths: ["**/*.sql"]
---
# SQL review examples (loaded only when editing SQL)

Flag a query ONLY when it can return wrong rows.

Example — FLAG:
  SELECT * FROM orders WHERE status = 'paid' OR amount > 0
  (OR widens the filter; likely a bug)

Example — OK:
  SELECT id FROM orders WHERE status = 'paid' AND amount > 0

ตรวจสอบอย่างรวดเร็ว

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

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

สรุป

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

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

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

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

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

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

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

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

บทเรียน “การทำให้เป็นทั่วไปเทียบกับการทำซ้ำ” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “การทำให้เป็นทั่วไปเทียบกับการทำซ้ำ”

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

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

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

บทเรียน “การทำให้เป็นทั่วไปเทียบกับการทำซ้ำ” ใช้เวลานานแค่ไหน

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

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

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

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

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