Module 13 Intermediate

Use Cases — ตำรวจ

Cybercrime Analysis, AML & Financial Crime, CDR & SIMBox Detection, Document Drafting — Prompt สำหรับงานสืบสวนสอบสวน

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

ตัวอย่างทั้งหมดใช้ ข้อมูลสมมติ (Synthetic Data) เท่านั้น — ห้ามใส่ข้อมูลคดีจริงหรือข้อมูลส่วนบุคคลใน AI สาธารณะ

🎯 วัตถุประสงค์การเรียนรู้ Module 13
⚡ Quick Start — ลองใช้ AI 3 คำสั่ง (2 นาที)

เปิด ChatGPT / Claude / Gemini แล้ว copy คำสั่งใดคำสั่งหนึ่ง — ใช้ข้อมูลสมมติเท่านั้น

① สรุป
สรุปข้อความด้านล่างเป็น bullet 5 ข้อ
ภาษาไทย โทนเป็นทางการ

[วางข้อความสมมติ 3–5 ย่อหน้า]
② ปรับโทน
ปรับข้อความนี้ให้เข้าใจง่าย
สำหรับประชาชนทั่วไป ไม่เกิน 4 บรรทัด

[วางข้อความทางการ]
③ ร่างจาก outline
ร่างเอกสารจาก outline นี้
โทนราชการ ไม่เกิน 1 หน้า
1. เรื่อง
2. เหตุผล
3. ข้อเสนอ
✅ Rubric — ผล AI "ใช้ได้" หรือยัง?
  1. ตรงเป้าหมายที่สั่ง
  2. ไม่มีข้อมูลที่ไม่มีใน input (hallucination)
  3. โทน/รูปแบบถูกต้อง
  4. ความยาวพอดี
  5. คุณยอมนำไปใช้ได้หลังแก้ ≤ 20%

ถ้าไม่ผ่าน 3 ข้อ → กลับ Module 2 (PTCF) เพื่อสั่งงานเป็นระบบ

🔐 ก่อนลงมือ — Security สำหรับงานตำรวจ

เรียนละเอียด → Module 12: AI Security 2026

13.1 Context Engineering สำหรับงานตำรวจ

ก่อนเรียนรู้ Prompt รายงาน — ต้องเข้าใจว่า Context Engineering คือกุญแจสำคัญที่ทำให้ AI ตอบได้ตรงประเด็นและปลอดภัย

🔑 Context Engineering คืออะไร? (สรุปสั้นจาก Module 3)

Context Engineering = การออกแบบ "สภาพแวดล้อม" ทั้งหมดที่ AI ต้องรู้ก่อนตอบ

ไม่ใช่แค่เขียน Prompt ดีๆ แต่ต้องเตรียม: System Rules + Knowledge + Memory + Tools + Guardrails

🎯 เปรียบเทียบง่ายๆ: ลองนึกภาพว่าคุณจ้างพนักงานใหม่ — Prompt คือ "สิ่งที่สั่งให้ทำ" แต่ Context Engineering คือ "ทุกอย่างที่พนักงานต้องรู้ก่อนทำงาน" เช่น นโยบายบริษัท ข้อมูลลูกค้า เครื่องมือที่ใช้ได้ และสิ่งที่ห้ามทำ

→ เรียน Context Engineering เต็มรูปแบบ

13.1.1 5 Context Layers สำหรับงานสืบสวน

🏗️ Context Stack — Investigation Assistant
#Layerตัวอย่างสำหรับงานตำรวจหมายเหตุ
1System Instructions"คุณเป็นผู้ช่วยวิเคราะห์คดี ตอบภาษาไทยทางการ ห้ามระบุชื่อจริง ใช้รหัสแทน"กฎพื้นฐานที่ทุก output ต้องปฏิบัติ
2Knowledgeพ.ร.บ.คอมพ์ 2560, ระเบียบ สตช., ฐาน MO แก๊ง Call Centerข้อมูลอ้างอิงที่ AI ใช้ได้
3Memoryหมายเลขคดี, ข้อมูลที่วิเคราะห์ไปแล้วใน session, timelineบริบทเฉพาะคดี
4Toolssearch_law(), analyze_pattern(), generate_timeline()เครื่องมือที่ AI เรียกใช้ได้
5Guardrailsห้ามสรุปว่าผิดกฎหมาย, ต้องอ้างอิงหลักฐาน, บอก Confidence Levelข้อจำกัดความปลอดภัย

