← กลับหน้าภาพรวม
ระดับ 2 · INTERMEDIATE

ระดับกลาง: analyst ใช้ AI เร่งงาน pandas/SQL อย่างมีวินัย

สำหรับ analyst ที่ใช้ SQL/pandas อยู่บ้าง ใช้ AI ช่วย draft/debug/EDA และวางระบบตรวจสอบผลลัพธ์แบบมืออาชีพ

📦 6 โมดูล⏱ 16-20 ชั่วโมง

6 โมดูลในระดับนี้: 2.1 ใช้ AI draft และ debug · 2.2 Natural-Language-to-SQ · 2.3 เครื่องมือ warehouse-n · 2.4 AI ใน BI: Power BI Cop · 2.5 RAG ไม่ใช่เครื่องคิดเล · 2.6 วินัยตรวจสอบสถิติ: จับ

2.1
โมดูล 2.1

ใช้ AI draft และ debug pandas อย่างเป็นระบบ

AI เป็นคู่หูช่วยเขียนโค้ด ไม่ใช่ผู้รู้แจ้งที่เชื่อได้ทุกคำ

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: AI เขียนโค้ดให้เหมือนลูกน้องมือไวที่ร่างงานมาให้เร็วมาก แต่บางทีก็เผลอทำพลาด เราจึงต้องเป็นหัวหน้าที่ตรวจงานก่อนส่ง ไม่ใช่เซ็นอนุมัติทันทีโดยไม่อ่าน
🎯
ทำไมต้องรู้: ถ้าเชื่อโค้ด AI ทั้งดุ้นแล้วรัน ตัวเลขที่ผิดเงียบ ๆ (เช่นแถวข้อมูลหายไปตอนรวมตาราง) อาจกลายเป็นรายงานที่ตัดสินใจธุรกิจผิดโดยไม่รู้ตัว การตรวจก่อนรันช่วยให้เราจับพลาดได้ตั้งแต่ต้น

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • ใช้ AI ช่วยร่างโค้ด (draft), ช่วยแก้จุดที่พัง (debug) และช่วยอธิบายโค้ด pandas ที่เราไม่คุ้น
  • อ่านและตรวจโค้ดที่ AI เขียนให้ก่อนกดรัน
  • จับจุดที่ชนิดข้อมูลถูกแอบเปลี่ยนแบบเงียบ ๆ (silent coercion) และแถวข้อมูลหายไป (dropped rows) ในโค้ดที่ AI เขียน

เนื้อหา

วิธีทำงานของนักวิเคราะห์ข้อมูล (analyst) คือให้ AI ช่วยร่างโค้ด (draft) และช่วยหาจุดที่โค้ดพัง (debug) ทั้ง pandas กับ SQL รวมถึงช่วยอธิบายโค้ดที่เราอ่านไม่ออก แต่คนที่ต้องตรวจและตีความผลว่าถูกไหมยังเป็นตัวเราเองอยู่ดี บทนี้จะสอนใช้ AI เขียน pandas สำหรับงานจริง เช่น จัดกลุ่มสรุปยอด (groupby), ต่อรวมสองตาราง (merge), สลับแถวเป็นคอลัมน์ (pivot) และคำนวณแบบเลื่อนหน้าต่าง (window) แล้วตรวจโค้ดก่อนกดรัน โดยเฉพาะจุดที่ AI ชอบแอบเปลี่ยนชนิดข้อมูลให้เองแบบเงียบ ๆ หรือทำแถวข้อมูลหายตอน merge เพราะคีย์ที่ใช้จับคู่ไม่ตรงกัน และย้ำเรื่องการทำซ้ำแล้วได้ผลเดิม (reproducibility) ก็คือ ต้องเก็บโค้ดไว้ ระบุเวอร์ชันให้ชัด แล้วรันซ้ำเพื่อยืนยัน เพราะถึงพิมพ์คำสั่งเดิม (prompt) AI ก็อาจให้โค้ดหรือคำตอบไม่เหมือนเดิมได้

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
pandasเครื่องมือในภาษา Python ที่ใช้จัดการข้อมูลแบบตาราง เหมือน Excel แต่สั่งด้วยโค้ด
groupbyการจับข้อมูลมาจัดกลุ่มแล้วสรุป เช่น รวมยอดขายแยกตามแต่ละสาขา
mergeการเอาสองตารางมาต่อรวมกันโดยจับคู่ด้วยคอลัมน์ที่ตรงกัน เช่น รหัสลูกค้า
validateการตรวจสอบว่าผลลัพธ์ถูกต้องจริงไหม ก่อนจะเชื่อและนำไปใช้
coerce ชนิดข้อมูลการที่โปรแกรมแอบเปลี่ยนชนิดข้อมูลให้เอง เช่นเปลี่ยนตัวเลขเป็นข้อความ ทำให้คำนวณเพี้ยนแบบไม่มีคำเตือน

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ร่างโค้ด + ตรวจจุด merge ที่เสี่ยงทำแถวหาย
เขียน pandas รวม orders กับ customers ด้วย customer_id แบบ left join แล้วรายงานจำนวนแถวก่อน-หลัง merge และจำนวน customer_id ใน orders ที่หา match ไม่เจอ (กลายเป็น null) อธิบายความเสี่ยงถ้าใช้ inner join แทน
✅ ผลลัพธ์ที่ได้

AI เขียน pd.merge(orders, customers, on='customer_id', how='left') แสดงขนาดตาราง (shape) ก่อน-หลัง แล้วนับค่าว่าง (null) ในคอลัมน์ที่มาจาก customers เช่นเจอ 1,204 ออเดอร์ที่หาลูกค้าตรงไม่เจอ และอธิบายว่าถ้าใช้ inner join แถวพวกนี้จะโดนทิ้ง

💡 จุดสอน

