คู่มือเรียนและนำเสนอ: วิเคราะห์การยกเลิกการจองโรงแรมด้วย AI Studio

อัปเดตรอบ PMML และเว็บไซต์ (11 ตุลาคม 2026): ส่งออกด้วย Extension จริงและมีเว็บทดลองแล้ว อ่าน คู่มือส่งออกโมเดลและเว็บแบบละเอียด พร้อมภาพหน้าจอ กติกาค่าว่าง การตรวจผล และบทพูด สไลด์ฉบับล่าสุดอยู่ใน 02-Slides พร้อม Canva ฉบับ PMML และเว็บ ทุกคนที่มีลิงก์แก้ไขได้

ฉบับรวม 11 ตุลาคม 2026 — ใช้ผล AI Studio 2026.1.1 ชุดเดียวกับรายงาน 7 หน้าและสไลด์ล่าสุด 54 หน้า

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

ไฟล์นี้เป็นคู่มือฉบับละเอียดสำหรับเรียนและซ้อม ไม่ใช่รายงานหลักที่ต้องจำกัด 5–7 หน้า รายงาน PDF และ Word พร้อมแก้ไขจัดทำไว้แล้วในชุดส่ง ส่วนชื่อ รหัสนักศึกษา และหน้าที่ที่สมาชิกทำจริง ให้สมาชิกเติมเองตามที่ตกลงไว้

วิธีอ่านให้ได้ความรู้

  1. รอบแรก เข้าใจเรื่อง: อ่านบท 0–6 ตามลำดับ ดูคำถามของแต่ละขั้นและส่วน “สรุปเพื่อเรียนและพูดนำเสนอ” ก่อน อย่าเริ่มจากจำชื่อกล่องในโปรแกรม
  2. รอบสอง ทำตาม: เปิด AI Studio ควบคู่บท 8 ชี้ให้ได้ว่าข้อมูลไหลผ่านแต่ละกล่องอย่างไร แล้วเทียบจำนวนแถวกับหลักฐานที่แนบ
  3. รอบสาม ซ้อมอธิบาย: ปิดคำตอบในบท 9 แล้วลองพูดด้วยภาษาของตัวเอง หากตอบไม่ชัดให้ย้อนอ่านขั้นนั้น ใช้บทพูดเป็นแนวทาง ไม่ต้องท่องตามทุกคำ
  4. ก่อนพรีเซนต์: ใช้บท 10 จับคู่กับหน้าสไลด์ และเปิด บทพูดครบ 54 หน้า เมื่อต้องการซ้อมตามลำดับหน้า

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

สถานะงานที่ต้องเข้าใจตรงกัน

ส่วนงาน สิ่งที่มีหลักฐานแล้ว ขอบเขตที่ยังไม่ควรอ้าง
ข้อมูลและกระบวนการ นำเข้า H1/H2 ตรวจคุณภาพ เตรียมข้อมูล แบ่งเวลา และมีไฟล์ .rmp การมีไฟล์ไม่ยืนยันว่าสมาชิกทุกคนฝึกรันและอธิบายได้แล้ว
แบบจำลอง ฝึกต้นไม้จริง เลือกค่าด้วยชุดตรวจสอบ และประเมินชุดทดสอบ ไม่ใช่ผลทดลองใช้งานกับโรงแรมจริง
การใช้โมเดลซ้ำ บันทึก .ioo โหลดกลับโดยไม่ฝึกใหม่ และตรวจผลตรงกัน 40,687 รายการ สร้างเว็บ StaySignal และเผยแพร่แบบสาธารณะให้ทุกคนที่มีลิงก์ทดลองได้แล้ว ยังไม่ทดลองใช้กับโรงแรมจริง
เอกสาร รายงาน PDF 7 หน้า Word แก้ไขได้ สไลด์ 54 หน้า และคู่มือนี้ ยังต้องเติมข้อมูลสมาชิกและส่ง Classroom โดยตัวแทนกลุ่ม

ผลสำคัญคือ Accuracy 64.45%, Precision 52.61%, Recall 81.80%, F1-Score 64.04% บนชุดทดสอบ 40,687 รายการ ผลรวมผ่านเกณฑ์เริ่มต้นของกลุ่ม แต่รีสอร์ตมี Precision 48.09% ต่ำกว่าเกณฑ์ 50% จึงต้องรายงานทั้งด้านที่ทำได้และด้านที่ยังไม่ผ่าน

อ่านคำตอบสำคัญก่อน

เราได้ไฟล์โมเดลจริงแล้ว คือ models/hotel-tree.ioo และโหลดกลับเข้า AI Studio โดยไม่ฝึกใหม่ได้ ผลตรงกับผลเดิมทั้ง 40,687 รายการ รอบล่าสุดส่งออก hotel-tree-native.pmml ด้วย Write PMML จริงแล้ว มี JSON สำหรับเว็บ StaySignal และสำเนา PMML 4.4 แยกจากไฟล์ดิบ อธิบายการบันทึกใน ขั้นที่ 4 และแนวทางเว็บไซต์ใน ขั้นที่ 6

ผลรวมผ่านเกณฑ์ที่กลุ่มกำหนด แต่ยังไม่เท่ากับพร้อมใช้งานจริง ตรวจพบรายการยกเลิกได้ 81.80% และรายการที่แจ้งเตือนยกเลิกจริง 52.61% ยังมีการแจ้งเตือนผิด 11,600 รายการ อีกทั้งข้อมูลเป็นของโรงแรมสองแห่งในอดีต และต้องตรวจเวลาที่รู้ข้อมูลก่อนนำไปใช้กับการจองที่ยังไม่จบ

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

## 0. อาจารย์ต้องการอะไร และเราทำอะไรจริง

ตรวจคำสั่งจาก การบ้าน/mini project (1).pdf ทั้ง 3 หน้าแล้ว อาจารย์ให้ทำกระบวนการ Cross-Industry Standard Process for Data Mining หรือกระบวนการมาตรฐานสำหรับงานเหมืองข้อมูล มี 6 ขั้นตอน ชื่อย่อคือ CRISP-DM ไม่ได้กำหนดให้ทุกงานต้องเริ่มด้วยโมเดล และไม่ได้ให้คะแนนจาก Accuracy สูงที่สุด

ข้อกำหนด คำตอบของโครงการ
ข้อมูลประมาณ 5,000 แถวขึ้นไป / อย่างน้อย 7 คอลัมน์ 119,390 รายการ; 31 คอลัมน์ต่อไฟล์ต้นฉบับ และเพิ่มประเภทโรงแรมเป็น 32
อธิบายทุกคอลัมน์ที่ใช้ ตารางครบ 19 ตัวทำนายและเฉลยในข้อ 2.1
ไม่ใช้ตัวระบุบุคคลโดยตรง ไม่พบชื่อบุคคล โทรศัพท์ อีเมล หรือเลขเอกสารในคอลัมน์ที่ใช้; รหัสตัวแทน/บริษัทเป็นรหัสแทนชื่อและแปลงเป็นธง
มีเฉลยที่ตรงกับวิธี IsCanceled ใช้แบ่งยกเลิก/ไม่ยกเลิก
มีสิ่งที่ต้องเตรียมข้อมูล NA, NULL ต่างความหมาย, ช่องว่าง, หมวดไม่ทราบค่า, แถวเหมือนกัน และค่าที่ต้องตรวจ
ใช้เทคนิคเหมืองข้อมูลเพียงหนึ่งเทคนิค Decision Tree; ทดลองหลายค่าของต้นไม้ยังเป็นเทคนิคเดียว
กราฟสำรวจอย่างน้อย 2 ภาพ อัตรายกเลิกตามโรงแรม และการกระจายวันจองล่วงหน้า
ประเมินตามสายที่เลือก ข้อ 5.1 ตารางผลทำนาย และตัวชี้วัดทั้ง 4; ข้อ 5.2–5.3 ไม่ใช้กับงานนี้
กลยุทธ์อย่างน้อย 2 ข้อ จัดคิวติดตามการจอง และใช้ประกอบการวางแผนห้องพัก
ส่งรายงาน PDF 5–7 หน้า + ไฟล์รันได้ + สไลด์ จัดรายงาน PDF 7 หน้า, Word แก้ไขได้, สไลด์ 54 หน้า และชุดกระบวนการรันได้แล้ว; สมาชิกเติมข้อมูลส่วนตนก่อนส่ง
เปิดเผยการใช้ AI และหน้าที่สมาชิก ตัวอย่างคำเปิดเผยและตารางให้ตรวจงานจริงอยู่ท้ายเอกสาร

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

ภาพรวมทั้งหกขั้นตอน
ภาพรวมทั้งหกขั้นตอน

แยกหลักฐานสามประเภทให้ถูก

  1. ภาพโปรแกรมจริง: ชื่อไฟล์ลงท้าย native และภาพ process/results ใน assets เป็นภาพ AI Studio ที่เก็บไว้จากการทำงานจริง
  2. กราฟจากผลจริง: กราฟอัตรายกเลิก สถิติ และผลโมเดล วาดให้อ่านง่ายจาก CSV ที่ AI Studio ส่งออก ด้วย Python; ไม่ใช่ภาพแคปกราฟใน AI Studio
  3. แผนภาพอธิบาย: ภาพลำดับงาน ภาพความหมายค่าหาย และแนวทางเว็บไซต์ สร้างเพื่อช่วยสอน ไม่ใช่หลักฐานว่าได้เปิดใช้ระบบธุรกิจแล้ว

การฝึกต้นไม้และนำต้นไม้ไปทำนายทำใน AI Studio จริง การคำนวณสถิติตรวจซ้ำ การค้นหาจุดแจ้งเตือนจากผลชุดตรวจสอบ การทำกราฟ และการจัดเอกสารมี Python ช่วย การใช้ JavaScript ในชุดนี้มีไว้ตรวจและนำต้นไม้ที่ส่งออกไปใช้ต่อ ไม่ได้ฝึกโมเดลอีกแบบ

## 1. ความเข้าใจธุรกิจ — Business Understanding

1.1 ปัญหาทางธุรกิจ: จำนวนการจองไม่เท่ากับจำนวนเข้าพักจริง

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

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

คำถามโครงการ: ข้อมูลการจองย้อนหลังช่วยระบุรูปแบบของการจองที่มีแนวโน้มยกเลิก เพื่อพัฒนาระบบจัดคิวติดตามการจองได้หรือไม่?

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

1.2 เป้าหมายสองระดับ

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

หนึ่งหน่วยวิเคราะห์คือ หนึ่งรายการจอง ไม่ใช่หนึ่งคน ลูกค้าคนเดียวอาจมีหลายรายการ แต่ชุดข้อมูลไม่มีรหัสให้เราเชื่อมบุคคลได้ ตัวแปรเฉลยคือ IsCanceled: 1/true = ยกเลิก, 0/false = ไม่ยกเลิก

เมื่อตรวจร่วมกับสถานะสุดท้ายใน CSV พบว่า IsCanceled=1 ครอบคลุม Canceled 43,017 รายการ และ No-Show 1,207 รายการ รวม 44,224 รายการ ส่วน IsCanceled=0 ตรงกับ Check-Out 75,166 รายการ ดังนั้นคำว่า “ยกเลิก” ที่ย่อในงานนี้รวมกรณีไม่มาเข้าพักตามการจัดป้ายของชุดข้อมูลด้วย ตัวเลขนี้เป็นการตรวจไขว้จากไฟล์ ไม่ใช่การเดานิยามเพิ่ม

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

1.3 เกณฑ์ความสำเร็จที่กำหนดก่อนทดลองรอบ AI Studio

เกณฑ์ อธิบายด้วยภาษาง่าย
Recall ≥70% จากรายการที่ยกเลิกจริง 100 รายการ ต้องตรวจพบอย่างน้อย 70
Precision ≥50% รายการที่ระบบแจ้งเตือน อย่างน้อยครึ่งหนึ่งต้องยกเลิกจริง
Precision สูงกว่าอัตรายกเลิกของชุดทดสอบ คิวที่เลือกต้องตรงกลุ่มกว่าการแจ้งเตือนทุกการจอง
เสนอกลยุทธ์อย่างน้อย 2 ข้อ ระบุคนรับผิดชอบ วิธีทำ และตัวชี้วัดติดตามผล

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

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

สรุปเพื่อเรียนและพูดนำเสนอ — ขั้นที่ 1

เราทำอะไรไป: ระบุปัญหา ผู้ใช้ผล หน่วยวิเคราะห์ เป้าหมายสองระดับ และเกณฑ์ที่วัดได้ ก่อนเลือกค่าของโมเดลรอบ AI Studio

สิ่งที่ส่งต่อขั้นที่ 2: ต้องหาข้อมูลระดับรายการจองที่มีผลยกเลิกให้ตรวจย้อนหลังได้ และต้องเข้าใจว่าข้อมูลแต่ละช่องเกิดขึ้นเมื่อใด

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

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

## 2. ความเข้าใจข้อมูล — Data Understanding

2.1 ที่มา ขนาด ความหมาย และเวลาที่ข้อมูลสะท้อน

