เปิดบทเรียนด้วยของจริงก่อน

เหมือนทุกบทเรียน เราเริ่มแบบ กลับด้าน — รันของที่ทำงานได้ก่อน แล้วค่อยแกะ วันนี้เปิดตัวอย่าง 16_edge_ai_sound_events.py มันคือเมนูรวมสามโมเดลเสียง (ไอ / เสียงเตือน / ไซเรน) ในหน้าเดียว

บทเรียน 1.1–1.3 เราทำ "เมนู 6 โมเดล" ให้เลือกได้ทุกตัว — สนุกดีสำหรับเดโม แต่วันนี้เราจะถอยไปอีกก้าว: เอาโมเดลเดียวมาทำเป็น แอป ที่มีหน้าจอเฉพาะตัว แล้วต่อ verdict เข้ากับการกระทำจริง

เป้าหมายของชุดบทเรียนนี้

จบชุดบทเรียนนี้เราจะเปลี่ยนจาก "รันโมเดล" เป็น "สร้างแอป" ครบ 4 เรื่อง แล้วปิดท้ายด้วยแอปที่คุณสร้างเอง:

1. เมนู กับ แอปโฟกัส ต่างกันตรงไหน และทำไมงานจริงมักเลือกอย่างหลัง
2. find_model() — เล็งโมเดลด้วยคีย์เวิร์ด แทนที่จะ hard-code เลข index
3. อ่าน scores ทุกคลาส + latency_ms ให้เป็น ไม่ใช่แค่คลาสที่ชนะ
4. จาก verdict สู่ action — นับเมื่อคลาสเป้าหมายข้ามเกณฑ์ CONF_FLOOR (ก้าวแรกของ Apps)
5. ลงมือ: เติม s15_apps.py ให้เป็น แอป Cough ที่นับจำนวนครั้งที่ไอบนจอ

ปลายทางวันนี้: แอปโฟกัสหน้าตาสะอาด รันโมเดลเดียว โชว์คลาสที่ชนะ + แถบทุกคลาส และตัวนับที่เพิ่มขึ้นจริงเมื่อเจอเสียงเป้าหมาย

วันนี้เรายังไม่แตะ RGB/เสียง/WiFi (นั่นคือ บทเรียน 6.3–6.6) เราโฟกัสที่ "โครงของแอปต่อโมเดล" กับการกระทำเบาที่สุดหนึ่งอย่าง คือการนับ

ชุดบทเรียนนี้อยู่ตรงไหนของวงจร

เราเดินมาครบสี่ Pillar แรกแล้ว (DAQ → Processing → Analysis → Training) ชุดบทเรียนนี้เข้าสู่ Pillar 5 · Apps — ขั้นที่เอาโมเดลไป "ใช้งาน" จริง

• บทเรียน 1.1–1.3 เราเคยแตะ Apps มาแล้วสั้นๆ (เมนู 6 โมเดล) และ บทเรียน 1.6–1.7 เราแกะ path จาก verdict สู่ action
• ชุดบทเรียนนี้เอาทั้งสองมาต่อยอด: สร้าง แอปที่โฟกัสและใช้ได้จริง ไม่ใช่แค่เดโมเมนู
• บทเรียน 6.3–6.4 (ชุดบทเรียนถัดไป) จะต่อ action ให้แรงขึ้น (RGB/เสียง/log + debounce เต็มรูปแบบ) · บทเรียน 6.5–6.6 ต่อ IoT

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

ทบทวนจากบทเรียน 1.6–1.7 — verdict สู่ action

บทเรียน 1.6–1.7 เราแกะแอป Edge AI จนเห็น "เส้นทางของผล" — จากเซนเซอร์ไปจนถึงการกระทำ วันนี้เราต่อจากปลายเส้นนั้น

• โมดูล 1 หยุดที่ช่อง verdict เป็นหลัก — เอา label + conf ขึ้นจอ
• ชุดบทเรียนนี้เราขยับไปช่อง action ช่องแรก: "นับ" เมื่อคลาสเป้าหมายมาแบบมั่นใจ
• การนับดูเล็กน้อย แต่มันสอนหลักการเดียวกับ action ที่ใหญ่กว่า: ตัดสินใจว่าจะเชื่อ verdict เมื่อไร แล้วค่อยลงมือ

"นับ" คือ action ที่ปลอดภัยที่สุดสำหรับเรียนรู้ — ไม่มีอะไรพัง แต่คุณจะได้เจอปัญหาจริงของ Apps ทันที: นับเฟ้อเพราะเสียงกระพริบ, false positive จาก conf ต่ำ เดี๋ยวเราแก้ทีละอย่าง

