← กลับหน้าภาพรวม
ระดับ 2 · INTERMEDIATE

Intermediate — พรอมป์ที่น่าเชื่อถือและทำซ้ำได้

ก้าวจากการสั่งทีละคำสั่งเดี่ยว ๆ ไปเป็นกระบวนการทำงาน (workflow) ที่คุมได้ วัดผลได้ ด้วยการบังคับรูปแบบผลลัพธ์ (structured output), การต่อขั้นตอน (chaining), การดึงข้อมูลมาช่วยตอบ (RAG) และการวัดผลเบื้องต้น (eval)

📦 6 โมดูล⏱ 18-22 ชั่วโมง (6 โมดูล)

6 โมดูลในระดับนี้: 2.1 Structured Output: เลิ · 2.2 Chain-of-thought และ s · 2.3 Decomposition และ prom · 2.4 RAG prompting และการ g · 2.5 System vs user prompt · 2.6 Self-consistency และ m

2.1
โมดูล 2.1

Structured Output: เลิกอ้อน ใช้ schema

JSON/schema แทนการขอด้วย prose

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: แทนที่จะสั่งกาแฟด้วยการพูดพร่ำยาว ๆ ให้บาริสต้าเดาเอง เราใช้ 'ใบสั่ง' ที่มีช่องกรอกตายตัวว่าเมนูอะไร ขนาดไหน หวานเท่าไหร่ AI ก็ต้องกรอกลงช่องให้ครบเป๊ะ
🎯
ทำไมต้องรู้: สิ่งที่ AI ตอบออกมาจะหน้าตาเหมือนเดิมทุกครั้ง เอาไปต่อกับโปรแกรมหรือฐานข้อมูลได้เลย ไม่ต้องมานั่งแกะข้อความทีละอันเอง งานอัตโนมัติก็เลยไม่พังกลางคัน

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • ใช้ฟีเจอร์บังคับรูปแบบผลลัพธ์ (structured output / JSON schema) ของแต่ละเจ้า แทนการพูดอ้อม ๆ ด้วยข้อความ
  • ออกแบบ schema พร้อมกลไกลองใหม่ (retry) สำหรับงานใช้จริง (production)
  • รู้ว่า Anthropic แนะนำให้ใช้ structured outputs แทนลูกเล่นเก่า (การเติม '{' นำหน้าคำตอบ หรือ prefill)

เนื้อหา

ถ้าอยากคุมหน้าตาของสิ่งที่ AI ตอบออกมาแบบมือโปร ให้เลิกพูดอ้อม ๆ เป็นความเรียง (prose) แล้วหันมาใช้ฟีเจอร์ "บังคับให้ตอบเป็นรูปแบบตายตัว" (structured output / JSON schema) ที่แต่ละเจ้ามีให้อยู่แล้ว ไม่ว่าจะเป็น OpenAI (Structured Outputs / JSON mode), Anthropic (Structured Outputs ที่บังคับด้วยแบบพิมพ์เขียว หรือ schema พร้อมช่องแบบ tool/enum ไว้จัดหมวด) หรือ Google Gemini (structured output / response schema) มีให้ใช้กันหมด. Anthropic บอกตรง ๆ เลยว่าให้ใช้ structured outputs "แทน" ลูกเล่นเก่าที่เคยเติมวงเล็บปีกกา '{' ไว้หน้าคำตอบ (ซึ่งตอนนี้เลิกใช้แล้ว และถูกถอดออกจากโมเดลรุ่นใหม่สุด). ถ้าเป็นงานทำครั้งเดียวจบ แค่ขอให้ตอบเป็นก้อน JSON ก็พอ แต่ถ้าจะเอาไปใช้กับระบบจริง (production) ให้ใช้ฟีเจอร์ schema ควบคู่กับการสั่งลองใหม่ (retry) เวลาผลไม่ผ่าน จะชัวร์กว่าเยอะ.

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Structured Outputการบังคับให้ AI ตอบเป็นรูปแบบตายตัว เช่น ตาราง/ช่องกรอก แทนการเขียนบรรยายเรื่อย ๆ
JSONรูปแบบข้อมูลที่จัดเป็นคู่ 'ชื่อ: ค่า' ที่โปรแกรมอ่านต่อได้ง่าย เหมือนฟอร์มกรอกข้อมูล
Schemaแบบพิมพ์เขียวที่กำหนดว่าคำตอบต้องมีช่องอะไรบ้าง และแต่ละช่องเป็นข้อมูลชนิดไหน
proseการเขียนบรรยายแบบร้อยแก้วปกติ (ตรงข้ามกับการตอบเป็นรูปแบบตายตัว)
enumรายการตัวเลือกที่จำกัดไว้ให้เลือก เช่น เลือกได้แค่ 'ดี/กลาง/แย่' ห้ามตอบนอกนี้

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