ใช้ข้อมูล Hotel booking demand datasets ของ Nuno António, Ana de Almeida และ Luís Nunes ตีพิมพ์ Data in Brief ปี 2019, เล่ม 22 หน้า 41–49, DOI 10.1016/j.dib.2018.11.126

  • บทความและคำอธิบายชุดข้อมูล
  • ไฟล์เสริม mmc2.zip จากระบบเผยแพร่ของ PubMed Central
  • แตกไฟล์แล้วใช้ H1.csv และ H2.csv; ไฟล์ที่ขึ้นต้น ._ เป็นไฟล์ประกอบของระบบ ไม่ใช่ตารางข้อมูลอีกชุด
  • H1 เป็นรีสอร์ตใน Algarve 40,060 รายการ; H2 เป็นโรงแรมใน Lisbon 79,330 รายการ ทั้งสองแห่งอยู่ในโปรตุเกส ไม่ใช่ข้อมูลโรงแรมไทย
  • วันเข้าพักที่ตรวจจากไฟล์อยู่ระหว่าง 1 กรกฎาคม 2015 ถึง 31 สิงหาคม 2017 ชุดทดสอบปี 2017 จึงครอบคลุมมกราคม–สิงหาคม ไม่ใช่ครบทั้งปี ต้องระวังการเทียบปีที่มีจำนวนเดือนต่างกัน
  • ต่อแถวทั้งสองไฟล์ เพิ่ม Hotel เพื่อจำแนกแหล่งที่มา ได้ 119,390 รายการ 32 คอลัมน์
  • เก็บต้นฉบับไว้ใน aistudioFolder/data/raw พร้อม source-manifest.json ระบุที่มาและค่าตรวจไฟล์ ไม่ต้องไปหาไฟล์ดัดแปลงจาก GitHub

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

พจนานุกรมข้อมูลที่เข้าแบบจำลอง

ชื่อช่อง อ่านว่าอะไร ชนิด / จุดที่ต้องเข้าใจ
LeadTime จองล่วงหน้าก่อนวันเข้าพักกี่วัน จำนวนวัน; ไม่ใช่จำนวนวันที่เหลือ ณ วันที่เปิดเว็บไซต์
StaysInWeekendNights จำนวนคืนวันเสาร์/อาทิตย์ที่จองหรือพัก จำนวนคืน
StaysInWeekNights จำนวนคืนวันจันทร์–ศุกร์ที่จองหรือพัก จำนวนคืน
Adults จำนวนผู้ใหญ่ จำนวนคน
Children จำนวนเด็ก จำนวนคน; 4 ช่องไม่ทราบค่าต้องจัดการ
Babies จำนวนทารก จำนวนคน; ศูนย์มีความหมาย
PreviousCancellations จำนวนการจองก่อนหน้าที่ถูกยกเลิกตามประวัติที่เชื่อมได้ หากไม่มีโปรไฟล์ลูกค้า ต้นฉบับกำหนดเป็น 0; อย่าแปลว่ารู้แน่ว่าไม่เคยยกเลิก
PreviousBookingsNotCanceled จำนวนการจองก่อนหน้าที่ไม่ยกเลิกตามประวัติที่เชื่อมได้ ไม่มีโปรไฟล์ก็กำหนด 0; ไม่ใช่จำนวนครั้งเข้าพักทั้งหมดที่พิสูจน์แล้ว
Hotel รีสอร์ต/โรงแรมในเมือง เพิ่มจากชื่อ H1/H2
ArrivalDateMonth เดือนเข้าพัก ข้อความ 12 เดือน; ไม่สมมติว่า December มากกว่า January ในเชิงปริมาณ
Meal รูปแบบอาหารที่จอง BB อาหารเช้า, HB เช้าและอีกหนึ่งมื้อ, FB สามมื้อ, SC/Undefined ไม่มีแพ็กเกจอาหาร
MarketSegment กลุ่มตลาดที่มาของการจอง เช่น Direct, Online TA, Offline TA/TO, Corporate, Groups; TA ตัวแทนท่องเที่ยว, TO ผู้จัดทัวร์
DistributionChannel ช่องทางจัดจำหน่ายการจอง เช่น Direct, TA/TO, Corporate, GDS; เป็นคนละมุมกับกลุ่มตลาด
IsRepeatedGuest ระบบเชื่อมว่าเป็นแขกที่เคยมีประวัติแล้วหรือไม่ รหัส 0/1 ไม่ใช่จำนวนครั้ง
ReservedRoomType รหัสประเภทห้องที่จอง A/B/… เป็นรหัสหมวด ไม่ทราบชื่อห้องจริง จึงไม่เรียงเป็นระดับราคา
CustomerType ประเภทของการจอง Contract มีสัญญาจัดสรร/สัญญาอื่น; Group ผูกกับกลุ่ม; Transient ไม่อยู่กลุ่ม/สัญญาและไม่ผูกกับรายการ transient อื่น; Transient-Party ผูกกับรายการ transient อื่นอย่างน้อยหนึ่งรายการ
ChildrenMissing เดิมจำนวนเด็กไม่ทราบค่าหรือไม่ สร้างใหม่ก่อนเติม: 1=เดิมหาย, 0=มีค่าเดิม
HasAgent มีตัวแทนการจองหรือไม่ สร้างจาก Agent; NULL=0, มีรหัส=1
HasCompany มีบริษัทเกี่ยวข้องกับการจอง/การชำระหรือไม่ สร้างจาก Company; NULL=0, มีรหัส=1

มี 19 ช่องสำหรับทำนาย และเฉลยอีก 1 ช่อง ตารางที่พร้อมฝึกจึงมี 20 คอลัมน์ บางช่องเป็นรหัสหมวดแต่สะกดด้วยตัวเลข ไม่ได้หมายความว่านำไปบวกลบหรือเฉลี่ยได้เสมอ

ช่องอื่นในต้นฉบับและการตัดสินใจของเรา

ช่อง ความหมาย ใช้อย่างไร/เหตุผลที่ไม่เข้าแบบจำลอง
IsCanceled ผลยกเลิก 1 หรือไม่ยกเลิก 0 เป็นเฉลย ไม่ให้เป็นคำใบ้ของตัวเอง
ArrivalDateYear ปีเข้าพัก แบ่งชุดตามเวลา
ArrivalDateWeekNumber / ArrivalDateDayOfMonth สัปดาห์ของปี / วันที่ของเดือนที่เข้าพัก ไม่เลือกในแบบจำลองนี้เพื่อลดรายละเอียดปฏิทินที่ซ้ำกัน; ไม่ใช่คำตอบรั่วโดยตัวมันเอง
Country ประเทศต้นทาง พบ NULL; ไม่เลือกใช้เพื่อลดความซับซ้อน ไม่ได้เติมประเทศ
AssignedRoomType ประเภทห้องที่จัดให้ อาจเปลี่ยนตามการปฏิบัติงาน ไม่เลือกเมื่อยังยืนยันเวลาที่รู้ค่าไม่ได้
BookingChanges จำนวนครั้งแก้ไขจนถึงเข้าพักหรือยกเลิก อาจรวมการเปลี่ยนแปลงหลังเวลาที่อยากทำนาย
DepositType ลักษณะเงินมัดจำ สร้างจากธุรกรรมก่อนมาถึงหรือยกเลิก; ต้องพิสูจน์ว่ารู้ ณ เวลาใช้งาน จึงไม่ใช้รอบนี้
Agent / Company รหัสตัวแทน / บริษัท ใช้เพียงว่ามีหรือไม่มี ไม่เฉลี่ยรหัสและไม่ถือ NULL เป็นข้อมูลหายทั้งหมด
DaysInWaitingList จำนวนวันที่รอการยืนยัน ไม่ใช้จนกว่าจะกำหนดเวลาประเมินและเวลาที่รู้ค่านี้ชัด
ADR ยอดธุรกรรมค่าที่พักหารจำนวนคืน ใช้สำรวจ แต่ไม่เข้าโมเดล ไม่ถือเป็นราคาที่รู้ตั้งแต่ตอนจองโดยอัตโนมัติ
RequiredCarParkingSpaces จำนวนที่จอดรถที่ขอ ไม่ใช้รอบนี้เนื่องจากยังไม่ยืนยันเวลาที่บันทึก/แก้ไข
TotalOfSpecialRequests จำนวนคำขอพิเศษ เหตุผลเรื่องเวลาบันทึกเช่นกัน
ReservationStatus สถานะสุดท้าย Canceled/Check-Out/No-Show เปิดเผยคำตอบ ไม่ให้เข้าแบบจำลอง
ReservationStatusDate วันที่บันทึกสถานะสุดท้าย ใช้ตรวจว่าเฉลยพร้อมก่อนวันฝึกเท่านั้น ไม่ส่งเข้าแบบจำลอง

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

2.2 สถิติพื้นฐาน: ต้องรู้ทั้งค่ากลางและการกระจาย

สำรวจข้อมูลปี 2015–2016 จำนวน 78,703 รายการ แยกจากปี 2017 ที่ใช้ทดสอบ ค่าเฉลี่ยคือผลรวมหารจำนวนข้อมูล มัธยฐานคือค่ากึ่งกลางเมื่อเรียงข้อมูล ส่วนเบี่ยงเบนมาตรฐานบอกว่าค่ากระจายห่างจากค่าเฉลี่ยมากเพียงใด เราใช้สูตรสำหรับตัวอย่างที่หารด้วย n−1

ตัวแปร ค่าที่ใช้คำนวณ เฉลี่ย มัธยฐาน ส่วนเบี่ยงเบนมาตรฐาน ต่ำสุด–สูงสุด
จองล่วงหน้า (วัน) 78,703 101.30 65 106.20 0–737
คืนวันธรรมดา 78,703 2.45 2 1.87 0–50
คืนสุดสัปดาห์ 78,703 0.90 1 0.99 0–19
ผู้ใหญ่ 78,703 1.85 2 0.62 0–55
เด็ก 78,699 0.09 0 0.38 0–10
ราคาเฉลี่ยต่อคืน ADR 78,703 95.21 89 48.31 0–5,400

จำนวนเด็กใช้ 78,699 ค่า เพราะไม่รวม 4 ช่องที่หายในการคำนวณสถิติก่อนเติม ค่าเฉลี่ยเด็ก 0.09 ไม่ได้หมายความว่ามีเด็กเป็นเศษคน แต่เป็นค่าเฉลี่ยต่อรายการจอง อย่าคำนวณค่าเฉลี่ยรหัสห้องหรือรหัสตัวแทนแล้วตีความเป็นปริมาณ

ระยะจองล่วงหน้าเฉลี่ย 101.30 วันสูงกว่ามัธยฐาน 65 วัน เพราะมีรายการจองล่วงหน้านานมากดึงค่าเฉลี่ยขึ้น ADR สูงสุด 5,400 ควรตรวจ แต่เราไม่มีหลักฐานว่าพิมพ์ผิดและไม่ได้ใช้ ADR ฝึกต้นไม้ จึงไม่แก้ตัวเลขโดยเดา

ตัวอย่างสอนที่ไม่ใช่ข้อมูลจริง: 1, 2, 3, 4, 100 มีค่าเฉลี่ย 22 แต่มัธยฐาน 3 ใช้อธิบายว่าทำไมต้องดูมากกว่าค่าเฉลี่ย โดยต้องบอกเสมอว่าเป็นตัวอย่างสมมติ

ภาพผลสำรวจจริงใน AI Studio
ภาพผลสำรวจจริงใน AI Studio

ภาพนี้เป็นหน้าผลสำรวจที่เก็บไว้ ไม่ได้แสดงตารางสถิติทั้งหมด หลักฐานตัวเลขครบอยู่ใน outputs/02-descriptive-statistics.csv

2.3 กราฟสำรวจอย่างน้อยสองภาพ พร้อมการตีความ

กราฟที่ 1: สัดส่วนยกเลิกของโรงแรมสองประเภท

อัตรายกเลิกแยกโรงแรม
อัตรายกเลิกแยกโรงแรม

แกนนอนคือประเภทโรงแรม แกนตั้งคือร้อยละการจองที่ยกเลิกภายในโรงแรมประเภทนั้น ข้อมูลพัฒนามี City Hotel 51,822 รายการ และ Resort Hotel 26,881 รายการ อัตรายกเลิกประมาณ 41.32% และ 26.29% ตามลำดับ

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

กราฟที่ 2: การกระจายจำนวนวันจองล่วงหน้า

การกระจายจำนวนวันจองล่วงหน้า
การกระจายจำนวนวันจองล่วงหน้า

แกนนอนคือจำนวนวันจองล่วงหน้า แกนตั้งคือจำนวนรายการในแต่ละช่วงวัน แท่งสูงอยู่ทางช่วงจองล่วงหน้าไม่นาน แต่มีหางยาวไปถึง 737 วัน สอดคล้องกับค่าเฉลี่ยที่สูงกว่ามัธยฐาน

สิ่งที่นำไปใช้คือไม่ตัดรายการจองล่วงหน้านานทิ้งเพียงเพราะห่างจากคนส่วนใหญ่ กราฟนี้ยังไม่ได้แยกยกเลิก/ไม่ยกเลิก จึงใช้ภาพนี้เพียงภาพเดียวสรุปว่า “ยิ่งจองนานยิ่งยกเลิก” ไม่ได้ ต้องดูผลที่จำแนกหรือกฎของต้นไม้เพิ่มเติม

ภาพช่วยอ่านคุณภาพข้อมูล

ความหมายของช่องที่ต้องจัดการ
ความหมายของช่องที่ต้องจัดการ

อย่ารวมทั้งสี่ช่องแล้วเรียกว่า missing จำนวนมากเหมือนกัน บางช่องไม่มีข้อมูลจริง แต่บางช่องมีคำตอบเชิงธุรกิจว่า “ไม่มี” อยู่แล้ว รายละเอียดและเหตุผลการจัดการอยู่ขั้นที่ 3

ปิดขั้นที่ 2 เมื่อ: บอกที่มา หน่วยวิเคราะห์ ความหมายคอลัมน์ ค่าเฉลี่ย/มัธยฐาน/การกระจาย และข้อสรุปจากกราฟได้ รวมทั้งรู้ว่าสิ่งใดยังสรุปไม่ได้

สรุปเพื่อเรียนและพูดนำเสนอ — ขั้นที่ 2

เราทำอะไรไป: อ่านบทความต้นฉบับ รวม H1/H2 ตรวจหน่วยของแต่ละช่อง คำนวณสถิติจากช่วงพัฒนา และสำรวจด้วยกราฟ ไม่ใช้กราฟอย่างเดียวแทนคำอธิบาย

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