13.1.2 W-S-C-I สำหรับงานสืบสวน

กลยุทธ์ 4 ขั้นตอนในการจัดการ Context:

✍️ Write — บันทึก Context ถาวร

ปัญหา: ถ้าต้องพิมพ์ซ้ำทุกครั้งว่า "ฉันเป็นพนักงานสอบสวน ต้องการผลลัพธ์แบบนี้..." = เสียเวลา + ลืมใส่บางส่วน

วิธีแก้: เขียน Custom Instructions ไว้ใน AI Tool

Custom Instructions สำหรับพนักงานสอบสวน
## Custom Instructions สำหรับพนักงานสอบสวน

# เกี่ยวกับฉัน
- ตำแหน่ง: พนักงานสอบสวน กก.สส.บก.ปอท.
- งานหลัก: วิเคราะห์คดีอาชญากรรมไซเบอร์
- เครื่องมือ: CDR Analysis, OSINT, Transaction Monitoring

# สิ่งที่ AI ควรทำเสมอ
- ตอบภาษาไทยทางการ
- ใช้รหัสแทนชื่อจริง (เช่น ผู้ต้องสงสัย A, เหยื่อ B)
- ระบุ Confidence Level (สูง/กลาง/ต่ำ) ทุกครั้ง
- อ้างอิงมาตรากฎหมายถ้าเกี่ยวข้อง

# สิ่งที่ AI ห้ามทำ
- ห้ามสรุปว่า "ผิดกฎหมาย" ใช้ "ต้องสงสัย" หรือ "มีเหตุอันควรสงสัย"
- ห้ามแนะนำให้ใส่ข้อมูลคดีจริงใน AI สาธารณะ

ผลลัพธ์: ไม่ต้องพิมพ์ซ้ำทุกครั้ง AI รู้บริบทของคุณตลอด

🔍 Select — ดึงเฉพาะที่เกี่ยวข้อง

ปัญหา: มี CDR 10,000 รายการ + เอกสารคดี 50 หน้า — ส่งทั้งหมดให้ AI ไม่ได้

วิธีแก้: Filter ก่อนส่ง AI

Select — Filter CDR ก่อนส่ง AI 📥 Download Mock Data
# ❌ ไม่ Select (ใช้ไม่ได้)
"วิเคราะห์ CDR 10,000 รายการนี้ [paste ทั้งหมด]"
→ เกิน context limit, ช้า, แพง

# ✅ Select ก่อน (ใช้ได้)
ขั้นตอน 1: Filter ด้วย SQL/Excel
- เฉพาะการโทรออก > 100 ครั้ง/วัน
- เฉพาะช่วงเวลาที่สงสัย (7 วัน)

ขั้นตอน 2: ส่งเฉพาะที่ผ่าน filter
"วิเคราะห์ CDR 50 รายการนี้ (pre-filtered: >100 calls/day)
[ตาราง CDR ที่ filter แล้ว]
ระบุว่าเป็น SIMBox หรือ Call Center หรือปกติ"
📦 Compress — สรุปให้กระชับ

ปัญหา: Chat history ยาว + เอกสารหลายฉบับ = context เต็ม

วิธีแก้: สรุปก่อนส่ง

Compress — สรุปบันทึกปากคำก่อนวิเคราะห์
# ตัวอย่าง: สรุปบันทึกปากคำ 5 ราย