merge เป็นจุดที่แถวข้อมูลชอบหายแบบเงียบ ๆ ให้นับจำนวนแถวก่อน-หลัง และเช็กชนิดของ join ทุกครั้ง

ให้ AI อธิบายโค้ดที่ไม่คุ้น
อธิบายทีละบรรทัดว่าโค้ดนี้ทำอะไร และมีกรณีขอบไหนที่อาจให้ผลผิด: df['rank'] = df.groupby('region')['sales'].rank(method='dense', ascending=False)
✅ ผลลัพธ์ที่ได้

AI อธิบายว่าโค้ดนี้จัดอันดับยอดขายภายในแต่ละภูมิภาค (region) แบบ dense rank จากมากไปน้อย และเตือนกรณีขอบ ๆ ไว้ เช่น ค่าว่าง (NaN) จะไม่ถูกจัดอันดับ และค่าที่เท่ากันจะได้อันดับเดียวกัน

💡 จุดสอน

การให้ AI อธิบายโค้ดช่วยให้เราเรียนรู้และจับกรณีขอบ ๆ (edge case) ได้ แต่ก็ยังต้องเอาไปทดสอบกับข้อมูลจริงอยู่ดี

แบบฝึกหัดท้ายโมดูล

  1. ให้ AI เขียน pandas สำหรับงานจริงของคุณที่ต้อง pivot บวกกับ window function แล้วอ่านตรวจโค้ด (review) หาจุดเสี่ยง 2 จุด (ชนิดข้อมูลถูกเปลี่ยนเอง หรือแถวหาย) ก่อนกดรัน
  2. ลองพิมพ์คำสั่งเดิม (prompt) แล้วขอโค้ดจาก AI 2 ครั้ง เทียบดูว่าออกมาต่างกันไหม แล้วสรุปว่าทำไมถ้าอยากให้ทำซ้ำได้ผลเดิม (reproducibility) เราต้องล็อกตัวโค้ดไว้ ไม่ใช่ล็อกแค่คำสั่งที่พิมพ์
2.2
โมดูล 2.2

Natural-Language-to-SQL: ความจริงเรื่องความแม่นยำ

แม่นตอนมีคู่มือข้อมูลดี ๆ แต่ตกฮวบพอเจอฐานข้อมูลจริงที่รก

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: AI แปลงคำถามเป็นภาษาฐานข้อมูล เหมือนล่ามเก่ง ๆ ถ้าคุยเรื่องที่ซ้อมไว้ดีก็แปลแม่นมาก แต่พอเจอศัพท์แปลก ๆ ในสถานการณ์จริงที่ซับซ้อน ก็แปลพลาดได้เยอะ
🎯
ทำไมต้องรู้: ตัวเลขโฆษณาความแม่น 90%+ มักมาจากสนามซ้อมที่จัดฉากไว้สวย พองานจริงข้อมูลรก ๆ ความแม่นอาจเหลือแค่ 20% การรู้ความจริงข้อนี้ช่วยให้เราไม่หลงเชื่อเกินจริงและตรวจงานเสมอ

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • เข้าใจว่าการแปลงคำถามเป็น SQL (text-to-SQL) จะแม่นก็ต่อเมื่อมีคู่มือข้อมูล (semantic model) ที่จัดเตรียมมาอย่างดี
  • รู้ตัวเลขตามความเป็นจริง: Cortex แม่นราว 90-95% บนชุดข้อมูลที่จัดเตรียมมาดี แต่บนสนามทดสอบ Spider 2.0 เหลือแค่ราว 21%
  • ตรวจ SQL ที่ AI เขียนให้ก่อนที่จะเชื่อผลลัพธ์

เนื้อหา

ตัวเลขที่เจ้าของผลิตภัณฑ์ (vendor) เอามาโฆษณามักจะสูง เพราะเขาทดสอบในระบบตัวเองที่มีคู่มือข้อมูล (semantic model) จัดเตรียมมาอย่างดี อย่าง Snowflake Cortex Analyst ก็บอกว่าแม่นราว 90-95% บนชุดข้อมูลที่ตรวจเช็กมาแล้ว แต่พอเอาไปเจอโจทย์ที่จำลองงานองค์กรจริง ตัวเลขก็ตกฮวบ อย่างสนามทดสอบ Spider 2.0 (ฐานข้อมูลโครงสร้างใหญ่ ใช้ SQL หลายภาษา ต้องตอบหลายขั้นตอน) ดันความแม่นเหลือแค่ราว 21% ทั้งที่บน Spider รุ่นเดิมที่ถามทีละคำถามสั้น ๆ ทำได้เกิน 90% แปลว่าการแปลงคำถามเป็น SQL ทำได้ดีกับคำถามเล็ก ๆ ตารางเดียว ที่มีคู่มือดี แต่พอเจอข้อมูลรก ๆ และคำถามที่ต้องคิดหลายขั้น ก็แย่ลงเยอะ บทเรียนสำคัญคือ คู่มือข้อมูล (semantic layer) ที่นิยามตัวเลขไว้ชัดและผ่านการรับรองแล้ว คือตัวช่วยเพิ่มความแม่นที่สำคัญที่สุด ถ้าปล่อยให้มีแค่โครงสร้างตารางเปล่า ๆ ผลจะออกมาด้อยกว่ากันมาก

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Natural-Language-to-SQLการพิมพ์คำถามเป็นภาษาคนธรรมดา แล้ว AI แปลงเป็นคำสั่งดึงข้อมูลจากฐานข้อมูลให้
SQLภาษาที่ใช้สั่งดึงและจัดการข้อมูลในฐานข้อมูล
schemaโครงสร้างของฐานข้อมูล ว่ามีตารางอะไร คอลัมน์อะไรบ้าง และเชื่อมกันยังไง
semantic modelคู่มืออธิบายให้ AI เข้าใจว่าข้อมูลแต่ละส่วนหมายถึงอะไร เช่นบอกว่า 'ยอดขาย' คือคอลัมน์ไหน
execution accuracyความแม่นที่วัดจากการรันคำสั่งจริงแล้วได้คำตอบถูก ไม่ใช่แค่หน้าตาคำสั่งดูดี

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ตรวจ SQL ที่ AI สร้าง
ฉันถามเป็นภาษาไทยว่า 'ลูกค้า 10 อันดับที่มียอดซื้อสุทธิสูงสุดในไตรมาส 2 ปี 2025 คือใคร' ช่วยสร้าง SQL แล้วอธิบายทีละส่วนว่า join ถูก table ไหน กรองช่วงวันที่อย่างไร และ 'ยอดสุทธิ' นับรวมส่วนลด/คืนสินค้าหรือไม่
✅ ผลลัพธ์ที่ได้