บทพูดตัวอย่าง: “เราใช้ข้อมูลจากบทความ Hotel booking demand datasets มีสองโรงแรมรวม 119,390 รายการ หนึ่งแถวคือหนึ่งการจอง เมื่อสำรวจปี 2015–2016 พบว่าโรงแรมในเมืองมีอัตรายกเลิก 41.32% ส่วนรีสอร์ต 26.29% จึงต้องประเมินผลแยกโรงแรมด้วย อีกกราฟแสดงวันจองล่วงหน้า ค่าเฉลี่ยประมาณ 101 วัน แต่มากกว่าค่ากลาง 65 วัน เพราะมีการจองล่วงหน้านานมากบางรายการ ข้อมูลแบบนี้ทำให้เห็นว่าดูแค่ค่าเฉลี่ยตัวเดียวไม่พอ”

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

## 3. การเตรียมข้อมูล — Data Preparation

ขั้นนี้ได้คะแนน 25% จึงต้องตอบให้ครบว่า พบอะไร → หมายถึงอะไร → ทำอย่างไร → ทำไมเลือกวิธีนี้ → ตรวจผลอย่างไร → ยังเหลือข้อจำกัดอะไร การทำให้ช่อง Missing ในโปรแกรมเหลือศูนย์เพียงอย่างเดียวไม่แปลว่าเราเข้าใจข้อมูลหรือแก้ถูกแล้ว

3.0 นำเข้าให้ถูกก่อนทำความสะอาด

เปิด process 01-import-hotels.rmp ใน AI Studio: Read CSV ของ H1/H2 → Generate Attributes เพิ่ม Hotel → Append ต่อแถว → Write CSV เก็บผลรวม 01-combined-native.csv ต้องได้ 119,390 แถว 32 คอลัมน์

  • เลือกไฟล์จริงในช่อง csv_file หากขึ้น No input file defined หมายถึงยังไม่ระบุไฟล์/แหล่งข้อมูล ไม่ใช่ข้อมูลใหญ่เกินไป
  • ใช้ comma เป็นตัวคั่น อ่านบรรทัดแรกเป็นชื่อช่อง และตรวจชนิดแต่ละคอลัมน์
  • ข้อความผิดพลาด unparseable real number (NA) หมายถึงโปรแกรมกำลังอ่านคอลัมน์ตัวเลขแต่เจอข้อความ NA ไม่ได้บอกว่าจำนวนแถวเกินความสามารถของโปรแกรม
  • process นี้กำหนดชนิดข้อมูลชัด และยอมให้ค่าที่ไม่ตรงชนิดถูกอ่านเป็น missing จึงนำ NA ของ Children เข้ามาได้ แต่การตั้งค่านี้อาจกลืนข้อความผิดรูปแบบอื่นด้วย เราจึงเทียบผลส่งออกกับต้นฉบับทุกคอลัมน์ ไม่ใช่เปิดตัวเลือกแล้วเชื่อทันที
  • ถ้าดูไม่พบ missing ให้ดู Statistics ของคอลัมน์ Children หลังอ่านไฟล์ เพราะ NULL ของ Agent/Company ที่ยังเป็นข้อความจะถูกนับเป็นหมวดหนึ่ง ไม่ใช่ช่อง missing ของโปรแกรม

การตรวจต้นฉบับกับผลอ่านจริงผ่านแล้ว ดู outputs/VERIFICATION.json การอ่านสำเร็จเป็นเพียงขั้นแรก ยังต้องตีความแต่ละรหัสก่อนเปลี่ยนค่า

3.1 ข้อมูลหาย ข้อมูลเหมือนกัน และค่าที่น่าสงสัย

ตารางตรวจคุณภาพ: ระบุฐานนับให้ชัด

สิ่งที่พบ ปี 2015–2016: 78,703 แถว ทั้งหมด: 119,390 แถว วิธีใช้ตัวเลข
Children ไม่ทราบค่า 4 4 missing ของจำนวนเด็ก
Country เป็น NULL 405 488 ไม่มีประเทศให้ใช้
Agent เป็น NULL 10,676 16,340 ไม่มีตัวแทน ไม่ใช่ missing ที่ต้องเดาตัวแทน
Company เป็น NULL 74,216 112,593 ไม่มีบริษัทเกี่ยวข้อง
แถวเหมือนทุกช่องที่เกินแถวแรก หลังตัดช่องว่าง 22,999 31,994 จำนวนแถวเหมือนกัน ไม่ใช่จำนวนการบันทึกซ้ำที่พิสูจน์แล้ว
ผู้เข้าพักรวมเป็นศูนย์ 113 180 ตรวจ Adults+Children+Babies; ในการนับใช้ Children ที่หายเป็น 0 และเปิดเผยเงื่อนไขนี้
คืนเข้าพักรวมเป็นศูนย์ 571 715 ตรวจคืนวันธรรมดา+สุดสัปดาห์
ADR ติดลบ 0 1 พบในปีทดสอบภายหลัง ไม่ได้ใช้เลือกวิธีฝึก
MarketSegment = Undefined 2 2 เปลี่ยนชื่อเป็น Unknown
DistributionChannel = Undefined 5 5 เปลี่ยนชื่อเป็น Unknown

จำนวนปี 2017 ในการตรวจคุณภาพรวมเป็นข้อมูลตรวจภายหลัง ไม่ใช้ย้อนกลับไปปรับต้นไม้ที่ล็อกแล้ว กลุ่มปัญหาอาจทับซ้อนกัน จึงห้ามบวกทุกแถวในตารางแล้วบอกว่าเป็นจำนวน “รายการเสียทั้งหมด”

จำนวนค่าที่ต้องตีความในชุดสำรวจ 78,703 รายการ
จำนวนค่าที่ต้องตีความในชุดสำรวจ 78,703 รายการ

แกนนอนคือจำนวนรายการ ไม่ใช่ร้อยละ และใช้ชุดสำรวจปี 2015–2016 จำนวน 78,703 รายการ แท่ง Company ยาวมากเพราะรายการส่วนใหญ่ไม่มีบริษัทเกี่ยวข้อง จึงไม่ใช่หลักฐานว่าคอลัมน์นี้มีข้อมูลสูญหายกว่าเจ็ดหมื่นรายการ ส่วน Children มีเพียง 4 รายการ แท่งจึงแทบมองไม่เห็นบนสเกลเดียวกัน ต้องอ่านตัวเลขกำกับ ไม่สรุปว่ามีศูนย์รายการจากความยาวแท่งอย่างเดียว

กรณี A: Children = NA — ไม่ทราบ ไม่เท่ากับไม่มีเด็ก

พบอะไร: มี 4 รายการอ่านจำนวนเด็กเป็นตัวเลขไม่ได้ เพราะเป็น NA ข้อมูลพัฒนา 78,703 แถวจึงมีค่าที่ใช้คำนวณได้ 78,699 แถว

สาเหตุ: ยังยืนยันสาเหตุของ 4 รายการไม่ได้ บทความบอกว่าระบบต้นทางรับรองไม่มีข้อมูลหาย แต่ไฟล์ที่เราตรวจพบ NA จริง เป็นข้อสังเกตที่ต้องรายงาน ไม่แต่งคำอธิบายว่า “พนักงานลืมกรอก” หรือ “ลูกค้าไม่ยอมบอก” โดยไม่มีหลักฐาน

วิธีที่ทำจริง: สร้าง ChildrenMissing ก่อนแก้ Children จากนั้นเติม Children ที่หายเป็น 0 ด้วยกฎคงที่

ก่อน ChildrenMissing Children หลังจัดการ อ่านให้ถูก
NA 1 0 เดิมไม่ทราบค่า; ใช้ศูนย์แทนชั่วคราว
0 0 0 ต้นฉบับบอกว่าไม่มีเด็ก
2 0 2 ต้นฉบับบอกว่ามีเด็กสองคน

ใน Generate Attributes เรียงสูตรให้ธงมาก่อนการเติม:

ChildrenMissing = if(missing(Children),1,0)
Children = if(missing(Children),0,Children)

ทำไมเลือก: มีรายการหายน้อยและไม่ต้องลบทิ้งทั้งแถว การเก็บธงช่วยแยก “เดิมหาย” ออกจาก “เดิมเป็นศูนย์” ในตารางพร้อมฝึก การเติมศูนย์เป็นข้อสมมติของโครงการ ไม่ใช่การกู้ข้อมูลจริงกลับมา แม้ค่ามัธยฐานที่ตรวจได้เป็นศูนย์ เราไม่ได้อ้างว่าใช้กระบวนการเรียนรู้ median จาก train มาเติมในรอบนี้

ตรวจอย่างไร: จำนวน ChildrenMissing=1 ต้องตรงกับจำนวน Children ที่หายในข้อมูลก่อนเติม: 4 รายการในชุดสำรวจปี 2015–2016 และยังมี 4 รายการในชุดฝึกสุดท้าย 78,310 แถว ตรวจว่าแถวเดิมที่เป็น 0 หรือ 2 ไม่ถูกเปลี่ยน ชุดที่เลือกส่งเข้าโมเดลไม่มีช่องว่างที่อ่านไม่ได้แล้ว แต่ธงยังต้องอยู่

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

กรณี B: Agent / Company = NULL — คำตอบว่าไม่มีความเกี่ยวข้อง

บทความต้นฉบับอธิบายชัดว่า NULL ในช่องเหล่านี้หมายถึง not applicable เช่น ไม่มีตัวแทนทำรายการ จึงไม่ควรเปลี่ยนเป็น “ตัวแทนที่พบบ่อยที่สุด” เพราะจะสร้างประวัติที่ไม่จริง และไม่ควรเฉลี่ยรหัสตัวแทน 9 กับ 240 เพราะรหัสไม่ใช่ปริมาณ

สร้าง HasAgent = 0 เมื่อ Agent เป็น NULL และเป็น 1 เมื่อมีรหัส สร้าง HasCompany เช่นเดียวกัน ตัวอย่าง Agent=240 → HasAgent=1 แต่ไม่ได้แปลว่ามีตัวแทน 240 คน ส่วน Company=NULL → HasCompany=0 ไม่ได้แปลว่าข้อมูลบริษัทสูญหาย 74,216 รายการ

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

กรณี C: Country = NULL — ยังไม่ทราบประเทศ และเราไม่ใช้ช่องนี้

พบ 405 รายการในชุดพัฒนา ไม่แปลว่าเป็นประเทศชื่อ NULL และไม่ควรแทนด้วยประเทศที่พบมากที่สุดจนกลายเป็นการเดาข้อมูลส่วนบุคคล บทความกล่าวว่าบางข้อมูลด้านสัญชาติอาจทราบเมื่อเช็กอิน แต่ไม่ได้พิสูจน์ว่านี่เป็นสาเหตุของทั้ง 405 รายการ

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

กรณี D: คำว่า Undefined ต้องอ่านตามคอลัมน์

  • Meal: ต้นฉบับระบุ SC และ Undefined ว่าไม่มีแพ็กเกจอาหาร จึงรวมเป็น NoMeal ได้ ในชุดพัฒนามี SC 5,472 และ Undefined 756 รวม 6,228 รายการ
  • MarketSegment: Undefined ไม่ได้ระบุกลุ่มตลาดที่ทราบ จึงเปลี่ยนชื่อเป็น Unknown สำหรับ 2 รายการ ไม่จัดเข้ากลุ่ม Direct ตามการเดา
  • DistributionChannel: ทำเช่นเดียวกันสำหรับ 5 รายการ

เปลี่ยนชื่อ Undefined→Unknown ไม่ได้สร้างข้อมูลที่หายกลับมา เพียงเก็บหมวดที่อธิบายตรงขึ้น ส่วน Meal ต่างออกไป เพราะมีความหมาย “ไม่มีอาหาร” จากแหล่งข้อมูลรองรับ

กรณี E: ช่องว่างหัวท้าย — แก้รูปแบบ ไม่เปลี่ยนความหมาย

ใช้ trim กับข้อความ เช่น " BB " เป็น "BB" เพื่อไม่ให้โปรแกรมนับอาหารเช้าเป็นสองหมวด เราไม่ได้ลบช่องว่างภายในชื่อ Transient-Party หรือเปลี่ยนชื่อหมวดเองโดยไม่มีเหตุผล ทำก่อนนับแถวเหมือนกันและก่อนเทียบ NULL/Undefined เพื่อให้กฎทำงานตรงกัน

กรณี F: แถวเหมือนทุกช่อง — ทำไมไม่กดลบซ้ำทั้งหมด

การนับ 22,999 คือแถวที่มีค่าเหมือนแถวที่พบก่อนหน้าสักแถวทุกคอลัมน์หลังตัดช่องว่าง ไม่จำเป็นต้องอยู่ติดกัน โดยนับส่วนที่เกินแถวแรก เช่น ถ้ามีแถวเหมือนกัน 3 แถว จะนับเป็น 2 ไม่ใช่ 3 และไม่ใช่สองลูกค้าที่พิสูจน์แล้ว

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

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

กรณี G: ศูนย์และค่ามากผิดกลุ่ม — ไม่แก้ด้วยกฎเดียวทุกช่อง

LeadTime=0 อาจหมายถึงจองวันเดียวกับเข้าพัก Children=0 หมายถึงไม่มีเด็ก จึงไม่ควรแทนศูนย์ทั้งหมดเป็น missing รายการผู้เข้าพักรวมศูนย์หรือคืนรวมศูนย์น่าสงสัยกว่า แต่เราไม่มีหลักฐานว่าต้องเป็นข้อผิดพลาดทั้งหมด จึงเก็บไว้และเปิดเผยจำนวน

ผู้ใหญ่สูงสุด 55 หรือวันจองล่วงหน้าสูงสุด 737 อาจเป็นรายการกลุ่มหรือการจองไกลล่วงหน้า แต่เป็นเพียงความเป็นไปได้ ไม่ใช่สาเหตุที่เรายืนยันแล้ว ไม่ตัดปลายการกระจายทิ้งเพื่อให้กราฟดูสวย

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

