Module 5 Intermediate

Structured Output & Templates

JSON, XML, Markdown — System Prompts, Prompt-as-Code & Reusable Templates

🎯 วัตถุประสงค์การเรียนรู้ Module 5

สร้าง JSON และ XML output schema ที่ AI ทำตามได้แม่นยำ
ใช้ XML Tags pattern แยก context/task/output_format/data ใน Prompt
เขียน JSON Schema ระดับ API ด้วย required และ enum fields
ออกแบบ System Prompt และ Prompt Template แบบ Prompt-as-Code
เข้าใจว่า Reasoning Models ปี 2026 ใช้ schema แทน Few-shot ได้อย่างไร

5.1 Structured Output คืออะไร?

Structured Output คือการให้ AI ตอบในรูปแบบที่มีโครงสร้างชัดเจน เช่น JSON, XML หรือ Markdown table — แทนที่จะตอบเป็นข้อความธรรมดา (free-text) ที่ต้องมาแกะทีหลัง

GPT-5.5 และ Claude รองรับ Structured Output อย่างเป็นทางการ (JSON mode)
ข้อมูลมีโครงสร้าง → นำไปใช้ต่อได้ง่าย (automation, database, report)
ลด Hallucination — AI ต้องตอบตาม schema ที่กำหนด
เหมาะกับ production systems ที่ต้อง parse output อัตโนมัติ

💡 Module นี้จะสอน

เริ่มจากตัวอย่าง JSON → XML → XML Tags pattern → แล้วสรุปว่าเมื่อไหร่ควรใช้ format ไหน พร้อมเปรียบเทียบกับ free-text ในหัวข้อ 5.3.2

5.2 JSON Output

JSON (JavaScript Object Notation) เป็น format ยอดนิยมที่สุดสำหรับ Structured Output เพราะอ่านง่าย แปลงเป็น object ได้ทันที และรองรับทุก programming language

ตัวอย่าง: วิเคราะห์ผู้ต้องสงสัย (ตำรวจ)

ใช้เมื่อ: ต้องการข้อมูลที่ส่งต่อเข้าฐานข้อมูลหรือ dashboard ได้ทันที ไม่ต้องมาแกะข้อความ

✅ ตัวอย่าง JSON: วิเคราะห์ผู้ต้องสงสัย (ตำรวจ)

วิเคราะห์ข้อมูลผู้ต้องสงสัยและตอบเป็น JSON:

ข้อมูล: ชายไทย อายุประมาณ 35 ปี ใช้รถ BMW สีดำ
ทะเบียน กท-1234 พบเห็นบริเวณซอยสุขุมวิท 55
เวลาประมาณ 02:30 น. วันที่ 15 มี.ค. 2026

ตอบเป็น JSON:
{
  "suspect": {
    "gender": "",
    "nationality": "",
    "estimated_age": 0,
    "description": ""
  },
  "vehicle": {
    "type": "",
    "brand": "",
    "color": "",
    "plate": ""
  },
  "sighting": {
    "location": "",
    "date": "",
    "time": "",
    "notes": ""
  },
  "risk_level": "high|medium|low",
  "recommended_actions": [],
  "confidence": "high|medium|low",
  "gaps": ["string — ข้อมูลที่ขาดและต้องหาเพิ่ม"]
}

// confidence + gaps เป็น standard fields ที่ควรมีในทุก schema — ให้ AI รายงานความไม่แน่ใจแทนการแต่งข้อมูล

💬 ทำไมตัวอย่างนี้ดี?

มี template ชัดเจน: AI รู้ว่าต้องใส่ข้อมูลอะไรบ้าง ไม่มัวแต่งเอง
มี enum: risk_level บังคับให้ตอบเฉพาะ high/medium/low
มี confidence + gaps: ให้ AI บอกตรงๆ ว่าไม่แน่ใจตรงไหน แทนที่จะแต่งขึ้นมา

ตัวอย่าง: วิเคราะห์ Feedback (ธุรกิจ)

ใช้เมื่อ: ต้องจัดกลุ่ม feedback จำนวนมาก (เช่น 100-1,000 ชิ้น) แล้วดึงข้อมูลเข้า dashboard หรือรายงานอัตโนมัติ

✅ ตัวอย่าง JSON: วิเคราะห์รีวิวลูกค้า (ธุรกิจ) 📥 Download Mock Data