AI สร้าง SQL มาพร้อมอธิบายเงื่อนไข WHERE ที่กรองช่วงวันที่ของไตรมาส 2, การเชื่อม (join) ตาราง orders กับ returns และชี้ว่านิยาม 'ยอดสุทธิ' ต้องหักยอดคืนสินค้าออก ซึ่งถ้าไม่ได้ระบุไว้ในคู่มือข้อมูล (semantic model) ก็อาจตีความผิดได้

💡 จุดสอน

ต้องอ่าน SQL ที่ AI สร้างทุกครั้ง โดยเฉพาะนิยามเชิงธุรกิจ (อย่าง 'ยอดสุทธิ') ที่ดูจากโครงสร้างฐานข้อมูลเปล่า ๆ แล้วไม่ชัด

เห็นผลของ semantic model ต่อความแม่น
เปรียบเทียบให้ฉันเห็นว่า ถ้าถามคำถามเดิมกับ schema เปล่า (แค่ชื่อ table/column) กับถามกับ semantic model ที่นิยาม metric 'ยอดสุทธิ' ไว้แล้ว ผลลัพธ์ SQL ต่างกันอย่างไร
✅ ผลลัพธ์ที่ได้

AI แสดงให้เห็นว่าถ้ามีแค่โครงสร้างฐานข้อมูลเปล่า ๆ มันต้องเดานิยามของยอดสุทธิเอง (ซึ่งเสี่ยงผิด) แต่ถ้ามีคู่มือข้อมูล (semantic model) ที่มีตัวเลขวัดผลผ่านการรับรองแล้ว (certified metric) มันจะเรียกนิยามที่ถูกต้องแบบตายตัว ทำให้ผลออกมาแม่นและสม่ำเสมอ

💡 จุดสอน

ชั้นคู่มือข้อมูล (semantic layer) ไม่ใช่ของฟุ่มเฟือย มันคือปัจจัยหลักที่ทำให้การแปลงคำถามเป็น SQL เชื่อถือได้

แบบฝึกหัดท้ายโมดูล

  1. เขียนคำถามเชิงธุรกิจ 3 ข้อ แล้วให้ AI สร้าง SQL จากนั้นตรวจว่าแต่ละข้อมีคำที่นิยามกำกวมไหม (เช่น ลูกค้าที่ยัง active อยู่ หรือ ยอดสุทธิ) ซึ่งต้องไปนิยามให้ชัดในคู่มือข้อมูล (semantic model)
  2. อ่านสรุปเรื่อง Spider 2.0 แล้วเขียน 3 เหตุผลว่าทำไมความแม่น (accuracy) ถึงตกจากกว่า 90% เหลือราว 21% เมื่อเจอฐานข้อมูลจริง (schema)
2.3
โมดูล 2.3

เครื่องมือ warehouse-native: Cortex Analyst และ Genie

ถาม-ตอบด้วยภาษาคนบนคลังข้อมูล โดยข้อมูลไม่ต้องออกนอกแพลตฟอร์ม

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: เหมือนมีผู้ช่วยที่ตอบคำถามข้อมูลให้เราได้ในห้องนิรภัยของบริษัทเอง โดยข้อมูลไม่ต้องถูกหอบออกไปนอกตึกให้เสี่ยงรั่วไหล
🎯
ทำไมต้องรู้: องค์กรที่ห่วงความปลอดภัยของข้อมูลจะสบายใจได้ เพราะถาม-ตอบได้ในที่เดียวโดยข้อมูลไม่ออกนอกแพลตฟอร์ม และเมื่อมีคู่มือ (semantic model) ที่ดี ความแม่นก็สูงพอใช้งานจริงได้

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • ใช้ Cortex Analyst ที่ทำงานบนคู่มือข้อมูล (semantic view/model เขียนเป็นไฟล์ YAML) และใช้พื้นที่ทำงาน Databricks Genie (Genie space)
  • เข้าใจว่าเครื่องมือพวกนี้มองเห็นเฉพาะข้อมูลที่อยู่ในแพลตฟอร์มตัวเองเท่านั้น
  • รู้จัก Snowflake Intelligence และมาตรฐาน Open Semantic Interchange (OSI) สำหรับใช้คู่มือข้อมูลข้ามแพลตฟอร์ม

เนื้อหา