3.2 แปลงข้อมูล เลือกตัวแปร และแบ่งเวลา

ทำจริงใน AI Studio ทีละกล่อง

เปิด 02-prepare-and-split.rmp:

  1. Read combined: อ่านตารางรวมที่ผ่านการตรวจนำเข้าแล้ว
  2. Clean text — Generate Attributes: ตัดช่องว่างข้อความ เพื่อให้หมวดและกฎเทียบค่าเหมือนกัน
  3. Create safe predictors — Generate Attributes: สร้างธงก่อนเติม Children, สร้าง HasAgent/HasCompany, รวมหมวดอาหาร, ตั้งชื่อ Unknown และสร้าง StatusKey จากวันที่สถานะ
  4. Copy for splits — Multiply: ส่งตารางเดียวกันไปแยกชุด ไม่ได้สร้างรายการเพิ่มในแต่ละชุดโดยไม่จำเป็น
  5. Filter train / validation / development / test — Filter Examples: แบ่งตามปี/เดือนและวันที่รู้สถานะ
  6. Select … — Select Attributes: เหลือ 19 ช่องทำนายและเฉลย เก็บวัน/สถานะที่ใช้กรองไว้นอกโมเดล
  7. Write … — Write CSV: บันทึกแต่ละชุดพร้อมใช้ในขั้นฝึกและตรวจผล
หน้ากระบวนการเตรียมข้อมูลจริง
หน้ากระบวนการเตรียมข้อมูลจริง

ชื่อกล่องในภาพเป็นชื่อที่ตั้งให้อ่านง่าย หน้าที่จริงอ้างอิงชนิด operator ด้านบน การที่ชื่อกล่องมีคำว่า safe ไม่ใช่หลักฐานว่าปลอดจากข้อมูลรั่วทั้งหมด ต้องตรวจเวลาข้อมูลตามที่อธิบายด้วย

ทำไมไม่ใส่คำตอบลงไปให้โมเดลดู

ถ้าให้ ReservationStatus=Canceled เป็นตัวทำนาย IsCanceled โมเดลอาจดูเก่งเพราะเห็นคำตอบ ไม่ได้ช่วยตัดสินใจก่อนรู้ผล เราจึงตัด ReservationStatus ออก ส่วน ReservationStatusDate ใช้ตรวจความพร้อมของเฉลยก่อนวันฝึกเท่านั้น

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

การแบ่งชุดที่ทำจริง

แผนภาพการแบ่งเวลา
แผนภาพการแบ่งเวลา
ชุด ใช้ทำอะไร เงื่อนไข จำนวน
ฝึกครั้งแรก ให้ต้นไม้เรียนรู้กฎ วันเข้าพักก่อน ต.ค. 2016 และสถานะก่อน 1 ต.ค. 2016 63,783
ตรวจสอบ เลือกขนาดต้นไม้และเกณฑ์แจ้งเตือน เข้าพัก ต.ค.–ธ.ค. 2016 และสถานะก่อน 1 ม.ค. 2017 14,124
พัฒนาสุดท้าย ฝึกต้นไม้ส่งมอบด้วยค่าที่เลือกแล้ว เข้าพัก 2015–2016 และสถานะก่อน 1 ม.ค. 2017 78,310
ทดสอบ วัดผลหลังล็อกวิธี เข้าพักปี 2017 40,687

ชุดสำรวจมี 78,703 แถว แต่ฝึกสุดท้ายใช้ 78,310 เพราะกัน 393 แถวที่เฉลยยังไม่พร้อมก่อนปี 2017 ออก Train+Validation=77,907 ไม่เท่ากับ 78,310 ต่าง 403 แถวเพราะขอบเขตวันที่รู้เฉลยของการฝึกช่วงแรกอยู่ก่อนกว่า ไม่ใช่แถวอ่านหาย

ไม่ได้ใช้การสุ่ม 80/20 เพราะต้องการฝึกด้วยช่วงก่อนและประเมินช่วงหลัง สัดส่วนสุดท้ายเป็นประมาณ 65.81% ฝึกและ 34.19% ทดสอบ เมื่อคิดบนแถวที่ใช้สองชุดจริง 118,997 แถว ไม่ได้กำหนดเปอร์เซ็นต์นั้นล่วงหน้า

ข้อจำกัดที่ต้องแจ้ง: ปี 2017 เคยถูกตรวจในงาน RStudio ก่อนหน้า การไม่ใช้ปีนี้เลือกค่าภายในรอบ AI Studio เป็นสิ่งที่ทำได้ แต่ยังเรียกปีนี้ว่า “ข้อมูลใหม่ที่ไม่เคยเห็นเลยตลอดโครงการ” ไม่ได้ ควรมีปีหรือโรงแรมใหม่สำหรับการยืนยันอิสระ

แปลงเฉลยและกำหนดบทบาท

ก่อนฝึก ใช้ Numerical to Binominal กับ IsCanceled แล้ว Set Role เป็น label ให้โปรแกรมรู้ว่าช่องใดเป็นคำตอบ true คือยกเลิก ไม่เปลี่ยนหมายเลขรหัสห้องหรือรหัสตัวแทนให้กลายเป็นปริมาณเพื่อให้ดูเป็นตัวเลขทั้งหมด ต้นไม้ใน AI Studio รับตัวแปรหมวดได้

3.3 เหตุใดไม่ปรับสเกล

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

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

ตรวจจบขั้นที่ 3

ตารางพร้อมฝึก/ตรวจสอบ/ทดสอบอ่านได้ ไม่มีช่องว่างใน 20 คอลัมน์ที่เลือก จำนวนแถวตรงตามกฎ และไม่มี ReservationStatus/ReservationStatusDate เป็นตัวทำนาย การเติมค่าคงที่และเปลี่ยนชื่อหมวดเป็นกฎที่กำหนดไว้ ไม่ใช่ค่าสถิติที่เรียนจากปีทดสอบ หากในอนาคตใช้การเติม median หรือเรียนรู้การแปลง ต้องเรียนกฎนั้นจากชุดฝึกแล้วนำกฎเดิมไปใช้ชุดอื่น

สรุปเพื่อเรียนและพูดนำเสนอ — ขั้นที่ 3

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

สิ่งที่ส่งต่อขั้นที่ 4: ตาราง 4 ชุดที่ใช้บทบาทต่างกัน มีตัวทำนาย 19 ช่องและเฉลย 1 ช่อง พร้อมกฎเตรียมข้อมูลที่ต้องใช้เหมือนกันเมื่อเรียกโมเดล

บทพูดตัวอย่าง: “ขั้นนี้เราไม่ได้ใช้คำสั่งเติมค่าทุกช่องด้วยวิธีเดียว จำนวนเด็กที่เป็น NA หมายถึงไม่ทราบ จึงสร้าง ChildrenMissing ก่อนแล้วค่อยเติมศูนย์ แต่ NULL ของ Agent กับ Company หมายถึงไม่มีตัวแทนหรือบริษัท จึงแปลงเป็นมีหรือไม่มีแทน ส่วนแถวที่เหมือนกัน เรายังพิสูจน์ไม่ได้ว่าเป็นการบันทึกซ้ำ เพราะไม่มีรหัสการจอง จึงเก็บไว้และรายงานข้อจำกัด จากนั้นตัดข้อมูลสถานะสุดท้ายออกจากตัวทำนาย และแบ่งช่วงเวลาเพื่อให้ฝึกด้วยอดีตแล้วประเมินกับช่วงถัดไป”

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

ตรวจความเข้าใจ: ถ้าเติม Children ก่อนสร้าง ChildrenMissing ธงจะไม่รู้ว่าแถวใดเคยหาย เพราะ NA ถูกแทนแล้ว ลำดับการทำจึงสำคัญพอ ๆ กับสูตรที่ใช้

## 4. การสร้างแบบจำลอง — Modeling

4.1 เลือกต้นไม้ตัดสินใจ เพราะต้องทำนายและอธิบายกฎ

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

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

เรียนเพิ่ม: ต้นไม้เลือกคำถามอย่างไร

โปรแกรมลองแบ่งข้อมูลด้วยเงื่อนไขต่าง ๆ แล้วดูว่าหลังแบ่ง กลุ่มยกเลิกและไม่ยกเลิกแยกกันชัดขึ้นเพียงใด ค่า Gini ที่ใช้ในงานนี้คำนวณจาก 1 − (สัดส่วนยกเลิก² + สัดส่วนไม่ยกเลิก²) ค่ายิ่งต่ำหมายถึงข้อมูลในกลุ่มนั้นยิ่งเป็นประเภทเดียวกันมากขึ้น

ตัวอย่างสมมติเพื่อสอน ไม่ใช่ผลของชุดโรงแรม: มี 100 รายการ ยกเลิก 40 ไม่ยกเลิก 60 ก่อนแบ่งได้ Gini = 1 − (0.4² + 0.6²) = 0.48 สมมติคำถามหนึ่งแบ่งได้สองกลุ่ม กลุ่มละ 50 รายการ กลุ่มแรกยกเลิก 10/50 มี Gini 0.32 กลุ่มที่สองยกเลิก 30/50 มี Gini 0.48 ค่าเฉลี่ยถ่วงน้ำหนักหลังแบ่งเท่ากับ 0.5×0.32 + 0.5×0.48 = 0.40 ลดลงจากเดิม 0.08 โปรแกรมจึงเห็นว่าคำถามนี้ทำให้กลุ่มแยกชัดขึ้น แล้วต้องเปรียบเทียบกับคำถามอื่นภายใต้ค่าจำกัดที่ตั้งไว้

ต้นไม้ที่แตกกิ่งละเอียดมากอาจจำลักษณะเฉพาะของชุดฝึก จึงจำกัดความลึก ขนาดใบ และตัดแต่งกิ่ง จากนั้นใช้ชุดตรวจสอบดูว่าวิธีใดช่วยกับรายการที่ไม่ได้ใช้เรียนกฎ ไม่เลือกเพียงต้นที่ทำกับชุดฝึกได้คะแนนดีที่สุด

แยกการฝึกออกจากการเรียกใช้

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

4.2 ค่าที่ตั้งและวิธีเลือก

ค่าที่ตั้ง ความหมาย ทดลอง/ใช้จริง
criterion = gini_index วัดว่าหลังแบ่งกิ่ง กลุ่มปะปนยกเลิก/ไม่ยกเลิกน้อยลงเพียงใด ใช้ Gini
maximal_depth จำกัดจำนวนชั้นการตัดสินใจ ป้องกันกิ่งละเอียดเกิน ทดลอง 3, 5, 7; เลือก 5
minimal_leaf_size จำนวนรายการขั้นต่ำที่ยอมให้มีในใบ ทดลอง 100, 500; เลือก 100
minimal_size_for_split ต้องมีข้อมูลพอก่อนแบ่งต่อ สองเท่าของขนาดใบ; สุดท้าย 200
apply_pruning / prepruning ลดกิ่งที่ไม่ช่วยทั่วไป และหยุดแบ่งที่ไม่คุ้ม เปิดทั้งสอง
confidence ของการตัดแต่งกิ่ง ควบคุมวิธีตัดแต่งต้นไม้ของโปรแกรม 0.25
minimal_gain การปรับปรุงขั้นต่ำที่ยอมแบ่ง 0.001
prepruning alternatives จำนวนทางเลือกที่โปรแกรมตรวจ 3
เกณฑ์คะแนนเพื่อแจ้งเตือน คะแนนยกเลิกเท่าใดจึงจัดเข้าคิว ทดลอง 0.20–0.70 ทีละ 0.05; เลือก 0.25

เลข 0.25 มีสองหน้าที่ต่างกัน: confidence ในหน้าตั้งค่า Decision Tree ใช้กับการตัดแต่งกิ่ง ส่วน threshold=0.25 ใช้หลังทำนายเพื่อจัดคิวแจ้งเตือน ไม่ใช่การตั้งค่าเดียวกัน และไม่ใช่เป้าหมายความแม่นยำ 25%

ลำดับทดลอง:

  1. ใช้ชุดฝึก 63,783 รายการฝึกต้นไม้ 3 ระดับความลึก × 2 ขนาดใบ = 6 ต้นไม้
  2. Apply Model กับชุดตรวจสอบ 14,124 รายการ เก็บคะแนนยกเลิกของแต่ละรายการ
  3. เปรียบเทียบเกณฑ์แจ้งเตือน 11 ค่าในแต่ละต้นไม้ รวม 66 ทางเลือก การเปรียบเทียบนี้คำนวณจากผล AI Studio ด้วย Python
  4. เก็บตัวเลือกที่ Recall≥70%, Precision≥50% และ Precision สูงกว่าอัตรายกเลิกของชุดตรวจสอบ
  5. ในกลุ่มที่ผ่าน เลือก F1 สูงสุด หากเสมอเลือกต้นไม้ตื้นกว่า ใบใหญ่กว่า แล้วเกณฑ์ต่ำกว่า ตามกฎที่บันทึกไว้
  6. ล็อกความลึก 5, ใบขั้นต่ำ 100, เกณฑ์แจ้งเตือน 0.25 ใน 03-FROZEN-CHOICE.json
  7. ฝึกต้นไม้ใหม่ด้วยข้อมูลพัฒนาสุดท้าย 78,310 รายการ โดยใช้ค่าที่เลือกเดิม จากนั้นประเมินปี 2017 ครั้งสุดท้ายของกระบวนการนี้โดยไม่เปลี่ยนเกณฑ์ตามผลทดสอบ
กราฟเลือกเกณฑ์ด้วยชุดตรวจสอบ
กราฟเลือกเกณฑ์ด้วยชุดตรวจสอบ