# ❌ ไม่ Compress
"อ่านบันทึกปากคำ 5 รายนี้ [paste 20 หน้า]"
→ ข้อมูลมากเกินไป AI อาจพลาดประเด็นสำคัญ

# ✅ Compress ก่อน
ขั้นตอน 1: ให้ AI สรุปทีละราย
"สรุปบันทึกปากคำรายนี้เป็น key facts 5 ข้อ"

ขั้นตอน 2: รวม summary แล้วค่อยวิเคราะห์
"จาก summary ปากคำ 5 ราย:
[Victim A: fact 1, 2, 3...]
[Victim B: fact 1, 2, 3...]
ระบุ pattern ร่วมและความขัดแย้ง"
🔒 Isolate — แยก Context เพื่อความปลอดภัย

ปัญหา: ข้อมูลคดี A ไม่ควรปนกับคดี B / ข้อมูลลับไม่ควร leak

วิธีแก้: แยก session และ access level

# หลักการ Isolate สำหรับงานสอบสวน 1. แยก Session ต่อคดี - คดี A → Chat window A (ไม่มีข้อมูลคดี B) - คดี B → Chat window B (ไม่มีข้อมูลคดี A) 2. แยก System vs User Input ┌─────────────────────────────────────┐ │ SYSTEM (ล็อค — แก้ไขไม่ได้) │ │ - ห้ามเปิดเผย PII │ │ - ต้องใช้รหัสแทนชื่อ │ └─────────────────────────────────────┘ ┌─────────────────────────────────────┐ │ USER INPUT (ข้อมูลคดี) │ │ [USER_INPUT_START] │ │ ข้อมูลที่ต้องวิเคราะห์... │ │ [USER_INPUT_END] │ └─────────────────────────────────────┘ 3. Multi-Agent: แต่ละ Agent เห็นเฉพาะที่ต้องใช้ - CDR Agent → เห็นเฉพาะ CDR - Financial Agent → เห็นเฉพาะธุรกรรม - Report Agent → เห็นเฉพาะ analysis results (ไม่เห็น raw data)

ตัวอย่างเต็ม: Context Engineering สำหรับคดี Call Center Fraud

# Context Stack สำหรับ Call Center Fraud Investigation ## Layer 1: System Instructions คุณคือผู้ช่วยวิเคราะห์คดีสำหรับพนักงานสอบสวน บก.ปอท. - ตอบเป็นภาษาไทยทางการ - ห้ามระบุชื่อจริง ใช้รหัสแทน (ผู้ต้องสงสัย A, เหยื่อ 1) - ห้ามสรุปว่า "ผิดกฎหมาย" ใช้คำว่า "มีเหตุอันควรสงสัย" - ระบุ Confidence Level ทุกครั้ง ## Layer 2: Knowledge (RAG) - พ.ร.บ. คอมพิวเตอร์ พ.ศ.2560 (มาตรา 5, 7, 14, 17, 18) - พ.ร.บ. ป้องกันการฟอกเงิน พ.ศ.2542 - ฐานข้อมูล MO แก๊ง Call Center (anonymized) - SIMBox detection criteria ## Layer 3: Memory (คดีปัจจุบัน) - หมายเลขคดี: XX-2569-0123 (สมมติ) - ประเภท: Call Center Fraud แอบอ้าง DSI - เหยื่อ: 5 ราย มูลค่ารวม 3.2 ล้านบาท - สถานะ: อยู่ระหว่างวิเคราะห์ CDR ## Layer 4: Tools (ถ้ามี) - search_law(query) → ค้นหากฎหมาย - analyze_cdr(data) → วิเคราะห์ CDR patterns - generate_timeline(events) → สร้าง timeline ## Layer 5: Guardrails - ต้องอ้างอิงมาตรากฎหมายทุกครั้งที่เกี่ยวข้อง - ข้อมูลทุกชิ้นต้องมี Confidence: สูง/กลาง/ต่ำ - หากไม่แน่ใจ → ตอบว่า "ต้องตรวจสอบเพิ่มเติม" - ห้ามเข้าถึงข้อมูลนอกขอบเขตคดี
💡 เปรียบเทียบ: ก่อน vs หลัง Context Engineering
ก่อน (ไม่มี CE)หลัง (มี CE)
"สรุปคดีนี้ให้หน่อย" → AI ถามกลับ 5 รอบ"สรุปคดีนี้ให้หน่อย" → ได้สรุป 7 หัวข้อทันที
ต้องพิมพ์ constraints ซ้ำทุกครั้งSystem Instructions จำไว้ให้
AI อาจใช้คำว่า "ผิดกฎหมาย"AI ใช้ "มีเหตุอันควรสงสัย" เสมอ
ข้อมูลคดีอาจปนกันแยก session ต่อคดี ไม่ปน