Snowflake Cortex Analyst จะแปลงคำถามเราให้กลายเป็น SQL (text-to-SQL) โดยอ่านจากคู่มือข้อมูลแบบ semantic view/model (ไฟล์ YAML ที่บอกว่ามีตารางอะไร มิติข้อมูลอะไร ตัวเลขวัดผลอะไร ตารางไหนเชื่อมกันยังไง พร้อมตัวอย่างคำถาม) ออกแบบมาให้โปรแกรมอื่นเรียกใช้ผ่านช่องทางมาตรฐาน (REST/API) ได้ และมันมองเห็นเฉพาะข้อมูลที่อยู่ใน Snowflake เท่านั้น โดยรายงานว่าเขียน SQL ได้แม่นราว 90% ขึ้นไปบนงานทำรายงานจริง (BI) เมื่อมีคู่มือข้อมูล และแม่นขึ้นอีกบนชุดข้อมูลที่ตรวจเช็กมาแล้ว ปี 2025 Snowflake ยังเปิดตัว Snowflake Intelligence และโครงการ Open Semantic Interchange (OSI) เพื่อให้ใช้คู่มือข้อมูลร่วมกันข้ามแพลตฟอร์มได้ ส่วนฝั่ง Databricks ก็มี AI/BI Genie (Genie Spaces) ที่ให้ถามข้อมูลด้วยภาษาคนโดยไม่ต้องเขียนโค้ด เปิดใช้งานจริงเต็มรูปแบบ (GA) ปี 2025 ทำงานผ่านพื้นที่ Genie space ที่ห่อตารางไว้พร้อมคู่มือ (นิยามตัวเลขวัดผล ตัวอย่างคำถาม คำแนะนำ และข้อมูลที่รับรองแล้ว) และเห็นเฉพาะข้อมูลใน Databricks เช่นกัน นอกจากนี้ยังมีทางเลือกอื่นที่แปลงคำถามเป็น SQL ได้ข้ามแพลตฟอร์ม (เช่น Dataherald, Promethium)

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
warehouse-nativeเครื่องมือที่ทำงานอยู่ในคลังข้อมูลเลย ไม่ต้องยกข้อมูลออกไปที่อื่น
Cortex Analyst / Genieผู้ช่วย AI ตอบคำถามข้อมูลด้วยภาษาคนของ Snowflake และ Databricks ตามลำดับ
semantic view/model (YAML)ไฟล์คู่มือที่เขียนบอก AI ว่าตารางและตัวเลขแต่ละอย่างหมายถึงอะไร
REST/API-firstออกแบบให้โปรแกรมอื่นเรียกใช้งานผ่านช่องทางมาตรฐานได้ง่าย เหมือนมีปลั๊กเสียบต่อ
BIการนำข้อมูลมาทำรายงานและกราฟเพื่อช่วยตัดสินใจทางธุรกิจ

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

ออกแบบ semantic model ของ Cortex
ช่วยร่างโครง semantic model แบบ YAML สำหรับ Cortex Analyst จากตาราง fact_sales และ dim_customer, dim_product โดยนิยาม metric 'net_revenue' (ยอดขายหักคืนสินค้า), dimension ภูมิภาคและหมวดสินค้า, ความสัมพันธ์ระหว่างตาราง และ example query 2 ข้อ
✅ ผลลัพธ์ที่ได้

AI ร่าง YAML ที่มีตารางเชิงตรรกะ (logical tables), ความสัมพันธ์ระหว่างตาราง, ตัวเลขวัดผล (metric อย่าง net_revenue พร้อมสูตร), มิติข้อมูล และตัวอย่างคำถาม ซึ่งเป็นสิ่งที่ทำให้ Cortex ตอบได้แม่นและสม่ำเสมอ

💡 จุดสอน

หัวใจของเครื่องมือที่ทำงานในคลังข้อมูล (warehouse-native) คือคู่มือข้อมูลที่นิยามตัวเลขวัดผลไว้ชัด ส่วนตัวอย่างคำถามช่วยให้ระบบเข้าใจรูปแบบคำถามจริง

เข้าใจขอบเขตข้อมูลที่ AI เห็น
ถ้าข้อมูลลูกค้าบางส่วนอยู่ใน Snowflake และบางส่วนอยู่ในไฟล์ Excel นอกระบบ Cortex Analyst จะตอบคำถามที่ต้องใช้ทั้งสองแหล่งได้ไหม
✅ ผลลัพธ์ที่ได้

AI อธิบายว่า Cortex เห็นเฉพาะข้อมูลใน Snowflake เลยตอบข้ามไปหาข้อมูลใน Excel นอกระบบไม่ได้ ต้องเอาข้อมูลเข้ามาก่อน หรือไม่ก็ใช้เครื่องมือแปลงคำถามเป็น SQL ที่ทำงานข้ามแพลตฟอร์มได้

💡 จุดสอน

เครื่องมือที่ทำงานในคลังข้อมูล (warehouse-native) มีข้อดีเรื่องความปลอดภัย เพราะข้อมูลไม่ออกนอกระบบ แต่ก็ถูกจำกัดอยู่แค่ข้อมูลที่มีในแพลตฟอร์มนั้น

แบบฝึกหัดท้ายโมดูล

  1. ร่างคู่มือข้อมูล (semantic model — เป็น YAML สำหรับ Cortex หรือคำอธิบายสำหรับ Genie space) ในหัวข้องานของคุณ โดยให้มีตัวเลขวัดผล (metric) ที่นิยามไว้ชัด ๆ อย่างน้อย 3 ตัว
  2. เปรียบเทียบ Cortex Analyst กับ Genie ในแง่ว่าเห็นข้อมูลได้แค่ไหน นิยามความหมายของข้อมูล (semantics) ยังไง และเข้าถึงได้อย่างไร แล้วสรุปว่าแต่ละตัวเหมาะกับการวางระบบขององค์กรแบบไหน
2.4
โมดูล 2.4

AI ใน BI: Power BI Copilot, Tableau Pulse/Agent