กราฟใช้ชุดตรวจสอบเท่านั้น เส้น Recall และ Precision เปลี่ยนเมื่อขยับเกณฑ์ เพราะจำนวนรายการที่เข้าคิวเปลี่ยน ต้นไม้ให้คะแนนเป็นกลุ่มตามใบ จึงอาจมีช่วงที่ขยับเกณฑ์แล้วผลไม่เปลี่ยน ไม่ได้เป็นข้อผิดพลาดของกราฟ ค่าที่เลือกได้ Recall 75.20%, Precision 53.39%, F1 62.45% บนชุดตรวจสอบ

4.3 ต้นไม้ที่ได้และวิธีอ่าน

ต้นไม้จริงจาก AI Studio
ต้นไม้จริงจาก AI Studio
ภาพวาดต้นไม้จากกฎที่ส่งออก
ภาพวาดต้นไม้จากกฎที่ส่งออก

ภาพแรกเป็นโปรแกรมจริง ภาพที่สองวาดจากกฎเดียวกันให้อ่านโครงสร้างได้ ต้นไม้สุดท้ายมี 9 ใบ และใช้เพียง 4 ช่องแบ่งกิ่ง: PreviousCancellations, PreviousBookingsNotCanceled, LeadTime และ CustomerType การป้อน 19 ช่องไม่ได้แปลว่าต้นไม้ต้องใช้ทุกช่อง

เพื่อให้พรีเซนต์อ่านชัด อย่าขยายภาพรวมแล้วบังคับอ่านตัวเล็กทุกกิ่ง ให้แสดงภาพรวมหนึ่งหน้า และแยกตัวอย่างเส้นทางดังภาพนี้

ตัวอย่างสองเส้นทาง
ตัวอย่างสองเส้นทาง
เงื่อนไขของใบ ไม่ยกเลิกในข้อมูลฝึก ยกเลิกในข้อมูลฝึก คะแนนยกเลิก แจ้งเตือนที่ 0.25
PreviousCancellations>0.5; PreviousBookingsNotCanceled≤0.5 22 5,809 99.62% ใช่
เคยยกเลิก; เคยไม่ยกเลิก; LeadTime>13.5 50 56 52.83% ใช่
เคยยกเลิก; เคยไม่ยกเลิก; LeadTime≤13.5 240 29 10.78% ไม่
PreviousCancellations≤0.5; LeadTime≤25.5 19,993 3,474 14.80% ไม่
PreviousCancellations≤0.5; LeadTime>25.5; Contract 1,454 187 11.40% ไม่
เงื่อนไขก่อนหน้าแต่ Group 117 22 15.83% ไม่
เงื่อนไขก่อนหน้าแต่ Transient-Party 10,463 2,941 21.94% ไม่
PreviousCancellations≤0.5; Transient; 25.5<LeadTime≤257.5 17,127 12,842 42.85% ใช่
PreviousCancellations≤0.5; Transient; LeadTime>257.5 365 3,119 89.52% ใช่

คำว่า “เคยยกเลิก/เคยไม่ยกเลิก” ในตารางย่อจากค่าประวัติที่มากกว่า 0.5 ซึ่งเมื่อข้อมูลเป็นจำนวนเต็มคืออย่างน้อย 1 ไม่ใช่เศษครึ่งรายการ ส่วนค่าศูนย์อาจเกิดจากไม่มีโปรไฟล์ให้เชื่อม ต้องระวังการตีความประวัติ

คะแนนในใบ = จำนวนยกเลิกในใบ ÷ จำนวนทั้งหมดในใบ เช่น 12,842 ÷ 29,969 = 42.85% แม้คนส่วนใหญ่ในใบนี้ไม่ยกเลิก ต้นไม้ปกติจึงมีป้าย false แต่โครงการใช้คะแนน≥25% เพื่อแจ้งเตือน จึงจัดใบนี้เข้าคิวได้ นี่อธิบายว่าทำไมป้ายในภาพต้นไม้กับผลแจ้งเตือนบางรายการต่างกัน

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

4.4 เก็บโมเดลแล้วนำกลับมาใช้

ขั้นฝึกและเรียกใช้โมเดล
ขั้นฝึกและเรียกใช้โมเดล
  • .rmp บันทึกกล่องและลำดับการทำงาน ไม่ใช่ต้นไม้ที่ฝึกเสร็จโดยตัวมันเอง
  • .ioo บันทึกต้นไม้ที่ฝึกจริงด้วย Store to File + Write File
  • .pmml รอบล่าสุดส่งออกด้วย Write PMML ในโปรแกรมจริงเป็น hotel-tree-native.pmml ตรวจพบ PMML Extension 10.0.0 ติดตั้งอยู่แล้ว ข้อสรุปเดิมว่าไม่มีส่วนขยายไม่ถูกต้อง มีสำเนา PMML 4.4 แยกต่างหากเพื่อแก้ความไม่สอดคล้องของรุ่น/namespace ในไฟล์ดิบ โดยเก็บต้นฉบับไม่แก้
  • .json เก็บกฎและจำนวนในแต่ละใบ พร้อมเกณฑ์แจ้งเตือน ให้โปรแกรมเว็บคำนวณตามกฎจริงได้

ทดสอบกระบวนการ 08-load-saved-model.rmp ซึ่งไม่มี Decision Tree ฝึกใหม่แล้ว ผลคะแนนและผลแจ้งเตือนตรงกับเดิม 40,687/40,687 รายการ รายละเอียดข้อจำกัดและไฟล์อยู่ในเอกสารส่งต่อเว็บไซต์

สรุปเพื่อเรียนและพูดนำเสนอ — ขั้นที่ 4

เราทำอะไรไป: ใช้ต้นไม้ตัดสินใจเพียงเทคนิคเดียว ทดลองขนาดต้นไม้ 6 แบบ เปรียบเทียบเกณฑ์คะแนน 11 ค่า เลือกด้วยชุดตรวจสอบ ล็อกค่า ฝึกต้นไม้สุดท้าย และบันทึกต้นไม้ที่ใช้ซ้ำได้

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

บทพูดตัวอย่าง: “เราเลือกต้นไม้เพราะต้องการทั้งคำทำนายและเหตุผลที่ตามเส้นทางได้ ลองความลึก 3, 5 และ 7 จับคู่กับขนาดใบขั้นต่ำ 100 และ 500 รวมเป็น 6 ต้นไม้ แล้วใช้ชุดตรวจสอบเลือกเกณฑ์เข้าคิว ตัวเลือกสุดท้ายคือความลึกสูงสุด 5 ใบขั้นต่ำ 100 และคะแนนตั้งแต่ 0.25 ขึ้นไปเข้าคิว ต้นไม้สุดท้ายมี 9 ใบ ใช้แบ่งจริง 4 ช่องจาก 19 ช่องที่ป้อน และเราได้บันทึกโมเดลพร้อมทดลองโหลดกลับแล้ว”

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

## 5. การประเมินผล — Evaluation

5.1 ตารางผลทำนายและตัวชี้วัดทั้งสี่

ใช้ชุดทดสอบช่วงมกราคม–สิงหาคม 2017 จำนวน 40,687 รายการ กำหนด “ยกเลิก” เป็นเหตุการณ์ที่ต้องการตรวจพบ อ่านตารางจากแถวว่าความจริงเป็นอะไร และจากคอลัมน์ว่าระบบแจ้งอย่างไร

ความจริง / ผลแจ้งเตือน ไม่แจ้งว่าอาจยกเลิก แจ้งว่าอาจยกเลิก รวม
ไม่ยกเลิกจริง 13,342 (TN) 11,600 (FP) 24,942
ยกเลิกจริง 2,866 (FN) 12,879 (TP) 15,745
รวม 16,208 24,479 40,687

TP คือจับรายการยกเลิกได้ถูก, TN คือไม่แจ้งและไม่ยกเลิกจริง, FP คือแจ้งแต่ไม่ยกเลิกจริง, FN คือไม่แจ้งแต่ยกเลิกจริง ต้องอธิบายเป็นผลต่อการทำงาน ไม่ใช่ท่องตัวอักษรอย่างเดียว

ตารางสี่ช่องจากผลจริง
ตารางสี่ช่องจากผลจริง
ตัวชี้วัด วิธีคำนวณจากผลจริง ผล ความหมายในงานนี้
Accuracy (12,879+13,342) ÷ 40,687 64.45% ตัดสินถูกทั้งหมดเท่าไร
Precision 12,879 ÷ (12,879+11,600) 52.61% ในรายการที่แจ้งเตือน มีรายการยกเลิกจริงเท่าไร
Recall 12,879 ÷ (12,879+2,866) 81.80% ในรายการที่ยกเลิกจริง ตรวจพบเท่าไร
F1-Score 2×12,879 ÷ (2×12,879+11,600+2,866) 64.04% ค่ารวมที่สะท้อนทั้งความตรงของคิวและการตรวจพบ

Precision และ Recall ใช้ตัวหารคนละกลุ่ม อย่าอธิบาย Recall ว่า “แจ้งเตือน 100 คนแล้วถูก 82 คน” ประโยคนั้นเป็นความหมายของ Precision ซึ่งในงานนี้ประมาณ 53 คน จากรายการที่ยกเลิกจริง 100 รายการ เราจับได้ประมาณ 82 รายการ จึงเป็น Recall

ตัวชี้วัดจากผลทดสอบ
ตัวชี้วัดจากผลทดสอบ
ผล Performance ใน AI Studio
ผล Performance ใน AI Studio

หน้าจอจริงของ AI Studio อาจวางแนวตารางต่างจากกราฟที่วาดใหม่ ให้ดูป้าย actual/predicted ให้ตรงก่อนอ่าน ตัวเลขได้จาก Performance operator และคำนวณตรวจซ้ำจาก final-predictions.csv แล้วตรงกัน

ผ่านเป้าหมายอะไร และยังติดข้อจำกัดอะไร

Recall 81.80% ผ่าน 70%; Precision 52.61% ผ่าน 50%; อัตรายกเลิกจริงในชุดทดสอบเท่ากับ 15,745/40,687 = 38.70% จึงได้ Precision สูงกว่า 13.91 จุดเปอร์เซ็นต์ ไม่ใช่ “สูงขึ้น 13.91%” ในความหมายเพิ่มสัมพัทธ์

แต่แจ้งเตือน 24,479/40,687 = 60.16% ของรายการทั้งหมด ในคิวนั้น 11,600 รายการไม่ได้ยกเลิกจริง คิดเป็นประมาณ 47.39% ของคิว การผ่านเกณฑ์เชิงตัวเลขจึงไม่ได้พิสูจน์ว่าพนักงานมีเวลาติดตามทั้งหมดได้

ต้องเทียบกับวิธีง่าย เพื่อรู้ว่าโมเดลช่วยอะไร

วิธี Accuracy Precision Recall บทเรียน
บอกว่าไม่ยกเลิกทุกคน 61.30% คำนวณไม่ได้เพราะไม่มีรายการที่แจ้งเตือน 0% Accuracy ดูสูงได้โดยไม่ช่วยจับการยกเลิกเลย
แจ้งเตือนทุกคน 38.70% 38.70% 100% จับได้หมดแต่พนักงานต้องตรวจทุกแถว
ต้นไม้และเกณฑ์ 0.25 64.45% 52.61% 81.80% ลดคิวจากทุกคนและตรงกลุ่มขึ้น แต่ยังมีภาระงานมาก

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

ภาพรวมดีพอไม่ได้หมายความว่าทุกกลุ่มดีเท่ากัน

ประเมินแยกโรงแรม
ประเมินแยกโรงแรม
ประเภทโรงแรม จำนวนทดสอบ Recall Precision เทียบเกณฑ์เดียวกัน
City Hotel 27,508 84.25% 54.18% ผ่านทั้งสองค่า
Resort Hotel 13,179 74.72% 48.09% Precision ยังต่ำกว่า 50%

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

เหตุใดไม่ทำข้อ 5.2 และ 5.3

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

สิ่งที่ผลนี้ยังตอบไม่ได้

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

สรุปเพื่อเรียนและพูดนำเสนอ — ขั้นที่ 5

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

สิ่งที่ส่งต่อขั้นที่ 6: หลักฐานว่าคิวที่เลือกตรงกลุ่มขึ้น พร้อมจำนวนรายการที่ต้องติดตาม การแจ้งเตือนผิด และผลที่ยังไม่ผ่านในรีสอร์ต เพื่อออกแบบการใช้งานตามข้อจำกัดจริง

บทพูดตัวอย่าง: “ในชุดทดสอบ 40,687 รายการ เราจับรายการยกเลิกได้ 12,879 รายการ และพลาด 2,866 รายการ จึงได้ Recall 81.80% ถ้ามองจากคิวที่แจ้งเตือน มีรายการยกเลิกจริง 52.61% ซึ่งเป็น Precision ตัวเลขสองค่านี้ใช้ฐานคนละกลุ่ม ผลรวมผ่านเกณฑ์ของกลุ่ม แต่คิวยังใหญ่ถึง 60.16% และรีสอร์ตมี Precision 48.09% จึงยังไม่เหมาะที่จะบอกว่าใช้ได้ดีเท่ากันทุกโรงแรม”

แปลความผิดพลาดเป็นงานจริง: FP 11,600 คือรายการในข้อมูลทดสอบที่ถูกเลือกเข้าคิวแต่ไม่ได้ยกเลิก อาจเพิ่มงานติดตาม ส่วน FN 2,866 คือรายการที่ยกเลิกแต่ไม่ถูกเลือก จึงอาจพลาดการติดตาม ทั้งสองจำนวนเป็นผลย้อนหลัง ไม่ใช่จำนวนที่พนักงานโทรจริงแล้ว

## 6. การนำไปใช้งาน — Deployment

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

6.1 กลยุทธ์จากผลวิเคราะห์

กลยุทธ์ที่ 1: จัดคิวติดตามการจองที่ควรได้รับการยืนยันก่อน