13.2 Cybercrime Analysis — วิเคราะห์อาชญากรรมไซเบอร์

13.2.1 MO (Modus Operandi) Analysis

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

วิเคราะห์ MO — เคส SMS พัสดุปลอม
คุณคือนักวิเคราะห์อาชญากรรมไซเบอร์ระดับผู้เชี่ยวชาญ

## ข้อมูลคดี (สมมติ)
- เหยื่อได้รับ SMS แจ้งพัสดุค้างส่ง พร้อมลิงก์
- เหยื่อกดลิงก์ → เว็บปลอมคล้าย Kerry Express
- กรอกข้อมูลบัตรเครดิต + OTP
- เงินถูกโอนออก 3 รายการ ไปยังบัญชีม้า 3 บัญชี
- เงินถูกแปลงเป็น USDT ผ่าน Binance P2P ภายใน 30 นาที

## วิเคราะห์:
1. MO (Modus Operandi) — ขั้นตอนการกระทำผิดทั้งหมด
2. Timeline — ลำดับเวลาของเหตุการณ์
3. Red Flags — สัญญาณเตือนที่เหยื่อควรสังเกต
4. Indicators of Compromise (IOC) — หลักฐานดิจิทัลที่ควรเก็บ
5. แนะนำแนวทางสืบสวนต่อ (Investigation Leads)

ตอบเป็นตารางและ bullet points

13.2.2 Timeline Reconstruction

สร้างไทม์ไลน์เหตุการณ์จากหลักฐานดิจิทัลที่กระจัดกระจาย

Timeline Reconstruction — สร้างไทม์ไลน์จากหลักฐาน 📥 Download Mock Data
บทบาท: นักวิเคราะห์ข้อมูลดิจิทัลฟอเรนสิกส์

งาน: สร้างไทม์ไลน์เหตุการณ์จากหลักฐานดิจิทัลต่อไปนี้

ข้อมูล:
- Log การเข้าใช้งานระบบ: [วาง log data]
- บันทึก CDR: [วาง CDR data]
- Transaction records: [วาง transaction data]

สิ่งที่ต้องการ:
1. จัดเรียงเหตุการณ์ตามลำดับเวลา (Chronological Order)
2. ระบุช่องว่างของข้อมูล (Data Gaps) ที่ต้องหาเพิ่ม
3. เชื่อมโยงความสัมพันธ์ระหว่างเหตุการณ์ (Correlations)
4. ระบุจุดที่น่าสงสัย (Anomalies) ในไทม์ไลน์
5. แนะนำหลักฐานเพิ่มเติมที่ควรรวบรวม

รูปแบบผลลัพธ์: ตารางไทม์ไลน์ พร้อม Column: วันเวลา | เหตุการณ์ | แหล่งข้อมูล | ระดับความน่าสงสัย | หมายเหตุ

⚠️ หมายเหตุ: ใช้ข้อมูลสมมติเท่านั้น ห้ามใช้ข้อมูลคดีจริง

13.2.3 Red Flags Identification

ระบุสัญญาณเตือนภัยจากพฤติกรรมผิดปกติในข้อมูลธุรกรรม