สกัดข้อมูลด้วย JSON schema (pseudo-config)
# แทนการเขียนพรอมป์ว่า "ตอบเป็น JSON นะ" ให้ผูก schema จริง response_format: type: json_schema schema: type: object properties: ชื่อลูกค้า: { type: string } เบอร์โทร: { type: [string, "null"] } ประเภทคำร้อง: { type: string, enum: ["คืนเงิน","เปลี่ยนสินค้า","สอบถาม","อื่นๆ"] } ความเร่งด่วน: { type: string, enum: ["สูง","กลาง","ต่ำ"] } required: [ชื่อลูกค้า, ประเภทคำร้อง, ความเร่งด่วน] # พรอมป์: "สกัดข้อมูลจากข้อความร้องเรียนนี้ ถ้าไม่มีเบอร์โทรให้ใส่ null"
✅ ผลลัพธ์ที่ได้

JSON ที่ตรง schema เป๊ะทุกครั้ง มี enum คุมค่าที่เป็นไปได้ ไม่มี field เกิน/ขาด นำไปเข้าระบบต่อได้ทันที

💡 จุดสอน

การผูก schema ให้ผลลัพธ์ที่ parse ได้แน่นอน enum ป้องกันค่านอกเหนือที่กำหนด สำหรับ production เพิ่ม retry เมื่อ validation ล้มเหลว ดีกว่าอ้อนด้วย prose ที่พังเป็นครั้งคราว

แบบฝึกหัดท้ายโมดูล

  1. ออกแบบ JSON schema สำหรับงานสกัดข้อมูลจริงของคุณ พร้อมกำหนด required และ enum
  2. แปลงพรอมป์เดิมที่ขอ JSON ด้วย prose ให้ใช้ structured output feature แล้วเทียบอัตราผลลัพธ์ที่ parse สำเร็จ
2.2
โมดูล 2.2

Chain-of-thought และ step-by-step (สำหรับโมเดลไม่-reasoning)

ให้คิดก่อนตอบเมื่อจำเป็น

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • สั่งให้ AI คิดทีละขั้นเอง (manual CoT) กับโมเดลที่ไม่ได้คิดเองอัตโนมัติ (พวก Haiku/Flash ที่ปิดโหมดคิด)
  • แยกส่วนคิด (thinking) ออกจากส่วนตอบ (answer) ด้วยป้ายคร่อมข้อความ (tag)
  • รู้ข้อควรระวัง: บางโมเดลที่ปิด thinking ไวต่อคำว่า 'think' ให้ใช้ 'พิจารณา/ประเมิน/ไล่เหตุผล' แทน

เนื้อหา