วิเคราะห์รีวิวลูกค้าต่อไปนี้ ตอบเป็น JSON:

รีวิว: "สินค้าดีมาก คุณภาพเกินราคา แต่ส่งช้าไป 3 วัน
บรรจุภัณฑ์ก็ไม่ค่อยดี กล่องบุบ พนักงานตอบแชทเร็วดี"

{
  "overall_sentiment": "positive|negative|mixed",
  "rating_estimate": 0,
  "aspects": [
    {
      "aspect": "product|delivery|packaging|service|price",
      "sentiment": "positive|negative|neutral",
      "evidence": "quote จากรีวิว"
    }
  ],
  "action_items": [],
  "priority": "high|medium|low",
  "confidence": "high|medium|low",
  "missing_info": ["string — สิ่งที่ไม่ชัดเจนจากรีวิว"]
}

// ตัวอย่างนี้ใช้ aspects array แยกวิเคราะห์แต่ละมิติ — ทำให้เห็นชัดว่าลูกค้าชมหรือติเรื่องอะไร

5.2.1 JSON Schema ระดับ API (OpenAI Structured Outputs)

สำหรับงาน production ที่ต้องการความแม่นยำสูง — ส่ง JSON Schema ผ่าน API parameter แทนการใส่ใน prompt

📋 Inline Schema vs API Schema

Inline Schema	API Schema
ใส่ใน Prompt ข้อความ (ทุก model รองรับ)	ส่งผ่าน API parameter `response_format` (แม่นยำกว่า)

🚔 JSON Schema ตัวอย่าง — งานตำรวจ