หลักฐานที่รองรับ: คิวที่ต้นไม้เลือกมีการยกเลิกจริง 52.61% สูงกว่าคิวทุกคนที่ 38.70% และตรวจพบ 81.80% ของรายการยกเลิกทั้งหมด แต่คิวใหญ่ถึง 60.16% จึงต้องจำกัดงานตามกำลังพนักงาน

ผู้รับผิดชอบ: หัวหน้าฝ่ายสำรองห้องพักและพนักงานติดตาม

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

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

กลยุทธ์ที่ 2: ใช้ข้อมูลความเสี่ยงประกอบการทบทวนแผนห้องพัก

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

ผู้รับผิดชอบ: ผู้จัดการโรงแรมและฝ่ายบริหารรายได้

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

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

6.2 ข้อจำกัดและแผนต่อยอด

ข้อจำกัดที่พบ ผลต่อข้อสรุป งานเพิ่มที่ควรทำ
ปี 2015/2017 มีข้อมูลไม่ครบทุกเดือน ผลไม่ได้ครอบคลุมทุกฤดูกาลเท่ากัน ทดสอบช่วงเวลาใหม่ที่ครอบคลุมทั้งปี
สองโรงแรมในโปรตุเกส ช่วงอดีต ยังใช้แทนโรงแรมไทยหรือยุคปัจจุบันไม่ได้ ทดสอบข้อมูลใหม่และโรงแรมใหม่
จุดอ้างอิงหลายช่องคือวันก่อนเข้าพัก ไม่ใช่ข้อมูล ณ วันจองครั้งแรก สร้างข้อมูล ณ เวลาตัดสินใจจริง และติดตามผลหลังเวลานั้น
บางรายการอาจยกเลิกก่อนจุดเวลาที่จะนำไปใช้ อาจกำลังจำแนกเรื่องที่รู้ผลแล้ว คัดเฉพาะการจองที่ยังเปิดอยู่ และนิยาม “ยกเลิกหลังจากให้คะแนน”
ประวัติเป็นศูนย์ได้เมื่อไม่มีโปรไฟล์ ไม่ได้พิสูจน์ว่าไม่มีประวัติยกเลิก แยกไม่พบประวัติออกจากประวัติศูนย์ หากต้นทางให้ข้อมูลได้
แถวเหมือนกันแต่ไม่มีรหัสการจอง ไม่แน่ว่าเป็นคนละรายการจริงหรือข้อมูลซ้ำ ขอรหัสและประวัติการนำเข้าหรือทดสอบความไวของผล
การเติม Children เป็นศูนย์ เป็นข้อสมมติ ไม่ได้รู้ค่าจริง เปรียบเทียบทางเลือกบนชุดตรวจสอบในรอบใหม่
รีสอร์ต Precision 48.09% ผลเฉพาะกลุ่มยังไม่ผ่าน ตรวจแยกกลุ่มด้วยข้อมูลใหม่ก่อนใช้งาน
คะแนนจากใบยังไม่ตรวจความตรงของโอกาสจริง ไม่ควรสัญญาเป็นโอกาสเฉพาะบุคคล ตรวจความตรงของคะแนน/ความถี่ในข้อมูลใหม่
ปี 2017 เคยเห็นในงาน R ก่อนหน้า ไม่ใช่การยืนยันด้วยข้อมูลใหม่เต็มรูปแบบ เก็บช่วงเวลาหรือโรงแรมที่ไม่เคยใช้มาก่อน
ยังไม่ทดลองติดต่อจริง ยังพิสูจน์การลดการยกเลิกหรือรายได้ไม่ได้ ทดลองใช้งานและมีกลุ่มเปรียบเทียบ

6.3 จากไฟล์โมเดลไปสู่เว็บไซต์

แนวทางเว็บไซต์
แนวทางเว็บไซต์

เว็บไซต์ควรรับข้อมูลที่กำหนด ตรวจว่าครบและอยู่ในรูปแบบที่รองรับ คำนวณตามต้นไม้ที่บันทึกไว้ แล้วแสดงผลกับเหตุผล ไม่ให้ AI ภาษาคิดคะแนนเอง ชุดส่งต่อปัจจุบันมี PMML ดิบจาก Write PMML จริง JSON ตัวคำนวณ JavaScript สำเนา PMML 4.4 และตัวอย่างครบ 9 ใบ สร้างเว็บ StaySignal และเผยแพร่แบบสาธารณะให้ทุกคนที่มีลิงก์ทดลองได้แล้ว ยังไม่ได้ทดลองใช้กับโรงแรมจริง

ต้นไม้สุดท้ายใช้สี่ช่องจริง จึงสร้างตัวคำนวณสำหรับสี่ช่องได้ อย่างไรก็ตามกระบวนการ AI Studio เดิมมี 19 ช่องสำหรับฝึก หากฝึกต้นไม้ใหม่อาจเลือกช่องอื่น เว็บไซต์จึงต้องตรวจรุ่นโมเดลและปรับแบบฟอร์ม ไม่ควรถือว่าสี่ช่องนี้ใช้ได้ตลอดไป

สรุปเพื่อเรียนและพูดนำเสนอ — ขั้นที่ 6

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

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

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

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

## 7. เตรียมส่งงานและเตรียมตอบคำถาม

ไฟล์ที่จัดทำเสร็จแล้วและการใช้แต่ละไฟล์

ไฟล์/โฟลเดอร์ในชุดส่ง ใช้ทำอะไร ตรวจแล้วอย่างไร
01-Report / รายงาน PDF 7 หน้า ส่งตามความยาวที่อาจารย์กำหนด ตรวจจัดหน้าและรูปทั้ง 7 หน้า
01-Report / รายงาน Word แก้ข้อความ ตาราง และปรับข้อมูลสมาชิก ข้อความแก้ไขได้ ตารางจริง 11 ตาราง และกราฟ 3 ภาพ; ก่อนแก้มี 7 หน้า
02-Slides / PPTX และ PDF 54 หน้า คัดเนื้อหาพรีเซนต์และเปิดภาพชัดเจน ตรวจข้อความและภาพแสดงผล; ตัวเลขตรงรายงาน
03-AI-Studio ข้อมูลดิบ กระบวนการ โมเดล และผลทดลอง ตรวจการอ่าน เตรียมข้อมูล และโหลดโมเดลหลังย้ายโฟลเดอร์
04-Checks-and-Sources โจทย์และผลตรวจตามหัวข้อ ตารางเทียบข้อ 1.1–7.6
05-Learning คู่มือนี้ บทพูด ภาพ และหลักฐานย่อ ใช้เรียน ซ้อม และตรวจย้อนกลับ

รายงานที่ทำเสร็จจัดหน้าไว้ดังนี้: หน้า 1 ปัญหา เป้าหมาย เกณฑ์และสมาชิก; หน้า 2 ที่มาและพจนานุกรม; หน้า 3 สถิติกับกราฟสำรวจ; หน้า 4 เหตุผลเตรียมข้อมูล; หน้า 5 วิธีสร้างต้นไม้และกฎ; หน้า 6 ประเมินผล; หน้า 7 กลยุทธ์ ข้อจำกัด การใช้ AI และอ้างอิง

หากแก้ Word ให้ตรวจความยาวอีกครั้งก่อนบันทึกเป็น PDF เพราะการเพิ่มเนื้อหาอาจทำให้เกิน 7 หน้า โจทย์ไม่ได้ระบุเวลานำเสนอเป็นนาทีใน PDF ที่มี จึงควรถามเวลาเรียนหรือใช้นัดหมายที่อาจารย์แจ้ง ไม่ถือว่าสไลด์ 54 หน้าต้องพูดทั้งหมดทุกครั้ง

หน้าที่สมาชิก: ต้องตรวจจากสิ่งที่ทำจริงก่อนส่ง

ผู้ใช้ให้ชื่อ รหัสนักศึกษา และผู้รับผิดชอบหลักครบหกคนแล้ว ใส่ไว้ในรายงานหน้า 1 และสไลด์หน้า 52 ดู รายชื่อและขอบเขตหน้าที่ สมาชิกช่วยกันทำและตรวจงานร่วมกัน และยังต้องซ้อมอธิบายด้วยตนเอง

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

ข้อความเปิดเผยการใช้ AI ที่ให้กลุ่มตรวจตามจริง

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

ข้อความนี้ยังไม่อ้างว่าสมาชิกตรวจครบแล้ว หากใครยังไม่เข้าใจให้ใช้ คำถามซ้อมอธิบายในบท 9 แล้วแก้คำเปิดเผยตามงานที่ตรวจจริง

สรุปสุดท้ายสำหรับใช้หน้าจบ

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

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

## 8. เปิด AI Studio ทำตามทีละกระบวนการ

ในบทนี้ ชื่อ processes, outputs และ models หมายถึงโฟลเดอร์ย่อยใน 03-AI-Studio/full-study ของชุดส่งฉบับเต็ม ไม่ใช่โฟลเดอร์ที่ต้องสร้างข้างไฟล์คู่มือนี้

ใช้ AI Studio 2026.1.1 บน Mac เครื่องนี้ กระบวนการทุกไฟล์ที่กล่าวว่ารันสำเร็จมีผลและตารางตรวจใน outputs; ผลตรวจการรันหลังย้ายตำแหน่งไฟล์อยู่ใน 04-Checks-and-Sources/PACKAGE-CHECKS.json ที่โฟลเดอร์ชุดส่ง ภาพเก็บจากการรันเดิมในโปรแกรมจริง ส่วนไฟล์โมเดลที่เพิ่มรอบนี้ตรวจด้วยการรัน AI Studio แบบ batch และโหลดกลับ ไม่ได้อ้างว่าได้ถ่ายหน้าจอ GUI ใหม่ทุกไฟล์

เตรียมก่อนเปิด

  1. เปิด 03-AI-Studio/full-study แล้วคงโครงสร้าง processes, outputs, models ไว้ ข้อมูลต้นฉบับอยู่ 03-AI-Studio/data/raw
  2. หลังย้ายหรือแตก ZIP ใหม่ ตั้งตำแหน่งด้วย configure_paths.py ตาม README ใน 03-AI-Studio ก่อน หรือแก้ Parameters ของช่องอ่านและเขียนให้ชี้ไฟล์จริงทั้งหมด แล้วใน AI Studio ใช้เมนู File → Import Process… แล้วเลือกไฟล์ .rmp ตามลำดับด้านล่าง เมนูนี้ใช้เปิดงานในเครื่องนี้ได้จริง
  3. ก่อนกด Run เลือกกล่องอ่าน/เขียนไฟล์ ตรวจ path ใน Parameters ทางขวา ถ้าย้ายเครื่องต้องปรับ path ให้ชี้ไฟล์บนเครื่องใหม่
  4. ถ้ามีงานที่แก้ค้างไว้ ให้บันทึกเป็นชื่อใหม่ก่อนนำเข้ากระบวนการถัดไป ไม่ต้องเขียนทับไฟล์ต้นแบบเพื่อทดลอง
  5. อ่านคำอธิบายของขั้นนั้นใน บท 1–6 ของคู่มือฉบับนี้ ก่อนรัน การกดผ่านไม่เท่ากับเข้าใจเหตุผล

รู้จักหน้าต่างและเส้นเชื่อมก่อนกดรัน

  • Design: หน้าที่จัดกล่องและสายเชื่อม แต่ละกล่องทำงานหนึ่งอย่าง ชื่อที่เห็นอาจเป็นชื่อที่ผู้จัดทำตั้งเอง ให้ดูชนิด operator และ Parameters ด้วย
  • Results: หน้าผลหลังรัน Data แสดงรายการ, Statistics แสดงชนิดและสถิติ/ค่าหาย, Visualizations ใช้ดูกราฟของตารางที่เลือก
  • ExampleSet: ตารางข้อมูลที่ส่งระหว่างกล่อง; mod: โมเดล; lab: ตารางที่มีผลทำนาย; per: ผลประเมิน การอ่านเส้นเชื่อมสำคัญกว่าตำแหน่งซ้ายขวาของกล่อง
  • Read CSV อ่านตาราง, Generate Attributes สร้าง/แก้ช่องตามสูตร, Filter Examples เลือกแถว, Select Attributes เลือกคอลัมน์ อย่าสับสนการกรองแถวกับการตัดช่อง
  • Decision Tree เรียนกฎจากชุดฝึก, Apply Model ใช้กฎกับอีกชุด, Performance เปรียบเทียบผลทำนายกับเฉลย

ลำดับอ่านบทเรียนกับลำดับรันไฟล์ต่างกันได้

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

  1. ตั้ง path → 01-import-hotels.rmp → 02-prepare-and-split.rmp
  2. prepare_eda.py → 03-explore-data.rmp เพื่อให้ตารางประกอบการสำรวจมีครบ
  3. ต้นไม้ทั้ง 6 ไฟล์ → evaluate_exports.py เพื่อเปรียบเทียบ validation → build_final.py เพื่อใช้ค่าที่เลือก
  4. final.rmp → evaluate_exports.py --test เพื่อสรุปผลที่ล็อกแล้ว
  5. build_model_export.py → 07-export-native-model.rmp → 08-load-saved-model.rmp
  6. รอบล่าสุดใช้ 09-export-pmml-native.rmp ส่งออกด้วย Extension แล้วอ่านคู่มือ PMML–เว็บไซต์เพื่อแปลงและตรวจผล; export_portable_model.py เป็นเส้นทางแปลงจาก .ioo ของรอบก่อน

run_core.py จัดลำดับเหล่านี้ให้และเรียก AI Studio ฝึกต้นไม้จริง ผู้เริ่มต้นให้ใช้สำเนาชุดงานและเริ่มจากเปิดโมเดลที่บันทึกแล้วก่อน ไม่จำเป็นต้องรันทุกการทดลองใหม่เพื่ออ่านคู่มือ

รอบที่ 1 — นำเข้าและตรวจจำนวน