การให้ AI ไล่ความคิดออกมาก่อนแล้วค่อยตอบ (chain-of-thought หรือ CoT) เหมาะกับงานเลข งานตรรกะ และงานที่ต้องตัดสินใจหลายชั้น. มันมีสองแบบ คือ (ก) แบบที่เราสั่งเอง (manual CoT) เช่นบอกว่า "คิดทีละขั้นนะ" หรือใช้ป้ายคร่อม thinking...answer สำหรับโมเดลที่ไม่ได้คิดเองอัตโนมัติ (ไม่ใช่ reasoning model) กับ (ข) การคิดในตัวของโมเดลรุ่นที่คิดเองได้ (reasoning models) ซึ่งจะเรียนกันในระดับ Advanced. โมดูลนี้เน้นแบบแรก คือ manual CoT ที่ยังช่วยได้จริงบนโมเดลรุ่นถูกและเร็ว (พวก Haiku/Flash ที่ปิดโหมดคิด). มีข้อควรระวังจาก Anthropic ว่าพอปิดโหมดคิด บางโมเดลจะไวกับคำว่า 'think' เป็นพิเศษ ให้เลี่ยงไปใช้คำว่า 'consider / evaluate / reason through' (พิจารณา / ประเมิน / ไล่เหตุผล) แทน. และคำเตือนสำคัญของยุค 2025/26 คือ อย่าเอา "คิดทีละขั้น" ไปแปะกับโมเดลที่ "คิดเองอยู่แล้ว" (เดี๋ยวไปดูรายละเอียดกันในระดับ Advanced).

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Chain-of-thought (CoT)การให้ AI เขียนขั้นตอนความคิดออกมาก่อนสรุปคำตอบ เหมือนโชว์วิธีทำเลขทีละบรรทัด
step-by-stepการสั่งให้ทำ/คิดทีละขั้นตอนตามลำดับ
reasoning modelAI รุ่นที่คิดเป็นขั้นตอนได้เองในตัวโดยไม่ต้องสั่ง
manual CoTการที่เราสั่งให้ AI คิดทีละขั้นด้วยตัวเอง (สำหรับรุ่นที่ไม่คิดเองอัตโนมัติ)
tagป้ายคร่อมข้อความ เช่น <thinking>...</thinking> เพื่อบอก AI ว่าตรงนี้คือส่วนคิด ตรงนี้คือส่วนตอบ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

manual CoT แยก thinking/answer
โจทย์: ร้านมีโปรโมชัน ซื้อ 2 แถม 1 ลูกค้าหยิบสินค้า 7 ชิ้น ราคาชิ้นละ 120 บาท ต้องจ่ายเท่าไร ไล่เหตุผลใน <reasoning> ก่อน แล้วสรุปคำตอบใน <answer> <reasoning> พิจารณา: ซื้อ 2 แถม 1 = ทุกๆ 3 ชิ้น จ่ายแค่ 2 7 ชิ้น = 2 ชุดเต็ม (6 ชิ้น จ่าย 4) + เหลือ 1 ชิ้น (จ่าย 1) จ่ายจริง = 4 + 1 = 5 ชิ้น 5 × 120 = 600 </reasoning> <answer>600 บาท</answer>
✅ ผลลัพธ์ที่ได้

คำตอบ 600 บาท พร้อมเหตุผลที่ตรวจสอบได้ ลดการตอบผิดจากการข้ามขั้น

💡 จุดสอน

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

แบบฝึกหัดท้ายโมดูล

  1. เขียนพรอมป์ manual CoT สำหรับงานตัดสินหลายขั้นของคุณ โดยแยก reasoning/answer
  2. ทดสอบพรอมป์เดียวกันมี/ไม่มี CoT บนโมเดลเร็ว (เช่น Flash/Haiku-class) เทียบความแม่นยำ
2.3
โมดูล 2.3

Decomposition และ prompt chaining

แตกงานซับซ้อนเป็นขั้นที่ตรวจสอบได้

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

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • แตกงานออกเป็นขั้น ๆ โดยเอาผลของขั้นก่อน (output) ไปป้อนขั้นถัดไป
  • ใช้การวนแก้ตัวเอง (self-correction chaining): ร่าง (draft) → ติชม (critique) → แก้ใหม่ (revise)
  • ตัดสินใจได้ว่าเมื่อไรควรต่อขั้นตอน (chain เพราะอยากเห็นและคุมกลางทาง) เมื่อไรไม่ควร

เนื้อหา