Red Flags Identification — วิเคราะห์ธุรกรรมต้องสงสัย 📥 Download Mock Data
บทบาท: ผู้เชี่ยวชาญด้านการตรวจจับพฤติกรรมผิดปกติทางการเงิน

งาน: วิเคราะห์ข้อมูลธุรกรรมต่อไปนี้และระบุ Red Flags ที่บ่งชี้ถึงพฤติกรรมต้องสงสัย

ข้อมูลธุรกรรม:
[วางข้อมูลธุรกรรมที่ต้องการวิเคราะห์]

เกณฑ์ Red Flags ที่ต้องตรวจสอบ:
1. Structuring — ซอยธุรกรรมให้ต่ำกว่าเกณฑ์รายงาน (เช่น <2 ล้านบาท)
2. Rapid Movement — เงินเข้า-ออกภายในเวลาสั้น (<24 ชม.)
3. Round Tripping — เงินวนกลับมาที่จุดเริ่มต้นผ่านหลายบัญชี
4. Unusual Patterns — ธุรกรรมนอกเวลาทำการ, จำนวนเงินกลมๆ ซ้ำๆ
5. Mismatch — ธุรกรรมไม่สอดคล้องกับอาชีพ/รายได้ที่แจ้ง

ข้อจำกัด:
- วิเคราะห์ตาม AMLO guidelines
- ระบุ Confidence Level (สูง/กลาง/ต่ำ) สำหรับแต่ละ Red Flag
- เสนอแนะขั้นตอนถัดไป (Next Steps) สำหรับแต่ละข้อ

รูปแบบ: ตาราง Red Flags พร้อม Column: # | ประเภท Red Flag | หลักฐาน | Confidence | Next Steps

⚠️ หมายเหตุ: ใช้ข้อมูลสมมติเท่านั้น ห้ามใช้ข้อมูลคดีจริง

13.3 AML & Financial Crime — ฟอกเงินและอาชญากรรมทางการเงิน

Suspicious Transaction Analysis 📥 Download Mock Data
คุณคือผู้เชี่ยวชาญด้าน Anti-Money Laundering (AML)

## ข้อมูลธุรกรรม (สมมติ)
| วันที่ | บัญชีต้นทาง | บัญชีปลายทาง | จำนวน | หมายเหตุ |
|--------|-------------|--------------|--------|----------|
| 1 ม.ค. | A-1234 | B-5678 | 9,900 | โอนปกติ |
| 1 ม.ค. | A-1234 | C-9012 | 9,800 | โอนปกติ |
| 1 ม.ค. | A-1234 | D-3456 | 9,700 | โอนปกติ |
| 2 ม.ค. | A-1234 | E-7890 | 9,500 | โอนปกติ |
| 2 ม.ค. | A-1234 | F-2345 | 9,900 | โอนปกติ |

## วิเคราะห์:
1. ระบุ Red Flags ตามหลัก AMLO (ปปง.)
2. ระบุรูปแบบ (Pattern) ที่น่าสงสัย — เช่น Structuring / Smurfing
3. ระดับความเสี่ยง (Risk Score) 1-10 พร้อมเหตุผล
4. แนะนำว่าควร STR (Suspicious Transaction Report) หรือไม่
5. แนวทางสืบสวนเพิ่มเติม

Format: ตาราง + สรุปผล

13.4 CDR & SIMBox Detection

13.4.1 Call Detail Records Analysis

วิเคราะห์ข้อมูล CDR เพื่อระบุรูปแบบการโทรที่ผิดปกติ เช่น Call Center Fraud

Call Detail Records Analysis — ตรวจจับ SIMBox 📥 Download Mock Data
คุณคือนักวิเคราะห์ข้อมูลโทรคมนาคมเชี่ยวชาญด้าน CDR Analysis

## ข้อมูล CDR (สมมติ)
หมายเลข: 09X-XXX-1234
ช่วงเวลา: 1-7 มกราคม 2569

