Anti-Patterns ที่การใช้ AI ทำให้ระบบพัง

ปัญญาประดิษฐ์ (AI) ถูกพูดถึงอย่างมากในประเทศไทย ทั้งในภาครัฐ (GovTech) รัฐวิสาหกิจ และองค์กรขนาดใหญ่ หลายโครงการเริ่มต้นด้วยความคาดหวังว่า AI จะช่วยลดคน ลดต้นทุน และเพิ่มความเร็ว

แต่ในทางปฏิบัติ เราพบว่า หลายระบบกลับพังหรือสร้างปัญหาใหม่ หลังจากนำ AI เข้าไปใช้

สาเหตุหลักไม่ใช่เพราะโมเดล AI แย่ แต่เป็นเพราะ ใช้ AI ด้วยกรอบความคิดแบบผิด และขาดประสบการณ์ด้าน system design

บทความนี้รวบรวม anti-patterns ที่พบบ่อยในประเทศไทย พร้อมคำอธิบายว่าทำไมมันถึงล้มเหลว และนักพัฒนาซอฟต์แวร์ควรออกแบบอย่างไรให้ระบบยังคงเชื่อถือได้

---

1. ใช้ AI แทน Logic ที่ควรเป็น Deterministic

Anti-Pattern

นำ AI ไปแทน business rules หรือกฎระเบียบที่ชัดเจนอยู่แล้ว

ตัวอย่างในบริบทไทย

• ใช้ AI ตัดสินสิทธิ์สวัสดิการแทน rule-based criteria
• ใช้ AI คำนวณภาษีหรือค่าธรรมเนียม
• ใช้ AI ตัดสินสิทธิ์การเข้าถึงระบบภายในหน่วยงาน

ทำไมระบบถึงพัง

• AI ให้ผลลัพธ์เชิงความน่าจะเป็น
• ผลลัพธ์ไม่สม่ำเสมอ
• อธิบายย้อนหลังไม่ได้ (audit ยาก)

แนวทางที่ถูกต้อง

Core logic ต้องเป็น deterministic code
AI ใช้เฉพาะส่วนที่ข้อมูลคลุมเครือ เช่น การจัดหมวดหมู่ หรือการสรุปข้อมูล

ถ้าระบบต้อง "ถูกต้อง 100%" — AI ไม่ควรเป็นผู้ตัดสินสุดท้าย

---

2. ไม่มี Human-in-the-Loop สำหรับการตัดสินใจสำคัญ

Anti-Pattern

ปล่อยให้ AI ตัดสินใจเองทั้งหมดในเรื่องที่กระทบประชาชนหรือธุรกิจ

ตัวอย่าง

• ปฏิเสธคำขอประชาชนอัตโนมัติ
• ระงับบัญชีหรือธุรกรรมโดยไม่มีการทบทวน

ทำไมระบบถึงพัง

• ความมั่นใจของ AI ≠ ความถูกต้อง
• กรณีขอบ (edge cases) สร้างความเสียหายสูง
• ความเชื่อมั่นต่อหน่วยงานลดลง

แนวทางที่ถูกต้อง

กำหนด threshold ชัดเจน

• ความมั่นใจต่ำ → เจ้าหน้าที่ตรวจสอบ
• ความมั่นใจสูง → ทำงานอัตโนมัติ + เก็บ log

---

3. เชื่อผลลัพธ์ AI เหมือนเป็นความจริง

Anti-Pattern

นำ output ของ AI ไปใช้ทันทีโดยไม่ validate

ตัวอย่าง

• ใช้ SQL ที่ AI สร้างใน production
• ใช้คำแนะนำด้านความปลอดภัยจาก AI โดยไม่ตรวจสอบ

ทำไมระบบถึงพัง

• AI hallucinate ได้
• ข้อผิดพลาดดูน่าเชื่อถือมาก

แนวทางที่ถูกต้อง

AI = ผู้ช่วยร่าง (draft)
มนุษย์ = ผู้รับผิดชอบสุดท้าย

---

4. ไม่มีขอบเขตของ AI ในระบบ

Anti-Pattern

ปล่อยให้ AI เข้าถึงฐานข้อมูลหรือ state ของระบบโดยตรง

ทำไมระบบถึงพัง

• พฤติกรรมคาดเดาไม่ได้
• ทดสอบยาก
• เสี่ยงด้านความปลอดภัย

แนวทางที่ถูกต้อง

แยก AI เป็น component ชัดเจน

• Input → AI → suggestion
• Core system เป็นผู้ตัดสินใจ

---

5. แก้ปัญหาสถาปัตยกรรมด้วย Prompt

Anti-Pattern

พยายาม encode business rules ทั้งหมดไว้ใน prompt

ทำไมระบบถึงพัง

• Prompt ไม่ใช่ logic ที่ test ได้
• เปลี่ยน model แล้วพฤติกรรมเปลี่ยน

แนวทางที่ถูกต้อง

• Prompt ใช้กับงานภาษา
• Rules / policy ต้องอยู่ใน code

---

6. ไม่มี Fallback เมื่อ AI ล้มเหลว

Anti-Pattern

ออกแบบระบบโดยคิดว่า AI จะพร้อมใช้งานเสมอ

ทำไมระบบถึงพัง

• API ล่ม
• latency สูง
• model drift

แนวทางที่ถูกต้อง

ต้องมี:

• timeout
• fallback flow
• manual override

---

7. ขาด Explainability และ Audit Trail

Anti-Pattern

ตอบคำถามผู้ใช้งานหรือผู้ตรวจสอบด้วยคำว่า “AI ตัดสินใจ”

ทำไมระบบถึงพัง

• ไม่ผ่านการตรวจสอบ
• วิเคราะห์เหตุการณ์ย้อนหลังไม่ได้

แนวทางที่ถูกต้อง

เก็บ log:

• input
• output
• confidence
• decision path

---

8. ใช้ AI กลบปัญหาเชิงกระบวนการ

Anti-Pattern

ใช้ AI แก้ปลายเหตุแทนการแก้ process

ทำไมระบบถึงพัง

• technical debt เพิ่ม
• ค่าใช้จ่ายบานปลาย

แนวทางที่ถูกต้อง

แก้ process ก่อน แล้วค่อยใช้ AI ขยายผล

---

9. วัดความสำเร็จจาก Demo ไม่ใช่การใช้งานจริง

Anti-Pattern

โครงการผ่านเพราะ demo สวย

ทำไมระบบถึงพัง

• production behavior ต่างจาก demo
• error เล็ก ๆ กลายเป็น incident ใหญ่

แนวทางที่ถูกต้อง

วัดจาก:

• error rate
• เวลาในการกู้ระบบ
• จำนวนครั้งที่ต้องใช้คนช่วย

---

บทสรุป: AI ไม่ได้ทำให้ระบบพัง — วิธีใช้ต่างหากที่ทำให้พัง

AI เป็นเพียงเครื่องมือ

ระบบจะพังเมื่อ:

• นักพัฒนายกความรับผิดชอบให้ AI
• ใช้ prompt แทนสถาปัตยกรรม
• มองความไม่แน่นอนเป็นความจริง

บทบาทของนักพัฒนาซอฟต์แวร์ที่มีประสบการณ์ในประเทศไทยจึงสำคัญมากขึ้น

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

นี่คือวิศวกรรมซอฟต์แวร์ที่แท้จริงในยุค AI