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

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

เราใช้แนว PRIMM เหมือนเดิม (Predict–Run–Investigate–Modify–Make) วันนี้ "ของที่ทำงานได้" คือกฎจำแนกความสบายที่ firmware แถมมาให้ (dsp.comfort_zone) เรารันมันก่อน เห็นมันตอบ comfortable / hot / humid แล้วค่อยถามว่า "มันรู้ได้ยังไงว่าตอนนี้ร้อน?"

ชุดบทเรียนนี้เราจะได้ classifier ตัวแรกของทั้งคอร์ส แต่มันยัง ไม่ใช่ ML เลย — เราเขียนเงื่อนไขทุกเส้นด้วยมือ พอเข้าใจของมือแล้ว ตอนขึ้น ML คุณจะเห็นชัดว่าโมเดต่างจากกฎมือตรงไหน

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

ต่อจาก บทเรียน 3.1–3.2 ที่เราแปลงสัญญาณดิบเป็นค่าฟิสิกส์ วันนี้เราเดินอีกก้าวในขั้น Processing:

1. Classifier คืออะไร — จากค่าตัวเลข ออกมาเป็น "คลาส" (ป้ายชื่อ) ได้ยังไง
2. ค่าอนุพัทธ์ (derived metrics) — dsp.dew_point และ dsp.heat_index แปลง temp+humidity เป็นข้อมูลที่ "ตัดสินง่ายขึ้น"
3. ตรรกะเส้นแบ่ง (threshold logic) — เส้นแบ่งเดียว → บันไดกฎ (threshold ladder) หลายชั้น
4. กฎ vs ML — ทำไมเรียกวันนี้ว่า "ก่อน ML" และกฎมือมีจุดแข็ง/จุดอ่อนอะไร
5. ลงมือ: เขียน classify() ของตัวเอง ให้จอโชว์คำตัดสิน comfortable/hot/humid/... พร้อมสี

ปลายทางของวันนี้: บอร์ดอ่านอุณหภูมิ+ความชื้นจริง แล้วโชว์คำตัดสินเป็นคลาสที่เปลี่ยนตามอากาศตรงหน้า

วันนี้เน้น "ตัดสินใจด้วยกฎที่เราเข้าใจทุกบรรทัด" — ความเข้าใจนี้คือฐานที่ทำให้ ML ในบทเรียน 5.3–5.5 ไม่ใช่กล่องดำ

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

เรายังอยู่ที่ ขั้น 2 · Processing เหมือน บทเรียน 3.1–3.2 แต่ขยับจาก "แปลงค่า" มาเป็น "ตัดสินใจจากค่า"

น่าสนใจตรงที่ การจำแนก ปรากฏได้สองที่: ที่นี่ (ขั้น 2) ทำด้วยกฎมือ และที่ขั้น 4 ทำด้วย ML ที่เรียนเอง งานเดียวกัน คนละวิธีหาเส้นแบ่ง — วันนี้เราทำแบบแรกให้เข้าใจทะลุก่อน

Classifier คืออะไร

Classifier คือฟังก์ชันที่รับข้อมูลตัวเลขเข้าไป แล้วคายออกมาเป็น "คลาส" — ป้ายชื่อหนึ่งจากชุดที่กำหนดไว้

• คลาสของเราวันนี้: comfortable / hot / humid / cold / dry / danger — 6 ป้าย
• โมเดล DEEPCRAFT ในบทเรียน 1.1–1.3 ก็เป็น classifier (idle/circle/shaking) เพียงแต่ "ข้างใน" เป็น neural network
• เข้า-ออกเหมือนกันเป๊ะ นั่นคือเหตุผลที่กฎมือเป็นบันไดขั้นแรกสู่ ML ได้ดี

จำรูปนี้ไว้: ตัวเลข → กล่องตัดสิน → คลาส ทั้งคอร์สจะเจอกล่องนี้ซ้ำ วันนี้เราเปิดกล่องแล้วเขียนข้างในด้วยมือเอง

กฎ (rule-based) กับ ML — สองวิธีหาเส้นแบ่ง

งานจำแนกคือการ "ลากเส้นแบ่ง" ในพื้นที่ของค่า สองสำนักลากเส้นคนละวิธี:

อย่าเพิ่งด่ากฎมือว่าล้าสมัย ในงานจริงหลายอย่าง กฎ threshold ง่ายๆ ชนะ ML เพราะเบา อธิบายได้ ไม่ต้องมีข้อมูล วิศวกรเก่งคือคนที่รู้ว่าเมื่อไรควรใช้กฎ เมื่อไรควรใช้ ML — ชุดบทเรียนนี้ให้คุณรู้จักฝั่งกฎก่อน

ค่าอนุพัทธ์ (derived metrics) — ทำไมต้องแปลงก่อนตัดสิน

ค่าดิบบางทีตัดสินยาก อุณหภูมิ 32°C ตอนแห้งกับตอนชื้นจัด "รู้สึก" ต่างกันมาก ค่าอนุพัทธ์รวมหลายค่าดิบเป็นตัวเดียวที่ "ตัดสินง่ายขึ้น"

• ในโลก ML ขั้นแปลงค่าดิบให้ "ตัดสินง่ายขึ้น" นี้เรียกว่า feature engineering — dew point/heat index คือ feature ที่คนคิดสูตรไว้ให้แล้ว
• บทเรียน 4.5–4.6 เราจะทำ feature ที่ซับซ้อนกว่านี้ (spectrogram) วันนี้เริ่มจาก feature ที่มีสูตรตรงๆ ก่อน

บทเรียนสำคัญ: classifier จะดีแค่ไหน ขึ้นกับว่าเราป้อน "ค่าอะไร" ให้มัน ป้อนค่าดิบเปล่าๆ กฎอาจตัดสินพลาด แต่ป้อน heat index กฎจับ "ร้อนอบอ้าว" ได้แม่นขึ้นทันที

dew point — จุดน้ำค้าง

Dew point (จุดน้ำค้าง) คืออุณหภูมิที่อากาศชื้นจนไอน้ำเริ่มกลั่นเป็นหยดน้ำ ยิ่ง dew point สูงเทียบกับอุณหภูมิ อากาศยิ่ง "อึดอัดชื้น"

dsp.dew_point(t, rh) ใช้สูตร Magnus–Tetens คืนค่าเป็นองศาเซลเซียส:

$$\gamma = \frac{a\,t}{b+t} + \ln\!\left(\frac{\mathrm{RH}}{100}\right),\qquad T_{dew} = \frac{b\,\gamma}{a-\gamma}\quad (a=17.27,\; b=237.7)$$

import dsp
dp = dsp.dew_point(30.0, 75.0)   # ~25.1 C  ->  ชื้นมาก ใกล้อุณหภูมิจริง
dp = dsp.dew_point(30.0, 30.0)   # ~10.5 C  ->  แห้ง ห่างจากอุณหภูมิจริงเยอะ

• เราไม่ต้องจำสูตร แค่รู้ว่า dsp คำนวณให้ และ dew point ที่เข้าใกล้อุณหภูมิ = อากาศอิ่มตัว/ชื้นมาก
• เป็นตัวชี้ความชื้นที่ "ตรง" กว่า %RH เปล่าๆ เพราะ %RH เดียวกันที่คนละอุณหภูมิ ให้ความรู้สึกต่างกัน

ตัวเลขในคอมเมนต์ (~25.1 C) มาจากสูตรจริงในเฟิร์มแวร์ (moddsp.c) ไม่ใช่เดา — ลองเรียกใน REPL เทียบดูได้

อ่านสูตร dew point ทีละตัว (ไม่ต้องท่อง)

สูตร Magnus แบ่งเป็นสองก้าว: ก้าวแรกรวม t กับ RH เป็นตัวกลาง $\gamma$ (แกมมา) ก้าวสองแปลง $\gamma$ กลับเป็นอุณหภูมิจุดน้ำค้าง:

$$\gamma \;=\; \ln\!\left(\frac{\mathrm{RH}}{100}\right) + \frac{a\,t}{b+t}, \qquad T_{d} \;=\; \frac{b\,\gamma}{\,a-\gamma\,} \qquad (a=17.27,\; b=237.7)$$

อ่านทีละสัญลักษณ์แบบภาษาคน:

• $t$ — อุณหภูมิอากาศตอนนี้ (°C) อ่านจาก DPS368
• $\mathrm{RH}$ — ความชื้นสัมพัทธ์เป็นเปอร์เซ็นต์ (0–100) อ่านจาก SHT40
• $\gamma$ — ตัวกลางที่ไม่มีความหมายทางกายภาพตรงๆ เป็นแค่ "ขั้นพัก" ที่รวม $t$ กับ $\mathrm{RH}$ ให้อยู่ในรูปเดียวก่อนแปลงกลับ
• $a,\,b$ — ค่าคงที่ของสูตร Magnus (จูนไว้ให้เข้ากับพฤติกรรมไอน้ำในอากาศ) ไม่ต้องจำ dsp ใส่ให้แล้ว
• $T_{d}$ — คำตอบที่เราต้องการ: อุณหภูมิจุดน้ำค้าง (°C)

