เทคนิคเฉพาะสำหรับ Reasoning Models — GPT-5.5, Claude Opus 4.8, DeepSeek R1
Reasoning Models (GPT-5.5, Claude Opus 4.8, DeepSeek R1) มี CoT built-in แล้ว — การสั่ง "คิดทีละขั้นตอน" กลับทำให้ช้าลงและสิ้นเปลือง token แทนที่จะสั่งวิธีคิด → ให้บอกแค่สิ่งที่ต้องการ + ข้อจำกัด
| Prompting แบบเดิม | Constraint-First (2026) |
|---|---|
| สั่ง "วิธีทำ" (How) | บอก "สิ่งที่ต้องการ" + "ข้อจำกัด" (What + Boundaries) |
| "คิดทีละขั้นตอน แล้ว..." | "ต้องการ X ภายใต้เงื่อนไข Y" |
| ยาว, ละเอียด, หลายส่วน | กระชับ, ตรงประเด็น, เน้น constraints |
| เหมาะกับ Standard Models | เหมาะกับ Reasoning Models |
| ประเภท | ความหมาย | ตัวอย่าง |
|---|---|---|
| Policy Constraints | ข้อจำกัดด้านกฎหมาย ความลับ และข้อมูลส่วนบุคคล | ห้ามเปิดเผย PII, ห้ามใช้ข้อมูลนอกสำนวนคดี |
| Domain Constraints | ขอบเขตความรู้และสาขาที่ AI ต้องตอบ | ตอบเฉพาะมาตราที่เกี่ยวข้อง, ไม่ออกนอกขอบเขตงาน |
| Quality Constraints | มาตรฐานคุณภาพ output | ต้องมีแหล่งอ้างอิง, ระบุ confidence level, output schema |
# Constraint-First Template (Production-Ready) # Version: [X] | Model: Reasoning (GPT-5/Claude Opus) ## Role: [บทบาท AI] ## Goal: [เป้าหมาย — 1-2 ประโยค] ## Hard Constraints (ต้องทำเสมอ): - [ข้อห้าม/บังคับ 1 — Policy] - [ข้อห้าม/บังคับ 2 — Domain] - [ข้อห้าม/บังคับ 3 — Quality] ## Soft Constraints (ควรทำ ถ้าทำได้): - [มาตรฐานคุณภาพ 1] - [มาตรฐานคุณภาพ 2] ## Fallback Rules: - ถ้าข้อมูลไม่พอ: [บอก AI ต้องทำอะไร เช่น ขอข้อมูลเพิ่ม] - ถ้าไม่แน่ใจ: [เช่น ระบุ confidence ต่ำ พร้อมเหตุผล] ## Input: [ข้อมูลที่ต้องประมวลผล] ## Output Schema: - [ส่วนที่ 1: ชื่อ + รูปแบบ] - [ส่วนที่ 2: ชื่อ + รูปแบบ] - [ส่วนที่ 3: Action Plan + timeline]
Hard Constraints = สิ่งที่ AI ต้องทำเสมอไม่ว่ากรณีใด | Soft Constraints = ทำถ้าทำได้ | Fallback = ให้ AI รู้ว่าต้องทำอะไรเมื่อ edge case เกิดขึ้น
ผ่าน checklist ทั้ง 4 ข้อก่อน deploy — prompt ที่ดีในห้องทดสอบอาจพังในสถานการณ์จริง
Goal: ประเมินว่าบริษัทนี้น่าลงทุนหรือไม่ Constraints: - วิเคราะห์จาก financial ratios เท่านั้น (ROE, D/E, Current Ratio, P/E) - เปรียบเทียบกับ SET industry average - ระบุ confidence level (high/medium/low) - สรุปไม่เกิน 200 คำ Input: [ข้อมูลงบการเงิน...] Output: ตาราง ratios + คำแนะนำ (Buy/Hold/Avoid) พร้อมเหตุผล 3 ข้อ
บทบาท: นักวิเคราะห์การเงิน สายคดีเศรษฐกิจ สังกัด บก.ปอท. งาน: สรุปรูปแบบการฟอกเงินและระดับความเสี่ยงจากข้อมูลธุรกรรม [Hard Constraints - ต้องทำเสมอ] 1) ใช้เกณฑ์ ปปง. เท่านั้น — ห้ามอ้างอิงความรู้ทั่วไป 2) ห้ามสรุปว่า "ผิดกฎหมาย" — ใช้ "มีเหตุอันควรสงสัย" 3) ห้ามระบุชื่อจริง — ใช้ "บุคคลที่ 1, บุคคลที่ 2" [Soft Constraints - ควรทำ] - อ้างอิงมาตรา ปปง. ที่เกี่ยวข้องทุกข้อ - ระบุ confidence level (สูง/กลาง/ต่ำ) ทุก Red Flag [Fallback Rules] - ถ้าข้อมูลธุรกรรมไม่ครบ 3 เดือน: ระบุช่วงเวลาที่ขาด และอาจทำให้วิเคราะห์คลาดเคลื่อน - ถ้า pattern ไม่ชัดเจน: ระบุว่า "ต้องเก็บข้อมูลเพิ่ม" พร้อมระบุว่าต้องการข้อมูลอะไร [Input] ข้อมูลธุรกรรม 3 เดือน [แนบ CSV] [Output Schema] - Red Flags: ตาราง | ลำดับ | Red Flag | หลักฐาน | ความเสี่ยง | มาตรา ปปง. | - Risk Score รวม (1-10) พร้อมเหตุผล - Action Plan: สิ่งที่ต้องทำใน 7 / 14 / 30 วัน
Fallback Rules บอก AI ชัดเจนว่าถ้า edge case เกิดขึ้นให้ทำอะไร — แทนที่จะให้ AI เดาเอง
Goal: เสนอกลยุทธ์เพิ่ม customer retention Constraints: - งบเพิ่มได้ไม่เกิน 15% จากปัจจุบัน - ต้องเห็นผลใน 90 วัน - ไม่ใช้กลยุทธ์สงครามราคา - ทีมมี 3 คน (marketer + dev + designer) Input: retention rate ปัจจุบัน 42% (ลดจาก 65%) Output: 3 กลยุทธ์ เรียงตาม impact สูง→ต่ำ พร้อม effort estimate
Reasoning Models มีพารามิเตอร์ที่กำหนดว่า AI ใช้เวลา "คิด" มากแค่ไหน (ในที่นี้เรียกรวมว่า thinking_budget เชิงแนวคิด — ชื่อจริงต่างกันตามผู้ให้บริการ: OpenAI ใช้ reasoning_effort, Anthropic ใช้ budget_tokens):
| Budget | เหมาะกับ | ตัวอย่าง |
|---|---|---|
| Low (quick) | งานง่าย, ตอบเร็ว | สรุปสั้นๆ, แปลภาษา |
| Medium (balanced) | งานทั่วไป | วิเคราะห์, เขียนรายงาน |
| High (thorough) | งานซับซ้อน, ต้องการความแม่นยำ | วิเคราะห์กฎหมาย, math proof |
Goal: สรุป paper วิจัยเรื่อง Transformer Architecture สำหรับ thesis literature review Constraints: - เข้าใจได้สำหรับนักศึกษาป.โท CS ที่ยังไม่เคยอ่าน paper นี้ - สรุปเฉพาะ: methodology + key findings + limitations - ห้ามใช้สมการ/formula (อธิบายเป็นภาษาพูด) - ความยาว: 300-400 คำ Input: [แนบ paper PDF] Output: structured summary แบ่ง 4 ส่วน: 1) Problem Statement 2) Approach 3) Results 4) Limitations & Future Work
Goal: สร้างแบบฟอร์มสอบถามอาการผู้ป่วย (triage) ที่ใช้ก่อนพบแพทย์ Constraints: - ภาษาไทยที่เข้าใจง่าย ผู้สูงอายุอ่านได้ - ไม่เกิน 10 คำถาม - ต้องครอบคลุม: อาการหลัก + ระยะเวลา + ประวัติแพ้ยา + ความเร่งด่วน - คำถามแบบ multiple choice เป็นหลัก (ลดการพิมพ์) - ต้องมี "red flag" ที่ trigger การส่งพบแพทย์ทันที Output: แบบฟอร์ม 10 ข้อ + เกณฑ์ scoring + flowchart ตัดสินใจ (describe)
ทั้ง 2 ตัวอย่างไม่ได้สั่ง "วิธีคิด" — แค่ระบุ เป้าหมาย + ข้อจำกัด + รูปแบบผลลัพธ์ แล้วปล่อยให้ Reasoning Model หาวิธีเอง
เมื่อ Constraints ขัดแย้งกัน หรือต้อง trade-off ให้ใช้ลำดับนี้:
| MUST (บังคับ) | SHOULD (ควรทำ) | NICE (เสริมคุณภาพ) |
|---|---|---|
| ข้อจำกัดที่ถ้าฝ่าฝืนถือว่า Prompt ล้มเหลว เช่น: กฎหมาย, ข้อมูลลับ, PII, ห้ามสรุปความผิดก่อนมีคำพิพากษา |
มาตรฐานคุณภาพที่ควรมีแต่ไม่ถึงกับทำให้ล้มเหลว เช่น: citation ทุกข้อ, confidence level, เสนอทางเลือก 3 ทาง |
สิ่งที่ถ้ามีจะดียิ่งขึ้น เช่น: visual summary, comparison table, action plan แบบ timeline |
กฎ trade-off: เมื่อต้องเลือก — รักษา MUST เสมอ, ลด SHOULD เมื่อ token จำกัด, ตัด NICE ออกถ้าต้องการ output กระชับ
| MUST | SHOULD | NICE |
|---|---|---|
| ห้ามเปิดเผยชื่อจริง ห้ามสรุปความผิด |
ระบุ confidence level ทุกข้อ | สร้าง timeline visual |
MUST / SHOULD / NICE เป็นมาตรฐานที่มาจาก RFC (Request for Comments) วิศวกรรมซอฟต์แวร์ — นำมาใช้ใน Prompt Engineering ได้ตรงมาก
| # | ❌ ข้อผิดพลาด | ✅ วิธีที่ถูกต้อง |
|---|---|---|
| 1 | สั่ง Reasoning Model ให้ "คิดทีละขั้นตอน" → ช้าและสิ้นเปลือง token | ไม่ต้องสั่ง CoT — แค่บอก Goal + Constraints + Output format |
| 2 | ใส่ Constraints แบบคลุมเครือ "ให้ดีที่สุด" "ถูกต้อง" | ระบุชัดเจน เช่น "ห้ามสรุปว่าผิดกฎหมาย ใช้คำว่า 'มีเหตุอันควรสงสัย'" |
| 3 | ไม่มี Fallback Rules → AI เดาเองเมื่อข้อมูลไม่พอ | ระบุชัดว่าถ้าข้อมูลไม่พอให้ทำอะไร เช่น "ระบุว่าต้องการข้อมูลเพิ่มใด" |
| 4 | ผสม Hard และ Soft Constraints → AI สับสนว่าต้องทำอะไรก่อน | แยกชัดเจน: MUST (บังคับ) / SHOULD (ควรทำ) / NICE (ถ้ามี) |
| 5 | ไม่มี Output Schema → ผลลัพธ์ไม่สม่ำเสมอ ยาก parse | กำหนด schema ชัด เช่น "ตาราง: Red Flag | หลักฐาน | Risk | มาตรา | Confidence" |
| 6 | Deploy โดยไม่ผ่าน 4-step Checklist → prompt พังในสถานการณ์จริง | ผ่านทุกข้อ: ห้ามทำชัด / Fallback / Output Schema / Injection guard |
โจทย์: งานสรุปคดีที่ห้ามระบุชื่อจริงและห้ามสรุปความผิด — constraint ข้อเหล่านี้ควรเป็น MUST หรือ SHOULD? และถ้า AI ไม่มีข้อมูลพอควร Fallback ว่าอย่างไร?