การแตกงานยาก ๆ ออกเป็นขั้นย่อยเรียงกันไป (decomposition) โดยเอาผลของขั้นก่อน (output) ส่งต่อให้ขั้นถัดไป ในปี 2025/26 ก็ยังมีประโยชน์อยู่ โดยเฉพาะตอนที่เราอยากมี "จุดตรวจกลางทาง" (gate) ไว้เช็กหรือกันของเสียก่อนไปต่อ อยากบังคับให้ทำเป็นสายพาน (pipeline) หรืออยากเก็บบันทึก (log) และแตกทางเลือกไว้. รูปแบบที่คนใช้จริงบ่อยสุดคือการวนแก้ตัวเอง (self-correction chaining) นั่นคือ ร่างแรกออกมา → ติชมเทียบกับเกณฑ์ที่ตั้งไว้ชัด ๆ → แล้วแก้ใหม่ โดยแยกแต่ละขั้นเป็นคนละครั้งของการเรียก AI (call). ข้อสังเกตคือ ถ้าเป็นโมเดลรุ่นที่คิดเองเก่ง ๆ (reasoning models) งานหลายขั้นที่เมื่อก่อนต้องต่อกันเป็นทอด ๆ ตอนนี้มันทำจบได้ในการเรียกครั้งเดียวเลย เพราะฉะนั้นเราควรต่อขั้นตอน (chain) "เฉพาะตอนที่อยากเห็นและอยากคุมแต่ละขั้น" ไม่ใช่ทำทุกงานโดยอัตโนมัติ.

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Decompositionการแตกงานใหญ่ที่ซับซ้อนออกเป็นงานย่อย ๆ ที่ทำทีละขั้น
prompt chainingการต่อคำสั่งหลายอันเป็นสายพาน โดยเอาผลลัพธ์ของอันก่อนไปป้อนอันถัดไป
pipelineสายการผลิตของขั้นตอนที่ไหลต่อกันเป็นทอด ๆ
self-correction chainingวนแก้ตัวเอง คือ ร่างแรก -> ตรวจติเทียบเกณฑ์ -> แก้ใหม่ให้ดีขึ้น
gateจุดตรวจด่านที่ต้องผ่านก่อนถึงจะให้ไปขั้นถัดไปได้

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

self-correction chain 3 ขั้น
# ขั้นที่ 1 (call แรก) — Draft "ร่างโพสต์โฆษณาคอร์สภาษาอังกฤษออนไลน์ ยาว 3 ย่อหน้า กลุ่มเป้าหมายวัยทำงาน" # ขั้นที่ 2 (call ที่สอง) — Critique ตามเกณฑ์ "วิจารณ์ร่างนี้ตามเกณฑ์: (1) hook ดึงดูดใน 1 บรรทัดแรกไหม (2) มี CTA ชัดไหม (3) พูดถึงผลลัพธ์ที่ผู้เรียนได้จริงไหม (4) ยาวเกินไปไหม — ให้คะแนนแต่ละข้อ 1-5 พร้อมเหตุผล" [แนบร่างจากขั้น 1] # ขั้นที่ 3 (call ที่สาม) — Revise "แก้ร่างตามคำวิจารณ์ให้ทุกเกณฑ์ได้ 5" [แนบร่าง + คำวิจารณ์]
✅ ผลลัพธ์ที่ได้

โพสต์เวอร์ชันสุดท้ายที่ผ่านเกณฑ์คุณภาพชัดเจน โดยเห็นร่องรอยการวิจารณ์กลางทางที่ตรวจสอบได้

💡 จุดสอน

การแยก draft/critique/revise เป็นคนละ call ทำให้ตรวจสอบและ gate คุณภาพกลางทางได้ ใช้เมื่อต้องการเห็นและควบคุมขั้นตอน ไม่ใช่ทุกงาน

แบบฝึกหัดท้ายโมดูล

  1. ออกแบบ prompt chain 3 ขั้นสำหรับงานสร้างเนื้อหาของคุณ พร้อมเกณฑ์ critique ที่วัดได้
  2. หาตัวอย่างงานที่เคย chain แต่จริงๆ reasoning model ทำใน call เดียวได้ แล้วลองยุบให้เหลือ call เดียว
2.4
โมดูล 2.4

RAG prompting และการ ground ป้องกัน hallucination

ตอบจากบริบทเท่านั้น + อ้างอิง

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: เหมือนข้อสอบแบบ 'เปิดหนังสือตอบ' ที่ครูสั่งว่าให้ตอบจากในหนังสือเล่มนี้เท่านั้น ถ้าไม่มีในเล่มให้บอกว่าไม่รู้ ห้ามมโนเอง และต้องอ้างหน้าที่เอามาด้วย
🎯
ทำไมต้องรู้: AI จะเลิกแต่งเรื่องมั่ว ๆ (มโน) เพราะถูกบังคับให้ตอบจากข้อมูลจริงที่เราให้ พร้อมชี้แหล่งอ้างอิง ทำให้เชื่อถือได้และตรวจย้อนได้

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • ใส่คำสั่งยึดคำตอบกับข้อมูลจริง (grounding): ให้ตอบจากข้อมูลที่ให้เท่านั้น ถ้าไม่มีก็ให้บอกว่าไม่รู้
  • ใช้เทคนิค "คัดข้อความก่อนแล้วค่อยตอบ" (quote-then-answer) ของ Anthropic กับเอกสารยาว
  • เข้าใจแนวโน้ม Agentic RAG ที่ตัว AI ตัดสินใจเองว่าจะไปดึงข้อมูล (retrieve) เมื่อไรและดึงอะไร

