ข้อมูลผิดนิดเดียว ทำไมคำตอบสุดท้ายถึงผิดทั้งระบบ?

ลองนึกภาพว่าเราสั่งกาแฟหนึ่งแก้ว ราคา 120 บาท

แต่ตอนข้อมูลถูกบันทึกเข้าไปในระบบ กลายเป็นว่าเราสั่ง 10 แก้ว ราคา 1,200 บาท

ถ้าเกิดขึ้นกับรายการเดียว อาจดูเหมือนเป็นความผิดพลาดเล็ก ๆ ที่แก้ได้ไม่ยาก

แต่ถ้าข้อมูลนั้นไม่ได้หยุดอยู่แค่หน้าร้านล่ะ?

มันอาจถูกส่งต่อไปยังระบบบัญชี ถูกนำไปคำนวณยอดขายประจำวัน เข้า Dashboard ของผู้จัดการ ใช้เป็นข้อมูล Forecast ยอดขายเดือนหน้า หรือในบางบริษัทอาจกลายเป็นข้อมูลสำหรับสอน Machine Learning Model อีกต่อหนึ่ง

ความผิดพลาดเพียงครั้งเดียวจึงอาจไม่ได้จบลงตรงจุดที่มันเกิด

มันสามารถเดินทางต่อไปเรื่อย ๆ

จนกลายเป็นคำตอบที่ดูถูกต้อง ทั้งที่ตั้งต้นจากข้อมูลผิด

นี่คือเหตุผลที่เรื่องที่ฟังดูธรรมดาอย่าง Data Quality สำคัญกว่าที่คิดมาก

ก่อนจะพูดถึง AI เราอาจต้องถามก่อนว่า “ข้อมูลที่ให้มันเชื่อได้แค่ไหน?”

ช่วงหลายปีที่ผ่านมา เราพูดกันเยอะมากว่า AI เก่งขึ้นแค่ไหน

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

แต่มีคำถามหนึ่งที่มักถูกพูดถึงน้อยกว่า

ถ้า AI เก่งมาก แต่ข้อมูลที่เราให้มันผิดตั้งแต่แรก จะเกิดอะไรขึ้น?

คำตอบง่ายที่สุดคือ

AI ก็มีโอกาสให้คำตอบผิดอย่างมั่นใจได้เหมือนกัน

จริง ๆ แล้วปัญหานี้ไม่ได้เกิดเฉพาะกับ AI Dashboard ก็เจอได้ Machine Learning ก็เจอได้ ระบบ Recommendation ก็เจอได้ และรายงาน Excel ธรรมดาก็เจอได้

เพราะระบบเหล่านี้ทั้งหมดมีสิ่งหนึ่งเหมือนกัน

พวกมันต้องเชื่อข้อมูลบางอย่างก่อนถึงจะคำนวณคำตอบออกมาได้

ข้อมูลหนึ่งแถวเดินทางไปไหนบ้าง?

เวลาเราเห็น Dashboard สวย ๆ หรือกราฟยอดขายในบริษัท สิ่งที่เราเห็นคือปลายทาง แต่เบื้องหลังข้อมูลหนึ่งตัวเลขอาจเดินทางผ่านหลายระบบมากกว่าที่คิด

ตัวอย่างเช่น แอปขายสินค้าออนไลน์หนึ่งระบบ

ลูกค้าสั่งสินค้า
      ↓
Application / API
      ↓
Operational Database
      ↓
Data Pipeline
      ↓
Clean / Transform
      ↓
Data Warehouse
      ↓
Dashboard / ML / AI
      ↓
การตัดสินใจ

สมมติลูกค้าซื้อสินค้า 1 ชิ้น ราคา 500 บาท ข้อมูลอาจเริ่มต้นประมาณนี้

order_id: 10125
quantity: 1
price: 500
status: completed

แต่ระหว่างทางอาจเกิดอะไรขึ้นได้เยอะมาก เช่น quantity: 10, price: -500, order_id: 10125 ที่ถูกส่งเข้ามาซ้ำสองครั้ง หรือสถานะ Order ถูกบันทึกว่า completed ทั้งที่ลูกค้ายกเลิกไปแล้ว