ทำไมต้องรู้แค่นี้ก็พอ: พจน์ $\ln(\mathrm{RH}/100)$ คือหัวใจ — ตอนอากาศชื้นจัด $\mathrm{RH}\to100$ ทำให้ $\ln(\mathrm{RH}/100)\to0$ (ค่าลบน้อยลง) $\gamma$ จึงโตขึ้น แล้วดัน $T_{d}$ ให้ เข้าใกล้ $t$ พอ $T_{d}$ เกือบเท่า $t$ = อากาศอิ่มตัว น้ำเริ่มกลั่น

นี่คือเหตุผลที่บันไดกฎวันนี้ดูที่ ระยะห่าง $t - T_{d}$ เป็นสัญญาณความชื้น: ห่างมาก = แห้งสบาย, ห่างน้อย = ชื้นอึดอัด สูตรทำงานหนักแทนเรา เราแค่เอา "ระยะห่าง" ไปตั้งเส้นแบ่ง

heat index — "รู้สึกเหมือน" ร้อนกว่าจริง

Heat index (ดัชนีความร้อน) รวมอุณหภูมิกับความชื้นเป็น "อุณหภูมิที่ร่างกายรู้สึก" ตอนชื้นจัด เหงื่อระเหยยาก เลยรู้สึกร้อนกว่าตัวเลขจริง

dsp.heat_index(t, rh) ใช้ Rothfusz regression คืนค่าเป็นองศาเซลเซียส:

import dsp
hi = dsp.heat_index(32.0, 40.0)   # ~32 C   -> ชื้นน้อย รู้สึกใกล้อุณหภูมิจริง
hi = dsp.heat_index(32.0, 80.0)   # ~44 C   -> ชื้นจัด รู้สึกร้อนกว่าจริง ~12 องศา

• อุณหภูมิดิบเท่ากัน (32°C) แต่ heat index ต่างกันราว 12 องศาเพราะความชื้น
• นี่คือเหตุผลที่บันไดกฎของเราตัดสิน "ร้อน/อันตราย" จาก heat index ไม่ใช่จากอุณหภูมิดิบ

สังเกตพลังของ derived metric: ถ้าเราจำแนกจากอุณหภูมิดิบอย่างเดียว จะพลาด "ร้อนอบอ้าวตอนชื้น" ทั้งที่มันคือภาวะอันตรายจริง — feature ที่ดีทำให้กฎง่ายๆ ฉลาดขึ้น

dsp มีอะไรให้ — สามฟังก์ชันสิ่งแวดล้อม

โมดูล dsp มีฟังก์ชันแปลงค่า+จำแนกสิ่งแวดล้อมสำเร็จรูปให้แล้ว ทั้งหมดเป็นคณิต/ฟิสิกส์ล้วน รันบน CM33 ไม่ใช้ NPU:

• สองตัวแรกคือ derived metric (แปลงค่า) · ตัวที่สามคือ classifier สำเร็จรูป (ตัดสินเป็นคลาส)
• dsp.comfort_zone คือ "ของที่ทำงานได้" ที่เราจะรันก่อน แล้วแกะ แล้วเขียนเวอร์ชันของเราเองแข่งกับมัน

เซนเซอร์ที่ป้อนค่าพวกนี้: DPS368 (ความดัน+อุณหภูมิ) กับ SHT40 (ความชื้น) — AI Kit มีทั้งคู่ Eva Kit ไม่มี ชุดบทเรียนนี้จึงรันบน AI Kit หรือ Emulator

แกะ dsp.comfort_zone — กฎที่ฝังในเฟิร์มแวร์

dsp.comfort_zone ที่เรารันตอนเปิดบทเรียน ข้างในมันคือ บันไดกฎ เขียนด้วย C — ไม่มี AI สักนิด เทียบเป็น Python ได้ประมาณนี้:

def comfort_zone(t, rh):          # กฎจริงใน moddsp.c (แปลงเป็น Python ให้อ่านง่าย)
    if t < 18:            return "cold"
    if t > 27:            return "hot"
    if rh < 30:           return "dry"
    if rh > 70:           return "humid"
    if 20 <= t <= 25 and 30 <= rh <= 60:
                          return "comfortable"
    return "acceptable"

• เห็นไหมว่ามันคือ if ไล่ทีละขั้น — นี่แหละบันไดกฎ ที่เราจะเขียนเองในไฟล์ฝึก
• มันตัดสินจาก ค่าดิบ (t, rh) ล้วน เราจะทำให้เวอร์ชันของเรา "ฉลาดขึ้น" ด้วยการใช้ heat index (derived) ด้วย

การ "แกะของสำเร็จรูปให้เห็นว่าข้างในไม่มีเวทมนตร์" คือหัวใจของการเรียนแบบกลับด้าน — พอเห็นว่ากฎนี้เป็นแค่ if ไม่กี่บรรทัด คุณจะกล้าเขียนของตัวเองทันที

threshold logic — เส้นแบ่งเดียว

หน่วยย่อยที่สุดของกฎคือ เส้นแบ่งเดียว (single threshold): ค่าหนึ่งค่าเทียบกับเลขหนึ่งเลข แล้วแบ่งโลกเป็นสองฝั่ง

if heat_index >= 32:
    verdict = "hot"          # ฝั่งเกินเส้น
else:
    verdict = "not hot"      # ฝั่งไม่ถึงเส้น

• เส้นแบ่งเดียวแบ่งได้แค่ 2 คลาส ถ้าอยากได้ 6 คลาส เราต้องวางเส้นหลายเส้น = บันไดกฎ
• ที่ตั้งเส้น (32) เรียกว่า hyperparameter ของกฎ — เราเลือกเอง จากความรู้/มาตรฐาน ไม่ได้เรียนจากข้อมูล

เก็บคำถามนี้ไว้: "ตั้งเส้นที่ 32 เอามาจากไหน?" ในกฎมือเราตอบได้ (มาตรฐาน heat index) แต่พอเป็น ML โมเดลจะหาเส้นเองจากข้อมูล — นั่นคือความต่างที่เราจะเห็นชัดในโมดูล 5 (Training)

บันไดกฎ (threshold ladder) — หลายเส้นต่อกัน

พอต้องการหลายคลาส เราเรียง if เป็นชั้นๆ ไล่จากบนลงล่าง ขั้นแรกที่เงื่อนไขจริงชนะทันที แล้ว return จบ:

def classify(t, h, hi):
    if hi >= 41:  return "danger"        # ชั้น 1 (อันตรายสุด อยู่บนสุด)
    if hi >= 32:  return "hot"           # ชั้น 2
    if h  >= 70:  return "humid"         # ชั้น 3
    if t  <  20:  return "cold"          # ชั้น 4
    if h  <  30:  return "dry"           # ชั้น 5
    return "comfortable"                 # ตกทุกชั้น = สบาย

• อ่านเป็นประโยค: "ถ้ารู้สึกร้อนถึงขั้นอันตราย → danger ไม่งั้นถ้ารู้สึกร้อน → hot ไม่งั้นถ้าชื้น → humid ..."
• แต่ละ return ตัดจบทันที คลาสล่างๆ จะได้ก็ต่อเมื่อผ่านทุกชั้นบนมาแล้ว
• นี่คือ ช่องเติมหลักของชุดบทเรียนนี้ — งาน 30% ของคุณคือเขียนบันไดนี้เอง

บันไดกฎอ่านง่ายและ "อธิบายได้" ทุกคำตัดสิน แต่มีกับดักหนึ่งข้อที่ทำคนพลาดบ่อย — ลำดับของชั้น ไปดูหน้าถัดไป

ทำไม "ลำดับ" ของบันไดถึงสำคัญ

บันไดกฎ return ขั้นแรกที่เจอ ดังนั้นถ้าวางชั้นผิดลำดับ คลาสที่ควรชนะจะโดนชั้นบนแย่งไปก่อน

กฎเหล็ก: เงื่อนไขที่เฉพาะ/รุนแรงกว่าต้องอยู่บน เงื่อนไขกว้างต้องอยู่ล่าง ถ้าวางสลับ ชั้นล่างจะกลายเป็น "โค้ดที่ไม่มีวันทำงาน" (dead branch) — บั๊กชนิดที่ compiler ไม่เตือน ต้องจับด้วยการทดสอบ