ไฟล์ processes/01-import-hotels.rmp

เดินตามสาย H1: Read CSV → เพิ่ม Hotel=Resort Hotel และสาย H2: Read CSV → เพิ่ม Hotel=City Hotel จากนั้น Append ต่อแถว → Write CSV

สิ่งที่ต้องดู: CSV separator เป็น comma; แถวแรกเป็นชื่อช่อง; Children อ่าน NA เป็น missing ได้; ผลรวม 119,390 แถว 32 คอลัมน์; ชื่อ Hotel ตรงกับ H1/H2

ผลที่เก็บ: outputs/01-combined-native.csv ห้ามใช้ไฟล์ ._H1.csv หรือ ._H2.csv ที่เป็นไฟล์ประกอบของระบบ

ถ้าขึ้น No input file defined ตรวจ csv_file ก่อน ถ้าขึ้น unparseable real number(NA) ตรวจชนิด Children และกฎอ่านค่าที่ไม่ตรงชนิด แล้วเทียบผลส่งออกกับต้นฉบับ อย่าเดาว่าเกิดจากแถวเยอะ

รอบที่ 2 — สำรวจอย่างมีคำถาม

ไฟล์ processes/03-explore-data.rmp ใช้ข้อมูลรวม เลือกปี 2015–2016 แล้วคำนวณข้อมูลประกอบการสำรวจ ควรมีไฟล์ผลเตรียม/ข้อมูลประกอบตามขั้นตอนของแพ็กเกจอยู่แล้ว หากสร้างใหม่ทั้งชุดให้ใช้ลำดับรันครบที่ท้ายเอกสาร

คำถามก่อนเปิดผล: หนึ่งแถวคืออะไร? โรงแรมไหนมีสัดส่วนยกเลิกมากกว่า? วันจองล่วงหน้ากระจายอย่างไร? ค่าเฉลี่ยต่างจากมัธยฐานเพราะอะไร? NULL แต่ละช่องมีความหมายเดียวกันหรือไม่?

กระบวนการสำรวจจริง
กระบวนการสำรวจจริง

สถิติฉบับครบอยู่ outputs/02-descriptive-statistics.csv และกราฟอ่านง่ายอยู่ assets/01-cancellation-by-hotel.png, 02-lead-time-distribution.png ภาพหน้าจอ Statistics ที่มีอยู่เป็นเพียงมุมหนึ่งของผล ไม่ใช่ตารางครบทุกตัวแปร

รอบที่ 3 — เตรียมข้อมูลและแบ่งชุด

ไฟล์ processes/02-prepare-and-split.rmp

กล่อง ทำอะไร ต้องตรวจอะไร
Read combined อ่านตารางรวม คอลัมน์และชนิดตรงต้นฉบับ
Clean text trim ข้อความ ไม่เปลี่ยนความหมายภายในชื่อ
Create safe predictors สร้างธง เติม Children เปลี่ยนหมวด และ StatusKey ChildrenMissing ต้องมาก่อนเติม; NULL ไม่เหมารวม
Copy for splits แยกสายข้อมูล แต่ละสายถูกกรองด้วยเงื่อนไขของตัวเอง
Filter train ก่อน ต.ค. 2016 + สถานะก่อน 1 ต.ค. 63,783 แถว
Filter validation ต.ค.–ธ.ค. 2016 + สถานะก่อน 2017 14,124 แถว
Filter development ก่อน 2017 + สถานะก่อน 2017 78,310 แถว
Filter test เข้าพักปี 2017 40,687 แถว
Select … เลือกเฉลยและ 19 ตัวทำนาย ไม่มีสถานะสุดท้ายเป็นตัวทำนาย
Write … บันทึก CSV แต่ละชุด ชื่อไฟล์ไม่สลับชุดกัน

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

รอบที่ 4 — ฝึกต้นไม้หลายค่าด้วยเทคนิคเดียว

ไฟล์ d3-l100.rmp, d3-l500.rmp, d5-l100.rmp, d5-l500.rmp, d7-l100.rmp, d7-l500.rmp

d หมายถึงความลึกสูงสุด l หมายถึงจำนวนขั้นต่ำในใบ ไม่ใช่ชื่อเทคนิคใหม่ เปิดแต่ละ process แล้วตรวจ Parameters ของ Decision Tree ให้ตรงชื่อ

  • สายฝึก: Read train → Numerical to Binominal(IsCanceled) → Set Role(label) → Decision Tree
  • สายตรวจสอบ: Read validation → แปลงเฉลยและตั้ง role → Apply Model รับโมเดลจากสายฝึก
  • ส่งออกคะแนนและต้นไม้ของแต่ละการทดลอง ห้ามเขียนผลทับกันโดยไม่ตั้งชื่อให้ต่าง
  • อ่าน confidence(true) เป็นคะแนนยกเลิกของต้นไม้ ยังไม่ใช่โอกาสจริงที่ตรวจความตรงแล้ว

ตาราง outputs/03-validation-search.csv เก็บ 66 ทางเลือก ขั้นคำนวณเปรียบเทียบคะแนนใช้ Python จากผลส่งออก ไม่ใช่ operator ฝึกโมเดลอีกชนิด เลือกค่าตามเกณฑ์ในคู่มือ ไม่กดเปลี่ยนจากผลทดสอบปี 2017

รอบที่ 5 — ฝึกสุดท้ายและประเมิน

ไฟล์ processes/final.rmp

  1. Read development ใช้ 78,310 แถว ตั้ง IsCanceled เป็น label
  2. Decision Tree ตั้ง depth=5, leaf=100 และค่าประกอบตามตารางในคู่มือ
  3. Read test ใช้ 40,687 แถว แล้ว Apply Model
  4. Frozen threshold แปลงคะแนนเป็นผลแจ้งเตือนด้วย 0.25
  5. Prediction role ตั้งช่องผลให้เป็น prediction
  6. Performance ตั้ง positive class=true เปิด Accuracy, Precision, Recall และ F1
  7. ตรวจตารางสี่ช่องและส่งออกผล
กระบวนการฝึกและประเมินจริง
กระบวนการฝึกและประเมินจริง

ค่าที่ควรได้: TP 12,879; FP 11,600; FN 2,866; TN 13,342 และ Recall 81.80% / Precision 52.61% ไม่เปลี่ยนตัวเลขให้ตรงเอกสารด้วยมือ หากต่างให้ตรวจไฟล์ชุดข้อมูล ค่าต้นไม้ และ threshold

รอบที่ 6 — บันทึกโมเดล

เปิด processes/07-export-native-model.rmp ใช้ต้นไม้แบบเดียวกับขั้นสุดท้ายแล้วต่อ Store to File → Write File ไป models/hotel-tree.ioo ตรวจ log ว่าทำสำเร็จและมีไฟล์ขนาดไม่เป็นศูนย์

การตั้งค่าหรือภาพของต้นไม้เพียงอย่างเดียวไม่ใช่การบันทึกโมเดล ต้องมีไฟล์ที่โหลดกลับได้

รอบที่ 7 — โหลดโมเดลเดิมเพื่อพิสูจน์ว่าใช้ซ้ำได้

เปิด processes/08-load-saved-model.rmp ตรวจว่า ไม่มีกล่อง Decision Tree ฝึกใหม่ มี Open File → Retrieve from File → Apply Model และเกณฑ์ 0.25

ผลเขียน outputs/reloaded-predictions.csv ตรวจเทียบกับ final-predictions.csv แล้วตรงทั้งหมด การรันไฟล์นี้ใหม่คือเรียกโมเดลเดิม ไม่ใช่ฝึกให้ได้ต้นไม้ใหม่หน้าตาคล้ายกัน

ถ้าต้องสร้างผลทั้งหมดใหม่

ใช้ configure_paths.py หลังย้ายโฟลเดอร์ แล้วใช้ full-study/run_core.py สำหรับรันกระบวนการหลักครบตั้งแต่ข้อมูลดิบและบันทึกโมเดล สคริปต์นี้เรียก AI Studio ให้ฝึกจริง ต้องมี Python pandas/numpy และ AI Studio ส่วน verify_portable_model.py ต้องมี Node.js และ lxml เพิ่ม อ่านรายละเอียดใน README.md ที่โฟลเดอร์ 03-AI-Studio กราฟ/รายงานที่แนบเป็นผลที่ตรึงไว้ ไม่มีการเปลี่ยนกราฟโดยอัตโนมัติเมื่อทดลองค่าใหม่

รายการภาพที่มีแล้วและภาพที่ควรเก็บเพิ่มเองตอนฝึก

มีแล้ว: หน้ากระบวนการสำรวจ/ผลสำรวจ/เตรียมข้อมูล/ต้นไม้/ฝึกและประเมิน/ผล Performance เก็บต้นฉบับไว้ครบใน assets

ควรเก็บเพิ่มเมื่อทีมฝึกเอง: หน้าตั้งชนิด Children ตอนอ่าน CSV, ก่อน–หลังการเติมพร้อม ChildrenMissing, ค่าพารามิเตอร์ต้นไม้ที่เลือก, หน้ากระบวนการโหลด .ioo โดยไม่ฝึกใหม่ ภาพเหล่านี้ยังไม่ได้อ้างว่ามีการแคปใหม่ในชุดนี้ ให้ตั้งชื่อตามสิ่งที่เห็นจริงและอย่าสร้างหน้าตาโปรแกรมปลอมแทน

## 9. คำถามซ้อมตอบและแบบฝึกพร้อมเฉลย

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

1. ทำไมเลือกข้อมูลนี้

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

2. หนึ่งแถวคืออะไร

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

3. ทำไมมี 31 แล้วกลายเป็น 32 คอลัมน์

H1 และ H2 มีอย่างละ 31 คอลัมน์ เมื่อรวมเราเพิ่ม Hotel เพื่อรู้ว่าแถวมาจากโรงแรมประเภทใด ไม่ได้เพิ่มข้อมูลลูกค้าจากการเดา ตารางพร้อมฝึกภายหลังเหลือ 19 ตัวทำนายและเฉลยอีกหนึ่ง ไม่ใช่ใช้ทั้ง 32 ช่องทั้งหมด

4. NA, NULL และ 0 เหมือนกันไหม

ไม่เหมือน ต้องอ่านตามช่อง Children=NA คือไม่ทราบจำนวนเด็ก Children=0 คือไม่มีเด็ก ส่วน Agent/Company=NULL ตามบทความหมายถึงไม่มีตัวแทนหรือบริษัท การเติม NULL ด้วยค่าเฉลี่ยรหัสจึงไม่มีความหมาย

5. ทำไม Children หาย

เรายืนยันได้ว่ามี NA 4 รายการ แต่ยังไม่ทราบสาเหตุ บทความกล่าวว่าต้นทางไม่มี missing จึงต้องเปิดเผยความต่างระหว่างคำอธิบายกับไฟล์ ไม่กล่าวว่าพนักงานลืมกรอกโดยไม่มีหลักฐาน

6. ทำไมเติม Children เป็นศูนย์ แล้วจะหลอกโมเดลไหม

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

7. ทำไมไม่ใช้ Replace Missing Values กับทุกช่องรวดเดียว

เพราะช่องแต่ละชนิดมีความหมายต่างกัน การแทน Children, Country และ Agent ด้วยกฎเดียวอาจสร้างคำตอบที่ไม่จริง วิธีที่ใช้ต้องเริ่มจากนิยามก่อน ไม่ใช่เริ่มจากปุ่มที่ทำให้โปรแกรมแสดง Missing=0

8. ทำไมไม่ลบแถวซ้ำทั้งหมด

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

9. ทำไมไม่ตัดค่าที่สูงหรือศูนย์

ค่าห่างจากคนส่วนใหญ่ไม่เท่ากับผิด LeadTime=0 อาจจองวันเดียวกัน ส่วนจำนวนคืนหรือผู้เข้าพักรวมศูนย์น่าสงสัยแต่ยังไม่มีเหตุผลพอให้แก้โดยเดา เรารายงานจำนวนและข้อจำกัด ไม่อ้างว่ารู้สาเหตุแล้ว

10. ทำไมตัด ReservationStatus

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

11. ข้อมูลนี้เป็นค่าตอนเริ่มจองทั้งหมดใช่ไหม

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

12. ทำไมประวัติยกเลิกเป็นศูนย์ยังต้องระวัง

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

13. Train, Validation และ Test ต่างกันอย่างไร

ชุดฝึกใช้ให้ต้นไม้เรียนรู้ ชุดตรวจสอบใช้เลือกขนาดต้นไม้กับเกณฑ์แจ้งเตือน ชุดทดสอบใช้วัดหลังล็อกแล้ว งานนี้เรียงตามเวลาแทนสุ่มปนทุกปี และยังแจ้งว่าปี 2017 เคยใช้ในงาน R เดิม จึงต้องมีข้อมูลใหม่สำหรับการยืนยันอิสระจริง ๆ

14. ทำไม 78,703 กลายเป็น 78,310 และ Train+Validation ยังไม่เท่ากัน

กัน 393 รายการที่เฉลยยังไม่พร้อมก่อนปี 2017 ออกจากการฝึกสุดท้าย ส่วน Train+Validation=77,907 ต่างอีก 403 เพราะการฝึกช่วงแรกใช้วันตัดเฉลยก่อนกว่า ไม่ใช่แถวสูญหายจากไฟล์หรือถูกลบซ้ำทั้งหมด

15. ทำไมเลือก Decision Tree และไม่ scaling

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

16. ทดลอง 6 ต้นไม้ผิดเงื่อนไขหนึ่งเทคนิคหรือไม่

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

17. threshold 0.25 คืออะไร ต่างจาก confidence ในหน้าตั้งต้นไม้อย่างไร