ช่วยสร้างรายงาน เขียนสูตร DAX และถาม-ตอบข้อมูลบนแพลตฟอร์มทำรายงาน (BI)

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: เหมือนมีผู้ช่วยทำรายงานนั่งข้าง ๆ เราสั่งเป็นคำพูดว่า 'ขอกราฟยอดขายรายเดือน' แล้วมันร่างหน้ารายงานและสูตรคำนวณให้ทันที
🎯
ทำไมต้องรู้: งานทำรายงานและเขียนสูตรที่เคยกินเวลาเป็นชั่วโมง ทำเสร็จได้ในไม่กี่นาที และคนที่ไม่เก่งสูตรก็ถาม-ตอบข้อมูลเองได้ ไม่ต้องรอทีมไอที

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • ใช้ Power BI Copilot สร้างหน้ารายงาน (report page), เขียนสูตร DAX และทำ Q&A ถาม-ตอบข้อมูลที่มีกราฟ (visual) รองรับคำตอบ
  • ใช้ Tableau Pulse ที่คอยจับแนวโน้ม ตัวขับ และค่าผิดปกติให้เองอัตโนมัติ (auto-detect trend/driver/outlier) และใช้ Tableau Agent
  • เข้าใจชั้นกำกับดูแล (governance layer อย่าง Agentforce Trust Layer) และเงื่อนไขการซื้อสิทธิ์ใช้งาน (licensing)

เนื้อหา

Power BI Copilot ช่วยสร้างหน้ารายงานจากคำสั่งภาษาคน เขียนสูตร DAX จากคำอธิบาย และทำ Q&A แบบ 'คุยกับข้อมูล' ที่ตอบมาพร้อมกราฟจริงประกอบ รวมถึงตอบคำถามจัดอันดับได้ และปลายปี 2025 ก็ขยายมาถึง Power BI Mobile ด้วย แต่โดยทั่วไปต้องซื้อแพ็กเกจ Fabric capacity หรือ Power BI ระดับ Premium ก่อนถึงจะใช้ได้ ส่วนฝั่ง Tableau มี Tableau Pulse ที่คอยเฝ้าตัวเลขสำคัญแล้วหาแนวโน้ม ตัวที่เป็นตัวขับ (driver) และค่าที่ผิดปกติ (outlier) ให้เอง แล้วสรุปออกมาเป็นภาษาคนด้วย AI ที่สร้างข้อความได้ (generative AI) โดยปี 2025 เพิ่มความสามารถถาม-ตอบ 'Discover' และการดูตัวเลขที่สัมพันธ์กัน (Correlated Metrics) มาด้วย และยังมี Tableau Agent (ชื่อเดิมคือ Einstein Copilot for Tableau) เป็นผู้ช่วยแบบพูดคุยที่ทำงานข้ามทั้ง Web Authoring, Prep และ Catalog ทั้งหมดนี้สร้างอยู่บนชั้นดูแลความน่าเชื่อถือ Agentforce Trust Layer (ชื่อเดิม Einstein Trust Layer) ที่คอยดูแลเรื่องการกำกับดูแล ความปลอดภัย และความเป็นส่วนตัว

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
Power BI Copilotผู้ช่วย AI ในโปรแกรมทำรายงาน Power BI ของ Microsoft
DAXภาษาสูตรคำนวณใน Power BI คล้ายสูตรใน Excel แต่ทรงพลังกว่า
measureตัวเลขที่คำนวณได้ในรายงาน เช่น ยอดขายรวม หรือกำไรเฉลี่ย
Tableau Pulseฟีเจอร์ของ Tableau ที่คอยจับตาตัวเลขสำคัญและแจ้งเตือนเมื่อมีอะไรผิดปกติ
Fabric capacity / Premium licenseแพ็กเกจจ่ายเงินของ Microsoft ที่ต้องมีก่อนถึงจะใช้ฟีเจอร์ AI เหล่านี้ได้

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

สร้าง DAX จากคำอธิบาย
ใน Power BI Copilot ช่วยสร้าง DAX measure ชื่อ Rolling3MonthSales ที่คำนวณยอดขายเฉลี่ยเคลื่อนที่ 3 เดือน อธิบายสูตรและเตือนสมมติฐานเรื่องความต่อเนื่องของเดือนในตารางวันที่
✅ ผลลัพธ์ที่ได้

Copilot สร้าง DAX ที่ใช้ CALCULATE คู่กับ DATESINPERIOD บนตารางวันที่ พร้อมอธิบาย และเตือนว่าต้องมีตารางปฏิทินที่ต่อเนื่องกัน ไม่งั้นค่าจะเพี้ยน

💡 จุดสอน

AI สร้าง DAX ได้เร็วก็จริง แต่เราต้องตรวจสมมติฐานที่มันตั้งไว้ (เช่น ตารางวันที่ต้องต่อเนื่อง) และเช็กผล (validate) กับตัวเลขจริงด้วย

อ่าน insight จาก Tableau Pulse อย่างมีวิจารณญาณ
Tableau Pulse บอกว่า 'ยอดขายภาคเหนือลดลงผิดปกติ 18% และตัวขับหลักคือหมวดเครื่องดื่ม' ฉันควรตรวจสอบอะไรก่อนนำไปรายงานผู้บริหาร
✅ ผลลัพธ์ที่ได้

AI แนะนำให้ตรวจช่วงเวลาที่เอามาเทียบ, จำนวนข้อมูลว่ามากพอไหม, ปัจจัยเรื่องฤดูกาลหรือเหตุการณ์พิเศษ และยืนยันว่า 'ตัวขับ' ที่มันบอกเป็นแค่สิ่งที่สัมพันธ์กัน (correlation) ยังไม่ใช่สาเหตุที่พิสูจน์แล้ว

💡 จุดสอน

ข้อสังเกต (insight) ที่ระบบ BI หามาให้อัตโนมัติเป็นแค่จุดตั้งต้น ไม่ใช่ข้อสรุป ต้องตรวจบริบทและระวังการเหมาว่าสิ่งที่สัมพันธ์กันคือสาเหตุ (correlation-as-cause) เสมอ