{
  "type": "object",
  "properties": {
    "case_type": {
      "type": "string",
      "enum": ["ฉ้อโกง","AML","CDR","Cybercrime","อื่นๆ"]
    },
    "risk_level": {
      "type": "string",
      "enum": ["high","medium","low"]
    },
    "red_flags": {
      "type": "array",
      "items": { "type": "string" },
      "maxItems": 5
    },
    "confidence": {
      "type": "string",
      "enum": ["high","medium","low"]
    },
    "action_items": {
      "type": "array",
      "items": { "type": "string" }
    },
    "gaps": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["case_type","risk_level","red_flags","confidence","action_items"]
}

📌 กฎ JSON Schema

required = AI ต้องตอบ fields เหล่านี้เสมอ
enum = จำกัดค่าที่ยอมรับ — ลด hallucination ได้ดีที่สุด
Claude: ใช้ผ่าน tool_use / GPT: ใช้ response_format parameter

⚡ 2026 Update — Reasoning Models + Structured Output

Reasoning Models (Claude Opus 4.8, GPT-5.5) parse JSON Schema ได้ดีมาก — ใช้ schema แทน Few-shot ยาวๆ ประหยัด token และแม่นยำกว่า
รูปแบบแนะนำ: Constraint-First + schema แทน "คิดทีละขั้นตอน" + ตัวอย่าง
Standard fields ที่ควรมีในทุก schema: "confidence": "high|medium|low" และ "gaps": ["ข้อมูลที่ยังขาด"] เพื่อให้ AI รายงานความไม่แน่ใจแทนการ hallucinate

❌ Before:

"คิดทีละขั้นตอน และตอบเป็น JSON ที่มี risk_level, red_flags, และ action_items"
+ ตัวอย่าง 3 ชุด (Few-shot) — ใช้ token ~800-1,200

✅ After (2026):

Constraints: facts only, cite source for each flag
Output: JSON schema with required/enum (ส่งผ่าน API)
→ ไม่ต้องใส่ตัวอย่าง — schema บังคับ format อัตโนมัติ — ใช้ token ~200

5.3 XML Output

XML เหมาะกับระบบราชการและ enterprise ที่ต้องการ structured data แบบ hierarchical — โดยเฉพาะระบบเก่าที่รับ JSON ไม่ได้

ใช้เมื่อ: ระบบปลายทางรับเฉพาะ XML หรือต้องการโครงสร้างข้อมูลหลายชั้น (nested) ที่อ่านง่ายกว่า JSON

สรุปข้อมูลคดีเป็น XML:

<case_summary>
  <case_number></case_number>
  <type></type>
  <date_reported></date_reported>
  <victim count=""></victim>
  <damage_value currency="THB"></damage_value>
  <modus_operandi>
    <step order="1"></step>
    <step order="2"></step>
  </modus_operandi>
  <evidence>
    <item type=""></item>
  </evidence>
  <status></status>
  <next_steps></next_steps>
</case_summary>

💬 ความเห็น: JSON vs XML

ถ้าเลือกได้ แนะนำ JSON เป็น default เพราะกระชับกว่า parse ง่ายกว่า และรองรับ modern tools ทั้งหมด — ใช้ XML เมื่อระบบปลายทางบังคับเท่านั้น

5.4 XML Tags Pattern — แยก Prompt Components

XML Tags pattern ใช้ tag เพื่อ แยกส่วนของ Prompt ให้ AI เข้าใจชัดเจนว่าตรงไหนคืออะไร — ไม่ใช่การกำหนด output format

ใช้เมื่อ: Prompt ยาวและซับซ้อน มีหลายส่วน (บทบาท, งาน, format, ข้อมูล) ต้องการให้ AI แยกแยะได้ชัด

💡 ความแตกต่างที่ต้องรู้

XML Tags pattern ≠ XML output schema — Tags pattern ใช้แยก "ส่วนของ Prompt" ส่วน XML schema ใช้กำหนด "รูปแบบ output"

🏷️ 4 Tags หลักสำหรับ Claude / Gemini

<context>
คุณเป็นนักวิเคราะห์คดีอาชญากรรมไซเบอร์ สังกัด บก.ปอท.
</context>

<task>
สรุป MO และระบุ Red Flags จากเอกสารคดีที่แนบ
</task>

<output_format>
ตอบเป็น JSON เท่านั้น:
{
  "mo_summary": "string (ไม่เกิน 120 คำ)",
  "red_flags": ["string"],
  "confidence": "high|medium|low",
  "gaps": ["ข้อมูลที่ยังขาด"]
}
</output_format>

<data>
[แนบเอกสารคดีที่นี่]
</data>

💬 ทำไมใช้ XML Tags ใน Prompt?

การแยก <context>, <task>, <output_format>, <data> ทำให้ AI ไม่สับสนระหว่าง "คำสั่ง" กับ "ข้อมูลที่ต้องวิเคราะห์" — ลด Lost-in-the-Middle effect ที่ AI ลืม instructions ตรงกลาง prompt ยาวๆ

💡 ตำแหน่งสำคัญ

วาง <output_format> หลัง <task> เสมอ — Lost-in-the-Middle: constraint ที่อยู่ใกล้ task ได้รับการปฏิบัติดีกว่า

5.5 สรุป: เมื่อไหร่ใช้ Structured Output และเลือก Format อย่างไร

หลังจากเห็นตัวอย่าง JSON และ XML แล้ว — มาสรุปว่าเมื่อไหร่ควรใช้ Structured Output และปัญหาของ free-text คืออะไร

⚠️ ปัญหาของ Output แบบ Free-text

เมื่อ AI ตอบเป็นข้อความธรรมดา (free-text) จะเกิดปัญหาหลายอย่าง:

ไม่แน่นอน: ถามเดิม 10 รอบ ได้ format ต่างกัน 10 แบบ
ใช้ต่อยาก: ต้องมาแกะข้อความด้วยมือก่อนนำเข้าระบบ
ผิดพลาดง่าย: AI อาจแต่งข้อมูลในส่วนที่ไม่ได้ถาม
ไม่ scale: ใช้ได้กับงาน 1 ชิ้น แต่ไม่ได้กับ 1,000 ชิ้น

🔄 เปรียบเทียบ Free-text vs Structured Output

Free-text Output	Structured Output (JSON/XML)
❌ "ผู้ต้องสงสัยเป็นชายไทย อายุประมาณ 35 ปี ขับรถ BMW สีดำ ทะเบียน กท-1234 ความเสี่ยงอยู่ในระดับสูง..."	✅ `{"gender":"male", "age":35, "vehicle":"BMW", "risk":"high"}`
ต้อง parse ด้วยมือ หรือเขียน regex ซับซ้อน	ใช้ `JSON.parse()` แล้วดึงค่าได้ทันที
AI อาจใส่ข้อมูลที่ไม่ได้ถาม	Schema บังคับให้ตอบเฉพาะ field ที่กำหนด
ใช้ได้กับ UI/chat เท่านั้น	เชื่อมต่อ API, Database, Automation ได้

🎯 สถานการณ์ที่ต้องใช้ Structured Output

สถานการณ์	ทำไมต้อง Structured	ตัวอย่างการใช้งาน
ส่งข้อมูลต่อระบบอื่น	ระบบอัตโนมัติอ่าน text ไม่ได้ ต้องเป็น JSON/XML	AI วิเคราะห์ → ส่งเข้า Database / Dashboard / รายงาน
ประมวลผลข้อมูลจำนวนมาก	ต้องการ consistency ใน output ทุกชิ้น	วิเคราะห์ feedback 1,000 ชิ้น → จัดกลุ่มอัตโนมัติ
ต้องการค่าเฉพาะ	ป้องกัน AI ตอบค่านอกเหนือที่กำหนด	risk_level ต้องเป็น "high", "medium", หรือ "low" เท่านั้น
ลด Hallucination	Schema บังคับให้ AI ตอบในกรอบที่กำหนด	ต้องมี "confidence" field บอกความมั่นใจในแต่ละข้อมูล
สร้างรายงานอัตโนมัติ	ต้องการข้อมูลที่จัดรูปแบบเรียบร้อย	AI สรุปคดี → ระบบสร้างรายงาน PDF อัตโนมัติ

🚔 ตัวอย่างงานตำรวจที่ต้องใช้ Structured Output

งาน	ทำไมต้อง JSON	ตัวอย่าง Fields
วิเคราะห์ธุรกรรมต้องสงสัย	ต้องส่งเข้าระบบ AML / AMLO portal	`risk_level, red_flags, transaction_patterns`
สรุปข้อมูล CDR	ต้องสร้าง timeline อัตโนมัติ	`caller, receiver, duration, cell_tower, timestamp`
วิเคราะห์คำให้การ	ต้องเปรียบเทียบข้อมูลจากหลายคน	`statements[], contradictions[], timeline_events[]`
ระบุ Red Flags	ต้องจัดลำดับความสำคัญและส่งต่อทีม	`flags[], severity, source, action_required`
สรุปคดีเพื่อรายงาน	ต้องกรอกข้อมูลลงแบบฟอร์มราชการ	`case_type, damage_value, victim_count, status`

💡 หลักการเลือก Format

Format	ใช้เมื่อ	ตัวอย่าง
JSON	งาน API, Web, Modern systems (แนะนำเป็น default)	Dashboard, Mobile App, Database
XML	ระบบราชการเก่า, Enterprise ที่ต้องการ hierarchical data	ระบบ AMLO, ระบบภาษี, Legacy ERP
Markdown	Documentation, Human-readable reports	รายงานสรุป, คู่มือ, Meeting notes

5.6 System Prompt — กำหนดพฤติกรรมพื้นฐาน

System Prompt = คำสั่งที่กำหนดพฤติกรรม AI ตลอดการสนทนา ซึ่ง user ปกติจะไม่เห็น — เป็น "กฎเบื้องหลัง" ที่ AI ต้องปฏิบัติตามทุกครั้งที่ตอบ

💡 System Prompt vs User Prompt

System Prompt: ตั้งค่าพฤติกรรม บทบาท และกฎที่ AI ต้องปฏิบัติตาม — ใส่ครั้งเดียว ใช้ได้ตลอดการสนทนา
User Prompt: คำถามหรือคำสั่งที่ user พิมพ์แต่ละครั้ง

🎯 เมื่อไหร่ควรใช้ System Prompt?

สถานการณ์	ตัวอย่าง
กำหนดบทบาท/ตัวตน	"คุณเป็นที่ปรึกษากฎหมายอาญา" / "คุณเป็น Customer Service"
ตั้งกฎความปลอดภัย	"ห้ามเปิดเผยข้อมูลส่วนบุคคล" / "ห้ามสรุปว่าผิดกฎหมาย"
กำหนด Tone & Style	"ตอบสุภาพ ใช้ภาษาทางการ" / "ตอบกระชับไม่เกิน 200 คำ"
ตั้งค่า Output Format	"ตอบเป็น JSON เสมอ" / "ทุกคำตอบต้องมีแหล่งอ้างอิง"
จำกัดขอบเขตความรู้	"ตอบเฉพาะเรื่องที่เกี่ยวกับสินค้าของบริษัท" / "ใช้ข้อมูลที่ให้มาเท่านั้น"

⚠️ ข้อควรระวัง

System Prompt ไม่ใช่ความลับ 100%: User ที่มีความรู้อาจใช้ Prompt Injection พยายามดึงออกมาได้
อย่าใส่ข้อมูลลับ: เช่น API keys, passwords, หรือข้อมูลภายในองค์กรที่สำคัญ
ทดสอบกับ edge cases: ลอง attack prompt ตัวเองดูว่า AI ยังทำตามกฎหรือไม่

ตัวอย่าง: System Prompt สำหรับงานตำรวจ

ใช้เมื่อ: สร้าง AI assistant สำหรับพนักงานสอบสวน ต้องการให้ปฏิบัติตามกฎความปลอดภัยและจริยธรรมอย่างเคร่งครัด

✅ ตัวอย่าง System Prompt: งานตำรวจ

คุณเป็นผู้ช่วยวิเคราะห์ข้อมูลสำหรับพนักงานสอบสวน

กฎ:
1. ตอบเป็นภาษาไทยทางการเสมอ
2. ห้ามระบุชื่อจริงของบุคคล — ใช้รหัสแทน
3. ห้ามสรุปว่า "ผิดกฎหมาย" — ใช้คำว่า "มีเหตุอันควรสงสัย"
4. ทุกข้อมูลตัวเลขต้องระบุแหล่งที่มา
5. หากไม่แน่ใจ ให้ระบุว่า "ต้องตรวจสอบเพิ่มเติม"
6. ทุกรายงานต้องมี: สรุป, รายละเอียด, ข้อเสนอแนะ
7. ห้ามเข้าถึง/อ้างอิงข้อมูลนอกขอบเขตที่ให้มา

💬 ทำไมตัวอย่างนี้ดี?

กฎข้อ 2-3: ป้องกันปัญหาทางกฎหมาย — AI ไม่ควรชี้ว่า "คนนี้ผิด" ต้องใช้คำว่า "มีเหตุอันควรสงสัย"
กฎข้อ 4-5: ลด Hallucination — บังคับให้อ้างอิงแหล่งที่มาและยอมรับเมื่อไม่แน่ใจ
กฎข้อ 7: จำกัดขอบเขต — ไม่ให้ AI แต่งข้อมูลจากที่อื่น

ตัวอย่าง: System Prompt สำหรับธุรกิจ

ใช้เมื่อ: สร้าง AI ที่ปรึกษาธุรกิจสำหรับ SME ไทย ต้องการให้ตอบตรงประเด็นและนำไปใช้ได้จริง

✅ ตัวอย่าง System Prompt: ธุรกิจ

คุณเป็นที่ปรึกษาธุรกิจ SME ไทย

กฎ:
1. ตอบกระชับ ตรงประเด็น ไม่เกิน 500 คำ
2. ใช้ตัวเลขและข้อมูลสนับสนุนเสมอ
3. เสนอทางเลือก 2-3 ทาง พร้อม pros/cons
4. คำนึงถึงบริบทตลาดไทยและงบประมาณ SME
5. ถ้าข้อมูลอาจล้าสมัย ให้แจ้งเตือน
6. ใช้ภาษาที่เข้าใจง่าย ไม่ใช้ศัพท์เทคนิคมากเกินไป
7. ทุกข้อเสนอแนะต้องมี action step ที่ชัดเจน

💬 หลักการเขียน System Prompt ที่ดี

ชัดเจน: เขียนเป็นข้อๆ ไม่คลุมเครือ — AI ต้องรู้ว่าทำอะไรได้/ไม่ได้
ครบถ้วน: ครอบคลุมทุกสถานการณ์ที่อาจเกิด — โดยเฉพาะ edge cases
ทดสอบได้: ลองถามคำถาม "ยากๆ" ดูว่า AI ยังปฏิบัติตามกฎหรือไม่
ไม่ยาวเกินไป: 5-10 กฎ มักเพียงพอ — ถ้ายาวมาก AI อาจลืมบางข้อ

5.7 Prompt Template — Prompt-as-Code

Prompt Template คือ prompt ที่ออกแบบมาให้ใช้ซ้ำได้ โดยมีช่องว่าง (variables) ให้เปลี่ยนค่าตามสถานการณ์ — เหมือนแบบฟอร์มที่กรอกข้อมูลต่างกันในแต่ละครั้ง

💡 แนวคิด Prompt-as-Code (2026)

Prompt ควรถูกจัดการเหมือน Code — มี version control, testing, reuse และ documentation เพราะ:

Prompt มีมูลค่า: prompt ที่ดีใช้เวลาปรับแต่ง ไม่ควรหายไปเมื่อคนสร้างลาออก
ต้อง Consistent: ทุกคนในทีมควรใช้ prompt เดียวกัน ได้ผลลัพธ์มาตรฐานเดียวกัน
ต้อง Auditable: รู้ว่าใคร/เมื่อไหร่แก้ไข และย้อนกลับได้ถ้ามีปัญหา
ต้อง Testable: เมื่อ AI model อัปเดต ต้องตรวจสอบว่า prompt ยังทำงานถูกต้อง

ตัวอย่าง: Prompt Template พื้นฐาน (งานตำรวจ)

ใช้เมื่อ: ต้องสร้างรายงานสรุปคดีหลายคดี โดยใช้รูปแบบเดียวกัน แค่เปลี่ยนข้อมูลแต่ละคดี

✅ Prompt Template: รายงานสรุปคดี (งานตำรวจ)

# Template: Case Summary Report
# Version: 2.1
# Last Updated: 2026-06-01
# Author: Investigation Unit
# Tags: police, case-summary, report

## Variables:
# {{case_type}} = ประเภทคดี
# {{victim_count}} = จำนวนผู้เสียหาย
# {{damage_value}} = มูลค่าความเสียหาย
# {{period}} = ช่วงเวลาเกิดเหตุ
# {{evidence_list}} = รายการหลักฐาน

## Prompt:
คุณเป็นพนักงานสอบสวนอาวุโส

สรุปคดี {{case_type}} สำหรับรายงานผู้บังคับบัญชา:
- ผู้เสียหาย: {{victim_count}} ราย
- มูลค่าเสียหาย: {{damage_value}}
- ช่วงเวลา: {{period}}
- หลักฐาน: {{evidence_list}}

รูปแบบ: รายงาน 1 หน้า A4
ประกอบด้วย: สรุปย่อ, MO, Timeline, หลักฐานสำคัญ, ข้อเสนอแนะ

💬 สังเกตโครงสร้าง Template

Metadata: Version, Date, Author, Tags — ติดตามประวัติได้
Variables: {{variable_name}} — ส่วนที่เปลี่ยนแปลงได้
Prompt: ส่วนที่ส่งให้ AI จริงๆ โดยแทนที่ variables ด้วยค่าจริง

5.8 Prompt-as-Code — Best Practices

เมื่อ Prompt ถูกใช้ซ้ำใน production ต้องจัดการเหมือน code — นี่คือ 5 practices ที่ทีมระดับ enterprise ใช้:

📐 5 Best Practices สำหรับ Prompt-as-Code

#	Practice	วิธีทำ	ประโยชน์
1	ใส่ Metadata	ระบุ version, author, date, model ไว้ต้น template	ติดตามได้ว่าใคร/เมื่อไหร่สร้าง/แก้ไข
2	ใช้ Variables	ใช้ {{variable}} แทนค่าคงที่ที่เปลี่ยนได้	Reuse template เดียวกับหลาย scenario
3	เขียน Test Cases	ระบุ input ตัวอย่าง + expected output ไว้ใน template	ตรวจสอบได้ว่า prompt ยังทำงานถูกหลังแก้ไข
4	ทำ Changelog	บันทึกทุกครั้งที่แก้ไข ว่าแก้อะไร/ทำไม	ย้อนกลับได้ถ้า version ใหม่ให้ผลแย่ลง
5	แชร์ใน Repository	เก็บใน shared repo (Git, Notion, Google Drive)	ทั้งทีมใช้ template เดียวกัน ได้ผลลัพธ์ consistent

🔄 Prompt Lifecycle — วงจรชีวิตของ Prompt

Draft → Test → Review → Deploy → Monitor → Iterate
  │        │       │        │         │          │
  ↓        ↓       ↓        ↓         ↓          ↓
เขียน   ทดสอบ   ตรวจ     นำไปใช้   ดู metrics   ปรับปรุง
ร่างแรก  หลาย    โดยทีม   production  (accuracy,  จาก feedback
        cases            จริง      cost, time)  แล้ววนใหม่

⚠️ ความผิดพลาดที่พบบ่อย

ไม่มี version: แก้ prompt แล้วไม่รู้ว่าใช้ version ไหนอยู่ → output ไม่ consistent
ไม่มี test cases: อัปเดต AI model แล้ว prompt พัง ไม่รู้ตัว
Prompt อยู่ในหัวคนเดียว: คนลาออก → ความรู้หายไปด้วย
ไม่มี changelog: ย้อนกลับไม่ได้เมื่อ version ใหม่แย่กว่าเดิม

💡 ทำไมต้อง Prompt-as-Code?

ในองค์กรที่ใช้ AI เป็นส่วนหนึ่งของ workflow — Prompt ที่ดีควรถูก version control, tested, shared, และ documented เหมือน codebase ขององค์กร ไม่ใช่อยู่แค่ในหัวคนเดียว

5.9 ตัวอย่าง Prompt Template — งานธุรกิจ

ตัวอย่าง template ที่พร้อมใช้งานจริง ครบทุก best practice:

✅ Prompt Template: รายงานประจำสัปดาห์ (ธุรกิจ)

# Template: Weekly Report Summary
# Version: 1.3
# Model: Any (GPT-5.5, Claude Sonnet 4)
# Author: Marketing Team
# Updated: 2026-06-01
# Changelog:
#   v1.3 - เพิ่ม Metrics table, ปรับ tone เป็น concise
#   v1.2 - เพิ่ม Blockers section
#   v1.1 - เปลี่ยน format จาก paragraph เป็น bullet

## Variables:
# {{department}} = ชื่อแผนก
# {{week_number}} = สัปดาห์ที่
# {{achievements}} = ผลงานสำคัญ
# {{blockers}} = อุปสรรค
# {{next_week_plan}} = แผนสัปดาห์หน้า

## Prompt:
สรุปรายงานประจำสัปดาห์สำหรับแผนก {{department}}

ข้อมูล:
- สัปดาห์ที่: {{week_number}}
- ผลงาน: {{achievements}}
- อุปสรรค: {{blockers}}
- แผนสัปดาห์หน้า: {{next_week_plan}}

Format: 
1. Highlights (3 bullet max)
2. Metrics (ตาราง)
3. Blockers & Solutions
4. Next Week Priorities
ความยาว: ไม่เกิน 200 คำ
Tone: Professional, concise

## Test Cases:
# Input: department=Marketing, week=23, achievements="เปิดตัว campaign X, reach 1M"
# Expected: สรุปกระชับ มี metrics table ไม่เกิน 200 คำ

💡 นำไปใช้

Copy template นี้ไปปรับใช้กับงานของคุณ — เปลี่ยน variables ให้ตรงกับ context ขององค์กร แล้ว save เป็น shared template สำหรับทั้งทีม

5.10 ข้อผิดพลาดที่พบบ่อย

🚧 7 ข้อผิดพลาดที่พบบ่อยกับ Structured Output — และวิธีแก้

#	❌ ข้อผิดพลาด	✅ วิธีที่ถูกต้อง
1	ไม่ใส่ schema ให้ AI ทำให้ output ไม่ตรงและเปลี่ยนรูปแบบไปเรื่อยๆ	ให้ schema ครบ (JSON/XML) พร้อม example — AI จะทำตามโครงสร้าง
2	ลืมใส่ `confidence` field ทำให้ AI แต่งข้อมูลโดยไม่บอกว่าไม่แน่ใจ	ทุก schema ต้องมี `confidence` + `gaps` fields เป็นมาตรฐาน
3	ใช้ System Prompt สั่งงานเฉพาะงาน ทำให้ยุ่งยากเมื่อต้องการทำงานอื่น	System Prompt = พฤติกรรมพื้นฐาน / งานเฉพาะใส่ user message
4	ใช้ Few-shot เยอะเกินไป (>5 examples) กิน tokens เปล่าๆ	ใช้ 2-3 examples ก็พอ — ถ้าต้องการมากกว่านี้ให้ใช้ Fine-tuning
5	ไม่ validate output หลัง AI ตอบ เชื่อว่า format ถูกเสมอ	ใช้ schema validator (JSON Schema, Pydantic) validate ทุก response
6	จัดการ Prompt เป็นข้อความยาวใน code โดยตรง ยากต่อการแก้ไข	ใช้ Prompt-as-Code: แยก template, version control, test ก่อนใช้งานจริง
7	คาดหวังว่า AI จะ parse ข้อมูลจาก unstructured data ได้ 100%	AI ช่วยได้มาก แต่ไม่ใช่ 100% — ต้อง Human-in-the-Loop verify

5.11 ข้อจำกัดของ Structured Output

⚠️ สิ่งที่ Structured Output ช่วยไม่ได้

ข้อจำกัด	คำอธิบาย	ทางแก้
1. ไม่รับประกัน Data Quality	Schema ดีแต่ข้อมูลที่ AI ใส่อาจผิด/แต่งขึ้น — ได้ format ถูกแต่ content ผิด	Verify output กับ source data + ใช้ confidence field
2. Schema ซับซ้อนเกิน AI ทำผิด	Nested objects ลึก 4-5 ชั้น หรือ array ซ้อน array AI อาจสับสน	แบ่ง schema ออกเป็นขั้นตอน (pipeline) หรือใช้ model ที่เก่งกว่า
3. ไม่แก้ Model Capability	Structured Output ไม่ทำให้ model เก่งขึ้น (เช่น math, logic)	เลือก model ที่เหมาะ — Reasoning Model สำหรับงานซับซ้อน
4. API-level Schema ไม่รองรับทุก Model	เฉพาะบาง provider (OpenAI, Anthropic) มี response_format — ส่วนอื่นต้องใช้ inline	ตรวจสอบ API docs ก่อนใช้ หรือใช้ inline schema + validation
5. XML Tags ใช้ Token มากกว่า JSON	XML มี opening/closing tags — ยาวกว่า JSON ~20-30%	ใช้ XML เมื่อต้องการความชัดเจน / ใช้ JSON เมื่อประหยัด tokens
6. System Prompt ไม่ได้รับประกันตลอดชีวิต	System Prompt อาจถูก "บิดเบือน" ถ้า user message ยาวมาก + ขัดแย้งกับระบบ	Test กับ adversarial prompts + ใช้ guardrails

💡 หลักคิด

Structured Output = การจัด "กรอบ" ให้ AI ตอบ แต่ไม่รับประกัน "เนื้อหา" — ต้อง verify ทุกครั้ง

5.12 Key Takeaways

📝 Key Takeaways Module 5

Structured Output (JSON/XML) ทำให้นำข้อมูลไปใช้ต่อได้ง่าย
ให้ schema/template ให้ AI → ลด Hallucination + ได้ format ตรงตามต้องการ
System Prompt กำหนดพฤติกรรมพื้นฐานตลอดการสนทนา
Prompt-as-Code: จัดการ Prompt เหมือน code (version, test, reuse)
Few-shot ช่วยให้ AI เข้าใจ format ที่ต้องการ — ใช้เมื่อ zero-shot ให้ผลไม่ดี
XML Tags pattern (<context><task><output_format><data>) แยก Prompt components ได้ดีกว่า plain text
Standard fields: confidence + gaps ในทุก schema ป้องกัน hallucination ในส่วนที่ AI ไม่แน่ใจ
ข้อจำกัด: Schema ดีไม่รับประกัน content ถูก — ต้อง verify เสมอ

✅ หลังเรียน Module 5 — สิ่งที่ควรทำได้

เขียน JSON schema ที่มี required/enum และ confidence field ได้
ใช้ XML Tags แยก context/task/output/data ใน Prompt ได้
สร้าง System Prompt + Prompt Template แบบ Prompt-as-Code พร้อม version
รู้ว่าเมื่อใดใช้ Inline schema และเมื่อใดใช้ API-level schema
หลีกเลี่ยงข้อผิดพลาด 7 ข้อที่พบบ่อย
ระบุข้อจำกัดของ Structured Output และทางแก้

🤔 คำถามทบทวน

โจทย์: ต้องการให้ AI สรุปรายงาน 50 หน้าเป็น JSON ที่มีเฉพาะ: สรุปย่อ, ประเด็นหลัก 5 ข้อ, ระดับความเสี่ยง (H/M/L) — ควรออกแบบ schema อย่างไร และวาง XML Tags อะไรบ้าง?

ดูเฉลย

JSON Schema:

summary: string (สรุปย่อ)
key_points: array, maxItems: 5
risk: enum ["H","M","L"]
confidence: enum ["high","medium","low"]
gaps: array (ข้อมูลที่ยังขาด)

XML Tags:

<context> บทบาทนักวิเคราะห์ </context>
<task> สรุปรายงาน </task>
<output_format> JSON schema ข้างต้น </output_format>
<data> เอกสาร 50 หน้า </data>

M4: Frameworks M6: Advanced Techniques