เนื้อหา

สำหรับงานแบบดึงข้อมูลมาช่วยตอบ (RAG) คำสั่งที่ได้ผลดีที่สุดคือบอกว่า "ให้ตอบโดยใช้ข้อมูลด้านล่างนี้เท่านั้น ถ้าในนั้นไม่มีคำตอบก็ให้บอกไปตรง ๆ ว่าไม่รู้" แค่นี้ก็ช่วยยึดคำตอบให้เกาะกับข้อมูลจริง (grounding) และกันไม่ให้ AI แต่งเรื่องมั่ว (hallucination) ได้แล้ว พร้อมกับสั่งเพิ่มว่า "ให้อ้างอิงหรือยกข้อความจากแหล่งมาด้วย". ส่วนเคล็ดลับสำหรับเอกสารยาว ๆ ของ Anthropic คือให้ AI "คัดข้อความส่วนที่เกี่ยวข้องออกมาก่อน" (ใส่ไว้ในป้าย quotes) "แล้วค่อยตอบจากข้อความที่คัดมานั้น" วิธีนี้ช่วยตัดส่วนที่ไม่เกี่ยวทิ้งไปในเอกสารใหญ่ ๆ. แนวโน้มใหม่ที่กำลังมาคือ Agentic RAG ที่ตัว AI จะตัดสินใจเองว่าจะไปดึงข้อมูลตอนไหนและดึงอะไร แทนที่จะทำตามสายพาน "ดึงมาแล้วตอบ" แบบตายตัวเหมือนเดิม.

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
RAGวิธีให้ AI ตอบโดยดึงข้อมูลจากเอกสารที่เราป้อนให้ก่อน ไม่ใช่ตอบจากความจำล้วน ๆ
groundingการยึดคำตอบให้อิงกับข้อมูลจริงที่ให้ไว้เท่านั้น
hallucinationอาการที่ AI แต่งเรื่องขึ้นมาเองอย่างมั่นใจทั้งที่ไม่จริง
citationการอ้างอิงแหล่งที่มา บอกว่าคำตอบนี้มาจากตรงไหน
long-contextการป้อนข้อมูลยาว ๆ จำนวนมากให้ AI อ่านทีเดียว

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

quote-then-answer + grounding
<document> {{วางนโยบายการคืนสินค้าของบริษัทตรงนี้}} </document> คำถามลูกค้า: "ซื้อสินค้าเมื่อ 40 วันก่อน ยังคืนได้ไหม" ขั้นตอน: 1. สกัดข้อความจากเอกสารที่เกี่ยวกับระยะเวลาคืนสินค้า ใส่ใน <quotes> 2. ตอบคำถามโดยอ้างอิงเฉพาะ <quotes> เท่านั้น 3. ถ้าเอกสารไม่ได้ระบุ ให้ตอบว่า "นโยบายไม่ได้ระบุกรณีนี้ กรุณาติดต่อฝ่ายบริการ" ห้ามเดา
✅ ผลลัพธ์ที่ได้

คำตอบที่อ้าง quote จริงจากนโยบาย เช่น 'คืนได้ภายใน 30 วัน' → แจ้งว่าเกินกำหนด โดยไม่กุข้อมูลนอกเอกสาร

💡 จุดสอน

การบังคับสกัด quote ก่อนตอบ + สั่งให้ 'บอกว่าไม่รู้' เมื่อไม่มีข้อมูล คือหัวใจกัน hallucination ในงาน RAG และทำให้ตรวจสอบที่มาได้

แบบฝึกหัดท้ายโมดูล

  1. สร้างพรอมป์ RAG แบบ quote-then-answer กับเอกสารนโยบายจริงของคุณ ทดสอบคำถามที่ 'ไม่มีคำตอบในเอกสาร'
  2. เทียบผลพรอมป์ที่มี/ไม่มีคำสั่ง 'ถ้าไม่มีให้บอกว่าไม่รู้' ดูว่าอันไหน hallucinate น้อยกว่า
2.5
โมดูล 2.5

System vs user prompt และ long-context