แบบฝึกหัดท้ายโมดูล

  1. ใช้ Power BI Copilot (หรือจำลองสถานการณ์) สร้างตัวเลขคำนวณ (DAX measure) จริง 2 ตัวจากคำอธิบายเชิงธุรกิจ แล้วตรวจว่าค่าถูกต้องไหม (validate) ด้วยการเทียบกับการคำนวณด้วยมือ
  2. วิเคราะห์ข้อสังเกต (insight) ที่ Tableau Pulse หามาให้อัตโนมัติ (หรือใช้กรณีตัวอย่าง) แล้วเขียนรายการตรวจสอบ (checklist) 5 ข้อที่ต้องเช็กก่อนจะเชื่อ
2.5
โมดูล 2.5

RAG ไม่ใช่เครื่องคิดเลข: ใช้เครื่องมือให้ถูกงาน

อยากได้ตัวเลขที่ถูกต้อง ต้องรันโค้ดหรือแปลงคำถามเป็น SQL ไม่ใช่ใช้ RAG

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: RAG เหมือนบรรณารักษ์ที่เก่งค้นหาข้อความในหนังสือ แต่ไม่ใช่เครื่องคิดเลข ถ้าอยากได้ตัวเลขที่บวกลบถูกต้อง ต้องใช้เครื่องมือคำนวณจริง ไม่ใช่ให้บรรณารักษ์เดา
🎯
ทำไมต้องรู้: ถ้าเอา RAG มาคำนวณตัวเลข มันจะตอบมั่ว ๆ เพราะมันถูกสร้างมาอ่านข้อความ ไม่ใช่คิดเลข การเลือกเครื่องมือให้ถูกงานคือความต่างระหว่างตัวเลขที่เชื่อได้กับตัวเลขที่ผิด

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • เข้าใจว่าทำไม RAG ถึงไม่เหมาะกับข้อมูลแบบตารางหรือตัวเลข (tabular/numeric)
  • รู้กฎง่าย ๆ ที่ใช้ได้จริง: ตัวเลขให้ใช้ pandas/SQL ส่วนเอกสาร นิยาม หรือผลวิเคราะห์เก่า ๆ ให้ใช้ RAG
  • ออกแบบระบบผสม (hybrid) ที่เอาสองวิธีมาใช้ร่วมกันอย่างถูกวิธี

เนื้อหา

RAG ถูกออกแบบมาสำหรับข้อความที่ไม่มีโครงสร้าง มันเลยไม่เหมาะกับการวิเคราะห์ตัวเลขหรือตารางอยู่แล้วโดยธรรมชาติ เหตุผลคือ พอเราแปลงตารางให้กลายเป็นข้อความ โครงสร้างความสัมพันธ์ต่าง ๆ ก็หายไป (เช่น ความเชื่อมโยงระหว่างคอลัมน์ ชนิดของข้อมูล และความถูกต้องตอนเชื่อมตาราง) ยิ่งไปกว่านั้น ตัว embedding ที่ฝึกมาจากข้อความก็จับและค้นหาค่าตัวเลขได้ไม่ดี แถมตารางที่มีตั้งแต่หลักพันถึงหลักล้านแถวก็ยัดเกินความจุที่ AI รับไหวในครั้งเดียว (context window) ทำให้การไล่ค้นทีละชิ้น (chunk) ใช้ไม่ได้ผลเมื่อข้อมูลใหญ่ และ RAG ยังรวมยอด กรองตามชนิด หรือคำนวณแบบ SQL ได้ไม่น่าเชื่อถือด้วย กฎที่ใช้ได้จริงคือ ถ้าอยากได้ตัวเลขจริง ๆ ให้รันโค้ด (pandas) หรือแปลงคำถามเป็น SQL ไปดึงจากข้อมูลต้นทางเลย แล้วเก็บ RAG ไว้ใช้ดึงเอกสาร นิยาม หรือผลวิเคราะห์เก่า ๆ ส่วนระบบผสม (hybrid) ปี 2025 ที่รวมหลายเทคนิคเข้าด้วยกัน (dense + BM25 + metadata filtering + structure-preserving chunking) ก็ช่วยได้ แต่ก็ยังแทนที่การรันคำสั่งไปดึงข้อมูลจริงไม่ได้

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
RAGเทคนิคให้ AI ไปค้นข้อมูลจากเอกสารมาก่อนตอบ เหมาะกับข้อความ ไม่เหมาะกับตัวเลข
code executionการให้ AI เขียนและรันโค้ดคำนวณจริง เพื่อให้ได้ตัวเลขที่ถูกต้องแน่นอน
unstructured textข้อความที่ไม่มีโครงสร้างเป็นตาราง เช่นบทความหรือเอกสารทั่วไป
embeddingการแปลงข้อความเป็นตัวเลขชุดหนึ่งเพื่อให้ AI เทียบความหมายได้ แต่ทำกับตัวเลขจริงได้ไม่ดี
context windowปริมาณข้อมูลสูงสุดที่ AI รับไหวในครั้งเดียว ตารางใหญ่มาก ๆ จะเกินขีดนี้

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

เลือกเครื่องมือให้ตรงชนิดคำถาม
ฉันมีเอกสารนโยบายการคืนสินค้า (PDF) และตารางธุรกรรม 2 ล้านแถวใน SQL คำถามคือ 'ยอดคืนสินค้ารวมเดือน มิ.ย. 2025 คือเท่าไร และนโยบายคืนสินค้าเกิน 30 วันเป็นอย่างไร' ควรใช้ RAG หรือ SQL กับแต่ละส่วน
✅ ผลลัพธ์ที่ได้

AI แยกให้ว่า 'ยอดคืนสินค้ารวม' เป็นการรวมยอดตัวเลข (aggregate) ต้องใช้แปลงคำถามเป็น SQL หรือ pandas ส่วน 'นโยบายคืนสินค้า' เป็นข้อความ ให้ใช้ RAG ไปดึงจาก PDF ไม่ควรเอา RAG มาคำนวณยอดรวม

