วิธีเลือกตัวชี้วัดประเมิน Neural Network ให้เหมาะกับงานและงบประมาณระบบ AI

การวัดผล Neural Network ไม่ควรดู Accuracy เพียงค่าเดียว เพราะข้อมูลที่แต่ละคลาสมีจำนวนต่างกันอาจทำให้ตัวเลขนี้ดูดีเกินความจริงได้
ควรเลือกตัวชี้วัดจากต้นทุนของความผิดพลาด เช่น Precision เมื่อการแจ้งผลเกินสร้างภาระสูง หรือ Recall เมื่อการพลาดกรณีเป้าหมายมีความเสี่ยงมากกว่า
สำหรับงานจำแนกประเภท ให้ดู Precision, Recall, F1-score, AUC-ROC และ Confusion Matrix ร่วมกัน
สำหรับงานพยากรณ์ค่าต่อเนื่อง ให้เปรียบเทียบ MAE, MSE และ RMSE ตามลักษณะความคลาดเคลื่อนที่ธุรกิจรับได้
ก่อนเลือกแพลตฟอร์ม MLOps, Cloud GPU หรือบริการผู้เชี่ยวชาญ ควรกำหนด KPI และวิธีติดตามผลหลังใช้งานจริงก่อน
การตัดสินใจที่ดีจึงไม่ได้เริ่มจากเครื่องมือราคาแพง แต่เริ่มจากการรู้ว่าโมเดลผิดแบบใดแล้วกระทบงานมากที่สุด

ดูแบบรวดเร็ว

• Accuracy อย่างเดียวไม่พอ โดยเฉพาะเมื่อจำนวนข้อมูลของแต่ละคลาสไม่สมดุล
• ให้เลือก Precision หรือ Recall จากต้นทุนของ False Positive และ False Negative ในงานจริง
• คะแนนบนชุดทดสอบเป็นเพียงจุดเริ่มต้น ต้องตรวจข้อมูลใหม่และติดตามการเปลี่ยนแปลงของโมเดลหลังใช้งาน

ตัวชี้วัด	เหมาะกับงานแบบใด	ใช้ตอบคำถามอะไร	ข้อควรระวัง
Accuracy	งานจำแนกที่ข้อมูลแต่ละคลาสมีสัดส่วนใกล้เคียงกัน	ทำนายถูกทั้งหมดมากเพียงใด	อาจทำให้เข้าใจผิดเมื่อข้อมูลไม่สมดุล
Precision	ตรวจจับทุจริต คัดกรองลูกค้า หรือกรณีที่การแจ้งผิดสร้างภาระ	สิ่งที่โมเดลบอกว่าเป็นเป้าหมาย ถูกต้องแค่ไหน	Precision สูงไม่ได้แปลว่าค้นหากรณีเป้าหมายได้ครบ
Recall	งานที่ไม่ควรพลาดกรณีเป้าหมาย	โมเดลค้นหากรณีเป้าหมายได้ครบแค่ไหน	Recall สูงอาจมาพร้อมการแจ้งผลเกิน
F1-score	งานที่ต้องการสมดุลระหว่าง Precision และ Recall	สมดุลของความผิดพลาดสองด้านเป็นอย่างไร	ยังต้องตีความร่วมกับผลกระทบทางธุรกิจ
AUC-ROC	งานจำแนกที่ต้องเปรียบเทียบความสามารถในการแยกกลุ่มหลาย threshold	โมเดลแยกกลุ่มได้ดีเพียงใดใน threshold หลายระดับ	ไม่ควรใช้แทนการเลือก threshold สำหรับการใช้งานจริง
MAE	พยากรณ์ยอดขายหรือค่าต่อเนื่อง	ความคลาดเคลื่อนโดยเฉลี่ยมีขนาดเท่าใด	ต้องตีความร่วมกับหน่วยของค่าที่พยากรณ์
RMSE	งานพยากรณ์ที่ต้องให้ความสำคัญกับความผิดพลาดขนาดใหญ่	ความคลาดเคลื่อนรุนแรงส่งผลต่อคะแนนมากเพียงใด	อาจไวต่อค่าคลาดเคลื่อนขนาดใหญ่