วางคำสั่งถาวรกับข้อมูลชั่วคราวให้ถูกที่

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: System prompt เหมือนคู่มือพนักงานที่ติดไว้บนผนัง (กฎ บทบาท มารยาท ใช้ตลอด) ส่วน user prompt เหมือนใบงานของลูกค้าคนนี้เดี๋ยวนี้ (เปลี่ยนไปเรื่อยตามงาน)
🎯
ทำไมต้องรู้: วางกฎถาวรกับข้อมูลชั่วคราวให้ถูกที่ AI จะจำบทบาทได้มั่นคง ไม่หลุด และเราแก้เฉพาะงานเฉพาะครั้งได้ง่าย ไม่ต้องรื้อกฎใหม่ทุกรอบ

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • แยก system prompt (บทบาท/กฎ/ข้อตกลงผลลัพธ์ ที่ใช้ถาวร) ออกจาก user prompt (งานและข้อมูลของแต่ละรอบ)
  • วางเอกสารยาวไว้ "บนสุด" เหนือคำถาม (ช่วยเพิ่มคุณภาพได้ถึงราว 30% ตามที่ Anthropic บอก)
  • ห่อเอกสารด้วยป้ายบอกรายละเอียด (metadata tag) เช่น document, source

เนื้อหา

System prompt คือที่ที่เราเก็บบทบาท กฎ ข้อตกลงว่าผลลัพธ์ต้องหน้าตาแบบไหน (output contract) ขอบเขตความปลอดภัย และโทนการพูด (tone) ที่ใช้ตลอดทุกครั้ง. ส่วน user prompt คืองานและข้อมูลเฉพาะของการถามรอบนั้น ๆ (turn). วิธีที่ดีคือเอาคำสั่งที่ค่อนข้างอยู่นิ่งกับข้อจำกัดสำคัญไปไว้ใน system prompt (Google เองก็แนะนำให้วางคำสั่งสำคัญไว้ตอนต้น หรือไว้ใน system prompt) แล้วเอาข้อมูลที่เปลี่ยนไปทุกรอบไปไว้ในฝั่ง user. สำหรับงานที่ต้องป้อนข้อความยาว ๆ (long-context คือข้อมูลที่ป้อนเข้าตั้งแต่ 20,000 token ขึ้นไป) ให้วางเอกสารยาว ๆ "ไว้บนสุด เหนือคำถามหรือคำสั่ง" ซึ่ง Anthropic รายงานว่าช่วยเพิ่มคุณภาพได้ถึงราว 30% ในงานที่มีหลายเอกสารและซับซ้อน แถมยังแนะนำให้ห่อเอกสารแต่ละชิ้นด้วยป้ายบอกรายละเอียด (metadata tag) เช่น document, source. ทั้ง Gemini และ Claude ตอนนี้รับข้อความได้ระดับล้าน token เลยจะ "โยนเข้าไปทั้งหมด" ก็ได้ แต่ตำแหน่งที่วางก็ยังสำคัญอยู่ดี.

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
System promptคำสั่งพื้นฐานที่ตั้งไว้ถาวร กำหนดบทบาท กฎ และโทนของ AI ใช้กับงานทุกครั้ง
user promptคำสั่ง/ข้อมูลเฉพาะของการถามครั้งนั้น ๆ ที่เปลี่ยนไปเรื่อย
turnหนึ่งรอบของการถาม-ตอบในการสนทนา
output contractข้อตกลงว่าผลลัพธ์ต้องออกมาหน้าตาแบบไหน
constraintข้อจำกัดหรือกฎกติกาที่ AI ต้องทำตาม เช่น ห้ามยาวเกิน 100 คำ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

แยก system/user + วางเอกสารบนสุด
=== SYSTEM PROMPT (คงที่ทุก turn) === คุณคือผู้ช่วยฝ่ายกฎหมายภายในองค์กร ตอบเป็นภาษาไทยทางการ กฎ: ตอบจากเอกสารที่ให้เท่านั้น อ้างอิงชื่อเอกสารทุกครั้ง ถ้าไม่มีข้อมูลให้บอกตรงๆ === USER PROMPT (เปลี่ยนตาม turn) === <document source="สัญญาเช่า-2026.pdf"> {{...เอกสารยาววางบนสุด...}} </document> <document source="ภาคผนวก-ก.pdf"> {{...}} </document> คำถาม: "ผู้เช่าบอกเลิกสัญญาก่อนกำหนดได้ในเงื่อนไขใดบ้าง"
✅ ผลลัพธ์ที่ได้

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