ถ้าข้อมูลเหล่านี้เดินทางเข้า Data Warehouse โดยไม่มีใครตรวจ Dashboard ก็อาจแสดงข้อมูลผิดได้อย่างสมบูรณ์แบบ

กราฟยังสวย ระบบยังทำงาน ไม่มี Error สีแดงขึ้นมา

และนี่แหละที่ทำให้ปัญหา Data Quality น่ากลัว

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

Data Quality คืออะไร?

ถ้าแปลตรงตัว Data Quality ก็คือ คุณภาพของข้อมูล แต่คำว่า “ข้อมูลคุณภาพดี” ไม่ได้หมายความแค่ว่าไม่มีช่องว่างหรือพิมพ์ถูก

ในงานจริง เรามักมองคุณภาพข้อมูลหลายด้าน ลองดูแบบไม่ต้องเริ่มจากศัพท์เทคนิคกันก่อน

1. ข้อมูลครบไหม?

สมมติเรามีข้อมูลลูกค้า

customer_id: 152
name: Somchai
email:
country: Thailand

ช่อง Email หายไป คำถามคือมันผิดไหม? คำตอบคือ ขึ้นอยู่กับว่าจะเอาข้อมูลไปทำอะไร

ถ้า Email เป็นข้อมูลเสริม อาจไม่เป็นไร แต่ถ้าระบบต้องส่ง Receipt ผ่าน Email ทุก Order ช่องนี้ก็กลายเป็นข้อมูลสำคัญทันที

แนวคิดนี้ในงาน Data มักเรียกว่า Completeness หรือความครบถ้วนของข้อมูล

2. ข้อมูลถูกต้องไหม?

ลองดูอันนี้

age: 240

ข้อมูลไม่ได้ว่าง Database รับค่าได้ ระบบอาจไม่ Error แต่เรารู้ทันทีว่าแปลก

หรืออีกตัวอย่าง

temperature_celsius: -800

ตัวเลขเป็น Number จริง แต่ในบริบทนั้นมันเป็นค่าที่ไม่น่าเป็นไปได้ นี่คือเรื่องของ Validity และ Accuracy

ข้อมูลอาจมี Format ถูกต้อง แต่ไม่ได้แปลว่าค่านั้นสมเหตุสมผล

3. ข้อมูลซ้ำหรือเปล่า?

สมมติเรามี Order แบบนี้

ORDER-001 | 500 บาท
ORDER-002 | 900 บาท
ORDER-002 | 900 บาท

ยอดขายที่ควรเป็น 1,400 บาท อาจกลายเป็น 2,300 บาท เพียงเพราะข้อมูลถูกโหลดซ้ำ

ปัญหานี้เจอบ่อยมากใน Data Pipeline โดยเฉพาะระบบที่มีการ Retry เมื่อการส่งข้อมูลล้มเหลว การ Retry เป็นเรื่องดี เพราะช่วยให้ข้อมูลไม่หาย แต่ถ้าระบบไม่ออกแบบเรื่อง Duplicate ไว้ดีพอ การพยายามป้องกันข้อมูลหายอาจกลับสร้างข้อมูลซ้ำแทน

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

4. ข้อมูลแต่ละระบบตรงกันไหม?

สมมติระบบ CRM บอกว่า Customer 1001 = Active แต่ระบบ Billing บอกว่า Customer 1001 = Cancelled แล้วระบบ Marketing บอกว่า Customer 1001 = Trial

ทุกระบบอาจมีเหตุผลของตัวเอง แต่ถ้าจะสร้าง Dashboard ว่า “ตอนนี้บริษัทมี Active Customer กี่คน?” เราต้องตอบให้ได้ก่อนว่า ระบบไหนคือแหล่งข้อมูลหลัก?

นี่เป็นเรื่องของ Consistency และเป็นปัญหาที่ไม่ได้แก้ด้วยการเขียน SQL เก่งอย่างเดียว แต่เกี่ยวข้องกับนิยามทางธุรกิจด้วย

5. ข้อมูลใหม่พอหรือยัง?