สรุปเร็ว: ต้องวัด Neural Network ด้วยตัวชี้วัดที่สอดคล้องกับความเสี่ยงของงาน

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

Accuracy เหมาะกับกรณีใด และเมื่อใดที่ไม่ควรใช้เป็นตัวตัดสินเพียงค่าเดียว

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

ดังนั้น หากข้อมูลไม่สมดุล ควรดู Precision, Recall, F1-score และ Confusion Matrix ควบคู่กัน อย่าตัดสินใจนำโมเดลขึ้นระบบจาก Accuracy เพียงบรรทัดเดียวในรายงาน

เริ่มจากต้นทุนของ False Positive และ False Negative ก่อนเลือก KPI

False Positive คือโมเดลแจ้งว่าเป็นกรณีเป้าหมาย แต่ความจริงไม่ใช่ ส่วน False Negative คือโมเดลพลาดกรณีเป้าหมายจริง หากการแจ้งเตือนเกินทำให้ทีมบริการลูกค้าต้องตรวจสอบจำนวนมาก Precision มักมีความสำคัญขึ้น แต่หากการพลาดกรณีเป้าหมายสร้างความเสี่ยงสูง Recall อาจเป็น KPI หลัก

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

ตารางเปรียบเทียบตัวชี้วัดสำหรับงานจำแนกประเภทและงานพยากรณ์

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

Precision, Recall, F1-score และ AUC สำหรับ Classification

Precision ใช้ตอบว่าเมื่อโมเดลทำนายว่าเป็นคลาสเป้าหมายแล้ว ถูกจริงมากน้อยแค่ไหน Recall ใช้ตอบว่าในกลุ่มเป้าหมายจริง โมเดลค้นพบได้ครบเพียงใด ส่วน F1-score ช่วยมองสมดุลระหว่างสองค่านี้ โดยเหมาะเมื่อไม่ต้องการให้ความผิดพลาดด้านใดด้านหนึ่งถูกมองข้าม

AUC-ROC ใช้ประเมินความสามารถของโมเดลในการแยกกลุ่มภายใต้ค่า threshold หลายระดับ จึงมีประโยชน์ในการเปรียบเทียบโมเดลจำแนกประเภท แต่เมื่อจะใช้งานจริง ทีมยังต้องกำหนด threshold ที่สอดคล้องกับขั้นตอนปฏิบัติงานและต้นทุนของความผิดพลาดอยู่ดี

MAE, MSE และ RMSE สำหรับ Regression

งานพยากรณ์ยอดขาย ปริมาณความต้องการ หรือค่าต่อเนื่องอื่น ๆ นิยมใช้ MAE, MSE และ RMSE โดยแต่ละค่ามองความคลาดเคลื่อนต่างกัน MAE ช่วยดูขนาดความคลาดเคลื่อนโดยเฉลี่ย ขณะที่ MSE และ RMSE ให้ความสำคัญกับความคลาดเคลื่อนในรูปแบบที่ต่างออกไป

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

Confusion Matrix และค่า threshold ที่ควรตรวจสอบร่วมกัน

Confusion Matrix แสดงจำนวน True Positive, True Negative, False Positive และ False Negative จึงช่วยให้เห็นจุดผิดพลาดที่คะแนนเฉลี่ยอาจซ่อนอยู่ ให้ตรวจว่าความผิดพลาดเกิดกับกลุ่มใดบ่อย และผลกระทบของแต่ละช่องตรงกับสิ่งที่ทีมธุรกิจยอมรับได้หรือไม่