💡 จุดสอน

บทบาท/กฎถาวรอยู่ใน system, ข้อมูล+คำถามอยู่ใน user, และเอกสารยาววาง 'บนสุด' เหนือคำถาม คือ pattern ที่วัดผลได้ว่าดีขึ้นในงานหลายเอกสาร

แบบฝึกหัดท้ายโมดูล

  1. เขียน system prompt สำหรับผู้ช่วยเฉพาะทางของคุณ (กฎ/บทบาท/output contract) แยกจาก user prompt ให้ชัด
  2. ทดลองวางเอกสารยาว 'บนสุด' vs 'ล่างสุด' ของพรอมป์ เทียบคุณภาพคำตอบกับ input หลายเอกสาร
2.6
โมดูล 2.6

Self-consistency และ meta-prompting เบื้องต้น

ยกความน่าเชื่อถือด้วยการ sample หลายครั้ง และใช้ AI ช่วยเขียนพรอมป์

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: Self-consistency เหมือนถามเพื่อนหลาย ๆ คนคำถามเดียวกัน แล้วเชื่อคำตอบที่คนส่วนใหญ่ตอบตรงกัน ส่วน meta-prompting คือให้ AI ช่วยร่างคำสั่งให้ AI อีกที เหมือนใช้ผู้ช่วยเขียนใบสั่งงานให้
🎯
ทำไมต้องรู้: ถามซ้ำหลายรอบแล้วเอาเสียงข้างมากช่วยลดคำตอบฟลุ๊ก ๆ ที่ผิด ทำให้แม่นขึ้น และให้ AI ช่วยเขียนพรอมป์ก็ประหยัดเวลาเราได้พรอมป์ดี ๆ เร็วขึ้น

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • ใช้ self-consistency: รันซ้ำหลายครั้ง (ตั้งค่าความสุ่ม หรือ temperature ให้สูง) แล้วเอาเสียงข้างมาก
  • ใช้เครื่องมือช่วยร่าง/ปรับพรอมป์ของแต่ละเจ้า (Anthropic Console, OpenAI Playground) เป็นจุดเริ่มต้น
  • เข้าใจว่า meta-prompting ได้ผลดีที่สุดเมื่อทำคู่กับการวัดผล

เนื้อหา