Dashboard อาจแสดงตัวเลขถูกทุกอย่าง แต่ถ้าข้อมูลล่าสุดคือเมื่อ 6 ชั่วโมงก่อน ทั้งที่ผู้ใช้เข้าใจว่าเป็น Real-time คำตอบก็อาจผิดในเชิงการใช้งานได้เหมือนกัน

เรื่องนี้เรียกว่า Freshness

ลองคิดถึง Dashboard คลังสินค้า หน้าจอบอกว่า สินค้าคงเหลือ: 10 ชิ้น แต่ข้อมูลจริงถูกอัปเดตล่าสุดตอน 9 โมงเช้า ตอนนี้ 4 โมงเย็นแล้ว และขายไป 9 ชิ้น

ตัวเลข 10 ไม่ได้ “ผิด” ในฐานข้อมูล แต่มัน เก่าเกินไปสำหรับการตัดสินใจในตอนนี้

Data Quality จึงไม่ได้มีแค่เรื่อง Correct หรือ Incorrect บริบทของการใช้ข้อมูลสำคัญมาก

Garbage In, Garbage Out

ในสาย Computer Science มีประโยคหนึ่งที่ใช้กันมานานมากคือ Garbage In, Garbage Out ถ้าใส่ข้อมูลที่ไม่มีคุณภาพเข้าไป ระบบที่อยู่ปลายทางก็ไม่สามารถสร้างความจริงขึ้นมาเองได้

สมมติบริษัทต้องการ Forecast ยอดขายเดือนหน้า

January   = 1,000,000
February  = 1,100,000
March     = 12,000,000
April     = 1,050,000

ถ้า March สูงขึ้นจริงเพราะ Promotion ครั้งใหญ่ ข้อมูลนี้อาจถูกต้อง แต่ถ้า March จริง ๆ คือ 1,200,000 แล้วมีคนเพิ่มเลขศูนย์ผิดหนึ่งตัว Model ที่ไม่รู้บริบทก็อาจพยายามเรียนรู้จากสิ่งนั้น

มันไม่รู้ว่า “นี่น่าจะพิมพ์ผิดนะ” มันเห็นเพียง Pattern ที่อยู่ในข้อมูล และถ้าเราไม่ได้ตรวจข้อมูลก่อน ความผิดพลาดที่เริ่มต้นจากเลขศูนย์หนึ่งตัวอาจไปเปลี่ยน Forecast ทั้งหมดได้

Data Quality กับ AI เกี่ยวกันยังไง?

AI ทำให้เราสามารถสร้างคำตอบจากข้อมูลจำนวนมหาศาลได้เร็วขึ้นมาก แต่ความเร็วในการสร้างคำตอบไม่ได้ทำให้ข้อมูลต้นทางถูกขึ้นโดยอัตโนมัติ

สมมติเราสร้าง AI Assistant ภายในบริษัท พนักงานถามว่า “สินค้า A เหลือในคลังกี่ชิ้น?” AI ไป Query Database แล้วตอบว่า “เหลือ 230 ชิ้นครับ”

ฟังดูดีมาก แต่ถ้า Inventory Table ไม่ได้ Sync มา 2 วันแล้วล่ะ? ปัญหาไม่ได้อยู่ที่ Language Model

Model อาจทำงานถูกทุกขั้นตอน มันค้นข้อมูลถูก เรียก Tool ถูก อ่าน Database ถูก และสรุปออกมาถูก แต่คำตอบสุดท้ายก็ยังผิดอยู่ดี เพราะ

AI ถูก
+
ข้อมูลผิด
=
คำตอบผิด

นี่เป็นเหตุผลหนึ่งที่การสร้าง AI System ในโลกจริงไม่ใช่แค่เลือก Model ที่เก่งที่สุด เราต้องคิดถึง Data Pipeline ที่อยู่ข้างหลังด้วย

แล้ว Data Engineer ทำอะไรกับปัญหาแบบนี้?

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

แทนที่จะปล่อยข้อมูลทั้งหมดเดินทางตรงเข้า Warehouse ระบบที่ดีอาจมีจุดตรวจระหว่างทาง

Source
  ↓
Raw Data
  ↓