| วันที่ | เวลา | ปลายทาง | ระยะเวลา | Cell Tower |
|--------|------|---------|----------|------------|
| 1 ม.ค. | 09:01 | 02-XXX-5001 | 45 วินาที | BKK-A01 |
| 1 ม.ค. | 09:03 | 02-XXX-5002 | 38 วินาที | BKK-A01 |
| 1 ม.ค. | 09:05 | 02-XXX-5003 | 52 วินาที | BKK-A01 |
| ... (โทรออก 200+ ครั้ง/วัน) | | | | |

## วิเคราะห์:
1. รูปแบบการโทร (Call Pattern) — ปกติหรือผิดปกติ?
2. ตรวจสอบ SIMBox Indicators:
   - ความถี่การโทรสูงผิดปกติ
   - ระยะเวลาสนทนาสั้น
   - โทรไปหมายเลขไม่ซ้ำ
   - ตำแหน่ง Cell Tower คงที่
3. ความน่าจะเป็นที่เป็น: Call Center Fraud / SIMBox / ปกติ
4. แนะนำ Next Steps สำหรับพนักงานสอบสวน

13.5 Document Drafting — ร่างเอกสารราชการ

13.5.1 หนังสือขอความร่วมมือ

ใช้ AI ช่วยร่างหนังสือราชการสำหรับการประสานงานระหว่างหน่วยงาน

ร่างหนังสือขอความร่วมมือ (ขอข้อมูลบัญชี)
คุณคือผู้เชี่ยวชาญการร่างหนังสือราชการไทย

## ร่างหนังสือขอความร่วมมือ
- ผู้ส่ง: กองบังคับการปราบปรามการกระทำความผิดเกี่ยวกับอาชญากรรมทางเทคโนโลยี (บก.ปอท.)
- ผู้รับ: ธนาคารแห่งหนึ่ง (สมมติ)
- เรื่อง: ขอข้อมูลบัญชีเกี่ยวข้องกับคดีฉ้อโกง
- อ้างอิง: พ.ร.บ.คอมพิวเตอร์ พ.ศ.2560 มาตรา 18
- รายละเอียด: ขอข้อมูลเจ้าของบัญชี, Statement 3 เดือน, IP Log-in

## เงื่อนไข:
- ใช้ภาษาราชการ สุภาพ กระชับ
- อ้างอิงกฎหมายที่เกี่ยวข้อง
- ระบุเอกสารแนบ (สำเนาหมายศาล)
- Format: หนังสือราชการตามระเบียบสำนักนายกรัฐมนตรี

หมายเหตุ: นี่คือข้อมูลสมมติเพื่อการฝึกอบรมเท่านั้น

13.5.2 Case Summary

สรุปคดีสำหรับรายงานผู้บังคับบัญชาหรือส่งพนักงานอัยการ

13.6 Call Center Fraud Analysis

13.6.1 วิเคราะห์ Script และ Social Engineering

ใช้ AI วิเคราะห์บทสนทนาของ Call Center มิจฉาชีพ เพื่อระบุเทคนิค Social Engineering ที่ใช้

🔍 รูปแบบ Call Center Fraud ที่พบบ่อย
รูปแบบวิธีการเป้าหมาย
แอบอ้างเป็นตำรวจ/DSIข่มขู่ว่าเกี่ยวข้องกับคดีให้โอนเงิน "ค้ำประกัน"
แอบอ้างเป็นธนาคารแจ้งบัตรถูก compromiseขอข้อมูลบัตร/OTP
แอบอ้างเป็นไปรษณีย์แจ้งพัสดุผิดกฎหมายให้โอนเงิน/ติดมัลแวร์
Romance Scamสร้างความสัมพันธ์ออนไลน์ขอเงินลงทุน/ช่วยเหลือ

13.7 ศูนย์ต่อต้านการฉ้อโกงออนไลน์ — Prompt สนับสนุน 11 ส่วนงาน

ตัวอย่าง Prompt ตามโครงสร้างงานจริง — ข้อมูลสมมติเท่านั้น · ใช้กับ AI ภายในองค์กร