Self-consistency คือการสั่งรันพรอมป์เดิมซ้ำหลายครั้ง (โดยตั้งค่าความสุ่ม หรือ temperature ให้สูง) แล้วเอาคำตอบที่โผล่มาบ่อยที่สุดเป็นตัวตัดสิน (เหมือนโหวตเสียงข้างมาก). วิธีนี้ช่วยให้แม่นขึ้นในงานเลขและงานเหตุผล โดยไม่ต้องไปเทรนโมเดลใหม่ แต่แลกกับค่าใช้จ่ายตอนรันที่เพิ่มขึ้น (ต้องจ่ายค่า token เพิ่มขึ้นเป็น N เท่าตามจำนวนครั้งที่รัน) ก็ถือเป็นวิธียกความน่าเชื่อถือมาตรฐานอยู่. ส่วน meta-prompting คือการให้ AI ช่วยเขียนพรอมป์ให้เรา ซึ่งตอนนี้กลายเป็นเรื่องปกติไปแล้ว. เครื่องมือของแต่ละเจ้า เช่น Anthropic Console (มี Prompt Generator / Prompt Improver) กับ OpenAI Playground (มี prompt generator) ช่วยแปลงคำอธิบายงานของเราให้กลายเป็นพรอมป์ที่มีโครงสร้างเรียบร้อย ถือเป็นจุดตั้งต้นที่ดี แต่ยังไม่ใช่ของสำเร็จรูปที่หยิบไปใช้ได้เลยทันที. ลำดับที่ควรทำคือ ร่างด้วยเครื่องมือ (generator) → เอาไปลองกับเคสจริง → ให้ตัวช่วยปรับ (optimizer) หรือตัวโมเดลเองเสนอแก้ โดยเทียบกับตัวเลขวัดผล → แล้วเก็บอันที่ทำคะแนนได้ดีจริง. สรุปคือ meta-prompting จะได้ผลดีก็ต่อเมื่อทำคู่กับการวัดผล ถ้าทำลอย ๆ เฉย ๆ ก็แค่ย้ายการเดาไปไว้อีกที่เท่านั้น.

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Self-consistencyการถาม AI คำถามเดิมหลายครั้งแล้วเลือกคำตอบที่ออกมาบ่อยที่สุด (เสียงข้างมาก)
temperatureค่าที่ปรับความสุ่ม/สร้างสรรค์ของคำตอบ ยิ่งสูงยิ่งหลากหลายและแปลกใหม่
Meta-promptingการใช้ AI ช่วยเขียนหรือปรับปรุงคำสั่ง (พรอมป์) ให้เรา
test-time computeการยอมใช้พลังประมวลผล/ค่าใช้จ่ายเพิ่มตอนใช้งานจริง เพื่อแลกกับคำตอบที่ดีขึ้น
tokenหน่วยย่อยของข้อความที่ AI นับเพื่อคิดค่าใช้จ่ายและปริมาณงาน

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ใช้ Prompt Improver + self-consistency
# ขั้น 1: ใช้ Prompt Improver (Anthropic Console) หรือ generator ของ OpenAI วางพรอมป์ร่างของคุณ → ให้เครื่องมือปรับโครงสร้าง เพิ่ม delimiter/ตัวอย่าง # ขั้น 2: self-consistency สำหรับคำถามที่ต้องแม่น รันพรอมป์เดียวกัน 5 ครั้งที่ temperature ~0.7: "ประเมินว่าคำร้องนี้เข้าเงื่อนไขประกันหรือไม่ ตอบ เข้า/ไม่เข้า พร้อมเหตุผลสั้น" → นับผล: เข้า x4, ไม่เข้า x1 → สรุปเสียงข้างมาก = เข้า
✅ ผลลัพธ์ที่ได้

พรอมป์ที่มีโครงสร้างดีขึ้นจาก improver + คำตอบที่นิ่งขึ้นจากเสียงข้างมาก 5 ครั้ง

💡 จุดสอน

generator/improver ช่วยยกร่างให้เร็ว แต่ต้องทดสอบต่อ ส่วน self-consistency แลก token เพิ่มเพื่อความน่าเชื่อถือ ใช้เมื่อความถูกต้องคุ้มค่ากว่าต้นทุน

แบบฝึกหัดท้ายโมดูล

  1. นำพรอมป์ของคุณเข้า Prompt Improver/generator เทียบ before/after ว่าโครงสร้างดีขึ้นตรงไหน
  2. เลือกคำถามที่ผลไม่นิ่ง รัน self-consistency 5 ครั้ง สรุปเสียงข้างมาก แล้วประเมินว่าคุ้มต้นทุน token ไหม

🎯 Mini-project: ผู้ช่วย RAG ตอบคำถามจากเอกสารองค์กร

  1. เลือกชุดเอกสารจริง (นโยบาย/คู่มือ/คำถามที่พบบ่อย) สัก 5-10 หน้า มาเป็นฐานความรู้
  2. เขียน system prompt (บทบาท + กฎให้ยึดข้อมูลจริง grounding) แยกจาก user prompt ที่ใช้ป้อนเอกสารกับคำถาม
  3. ใช้เทคนิคคัดข้อความก่อนแล้วค่อยตอบ (quote-then-answer) พร้อมคำสั่ง "ถ้าไม่มีให้บอกว่าไม่รู้" และให้อ้างอิงชื่อเอกสารด้วย
  4. ให้บางส่วนของผลลัพธ์ (เช่น การจัดหมวดคำถาม) ออกมาเป็นรูปแบบตายตัว (structured output) ด้วย JSON schema และ enum
  5. สร้างชุดคำถามทดสอบ 10 ข้อ (โดยมี 3 ข้อที่ "ไม่มีคำตอบอยู่ในเอกสาร") แล้วเช็กว่า AI ไม่แต่งเรื่องมั่ว (hallucinate)
  6. ใช้ Prompt Improver ปรับพรอมป์ 1 รอบ แล้วเทียบผลก่อน/หลังบนชุดทดสอบชุดเดิม
ก้าวต่อไป

Advanced — วิศวกรรมพรอมป์ระดับ production

ไปต่อ →