💡 จุดสอน

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

เห็นข้อจำกัดของ RAG กับตัวเลข
อธิบายว่าถ้าฉันฝังตารางยอดขาย 500,000 แถวเป็น embeddings แล้วถาม 'ยอดขายรวมทั้งปีเท่าไร' ทำไมผลจึงไม่น่าเชื่อถือ
✅ ผลลัพธ์ที่ได้

AI อธิบายว่าตอนไปค้น (retrieve) มันเจอแค่บางชิ้น (chunk) ไม่ครบทุกแถว แถม embedding เก็บค่าตัวเลขได้แย่ และ RAG ก็บวกรวม (SUM) ทั้งตารางไม่ได้ ยอดรวมเลยผิด ทางที่ถูกคือสั่ง SUM ด้วย SQL หรือ pandas

💡 จุดสอน

RAG มองไม่เห็นทุกแถวและรวมยอดไม่ได้ อย่าเอา RAG มาใช้เป็นเครื่องคิดเลข

แบบฝึกหัดท้ายโมดูล

  1. ออกแบบโครงสร้างระบบสำหรับผู้ช่วยวิเคราะห์ที่ต้องตอบได้ทั้งคำถามที่เป็นตัวเลขและคำถามเรื่องนโยบาย โดยระบุให้ชัดว่าส่วนไหนใช้ SQL/pandas ส่วนไหนใช้ RAG
  2. หากรณีในงานของคุณสัก 1 อย่างที่เคยหรืออาจจะเผลอเอา RAG ไปใช้คำนวณตัวเลข แล้วเขียนวิธีที่ถูกต้องมาแทน
2.6
โมดูล 2.6

วินัยตรวจสอบสถิติ: จับกับดักที่ AI ทำผิดบ่อย

ตั้งสมมติฐานก่อน แล้วระบุ test สมมติฐาน ขนาดของผล และช่วงความเชื่อมั่น ไม่ใช่ดูแค่ p-value

👋 สำหรับผู้เริ่มต้น — อ่านตรงนี้ก่อน
💡
เปรียบง่าย ๆ: เหมือนสืบสวนคดี ต้องตั้งสมมติฐานและหาหลักฐานให้ครบก่อนสรุป ไม่ใช่เห็นเบาะแสชิ้นเดียว (p-value) แล้วรีบชี้ตัวคนผิด
🎯
ทำไมต้องรู้: AI ทำผิดสถิติแบบคลาสสิกได้บ่อยมาก เช่นมองว่าสองอย่างเกิดพร้อมกันแปลว่าอันหนึ่งทำให้เกิดอีกอัน การมีวินัยตรวจสอบช่วยกันไม่ให้เราตัดสินใจธุรกิจจากข้อสรุปที่ฟังดูดีแต่ผิด

🎯 สิ่งที่คุณจะทำได้หลังเรียนโมดูลนี้

  • จับกับดักทางสถิติที่ทั้งตัว AI (LLM) และคนใช้ชอบทำผิด เช่น ตีความ p-value ผิด, เข้าใจว่าเกิดพร้อมกันคือเป็นเหตุเป็นผลกัน (correlation=causation), การลองซ้ำจนได้ผลถูกใจ (p-hacking) และการละเลยเงื่อนไขของการทดสอบ
  • บังคับให้ AI บอกชื่อ test พร้อมเงื่อนไข ระบุขนาดของผล (effect size) และช่วงความเชื่อมั่น (CI)
  • รู้จักเครื่องมือช่วยตรวจสถิติ เช่น Statcheck และ GRIM

เนื้อหา

ทั้งตัว AI และคนที่พึ่งมันทำผิดสถิติแบบคลาสสิกกันบ่อยมาก เช่น ตีความ p-value ผิด (ชอบพูดว่า 'กำลังจะมีนัยสำคัญ'), เข้าใจว่าสิ่งที่เกิดพร้อมกันคือสาเหตุของกันและกัน (จริง ๆ แล้ว AI แค่จับความสัมพันธ์เชิงภาษาหรือเชิงสถิติที่อาจเป็นของปลอม ไม่ใช่ความเป็นเหตุเป็นผลจริง), ลองสั่งซ้ำ ๆ จนได้ผลถูกใจ (p-hacking), ละเลยเงื่อนไขของการทดสอบ (เช่น ข้อมูลต้องกระจายแบบปกติ ต้องเป็นอิสระต่อกัน และเรื่องการทดสอบหลายคู่พร้อมกัน) และเลือกใช้ test ผิดชนิด ซึ่งมีเครื่องมืออย่าง Statcheck และ GRIM ที่ช่วยจับข้อผิดพลาดพวกนี้ได้ วิธีป้องกันคือ ตั้งสมมติฐานให้ชัดก่อนเริ่มวิเคราะห์ แล้วบังคับให้ AI บอกชื่อ test พร้อมเงื่อนไขของมัน ระบุขนาดของผล (effect size) และช่วงความเชื่อมั่น (CI) มาด้วย ไม่ใช่ให้แค่ p-value ตัวเดียว และย้ำให้ชัดว่าสองอย่างที่สัมพันธ์กัน (correlation) ไม่ได้แปลว่าอันหนึ่งเป็นสาเหตุของอีกอัน (causation)