🔍 กลุ่มที่ 1 — งานสืบสวน/วิเคราะห์
ส่วนที่ 1: วิเคราะห์รูปแบบคดี 📥 Download Mock Data
[P] นักวิเคราะห์อาชญากรรมไซเบอร์ [T] เปรียบเทียบ MO ของ 5 คดีที่แนบ ระบุ pattern ร่วมและจุดต่าง
[C] ข้อมูล 5 คดี [แนบ] [F] ตาราง: คดี | MO | เป้าหมาย | ช่องทาง | Pattern ร่วม
ส่วนที่ 2: สรุปข้อมูลเครือข่าย 📥 Download Mock Data
[P] นักวิเคราะห์ข่าวกรอง [T] สร้าง network map จากข้อมูลผู้ต้องสงสัย ระบุความเชื่อมโยง
[C] ข้อมูลบุคคล 10 ราย [แนบ] [F] ตาราง: บุคคล | บทบาท | เชื่อมโยงกับใคร | หลักฐาน
ส่วนที่ 3: ทำนายแนวโน้ม 📥 Download Mock Data
[P] นักวิเคราะห์สถิติอาชญากรรม [T] วิเคราะห์ trend รายไตรมาส ระบุประเภทคดีที่เพิ่มขึ้น/ลดลง
[C] สถิติ 4 ไตรมาส [แนบ] [F] สรุป 5 ข้อ + กราฟแนวโน้ม + คาดการณ์ไตรมาสหน้า
📋 กลุ่มที่ 2 — งานสอบสวน/เอกสาร
ส่วนที่ 4: สรุปปากคำผู้เสียหาย
[P] พนักงานสอบสวน [T] สกัดข้อเท็จจริงจากบันทึกปากคำ แยก fact vs ความเห็น
[C] บันทึกปากคำ [แนบ] [F] ตาราง: ข้อเท็จจริง | แหล่งข้อมูล | ยืนยันแล้ว/รอตรวจ
ส่วนที่ 5: ร่างหนังสือขอความร่วมมือ
[P] เจ้าหน้าที่ธุรการ [T] ร่างหนังสือขอความร่วมมือไปยัง [หน่วยงาน]
[C] เรื่อง: [ระบุ] เหตุผล: [ระบุ] [F] รูปแบบหนังสือราชการ โทนทางการ ≤1 หน้า
ส่วนที่ 6: สรุปคดีสำหรับ ผบ.
[P] พนักงานสอบสวน [T] สรุปคดีสำหรับรายงานผู้บังคับบัญชา
[C] ข้อมูลคดี [แนบ] [F] 7 หัวข้อ: ประเภท/MO/ผู้เสียหาย/มูลค่า/ผู้ต้องสงสัย/สถานะ/ขั้นตอนถัดไป ≤1 หน้า A4
📢 กลุ่มที่ 3 — งานอำนวยการ/ประชาสัมพันธ์
ส่วนที่ 7: จัดทำรายงานสถิติ 📥 Download Mock Data
[P] นักวิเคราะห์สถิติ [T] สร้าง dashboard summary รายเดือน
[C] ข้อมูลคดีเดือน [X] [แนบ] [F] สรุป: จำนวนคดี/มูลค่ารวม/ประเภท Top 5/เปรียบเทียบเดือนก่อน
ส่วนที่ 8: ประกาศเตือนภัย
[P] เจ้าหน้าที่ประชาสัมพันธ์ [T] เขียนประกาศเตือนภัย [ประเภท]
[C] MO [วาง] กลุ่มเป้าหมาย: ผู้สูงอายุ [F] ≤200 คำ + Red Flags 5 ข้อ + ช่องทางแจ้ง 1441
ส่วนที่ 9: ตอบคำถาม FAQ
[P] เจ้าหน้าที่ศูนย์ [T] ตอบคำถามประชาชนจาก FAQ database
[C] คำถาม: [X] FAQ: [แนบ] [F] คำตอบสั้น ≤3 ประโยค + link ที่เกี่ยวข้อง
ส่วนที่ 10: แปลเอกสาร MLA/MLAT
[P] นักแปลเอกสารกฎหมาย [T] แปลเอกสาร MLA/MLAT ไทย→อังกฤษ
[C] เอกสาร [แนบ] [F] แปลทางการ + หมายเหตุคำศัพท์กฎหมายเฉพาะทาง
ส่วนที่ 11: สรุปบทเรียน Post-Case
[P] นักวิเคราะห์คดี [T] สกัด lesson learned จากคดีที่ปิดแล้ว
[C] สรุปคดี [แนบ] [F] 4 หัวข้อ: สิ่งที่ทำดี/จุดที่ต้องปรับ/ข้อเสนอแนะ/แนวทางป้องกันซ้ำ

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