Threshold ไม่ใช่ค่าที่ตั้งแล้วจบ หากปรับให้โมเดลไวต่อการค้นหากรณีเป้าหมายมากขึ้น Recall อาจเปลี่ยนพร้อมกับจำนวนการแจ้งผลเกิน จึงควรทดลอง threshold บนชุด Validation และบันทึกเหตุผลของค่าที่เลือกไว้สำหรับการตรวจสอบภายหลัง

วิธีประเมินโมเดลอย่างเป็นขั้นตอนก่อนนำขึ้นระบบจริง

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

แยกชุด Train, Validation และ Test โดยไม่ปนเปื้อนข้อมูล

ชุด Train ใช้สร้างโมเดล ชุด Validation ใช้ช่วยปรับการตัดสินใจระหว่างพัฒนา และชุด Test ใช้ตรวจผลในขั้นประเมินสุดท้าย จุดสำคัญคือ ต้องป้องกัน Data Leakage หรือการที่ข้อมูลซึ่งไม่ควรรู้ล่วงหน้าหลุดเข้าไปมีอิทธิพลต่อการฝึกหรือการประเมิน

หากใช้ชุดทดสอบเดิมซ้ำเพื่อปรับโมเดล ผลที่ได้อาจดูดีเกินจริง เพราะการตัดสินใจพัฒนาเริ่มอิงกับชุดนั้นแล้ว ควรรักษาบทบาทของแต่ละชุดข้อมูลให้ชัดเจน

ตรวจสอบข้อมูลไม่สมดุลและเลือกวิธีรายงานผลที่เหมาะสม

เมื่อจำนวนตัวอย่างแต่ละคลาสต่างกันมาก รายงานควรแสดงมากกว่า Accuracy เช่น Precision, Recall, F1-score และ Confusion Matrix สำหรับงานจำแนกประเภท ควรรายงานผลให้ทีมเห็นว่าโมเดลทำงานกับคลาสเป้าหมายได้อย่างไร ไม่ใช่เห็นเพียงค่าเฉลี่ยรวม

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

ทดสอบกับข้อมูลใหม่และติดตาม Model Drift หลังเริ่มใช้งาน

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

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

ข้อผิดพลาดที่ทำให้คะแนนดีบนรายงานแต่ใช้จริงไม่ได้

ปัญหาส่วนใหญ่ไม่ได้เกิดจากเลือกโมเดลผิดเพียงอย่างเดียว แต่อาจเกิดจากวิธีอ่านคะแนน วิธีเลือก threshold และกระบวนการประเมินที่ไม่ตรงกับงานจริง

มองเฉพาะค่าเฉลี่ยจนไม่เห็นกลุ่มลูกค้าที่โมเดลทำงานผิดพลาด

ค่าเฉลี่ยรวมอาจปกปิดความผิดพลาดในกลุ่มข้อมูลบางส่วนได้ ให้แยกตรวจผลตามกลุ่มที่มีความหมายต่อบริการหรือรายได้ของธุรกิจ แล้วใช้ Confusion Matrix เพื่อดูชนิดของข้อผิดพลาด การรายงานแบบนี้ช่วยให้ทีมไม่สรุปเร็วเกินไปจากตัวเลขเดียว

ปรับ threshold โดยไม่คำนึงถึงผลกระทบด้านรายได้ ความเสี่ยง หรือบริการลูกค้า

การปรับ threshold เปลี่ยนจำนวน False Positive และ False Negative ได้โดยตรง หากไม่มีข้อตกลงเรื่องต้นทุนของความผิดพลาด ทีมอาจเลือกค่าที่คะแนนสวย แต่สร้างงานตรวจสอบเพิ่มหรือทำให้พลาดกรณีสำคัญ ควรจำลองผลกระทบเชิงกระบวนการก่อนกำหนดค่าใช้งาน

ใช้ข้อมูลทดสอบซ้ำเพื่อปรับโมเดลจนผลประเมินคลาดเคลื่อน