Quality Checks
  ↓
Clean Data
  ↓
Warehouse
  ↓
Dashboard / ML / AI

Quality Check อาจตรวจ quantity > 0, price >= 0, order_id ต้องไม่ซ้ำ, customer_id ต้องมีอยู่จริง หรือข้อมูลต้องไม่เก่ากว่า 30 นาที

ถ้าข้อมูลผ่านก็ไปต่อ ถ้าไม่ผ่านอาจถูกแยกไปไว้ที่อื่นก่อน

                     ┌──→ Valid Data → Warehouse
Raw Data → Validation
                     └──→ Invalid Data → Quarantine

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

ทำไมไม่ลบข้อมูลผิดไปเลย?

สมมติเราเจอ quantity = -15 ดูแล้วผิดแน่นอน ทำไมไม่ลบทิ้งไปเลย?

เพราะในโลกจริง สิ่งที่ดูผิดอาจมีความหมายบางอย่างซ่อนอยู่ เช่น การคืนสินค้า, Stock adjustment, Bug จากระบบต้นทาง หรือ Transaction ที่เกิดจากกระบวนการบัญชีบางอย่าง

ถ้า Data Pipeline เปลี่ยนทุกค่าติดลบเป็นศูนย์ทันที เราอาจไม่ได้ “แก้ข้อมูล” แต่อาจกำลัง ลบความหมายของข้อมูล

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

จุดที่น่าสนใจ: Data Quality ไม่ใช่ปัญหา Technical อย่างเดียว

สมมติสองทีมใช้คำว่า Active Customer

ทีม Marketing นิยามว่า ลูกค้าที่ Login ภายใน 30 วัน ทีม Finance นิยามว่า ลูกค้าที่มี Subscription ที่ยังชำระเงินอยู่ และทีม Product นิยามว่า ลูกค้าที่ใช้งาน Feature หลักอย่างน้อยหนึ่งครั้งใน 14 วัน

ทั้งสามนิยามอาจถูกทั้งหมด แต่ถ้ามีคนถามว่า “เรามี Active Customer เท่าไหร่?” SQL อาจเขียนถูกทุกบรรทัด Database อาจไม่มีข้อมูลผิดเลย แต่เรายังตอบคำถามไม่ได้อยู่ดี เพราะปัญหาคือ ความหมายของข้อมูล

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

Dashboard สวย ไม่ได้แปลว่าข้อมูลถูก

Dashboard สมัยนี้ทำให้ข้อมูลดูน่าเชื่อถือได้ง่ายมาก กราฟสวย ตัวเลขมี Animation มี Percentage เพิ่มขึ้นหรือลดลง และมี KPI สีเขียวแดงครบ

แต่หน้าตาของ Dashboard ไม่ได้บอกอะไรเกี่ยวกับคุณภาพของข้อมูลข้างหลังเลย ตัวเลข Revenue +12.4% อาจคำนวณถูกตามข้อมูลใน Warehouse ทุกอย่าง แต่ถ้า Order ถูก Duplicate เข้า Warehouse สองครั้ง Dashboard ก็จะนำเสนอคำตอบผิดได้อย่างสวยงามมาก

ดังนั้นเวลามอง Metric สำคัญ สิ่งที่น่าสนใจไม่ใช่แค่ “ตัวเลขเท่าไหร่?” แต่อีกคำถามคือ “ตัวเลขนี้มาจากไหน?”

Data Lineage: ถ้าตัวเลขผิด เราตามกลับไปได้ไหม?

ลองนึกภาพว่า CEO เปิด Dashboard แล้วพบว่ายอดขายวันนี้สูงกว่าปกติ 300% สิ่งแรกที่ต้องถามคือ “เกิดอะไรขึ้น?”

ถ้า Data Platform ไม่มีการเก็บที่มาของข้อมูล ทีมอาจต้องไล่ตรวจทีละระบบ แต่ถ้าเรารู้เส้นทางของข้อมูล

Dashboard Revenue
      ↓
fact_orders
      ↓
silver_orders
      ↓
raw_orders
      ↓
production database