🚧 7 ข้อผิดพลาดที่พบบ่อยในงานสืบสวน/ตำรวจ — และวิธีแก้
#❌ ข้อผิดพลาด✅ วิธีที่ถูกต้อง
1 ใส่ข้อมูลคดีจริง (ชื่อ-ที่อยู่ เลขบัตร เบอร์โทร) ลงใน AI สาธารณะ ใช้ Synthetic Data/Mock Data เสมอ หรือใช้ AI ภายในองค์กร + ต้องผ่าน PDPA
2 เชื่อผล AI วิเคราะห์ทันที ไม่ verify กับ source data AI ช่วยวิเคราะห์ แต่พนักงานสอบสวนต้อง verify + ตัดสินใจ (Human-in-the-Loop)
3 ไม่ใช้ Context Engineering ทำให้ AI ไม่เข้าใจบริบทงานสืบสวน เตรียม Context Stack 5 Layers (System, Knowledge, Memory, Tools, Guardrails) ก่อน
4 ใส่เอกสารทั้งหมดโดยไม่ Compress/Select ทำให้ context เต็มกะทันหัน ใช้ W-S-C-I: Select → Compress → ใส่เฉพาะที่เกี่ยวข้อง
5 ใช้ AI สรุปปากคำโดยไม่ระบุ format ทำให้ได้ผลลัพธ์ไม่สม่ำเสมอ ใช้ structured output (JSON/Markdown template) พร้อม confidence field
6 ไม่ test Prompt กับ edge cases (ข้อมูลไม่ครบ/ขัดแย้ง) Test ด้วย: (1) คดีปกติ (2) คดีข้อมูลขาด (3) คดีข้อมูลขัดแย้ง — ดู error handling
7 ไม่มี Quick Start Rubric วัดคุณภาพ output ใช้ Rubric 5 ข้อ: ตรงเป้า, ไม่ hallucinate, โทนถูก, ความยาวพอดี, แก้ ≤ 20%

13.9 Key Takeaways

📝 Key Takeaways Module 13
✅ หลังเรียน Module 13 — สิ่งที่ควรทำได้
🤔 คำถามทบทวน

โจทย์: มีรายงานปากคำผู้เสียหาย 3 ราย ต้องการสรุปเป็นเอกสารสำหรับ ผบ. และสร้างประกาศเตือนภัยประชาชน — จะใช้ Prompt ใดจาก Module 13 บ้าง? เรียงลำดับการทำงาน

ดูเฉลย
  1. ส่วนที่ 4 สรุปปากคำ → สกัด fact จากบันทึกปากคำ 3 ราย
  2. ส่วนที่ 6 Case Summary → สรุป 7 หัวข้อ ไม่เกิน 1 หน้า A4 สำหรับ ผบ.
  3. ส่วนที่ 8 ประกาศเตือนภัย → สร้างประกาศสำหรับประชาชน

ทุกขั้น: ตรวจ Rubric 5 ข้อก่อนนำไปใช้จริง

M12: AI Security M14: Use Cases ธุรกิจ