threshold เป็นเกณฑ์หลังต้นไม้ให้คะแนน ถ้าคะแนนยกเลิกอย่างน้อย 0.25 ก็เข้าคิว ส่วน confidence ที่ตั้ง 0.25 ในตัวต้นไม้เป็นค่าควบคุมการตัดแต่งกิ่ง เลขเหมือนกันแต่คนละหน้าที่

18. ทำไมภาพต้นไม้เป็น false แต่ผลที่เว็บต้องแจ้งเป็น true

ต้นไม้ปกติเลือกคลาสที่มีจำนวนมากกว่า เช่น ใบหนึ่งยกเลิก 42.85% จึงให้ false แต่เกณฑ์คิวของเราเป็น 25% ใบนี้จึงเข้าคิว ต้องรักษากฎเดียวกันในเว็บ ไม่ใช้คลาสปกติแทนผลแจ้งเตือน

19. Recall 81.80% กับ Precision 52.61% แปลว่าอะไร

Recall: จากรายการที่ยกเลิกจริง 100 รายการ จับได้ประมาณ 82 ส่วน Precision: จากรายการที่แจ้งเตือน 100 รายการ ยกเลิกจริงประมาณ 53 ใช้ตัวหารต่างกัน ควรชี้กลับไปที่ตารางสี่ช่องให้ได้

20. ทำไม Accuracy 64.45% ยังถือว่ามีสิ่งให้เรียนรู้

วิธีบอกไม่ยกเลิกทุกคนได้ Accuracy 61.30% แต่จับการยกเลิกไม่ได้เลย งานเราต้องดูการจัดคิวที่ตรงกลุ่มและการพลาดร่วมด้วย PDF ให้คะแนนจากเหตุผล ความเข้าใจ และข้อจำกัด ไม่ใช่ Accuracy สูงสุด

21. ผ่านเกณฑ์แล้วพร้อมใช้ไหม

ยังไม่พร้อมสรุปเช่นนั้น คิวใหญ่ถึง 60.16% มีแจ้งเตือนผิด 11,600 รายการ และรีสอร์ต Precision 48.09% ยังไม่ผ่าน ต้องตรวจเวลาข้อมูล ความสามารถพนักงาน และผลกับข้อมูลใหม่

22. .rmp, .ioo, .pmml และ .json ต่างกันอย่างไร

.rmp เก็บวิธีทำงาน .ioo เก็บโมเดลที่ฝึกเสร็จ .pmml แลกเปลี่ยนโครงสร้างโมเดลระหว่างเครื่องมือ และ .json ในโครงการนี้เก็บกฎให้ตัวคำนวณเว็บอ่าน .pmml ดิบฉบับล่าสุดส่งออกจาก Write PMML จริง ส่วน portable 4.4 เป็นสำเนาปรับโครงสร้างแยกไฟล์ เว็บใช้ JSON ที่สกัดจากไฟล์ดิบและตรวจคะแนนแล้ว

23. รู้ได้อย่างไรว่าโมเดลที่บันทึกไม่ใช่แค่ไฟล์ว่าง

เปิด .ioo กลับด้วยกระบวนการที่ไม่มี Decision Tree ฝึกใหม่ แล้วให้ผลตรงกับของเดิมทั้ง 40,687 รายการ JSON และตัวตรวจเส้นทาง PMML ที่เขียนแยกก็เทียบกับผลเดียวกันแล้ว; สำเนา PMML 4.4 ผ่านการตรวจโครงสร้างตามมาตรฐาน ส่วนไฟล์ดิบจาก Extension มีรุ่น/namespace ไม่สอดคล้องกันตามที่อธิบายในคู่มือเว็บ แต่ยังไม่ได้ทดสอบด้วยระบบอ่าน PMML ของผู้ให้บริการอื่น นี่พิสูจน์การส่งต่อกฎ ไม่ได้พิสูจน์ความเหมาะสมกับทุกข้อมูลใหม่

24. เว็บไซต์ต้องใช้ AI มาคิดคะแนนทุกครั้งไหม

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

25. กราฟทั้งหมดแคปจาก AI Studio หรือไม่

ไม่ใช่ มีภาพหน้าจอโปรแกรมจริง และกราฟที่วาดใหม่จาก CSV ผล AI Studio ด้วย Python เพื่อให้อ่านบนสไลด์ได้ ภาพแผนผังบางภาพเป็นสื่อช่วยอธิบาย ต้องบอกที่มาให้ถูก ไม่อ้างว่าเป็นภาพโปรแกรมทั้งหมด

26. ลดการยกเลิกหรือเพิ่มรายได้ไปเท่าไรแล้ว

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

27. ถ้ามีเวลาต่อ ควรทำอะไรก่อน

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

แบบฝึกท้ายการซ้อม

ให้แต่ละคนทำให้ได้: เปิด process หนึ่งไฟล์ → ชี้กล่องและหน้าที่ → เปิดผล → อธิบายกราฟหนึ่งภาพ → คำนวณ Precision/Recall จากตาราง → อธิบายการแปลง NA/NULL → โหลดไฟล์โมเดล → บอกข้อจำกัดโดยไม่อ้างเกินหลักฐาน เมื่อทำได้จึงยืนยันหน้าที่และเตรียมพูดจริง

แบบฝึกพร้อมเฉลย: ลองตอบก่อนเปิดอ่าน

ข้อ A — อ่านฐานของตัวเลข: ถ้าคนพูดว่า “Recall 81.80% หมายถึงคิว 100 รายการมีรายการยกเลิกจริง 82 รายการ” ถูกหรือไม่?

เฉลย: ไม่ถูก คิว 100 รายการเป็นฐานของ Precision ซึ่งได้ประมาณ 53 รายการ ส่วน Recall เริ่มจากรายการที่ยกเลิกจริง 100 รายการ แล้วถามว่าคิวจับได้กี่รายการ คือประมาณ 82 รายการ

ข้อ B — รักษาความหมายข้อมูล: Children เป็น [NA, 0, 2] หลังเตรียมควรได้สองคอลัมน์อะไร?

เฉลย: ChildrenMissing เป็น [1, 0, 0] และ Children เป็น [0, 0, 2] ต้องสร้างธงก่อนเติม จุดสำคัญคือรู้ว่าศูนย์ตัวแรกเป็นค่าทดแทน ไม่ใช่ค่าที่ต้นฉบับยืนยัน

ข้อ C — นับแถวที่ไม่ได้ใช้: 78,703 − 78,310 และ 78,310 − (63,783 + 14,124) เท่ากับเท่าไร และแปลว่าอะไร?

เฉลย: 393 คือรายการที่เฉลยยังไม่พร้อมก่อนปี 2017 จึงไม่ใช้ฝึกสุดท้าย ส่วน 403 คือรายการของช่วงก่อนหน้าที่เฉลยพร้อมทันวันฝึกสุดท้าย แต่ไม่ทันวันตัดของชุดฝึกแรก ไม่ใช่จำนวนแถวซ้ำที่ลบทิ้ง

ข้อ D — ทำไม false แล้วยังเตือน: ใบหนึ่งมีไม่ยกเลิก 17,127 และยกเลิก 12,842 เกณฑ์แจ้งเตือนคือ 0.25 ต้องทำอย่างไร?

เฉลย: คะแนน 12,842/29,969 = 0.4285 จึงเข้าคิว เพราะเกิน 0.25 แม้ป้ายตามเสียงส่วนใหญ่ของใบจะเป็นไม่ยกเลิก ต้องแยกป้ายต้นไม้ปกติออกจากกฎจัดคิวของงาน

ข้อ E — เลือกทางปรับปรุง: เห็น Precision รีสอร์ต 48.09% แล้วลองเกณฑ์ใหม่กับ test จนผ่าน 50% จากนั้นรายงานว่าเป็นผลยืนยันอิสระได้หรือไม่?

เฉลย: ไม่ได้ เพราะเริ่มใช้ test ช่วยเลือกค่าแล้ว หากต้องการปรับแยกโรงแรมต้องวางชุดพัฒนา/ตรวจสอบใหม่ และเก็บข้อมูลใหม่ไว้ยืนยันหลังเลือกเสร็จ

ข้อ F — เชื่อมสู่ธุรกิจ: โมเดลผ่านเกณฑ์รวมแล้ว ควรสรุปว่าการยกเลิกลดลงหรือไม่?

เฉลย: ยังไม่ได้ ผลนี้วัดการจำแนกย้อนหลัง การวัดว่าการติดตามช่วยลดการยกเลิกต้องทดลองวิธีทำงานจริง เก็บผลและมีกลุ่มเปรียบเทียบที่เหมาะสม

## 10. ใช้คู่มือนี้นำเสนอและอ่านศัพท์สำคัญ

จับคู่บทเรียนกับสไลด์ล่าสุด

เนื้อหาในคู่มือ หน้าสไลด์ สิ่งที่ผู้ฟังควรเข้าใจเมื่อจบช่วง
ภาพรวมโครงการ 1–2 กำลังแก้ปัญหาอะไรและจะเล่าครบหกขั้น
ขั้นที่ 1 ความเข้าใจธุรกิจ 3–7 ช่วยใคร ต้องการผลอะไร และวัดอย่างไร
ขั้นที่ 2 ความเข้าใจข้อมูล 8–15 ข้อมูลมาจากไหน แต่ละช่องหมายถึงอะไร และเห็นอะไรจากกราฟ
ขั้นที่ 3 การเตรียมข้อมูล 16–30 แต่ละปัญหาต่างกันอย่างไร ทำไมจึงเลือกวิธีจัดการนั้น
ขั้นที่ 4 การสร้างแบบจำลอง 31–40 เรียนกฎอย่างไร เลือกค่าจากชุดไหน และได้ไฟล์โมเดลอะไร
ขั้นที่ 5 การประเมินผล 41–46 โมเดลทำได้เท่าไร พลาดอะไร และผลรวมปิดบังปัญหากลุ่มไหน
ขั้นที่ 6 การนำไปใช้งาน 47–51 นำผลไปช่วยงานอะไร และยังต้องตรวจอะไรเพิ่มเติม
หน้าที่ AI อ้างอิง และสรุป 52–54 ใครทำอะไร หลักฐานมาจากไหน และได้เรียนรู้อะไร

บทพูดรายหน้าอยู่ใน SPEAKER-NOTES-54-SLIDES.md เป็นข้อความชุดเดียวกับสไลด์ล่าสุด สำเนาในชุดเรียนตัดภาพย่อสไลด์ออกเพื่อให้ไฟล์ไม่หนัก ภาพกราฟและภาพโปรแกรมที่ใช้สอนยังอยู่ในคู่มือนี้และโฟลเดอร์ assets

หลักเล่าให้คนฟังตามทัน

แต่ละช่วงให้พูดว่า เรามีคำถามอะไร → ทำอะไรเพื่อตอบ → พบอะไร → ผลนั้นทำให้ตัดสินใจอย่างไรต่อ ตัวอย่างเช่น “เราอยากรู้ว่า NULL คือข้อมูลหายหรือไม่ จึงอ่านนิยามต้นฉบับ พบว่า Agent หมายถึงไม่มีตัวแทน เราจึงแปลงเป็นมี/ไม่มีแทนการเติมรหัส” ประโยคแบบนี้แสดงเหตุผลได้ชัดกว่าการอ่านชื่อ operator หลายชื่อเรียงกัน

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

คำที่พบในงาน แปลให้เข้าใจในบริบทนี้

คำ ความหมายที่ใช้ในงานนี้
ตัวแปร / Attribute คอลัมน์หนึ่งช่อง เช่น จำนวนวันจองล่วงหน้า
หน่วยวิเคราะห์ สิ่งที่หนึ่งแถวแทน ในงานนี้คือหนึ่งรายการจอง
ตัวทำนาย / Predictor ข้อมูลที่ให้ต้นไม้ใช้ถามเงื่อนไข
เฉลย / Label / Target ผลที่รู้แล้วเพื่อฝึกหรือเช็กคำตอบ คือ IsCanceled
Missing value ค่าที่ควรมีแต่ยังไม่ทราบ ต้องอ่านความหมายก่อนเลือกวิธีจัดการ
Imputation การแทนค่าที่หายด้วยข้อสมมติ ไม่ใช่การค้นพบค่าจริง
Encoding การเปลี่ยนรูปแบบให้เหมาะกับวิธี เช่น รหัสตัวแทนเป็นมี/ไม่มี
Leakage ให้ข้อมูลที่ไม่ควรรู้ในเวลาตัดสินใจแอบช่วยทำนาย ทำให้การประเมินดูดีเกินงานจริง
Training ช่วงที่ให้ต้นไม้เรียนรู้คำถามจากข้อมูลฝึก
Validation ชุดที่ใช้เลือกขนาดต้นไม้และเกณฑ์เข้าคิว
Test ชุดที่ใช้ประเมินหลังล็อกวิธี; ของงานนี้เคยเห็นในงาน R ก่อน จึงยังไม่ใช่การยืนยันอิสระทั้งโครงการ
Overfitting เรียนลักษณะเฉพาะของชุดฝึกมากจนใช้กับข้อมูลอื่นได้ไม่ดี
Pruning การตัดแต่งกิ่งเพื่อควบคุมความละเอียดของต้นไม้
Threshold คะแนนขั้นต่ำที่กำหนดให้เข้าคิว ในงานนี้ 0.25
Baseline วิธีง่ายที่ใช้เปรียบเทียบ เช่น บอกว่าไม่ยกเลิกทุกแถว
Calibration การตรวจ/ปรับให้คะแนนสอดคล้องกับความถี่ของเหตุการณ์ในข้อมูลใหม่; งานนี้ยังไม่ได้ยืนยันส่วนนี้
Deployment การวางวิธีนำผลไปใช้ พร้อมข้อจำกัดและการติดตามผล ไม่จำเป็นต้องเป็นเว็บไซต์เสมอ

บทปิดการนำเสนอ

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

ตารางจำหกขั้นโดยไม่ท่องแต่ชื่อ

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

## หลักฐานและเอกสารอ้างอิง

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