📖 คำศัพท์ในโมดูลนี้ (อธิบายง่าย ๆ)
p-valueตัวเลขบอกโอกาสที่ผลลัพธ์จะเกิดจากความบังเอิญ ยิ่งน้อยยิ่งน่าเชื่อว่าไม่ใช่ฟลุ๊ก แต่ตีความผิดกันบ่อย
correlation vs causationสองอย่างเกิดพร้อมกัน (correlation) ไม่ได้แปลว่าอันหนึ่งทำให้เกิดอีกอัน (causation)
effect sizeขนาดของผลว่าต่างกันมากน้อยแค่ไหนจริง ๆ ไม่ใช่แค่ต่างหรือไม่ต่าง
CI (Confidence Interval)ช่วงตัวเลขที่น่าจะเป็นค่าจริง บอกว่าเรามั่นใจแค่ไหน แทนที่จะให้ค่าเดียวลอย ๆ
p-hackingการลองซ้ำ ๆ หรือปรับไปเรื่อย ๆ จนได้ผลที่ดูมีนัยสำคัญ ซึ่งเป็นการหลอกตัวเอง

🧪 ตัวอย่างจริง + ผลลัพธ์ที่ได้

บังคับความเข้มงวดของ test
ฉันอยากรู้ว่ายอดขายเฉลี่ยของกลุ่ม A กับ B ต่างกันอย่างมีนัยสำคัญไหม ก่อนรัน ให้บอกฉันว่าจะใช้ test อะไร มีสมมติฐานอะไร (normality/variance เท่ากันไหม), จะรายงาน effect size และ confidence interval ด้วย ไม่ใช่แค่ p-value และตรวจสมมติฐานก่อนสรุป
✅ ผลลัพธ์ที่ได้

AI ระบุว่าจะใช้ two-sample t-test (หรือแบบ Welch ถ้าความแปรปรวนต่างกัน), จะตรวจว่าข้อมูลกระจายแบบปกติไหม (normality), รายงานผลต่างของค่าเฉลี่ย, ค่า Cohen's d และช่วงความเชื่อมั่น 95% พร้อมเตือนเรื่องการทดสอบหลายคู่พร้อมกัน (multiple comparisons) ถ้าทดสอบหลายคู่

💡 จุดสอน

การวิเคราะห์ที่ดีจะระบุ test สมมติฐาน ขนาดของผล และช่วงความเชื่อมั่น ไว้ล่วงหน้า เพราะ p-value ตัวเดียวมันไม่พอและตีความผิดกันง่าย

จับ p-hacking และ 'trending toward significance'
ฉันลองแบ่งกลุ่มหลายแบบจนได้ p=0.049 ในแบบหนึ่ง และอีกแบบได้ p=0.07 ซึ่งฉันจะเขียนว่า 'มีแนวโน้มมีนัยสำคัญ' ช่วยวิจารณ์แนวทางนี้
✅ ผลลัพธ์ที่ได้

AI เตือนว่าการลองหลาย ๆ แบบจนกว่าจะเจอ p<0.05 นั่นแหละคือ p-hacking และต้องปรับแก้เรื่องการทดสอบหลายคู่พร้อมกัน ส่วนคำว่า 'กำลังจะมีนัยสำคัญ (trending toward significance)' เป็นการตีความ p-value ที่ผิด เพราะ p=0.07 ถือว่าไม่มีนัยสำคัญตามเกณฑ์ที่ตั้งไว้

💡 จุดสอน

การตั้งสมมติฐานและเกณฑ์ไว้ก่อนเริ่มวิเคราะห์ช่วยกัน p-hacking ได้ และอย่าใช้คำกำกวมกับ p-value

แบบฝึกหัดท้ายโมดูล

  1. เอาผลวิเคราะห์เดิมมาสัก 1 ชิ้น แล้วบังคับให้ AI ระบุ test สมมติฐาน ขนาดของผล (effect size) และช่วงความเชื่อมั่น (CI) ใหม่ทั้งหมด แล้วดูว่าข้อสรุปเปลี่ยนไปไหม
  2. ลองให้ AI (ที่ตั้งค่าให้เข้มงวด) ตรวจข้อความสรุปที่มีคำว่า 'กำลังจะมีนัยสำคัญ (trending toward significance)' หรือ 'เพราะสัมพันธ์กันจึงเป็นสาเหตุ' แล้วให้แก้ให้ถูกต้อง

🎯 Mini-Project: วิเคราะห์เชิงลึกด้วย AI + semantic layer พร้อมบันทึกการ validate

  1. เลือกชุดข้อมูล (dataset) ที่มีหลายตารางเชื่อมกัน (หรือคลังข้อมูล) พร้อมคำถามเชิงธุรกิจที่ต้องเชื่อมตาราง (join) และรวมยอด (aggregate) หลายขั้น
  2. ให้ AI ช่วยร่าง (draft) pandas/SQL หรือแปลงคำถามเป็น SQL บนคู่มือข้อมูล (semantic model) ที่นิยามตัวเลขวัดผล (metric) ไว้อย่างน้อย 3 ตัว
  3. ทำการทดสอบทางสถิติอย่างน้อย 1 ครั้ง โดยระบุ test สมมติฐาน ขนาดของผล (effect size) และช่วงความเชื่อมั่น (CI) แล้วตรวจเงื่อนไขของการทดสอบด้วย
  4. สิ่งที่ต้องส่งมอบ: notebook/SQL ที่รันซ้ำแล้วได้ผลเดิม บวกเอกสารคู่มือข้อมูล (semantic model) บวกบันทึกการตรวจ (validate) ทุกตัวเลขสำคัญ บวกจุดที่ AI ให้ SQL หรือสถิติผิด พร้อมวิธีที่คุณจับได้
  5. ระบุว่าคำถามข้อไหนเสี่ยงตกไปอยู่ในโซนที่ความแม่นต่ำแบบ Spider 2.0 (ฐานข้อมูลรก/ต้องตอบหลายขั้น) แล้วคุณลดความเสี่ยงนั้นยังไง
ก้าวต่อไป

ระดับสูง: การกำกับดูแล (governance), ชั้นคู่มือข้อมูล (semantic layer), การพยากรณ์ (forecasting) และการทำตามกฎ (compliance)

ไปต่อ →