เมนู กับ แอปโฟกัส ต่างกันตรงไหน

ทั้งคู่ใช้ edge_ai ตัวเดียวกัน ต่างกันที่ เจตนาของการออกแบบ — และงานจริงเกือบทั้งหมดเป็นแบบขวา

คิดง่ายๆ: เมนูคือ "รีโมตรวม" ที่คุมทีวีได้ทุกยี่ห้อ ส่วนแอปโฟกัสคือ "ปุ่มเดียว" บนเครื่องที่ทำงานหนึ่งอย่างให้ดีที่สุด งานวิศวกรรมจริงต้องการอย่างหลังมากกว่า

ตระกูลแอปอ้างอิง — ตัวอย่าง 13 ถึง 16

ก่อนสร้างเอง มาดูของที่มีอยู่ ทั้งสี่ตัวคือ "แอปต่อโมเดล" ที่โครงเกือบเหมือนกันเป๊ะ ต่างแค่โมเดลกับ UI นิดหน่อย

• สังเกตว่าทั้งสี่ตัวมีก้อนเดียวกัน: find_model() → select() → ลูป result() → วาด verdict + แถบ → finally: stop()
• ตัวอย่าง 13/14/15 คือ แอปโฟกัสโมเดลเดียว (แม่แบบของเรา) · ตัวอย่าง 16 เป็นเมนูย่อยของสามโมเดลเสียง
• งานชุดบทเรียนนี้: เอาโครงเดียวกันนี้ บวก action หนึ่งอย่าง (การนับ) แล้วทำให้รีทาร์เก็ตง่ายด้วยตัวแปรบนหัวไฟล์

จำ pattern นี้ไว้ให้ขึ้นใจ เพราะแอป Edge AI 90% ที่คุณจะเขียนต่อจากนี้ ล้วนเป็นโครงนี้ทั้งนั้น เปลี่ยนแค่ "โมเดลอะไร" กับ "ทำอะไรกับผล"

6 โมเดล — ตัวไหนเอามาทำแอปโฟกัสได้บ้าง

ทะเบียนโมเดลยังเป็น 6 ตัวเดิมจากบทเรียน 1.1–1.3 ชุดบทเรียนนี้เราจะหยิบ โมเดลเสียง มาทำแอป เพราะทดสอบง่าย (ส่งเสียงเอง) และเป็นสนามใหญ่ของ Edge AI จริง

• ค่าตั้งต้นของ s15_apps.py เล็งที่ Cough Detection — เราสร้างแอป "เครื่องนับเสียงไอ"
• โมเดล Cough/Alarm/Siren มาจาก DEEPCRAFT Ready-Model แต่ละตัวมีสองคลาส: unlabelled กับคลาสเป้าหมาย
• การบ้าน: เปลี่ยนสองบรรทัดบนหัวไฟล์ให้เป็น Alarm และ Siren แล้วเซฟเป็นไฟล์แยก

เราเลือก Cough เป็นตัวตั้งต้นเพราะ "ไอ" เป็นเสียงสั้นชัด นับง่าย เห็นตัวเลขขยับทันที — เหมาะกับการเรียนเรื่อง "ขอบขาขึ้น" กับ debounce ที่จะเจอต่อไป

ทวนคำสั่งหลักของ edge_ai

แอปโฟกัสยืนอยู่บนคำสั่งเดิมจาก บทเรียน 1.1–1.3 แต่ชุดบทเรียนนี้เราตัด count()/models() ออกจากลูปหลัก เหลือแค่สามตัวที่ทำงานจริงตอนรัน

• ต่างจาก บทเรียน 1.1–1.3 ตรงที่ select() เรียก ครั้งเดียวตอนเปิดแอป ไม่ต้องรอผู้ใช้กด Load — แอปโฟกัสรู้อยู่แล้วว่าจะรันอะไร
• CONF_FLOOR คราวนี้ไม่ใช่แค่เปลี่ยนสี แต่เป็น เงื่อนไขของ action จริง (นับหรือไม่นับ)

น้อยลงแต่คมขึ้น — เมื่อคุณรู้ว่าจะรันโมเดลไหน โค้ดก็สั้นลง เหลือแต่แก่น: อ่านผล แล้วตัดสินใจ

result() เจาะลึก — คราวนี้เราใช้ scores กับ latency

result() คืน dict เดิมจาก บทเรียน 1.1–1.3 แต่ชุดบทเรียนนี้เราจะใช้ฟิลด์ให้ครบขึ้น โดยเฉพาะ scores (ทุกคลาส) และ latency_ms

