ตัวอย่างปัญหาจริง

Why this matters

ทฤษฎีบอกว่า AI ผิดได้ — แต่เห็นเคสจริงแล้วจะจำแม่นกว่า ต่อไปนี้คือตัวอย่างสถานการณ์ในบริบทงาน QA ที่พบได้บ่อย พร้อมบทเรียนของแต่ละเคส (เคสถูกเรียบเรียงขึ้นเพื่อการเรียนรู้ แต่รูปแบบความผิดพลาดเหล่านี้เกิดขึ้นจริงเป็นประจำ)

เคส 1 — AI แต่งค่า spec ขึ้นมาเอง

QA ถาม AI ว่า “coating thickness ของ Part ABC-001 ต้องอยู่ที่เท่าไร” AI ตอบทันทีว่า “12–15 µm ตาม spec Rev.C” — ตัวเลขดูน่าเชื่อถือมากจนเกือบถูกคัดลอกไปใส่ในคำตอบลูกค้า แต่พอเปิด specification จริง ค่าที่ถูกต้องคือคนละช่วง และเอกสารก็ไม่มี Rev.C

บทเรียน: ตัวเลขและข้อกำหนดทุกตัวต้องมี source ที่เปิดตรวจได้ ถ้า AI ไม่ได้รับเอกสารจริงไปด้วย ให้ถือว่าตัวเลขที่ตอบมาคือการเดา

เคส 2 — สรุป complaint ตกข้อมูลสำคัญ

AI สรุป complaint ยาว 3 หน้าได้กระชับอ่านง่าย แต่ดันตัดข้อมูล Lot number ที่ได้รับผลกระทบและ deadline ที่ลูกค้ากำหนดออกไป ทีมจึงวางแผนสอบสวนช้ากว่ากำหนดโดยไม่รู้ตัว

บทเรียน: งานสรุปต้องมี checklist ของ field ที่ห้ามหาย (Part, Lot, ปริมาณ, วันที่, deadline, คำขอของลูกค้า) และสั่งให้ AI ระบุ “ข้อมูลที่ยังขาด” แยกออกมาเสมอ

เคส 3 — แปลศัพท์เทคนิคเพี้ยน

ลูกค้าต่างประเทศรายงาน defect เป็นภาษาอังกฤษ AI แปลเป็นไทยได้ลื่นไหล แต่แปลศัพท์เทคนิคของอาการ defect ผิดความหมาย ทำให้หน้างานไปตรวจผิดจุดและเสียเวลาไปหลายชั่วโมง

บทเรียน: งานแปลเอกสารเทคนิคควรแนบ glossary ศัพท์เฉพาะของบริษัทไปกับคำสั่ง และให้คนที่รู้ทั้งสองภาษา + รู้หน้างาน ตรวจก่อนใช้

เคส 4 — มั่นใจ root cause ผิด

เมื่อป้อนอาการ defect ให้ AI มันวิเคราะห์ root cause ออกมาอย่างเป็นขั้นตอนน่าเชื่อถือ ทีมเกือบปิดเคสตามนั้น — แต่การตรวจหน้างานจริงพบว่าสาเหตุเป็นคนละเรื่อง เพราะ AI ไม่เคยเห็นเครื่องจักร ไม่เห็นชิ้นงานจริง และไม่รู้ว่าข้อมูลที่ป้อนไปนั้นไม่ครบ

บทเรียน: ใช้ AI ช่วย ตั้งสมมติฐาน root cause ได้ (brainstorm) แต่การ สรุป root cause ต้องมาจากหลักฐานจริงและการตัดสินใจของคนเท่านั้น

Completion Checklist

• เล่าได้ว่าแต่ละเคสพลาดตรงไหน
• บอกวิธีป้องกันของแต่ละเคสได้โดยไม่ต้องเปิดดู
• นึกออกว่าในงานของตัวเอง เคสแบบไหนมีโอกาสเกิดที่สุด