เมื่อทีมเปิดดูผลชุด Test แล้วนำข้อสังเกตไปปรับโมเดลซ้ำหลายรอบ ชุด Test จะไม่เป็นตัวแทนการประเมินสุดท้ายอย่างอิสระอีกต่อไป วิธีที่ปลอดภัยกว่าคือใช้ Validation สำหรับการปรับ และเก็บชุด Test ไว้ตรวจผลในช่วงที่พร้อมตัดสินใจจริง

เลือกแนวทางวัดผลตามขนาดทีม ข้อมูล และงบประมาณ

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

งานทดลองหรือทีมเล็ก: เริ่มจากไลบรารีวิเคราะห์ผลและแดชบอร์ดพื้นฐาน

ทีมขนาดเล็กอาจเริ่มจากไลบรารีวิเคราะห์ผลที่สร้างตารางตัวชี้วัดและ Confusion Matrix ได้ พร้อมแดชบอร์ดพื้นฐานสำหรับบันทึกผลทดลอง จุดสำคัญคือกำหนด KPI, ชุดข้อมูล และ threshold ให้เป็นระบบก่อน ไม่จำเป็นต้องใช้แพลตฟอร์มขนาดใหญ่ทันที

ระบบที่มีข้อมูลมาก: พิจารณา MLOps, การติดตามเวอร์ชัน และระบบมอนิเตอร์

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

งานความเสี่ยงสูง: กำหนดเกณฑ์ตรวจสอบและการทบทวนโดยผู้เชี่ยวชาญ

งานที่ความผิดพลาดมีผลกระทบสูงควรกำหนดเกณฑ์ตรวจสอบให้ชัดเจน ตั้งแต่ตัวชี้วัดขั้นต่ำ วิธีอนุมัติการเปลี่ยนโมเดล ไปจนถึงการทบทวนเมื่อผลมอนิเตอร์เปลี่ยนไป การใช้ผู้เชี่ยวชาญภายนอกอาจเหมาะเมื่อทีมยังขาดทักษะเฉพาะด้านหรือจำเป็นต้องเร่งวางกระบวนการ แต่ขอบเขตงานและเงื่อนไขบริการต้องตรวจสอบเป็นรายกรณี

เกณฑ์เลือกเครื่องมือและเปรียบเทียบความคุ้มค่าก่อนตัดสินใจ

การลงทุนในแพลตฟอร์ม AI ไม่ควรแยกจากแผนประเมินโมเดล เพราะค่าใช้จ่ายจริงไม่ได้มีเฉพาะการฝึก Neural Network แต่รวมถึงการจัดเก็บข้อมูล การรันโมเดล การติดตามผล และเวลาของทีม

เปรียบเทียบต้นทุน Cloud GPU, พื้นที่จัดเก็บข้อมูล และการรันโมเดล

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

เลือกเครื่องมือจากความสามารถด้าน Monitoring, Security, Integration และการขยายระบบ

แพลตฟอร์ม MLOps ที่เหมาะควรตอบคำถามพื้นฐานได้ว่า ติดตามตัวชี้วัดหลังใช้งานได้หรือไม่ ตรวจสอบเวอร์ชันโมเดลและข้อมูลได้หรือไม่ เชื่อมกับระบบเดิมได้อย่างไร และรองรับการขยายงานในอนาคตหรือไม่ ด้าน Security และสิทธิ์เข้าถึงข้อมูลควรได้รับการตรวจสอบให้ตรงกับข้อกำหนดขององค์กร

เช็กลิสต์ตัดสินใจระหว่างพัฒนาเอง ใช้แพลตฟอร์มสำเร็จรูป หรือจ้างผู้ให้บริการภายนอก

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

เกณฑ์การเลือกและสรุปเปรียบเทียบ

1. ระบุว่าความผิดพลาดแบบ False Positive หรือ False Negative แบบใดมีต้นทุนสูงกว่า