r = edge_ai.result()
# {'index': 3, 'label': 'cough', 'top': 1, 'conf': 0.88,
#  'scores': [0.12, 0.88], 'latency_ms': 6.4, 'seq': 210, 'running': True}

ใน บทเรียน 1.1–1.3 เราสนใจแค่ label/conf — ชุดบทเรียนนี้ scores กับ latency_ms เลื่อนมาเป็นพระเอก เพราะแอปที่ดีต้องบอกผู้ใช้ได้ว่า "มั่นใจแค่ไหน" และ "เร็วแค่ไหน" ไม่ใช่แค่ "คืออะไร"

find_model() — เล็งด้วยคีย์เวิร์ด ไม่ hard-code index

หัวใจที่ทำให้แอปโฟกัส "ทน" คือไม่ผูกกับเลข index ตายตัว เราค้นทะเบียนจากชื่อแทน แบบเดียวกับตัวอย่าง 13–16

def find_model(keywords, sensor):
    ms = edge_ai.models()
    for m in ms:                       # 1) ลองจับชื่อก่อน
        for k in keywords:
            if k.lower() in m['name'].lower():
                return m
    for m in ms:                       # 2) ไม่เจอชื่อ -> ใช้เซนเซอร์ที่ตรงกันตัวแรก
        if m['sensor'] == sensor:
            return m
    return ms[0]                       # 3) กันเหนียว -> ตัวแรกสุด

• ส่ง ("cough",) เข้าไป มันจะคืน dict ของโมเดล Cough ไม่ว่ามันจะอยู่ index เท่าไร
• ถ้าเฟิร์มแวร์สลับลำดับโมเดล หรือเพิ่ม/ลดโมเดล โค้ดนี้ยังหาถูกตัว — ต่างจาก select(3) ที่จะพังทันที
• มีสามชั้นถอยหลัง (ชื่อ → เซนเซอร์ → ตัวแรก) เพื่อให้แอป ไม่ crash แม้หาไม่เจอเป๊ะ

นี่คือนิสัยเดียวกับ บทเรียน 1.1–1.3 — "ถามฮาร์ดแวร์ อย่าเดา" แค่คราวนี้เราถามแบบเจาะจง "ขอโมเดลที่ชื่อมีคำว่า cough" แล้วปล่อยให้เฟิร์มแวร์ตอบว่ามันอยู่ตรงไหน

โครงของแอปโฟกัส

จับโครงให้ได้ก่อนดูโค้ดจริง แอปโฟกัสทุกตัวเดินตามห้าจังหวะนี้ — เป็นญาติสนิทของ "โครงร่วม" จาก บทเรียน 1.4–1.5 แต่ select ขยับมาอยู่ต้นเรื่อง

ต่างจากเมนู บทเรียน 1.1–1.3 ตรงที่ ไม่มีปุ่ม Load — select() อยู่ก่อนลูปเลย เพราะแอปโฟกัส "รู้ตั้งแต่เปิด" ว่าจะรันโมเดลอะไร ผู้ใช้ไม่ต้องเลือก

อ่าน scores ทุกคลาส — แถบต่อคลาส

scores คือหัวใจที่ทำให้ผู้ใช้ "เห็นความมั่นใจ" ไม่ใช่แค่คลาสเดียว เราวาดหนึ่งแถบต่อหนึ่งคลาส ตัวที่ชนะระบายเขียว

top = r['top']
for i, (lb, br) in enumerate(rows):
    if i < len(r['scores']):
        br.value(int(r['scores'][i] * 100))   # ความสูงของแถบ = คะแนนคลาสนั้น
        br.color(GREEN if i == top else DIM)   # คลาสที่ชนะ = เขียว, ที่เหลือ = จาง

• โมเดล Cough มีสองคลาส ['unlabelled', 'cough'] เราจึงเห็นสองแถบ ขยับสวนทางกัน
• เวลาไอชัดๆ แถบ cough จะพุ่งเข้าใกล้ 100% แถบ unlabelled จะยุบลง
• เวลาเงียบ/เสียงอื่น แถบสองอันจะ สูสี — นี่แหละคือตอนที่ conf ต่ำกว่า CONF_FLOOR

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

latency — เวลาอนุมานต่างกันตามเซนเซอร์

latency_ms คือเวลาที่ NPU ใช้อนุมานหนึ่งครั้ง แอปที่ดีควรโชว์ให้เห็น เพราะมันบอก "ความสด" ของคำตอบ

lat.text("latency: %.1f ms" % r['latency_ms'])

