บทเรียน 1.1 — Edge AI และ IoT ทำอะไรได้ และทำอะไรไม่ได้

เป้าหมาย

เมื่อจบบทเรียนนี้ คุณจะ

1. จำแนกได้ว่าโจทย์ไหนเหมาะกับ IoT อย่างเดียว IoT ร่วมกับ Edge AI หรือไม่ควรใช้ทั้งคู่
2. อธิบายข้อจำกัดหลักของ Edge AI ได้อย่างน้อย 3 ข้อ
3. เขียนโจทย์ธุรกิจของตัวเองเป็นประโยคเดียวที่ทีมเทคนิคเอาไปทำงานต่อได้

ก่อนเริ่ม

ลองนึกถึงปัญหาหนึ่งเรื่องในกิจการของคุณที่ "อยากรู้ก่อนที่จะสายเกินไป" เช่น เครื่องจักรกำลังจะเสีย ของในตู้แช่กำลังจะเสีย หรือลูกค้ากำลังรอคิวนานเกินไป จดไว้หนึ่งบรรทัด เราจะกลับมาใช้ตอนท้ายบท

ดูของจริงก่อน — สี่กรณีตัวอย่าง

อ่านตารางนี้แล้วลองเดาก่อนว่าแถวไหน "ต้องมี AI" จริง ๆ

สองในสี่แถวไม่ต้องใช้ AI เลย — โจทย์ส่วนใหญ่ต้องการการวัดที่ดีกับกฎที่ชัด ก่อนจะต้องการ AI

แนวคิด (1) — สองคำที่มักถูกใช้ปนกัน

• IoT (Internet of Things) คืออุปกรณ์ที่มีเซนเซอร์ วัดค่าได้เอง และส่งข้อมูลผ่านเครือข่าย ทำให้เรารู้สิ่งที่เกิดขึ้นโดยไม่ต้องมีคนไปยืนดู
• Edge AI คือการรันโมเดล AI ที่ฝึกมาแล้ว บนตัวอุปกรณ์เอง ใกล้เซนเซอร์ แทนที่จะส่งข้อมูลดิบทั้งหมดขึ้นคลาวด์ไปให้คอมพิวเตอร์ที่อื่นคิด

ชิปรุ่นใหม่สำหรับงานนี้เล็กลงและเก่งขึ้นมาก ตัวอย่างเช่นบอร์ด TESAIoT Dev Kit ที่ใช้ในหลักสูตรของ TESA ใช้ชิป Infineon PSoC™ Edge E84 ซึ่งมี Arm® Cortex®-M55 ร่วมกับหน่วยเร่ง AI (NPU) Ethos™-U55 และมีเซนเซอร์ความเคลื่อนไหว เรดาร์ 60 GHz ไมโครโฟน และเซนเซอร์สภาพแวดล้อมอยู่บนบอร์ด — ไม่ได้ยกตัวอย่างนี้เพื่อให้ซื้อบอร์ดรุ่นนี้ แต่เพื่อให้เห็นว่า "AI บนอุปกรณ์ตัวเล็ก" เป็นของที่มีอยู่จริงแล้ว

แนวคิด (2) — บันไดสามขั้นก่อนพูดถึง AI

ถามตามลำดับนี้ ถ้าตอบได้ที่ขั้นไหน หยุดที่ขั้นนั้น

1. วัดได้ไหม ปัญหานี้มีสัญญาณอะไรที่เซนเซอร์จับได้ ถ้าไม่มีสัญญาณ ไม่มีเทคโนโลยีไหนช่วยได้
2. กฎธรรมดาพอไหม ถ้าตัดสินใจได้ด้วย "ค่าเกินเกณฑ์" หรือ "เกินเกณฑ์นานกว่า X นาที" ใช้ IoT กับกฎก็พอ ถูกกว่าและอธิบายง่ายกว่า
3. ต้องจำรูปแบบไหม ถ้า "ผิดปกติ" ไม่ใช่ตัวเลขตัวเดียว แต่เป็นรูปแบบของสัญญาณ เช่น เสียง การสั่น หรือท่าทาง นั่นคือที่ที่ Edge AI คุ้มค่า

แนวคิด (3) — สิ่งที่ Edge AI ทำไม่ได้ หรือทำได้ไม่ดี

• ไม่ถูกร้อยเปอร์เซ็นต์ โมเดลทุกตัวมีทั้งเตือนผิด (false alarm) และพลาดเหตุการณ์จริง ต้องออกแบบว่าผิดแล้วใครรับผิดชอบ และต้นทุนของการผิดแต่ละแบบเป็นเท่าไร
• ไม่มีข้อมูล ไม่มีโมเดล โมเดลเรียนจากตัวอย่าง ต้องมีข้อมูลจากหน้างานจริงทั้งตอนปกติและผิดปกติ การเก็บข้อมูลมักเป็นงานที่นานที่สุดของโครงการ
• ไม่ใช่ติดตั้งแล้วจบ สภาพหน้างานเปลี่ยน เครื่องจักรเปลี่ยน ฤดูเปลี่ยน โมเดลที่แม่นวันนี้อาจแม่นน้อยลงในปีหน้า ต้องมีแผนดูแลและอัปเดต
• ไม่แทนการแก้กระบวนการ ถ้าเตือนแล้วไม่มีใครรู้ว่าต้องทำอะไรต่อ ระบบที่แม่นแค่ไหนก็ไม่มีประโยชน์

แนวคิด (4) — โจทย์ที่ดีมีสามส่วน

ประโยคโจทย์ที่ทีมเทคนิคเอาไปทำงานต่อได้ ต้องตอบครบสามส่วน วัดอะไร · ตัดสินใจอะไร · ใครทำอะไรต่อ

วัดอุณหภูมิในตู้แช่ทุกตู้ ถ้าอุ่นเกินเกณฑ์นานกว่า 15 นาที ให้ส่งข้อความหาผู้จัดการกะ เพื่อไปตรวจประตูตู้ภายใน 30 นาที

ประโยคนี้ไม่มีคำว่า AI เลย และนั่นไม่ใช่ข้อเสีย

ฝึกเติม

กลับไปที่ปัญหาที่คุณจดไว้ตอนต้นบท เขียนใหม่ให้ครบสามส่วน แล้วเดินบันไดสามขั้น บอกว่าโจทย์ของคุณหยุดที่ขั้นไหน

เช็กความเข้าใจ

ตอบคำถามใน quiz.yaml ถูกตั้งแต่ 80% ขึ้นไปถือว่าผ่าน

ไปต่อ / สะท้อนคิด

ถ้าอยากเห็นกับตาว่าอุปกรณ์ตัวเล็ก "วัดแล้วตัดสินใจ" อย่างไร ลองหลักสูตร Explorer บทเรียนเรื่องอ่านเซนเซอร์ ใช้เวลาราวครึ่งชั่วโมงในเบราว์เซอร์ ไม่ต้องมีบอร์ด

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