2. เลือก KPI หลักให้ตรงกับงาน แล้วรายงานตัวชี้วัดประกอบแทนการดู Accuracy ค่าเดียว

3. ตรวจ Data Leakage การแยก Train, Validation และ Test รวมถึงความไม่สมดุลของข้อมูล

4. ทดสอบ threshold ที่สะท้อนกระบวนการทำงานจริง ไม่ใช่เลือกจากคะแนนสูงสุดอย่างเดียว

5. เปรียบเทียบ MLOps, Cloud GPU และบริการผู้เชี่ยวชาญจากภาระงานมอนิเตอร์ การเชื่อมระบบ ความปลอดภัย และงบประมาณรวม

รายละเอียดฟีเจอร์ ราคา และเงื่อนไขของแพลตฟอร์ม AI ควรตรวจสอบจากหน้าทางการของผู้ให้บริการก่อนเลือกใช้งาน

บทส่งท้าย

เกณฑ์วัด Neural Network ที่ดีคือเกณฑ์ที่ทำให้ทีมเห็นความเสี่ยงจริง ไม่ใช่เพียงทำให้รายงานมีคะแนนสูง Accuracy ยังมีประโยชน์ แต่ควรใช้ร่วมกับตัวชี้วัดที่อธิบายลักษณะความผิดพลาดได้ชัดกว่า เมื่อกำหนด KPI, threshold และวิธีติดตามผลไว้ตั้งแต่ต้น การเลือกเครื่องมือและงบประมาณของระบบ AI จะมีเหตุผลมากขึ้น

ข้อมูลที่ควรรู้เพิ่มเติม

Confusion Matrix ช่วยแปลงคะแนนรวมให้กลายเป็นภาพของความผิดพลาดแต่ละประเภท

F1-score เหมาะสำหรับดูสมดุลของ Precision และ Recall แต่ไม่แทนการวิเคราะห์ผลกระทบทางธุรกิจ

Model Drift เป็นเหตุผลสำคัญที่ต้องติดตามผลหลังโมเดลเริ่มทำงานกับข้อมูลจริง

เครื่องมือที่เหมาะที่สุดอาจไม่ใช่เครื่องมือที่มีฟีเจอร์มากที่สุด แต่เป็นเครื่องมือที่ทีมใช้งานและตรวจสอบผลได้ต่อเนื่อง

ข้อควรระวังสำคัญ

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

คำถามที่พบบ่อย

Q1. Accuracy สูงหมายความว่า Neural Network ใช้งานจริงได้ดีเสมอหรือไม่?

A1. ไม่เสมอไป โดยเฉพาะเมื่อข้อมูลแต่ละคลาสไม่สมดุล Accuracy อาจสูงแม้โมเดลทำงานได้ไม่ดีสำหรับคลาสเป้าหมาย ควรดู Precision, Recall, F1-score และ Confusion Matrix ร่วมกัน

Q2. ระหว่าง Precision กับ Recall ควรให้ความสำคัญกับค่าใดมากกว่า?

A2. ขึ้นอยู่กับต้นทุนของความผิดพลาด หากการแจ้งผลเกินสร้างภาระมาก Precision อาจสำคัญกว่า หากการพลาดกรณีเป้าหมายมีความเสี่ยงมาก Recall อาจสำคัญกว่า

Q3. ทีมขนาดเล็กควรลงทุนในแพลตฟอร์ม MLOps ตั้งแต่เริ่มต้นหรือไม่?

A3. ไม่จำเป็นเสมอไป ทีมขนาดเล็กอาจเริ่มจากเครื่องมือวิเคราะห์ผลและแดชบอร์ดพื้นฐานก่อน แล้วพิจารณาแพลตฟอร์ม MLOps เมื่อจำนวนโมเดล ข้อมูล หรือความต้องการติดตามเวอร์ชันเพิ่มขึ้น