เราสามารถย้อนกลับไปดูได้ว่าความผิดปกติเกิดขึ้นตั้งแต่จุดไหน แนวคิดนี้เรียกว่า Data Lineage เหมือนกับการติด Tracking Number ให้ข้อมูล ไม่ใช่แค่รู้ว่าข้อมูลมาถึงแล้ว แต่รู้ด้วยว่ามันเดินทางมาจากไหนและผ่านอะไรบ้าง

Monitoring ข้อมูลก็สำคัญพอ ๆ กับ Monitoring Server

เวลาเราทำระบบ Software เรามัก Monitor CPU, Memory, Latency และ Error Rate แต่ใน Data Platform เราควร Monitor ข้อมูลด้วย

ตัวอย่างเช่น จำนวน Order วันนี้ลดลง 80% ระบบไม่ได้ล่ม CPU ปกติ Database ปกติ API ปกติ และ Pipeline Run สำเร็จ แต่ข้อมูลอาจหายไปครึ่งหนึ่ง

ดังนั้น

Pipeline Status = SUCCESS

ไม่ได้แปลว่า

Data = Correct

ระบบอาจทำงานสำเร็จทุกขั้นตอน แต่ผลลัพธ์ทางธุรกิจยังผิดได้

แล้วเราจะรู้ได้ยังไงว่าข้อมูล “ดีพอ”?

ไม่มี Data Quality ที่สมบูรณ์แบบสำหรับทุกระบบ ความเข้มงวดขึ้นอยู่กับผลกระทบ

ถ้าระบบแนะนำหนังผิดหนึ่งเรื่อง ผลกระทบอาจน้อยมาก แต่ถ้าเป็น Fraud Detection ระบบการเงิน Medical System Inventory ของโรงงาน หรือระบบ Safety ความผิดพลาดเพียงเล็กน้อยอาจมีต้นทุนสูงกว่าเยอะ

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

จาก Data Quality ไปสู่ Data Trust

สุดท้ายแล้ว สิ่งที่องค์กรต้องการอาจไม่ใช่ Data เยอะที่สุด แต่คือ ข้อมูลที่คนกล้าใช้ตัดสินใจ

ถ้าทุกครั้งที่เปิด Dashboard คนในทีมต้องถามว่า “ตัวเลขนี้เชื่อได้ไหม?”, “วันนี้ Pipeline พังอีกหรือเปล่า?” หรือ “ยอดจาก Finance กับ Dashboard ทำไมไม่เท่ากัน?” สิ่งที่หายไปไม่ใช่แค่คุณภาพข้อมูล แต่คือ ความเชื่อมั่นในข้อมูล

และเมื่อคนไม่เชื่อ Dashboard พวกเขาก็จะกลับไปสร้าง Excel ของตัวเอง

dashboard_final.xlsx
dashboard_final_v2.xlsx
dashboard_final_revised.xlsx
dashboard_final_REAL.xlsx

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

แล้ว AI จะช่วยแก้ Data Quality ได้ไหม?

ช่วยได้บางส่วน AI สามารถช่วย Detect anomaly, Suggest schema mapping, หา Duplicate, วิเคราะห์ Missing Data, ช่วยสร้าง Validation Rule และอธิบายว่าทำไม Pipeline บางจุดถึงผิดปกติ

แต่ AI ไม่สามารถตัดสินความหมายทางธุรกิจแทนเราได้ทั้งหมด

AI อาจเห็นว่า quantity = -5 ผิดปกติ แต่ไม่รู้ว่าบริษัทของเรานิยามค่าติดลบว่าเป็น Return หรือ Error

ดังนั้นอนาคตของ Data Engineering อาจไม่ใช่ “AI มาแทน Data Engineer” แต่เป็น “AI ช่วย Data Engineer ตรวจสอบระบบที่ซับซ้อนขึ้นได้เร็วกว่าเดิม” ส่วนการตัดสินใจว่าข้อมูลอะไรควรเชื่อและอะไรมีความหมายต่อธุรกิจยังต้องอาศัยทั้ง Engineering และความเข้าใจ Domain อยู่ดี

สิ่งที่ได้เรียนรู้จากการทำ Data Platform