• โมเดลเสียง (Cough/Alarm/Siren) มักใช้เวลาต่างจากโมเดล IMU (Motion) เพราะขนาดอินพุตและสถาปัตยกรรมต่างกัน
• ตัวเลขนี้เล็ก (ไม่กี่ ms) เพราะมี Ethos-U55 ช่วยคูณเมทริกซ์ — ถ้าให้ CPU ทำเองจะช้ากว่าหลายเท่า
• ในงานจริง latency สำคัญมากกับงานที่ต้องตอบทันที (ตรวจการล้ม เสียงเตือน) — ช้าไปคือพลาดจังหวะ

ลองสังเกตในแล็บ: สลับระหว่างแอป Cough (ไมค์) กับตัวอย่าง 13 (IMU) แล้วเทียบ latency_ms คุณจะเห็นด้วยตาว่า "โมเดลคนละแบบ กินเวลาคนละอย่าง" — นี่คือข้อมูลที่วิศวกรใช้เลือกโมเดล

จาก verdict สู่ action — นับเมื่อข้าม CONF_FLOOR

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

is_target = (r['label'] == TARGET_CLASS
             and r['conf'] >= edge_ai.CONF_FLOOR)   # เชื่อก็ต่อเมื่อมั่นใจถึงเกณฑ์
if is_target and not was_target:                    # นับเฉพาะ "ขอบขาขึ้น"
    hits += 1
    hits_lbl.text(str(hits))
was_target = is_target

• เงื่อนไขมีสองส่วน: คลาสต้องเป็นเป้าหมาย และ conf ต้องถึง CONF_FLOOR — ถ้าปล่อยเงื่อนไข conf ทิ้ง ตัวนับจะเก็บ false positive เต็มไปหมด
• CONF_FLOOR เลื่อนสถานะจาก "ตัวเปลี่ยนสี" (บทเรียน 1.1–1.3) มาเป็น "ประตูของ action" จริง
• นี่คือหลักการเดียวกับทุก action ในโลก Edge AI: ตัดสินใจว่าจะเชื่อ verdict ไหม ก่อนลงมือ

action แรกของคุณคือการนับ — เล็กแต่จริง ในบทเรียน 6.3–6.4 เราจะเปลี่ยน hits += 1 เป็น "จุด RGB / เล่นเสียง / เขียน log" ด้วยโครงตัดสินใจอันเดียวกันนี้

คณิตเบื้องหลัง (1) — argmax เลือกคลาสที่ชนะ

โมเดลไม่ได้คืนแค่ "คลาสเดียว" แต่คืน scores เป็นคะแนนของทุกคลาส เราต้องเลือก "ตัวที่ชนะ" ออกมาหนึ่งตัว วิธีคิดคือหาตำแหน่งที่คะแนนสูงสุด:

$$\hat{y} \;=\; \arg\max_{i}\; s_i$$

โดยที่ $s = (s_0, s_1, \dots, s_{K-1})$ คือเวกเตอร์คะแนนของ $K$ คลาส และ $\hat{y}$ คือ index ของคลาสที่ชนะ (ในโค้ดคือ r['top'])

• $s_i$ — คะแนน (คล้ายความน่าจะเป็น) ของคลาสที่ $i$ รวมกันทุกคลาสได้ประมาณ 1
• $\arg\max$ — แปลว่า "เอา index ที่ทำให้ค่ามากที่สุด" ไม่ใช่ตัวเลขค่ามากที่สุด
• $\hat{y}$ — คลาสที่โมเดลเชียร์ที่สุด เราจึงระบายแถบของคลาสนี้เป็นสีเขียว

ตัวอย่างโมเดล Cough ที่มีสองคลาส ['unlabelled', 'cough']: ได้ $s = (0.12,\ 0.88)$ → $\hat{y}=1$ → คลาส cough ชนะ, และ conf ของผลนี้คือ $0.88$

argmax บอกแค่ "ใครชนะ" มันไม่เคยบอกว่า "ชนะขาดหรือชนะเฉียด" — เพราะแม้คะแนน $0.51$ ต่อ $0.49$ ก็ยังมีผู้ชนะ นั่นคือเหตุผลที่เราต้องดู conf ต่ออีกชั้นในสไลด์ถัดไป ก่อนจะเชื่อผล

คณิตเบื้องหลัง (2) — CONF_FLOOR ประตูของ action

เพราะ argmax เลือกผู้ชนะเสมอ แม้ตอนคะแนนสูสี เราจึงตั้ง "เส้นแบ่งความมั่นใจ" ไว้อีกชั้น ก่อนจะยอมนับ ความมั่นใจของผลก็คือคะแนนของตัวที่ชนะ:

$$\text{conf} \;=\; s_{\hat{y}} \;=\; \max_i\, s_i$$

$$\text{count} \;\Longleftarrow\; \big(\,\text{label} = \text{TARGET}\,\big)\ \wedge\ \big(\,\text{conf} \ge \tau\,\big), \qquad \tau = 0.50$$

• $\text{conf}$ — คะแนนของคลาสที่ชนะ (ตัวสูงสุด) ใช้เป็นค่าความมั่นใจ
• $\tau$ (อ่านว่า "เทา") — เกณฑ์ขั้นต่ำ คือ edge_ai.CONF_FLOOR = $0.50$ ในชุดบทเรียนนี้
• $\wedge$ — เครื่องหมาย "และ" ทั้งสองเงื่อนไขต้องจริง พร้อมกัน จึงจะนับ

ทำไมมันสำคัญกับชุดบทเรียนนี้: ถ้าไม่มี $\tau$ ทุกครั้งที่ cough แค่ชนะแบบ $0.51$ ต่อ $0.49$ ก็จะถูกนับ ตัวนับจะเฟ้อไปด้วย false positive การใส่ $\tau$ คือการเขียนกฎว่า "เชื่อก็ต่อเมื่อมั่นใจถึงเกณฑ์" ซึ่งเป็นหัวใจของการเปลี่ยน verdict ให้เป็น action

เลข $0.50$ ไม่ใช่ของศักดิ์สิทธิ์ — ตั้งสูง ($\tau=0.7$) ได้ความชัวร์แต่พลาดเสียงเบาๆ ตั้งต่ำ ($\tau=0.3$) จับได้ไวแต่ false positive เยอะ การเลือก $\tau$ คือการชั่งน้ำหนักสองอย่างนี้ให้เข้ากับงาน

ขอบขาขึ้น — ทำไมต้อง "not was_target"

ถ้านับทุกผลที่เข้าคลาสเป้าหมาย จะได้ตัวเลขเฟ้อมหาศาล เพราะไอหนึ่งครั้งกินเวลาหลายผลอนุมาน เราจึงนับเฉพาะ จังหวะที่เพิ่งเข้า

• was_target จำสถานะรอบก่อน เรานับเฉพาะตอน "รอบนี้เข้าเป้า แต่รอบก่อนยังไม่เข้า" (ขอบขาขึ้น false → true)
• ตราบใดที่เสียงยังดังค้างเหนือเกณฑ์ จะไม่นับซ้ำ ต้องตกลงต่ำกว่าเกณฑ์ก่อน แล้วขึ้นใหม่ถึงนับอีกครั้ง
• ในฉบับเต็ม (examples/) เราเสริม debounce เบาๆ อีกชั้น: ต้องเจอติดกันสองผลถึงนับ กันเสียงกระพริบชั่วขณะ

เทคนิค "ขอบขาขึ้น" นี้เหมือนกับการอ่านปุ่มกดในคอร์สอื่นเป๊ะ — เรานับ "การกด" หนึ่งครั้ง ไม่ใช่นับทุกมิลลิวินาทีที่นิ้วยังกดค้างอยู่

ข้อควรรู้ — Ready-Model แบบ eval มีขีดจำกัด

โมเดล Cough/Alarm/Siren เป็น DEEPCRAFT Ready-Model แบบ eval มีเงื่อนไขที่ต้องรู้ก่อนทดสอบ ไม่งั้นจะงงว่าทำไมผลหยุดนิ่ง

• Ready-Model แบบ eval จำกัดจำนวนครั้งการอนุมาน (inference count) ต่อการบูตหนึ่งครั้ง
• ถ้ารันนานๆ แล้วผลค้างนิ่ง (ตัวเลข seq ไม่ขยับ) นั่นแปลว่าถึงขีดจำกัดแล้ว — รีบูตบอร์ด จะรีเซ็ต
• นี่ไม่ใช่บั๊กในโค้ดเรา เป็นลักษณะของโมเดล eval ซึ่งเป็นของ Imagimob AB (บริษัทในเครือ Infineon) ใช้ได้เพื่อประเมินผลเท่านั้น ห้ามใช้เชิงพาณิชย์หรือแจกจ่ายต่อ

จุดนี้สำคัญเชิงวิศวกรรม: โมเดลที่ "ให้ลองฟรี" มักมีเงื่อนไขซ่อนอยู่ พอเราฝึกโมเดลเองได้ (โมดูล 5 (Training) ที่เพิ่งผ่านมา) เราก็หลุดจากข้อจำกัดนี้ — นี่คือเหตุผลหนึ่งที่คอร์สพาไปถึงการเทรนเอง