เวลาสร้าง Data Project เรามักตื่นเต้นกับส่วนปลายทาง เช่น Dashboard, Machine Learning, AI, Visualization หรือ Real-time Analytics เพราะมันเป็นส่วนที่เห็นผลลัพธ์ได้ง่าย

แต่สิ่งที่ใช้เวลามากอย่างหนึ่งกลับเป็นเรื่องที่ดูธรรมดากว่า

• ข้อมูลซ้ำหรือไม่
• Schema เปลี่ยนหรือเปล่า
• Null นี้ยอมรับได้ไหม
• ข้อมูลใหม่พอหรือยัง
• Pipeline Run ซ้ำแล้วเกิดอะไรขึ้น
• ถ้า Source ส่งข้อมูลผิดมา เราควรทำอย่างไร
• ถ้า Transformation พัง เราจะย้อนกลับไปตรวจตรงไหน

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

ข้อมูลผิดนิดเดียว อาจไม่ผิด “นิดเดียว”

กลับมาที่กาแฟแก้วแรกของเรา จาก 1 แก้ว กลายเป็น 10 แก้ว ตอนแรกมันเป็นเพียง Record หนึ่งแถว แต่ถ้าไม่มีใครตรวจ มันอาจเดินทางต่อไปเป็น

Wrong Order
   ↓
Wrong Revenue
   ↓
Wrong Dashboard
   ↓
Wrong Forecast
   ↓
Wrong Decision

ความผิดพลาดใน Data System จึงมีลักษณะคล้าย Domino จุดเริ่มต้นอาจเล็กมาก แต่ผลลัพธ์ขึ้นอยู่กับว่ามีระบบอะไรนำข้อมูลนั้นไปใช้ต่ออีกบ้าง

คุณภาพของข้อมูลต้นทางจึงสำคัญขึ้นเมื่อข้อมูลถูกใช้เพื่อให้ Machine Learning และ AI ช่วยตัดสินใจ

ก่อนเชื่อคำตอบ ลองถามว่าข้อมูลมาจากไหน

เวลาเราเห็น Dashboard, AI Answer หรือ Prediction มีคำถามง่าย ๆ ชุดหนึ่งที่น่าถามเสมอ

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

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

ก่อนถามว่า AI ตอบเก่งแค่ไหน เราอาจต้องถามก่อนว่า ข้อมูลที่มันกำลังเชื่ออยู่ น่าเชื่อถือแค่ไหน

Takeaway

1. ระบบทำงานสำเร็จ ไม่ได้แปลว่าข้อมูลถูก

Pipeline สามารถ Run ผ่านทุกขั้นตอนพร้อมกับส่งข้อมูลผิดไปปลายทางได้

2. Data Quality ไม่ได้มีแค่ Null หรือ Duplicate

มันรวมถึงความถูกต้อง ความครบถ้วน ความสม่ำเสมอ ความสดใหม่ และความหมายทางธุรกิจ

3. Dashboard และ AI ไม่สามารถแก้ข้อมูลต้นทางที่ผิดได้เองเสมอไป

คำตอบที่ดูน่าเชื่อถืออาจสร้างมาจากข้อมูลที่ไม่น่าเชื่อถือ

4. Quality Check ควรเกิดก่อนข้อมูลถูกนำไปใช้

ยิ่งตรวจพบปัญหาเร็ว ต้นทุนในการแก้ก็มักยิ่งต่ำ

5. เป้าหมายสุดท้ายไม่ใช่ข้อมูลที่สมบูรณ์แบบ แต่คือ Data Trust

ข้อมูลที่คนรู้ว่ามาจากไหน เข้าใจข้อจำกัด และกล้าใช้มันในการตัดสินใจ

อ่านต่อ

ถ้าสนใจว่าแนวคิดเหล่านี้ถูกนำไปใช้ใน Data Platform จริงอย่างไร ผมมีโปรเจกต์ RetailGuard Data Platform ที่ลองพาข้อมูลตั้งแต่ Raw Data, Validation และ Quality Gate ไปจนถึง Warehouse และ Reporting โดยให้แถวที่มีปัญหาหยุดก่อนถึงรายงาน