Statistical Anomaly Detection & Data Drift
Anomaly & Drift Detection
การตรวจจับความผิดปกติของข้อมูลและการเปลี่ยนแปลงของรูปแบบข้อมูล (Data/Concept Drift)
1. Statistical Anomaly Detection
⚙️ทฤษฎีและกลไกการทำงาน
คือการใช้สถิติและ Machine Learning เพื่อหาข้อมูลที่ผิดไปจากปกติ (Outliers):
- Z-Score: หาความเบี่ยงเบนของข้อมูลแต่ละตัวจากค่าเฉลี่ย เหมาะสำหรับข้อมูลที่มีการกระจายแบบปกติ (Normal Distribution)
- Isolation Forest: ใช้วิธีสุ่มแบ่งพื้นที่ข้อมูล จุดที่เป็น Anomaly จะถูกแยกออกจากกลุ่มได้ง่าย (ใช้ความลึกของต้นไม้น้อยกว่า)
💻ตัวอย่างโค้ดหรือการตั้งค่า
ตัวอย่างการใช้ Isolation Forest (Python + scikit-learn):
from sklearn.ensemble import IsolationForest
import numpy as np
data = np.array([[10], [12], [11], [100], [13], [12]])
model = IsolationForest(contamination=0.1) # คาดว่ามี outlier 10%
model.fit(data)
# -1 คือ Anomaly, 1 คือ Normal
predictions = model.predict(data)
print(predictions) # [ 1 1 1 -1 1 1]🌍Use Case ในชีวิตจริง
ระบบตรวจสอบยอดการโอนเงินรายวันของธนาคาร ปกติเฉลี่ยที่ 1 ล้านบาทต่อชั่วโมง แต่วันนี้พุ่งไป 50 ล้านบาทในชั่วโมงเดียว ระบบตรวจจับด้วย Z-Score หรือ Isolation Forest จะส่ง alert ให้ทีม fraud ตรวจสอบทันที
⚠️ข้อควรระวังและวิธีแก้
Pitfall: การใช้ Z-Score กับข้อมูลที่ไม่ใช่ Normal Distribution ทำให้เกิด False Positives สูงมาก
Mitigation: ตรวจสอบการกระจายข้อมูลก่อนเสมอ หากข้อมูลเบี้ยวให้ใช้วิธี Non-parametric อย่าง Isolation Forest หรือแปลงข้อมูลด้วย Log Transformation ก่อน
2. Data Drift vs Concept Drift (KS-Test)
⚙️ทฤษฎีและกลไกการทำงาน
- Data Drift: ข้อมูลขาเข้าเปลี่ยนการกระจายตัว (เช่น อายุลูกค้าจากเดิม 20-30 กลายเป็น 40-50)
- Concept Drift: ความสัมพันธ์ระหว่าง Input กับ Output เปลี่ยนไป (เช่น พฤติกรรมซื้อของช่วง Covid แตกต่างจากปกติ)
เรามักใช้ KS-Test (Kolmogorov-Smirnov Test) เพื่อวัดว่า Distribution ของข้อมูลใหม่กับข้อมูลเดิมแตกต่างกันอย่างมีนัยสำคัญทางสถิติหรือไม่
💻ตัวอย่างโค้ดหรือการตั้งค่า
ตรวจจับ Drift ด้วย KS-Test:
from scipy.stats import ks_2samp
# Reference data (อดีต) vs Current data (ปัจจุบัน)
reference_data = np.random.normal(loc=0, scale=1, size=1000)
current_data = np.random.normal(loc=0.5, scale=1, size=1000)
statistic, p_value = ks_2samp(reference_data, current_data)
if p_value < 0.05:
print("Drift Detected! Data distributions are different.")🌍Use Case ในชีวิตจริง
บริษัท E-commerce นำโมเดลแนะนำสินค้าไปใช้ แต่พอผ่านไป 6 เดือน โมเดลแม่นยำน้อยลง Data Engineer รัน KS-Test และพบ Data Drift ในฟีเจอร์ "ช่องทางการจ่ายเงิน" เนื่องจากมี E-wallet ใหม่เข้ามาตีตลาด ทำให้ต้องเทรนโมเดลใหม่
⚠️ข้อควรระวังและวิธีแก้
Pitfall: การตรวจจับ Drift ส่ง alert บ่อยเกินไปเพราะปัจจัยตามฤดูกาล (Seasonality) เช่น ยอดขายช่วงปีใหม่พุ่งสูงจนถูกมองเป็น Drift
Mitigation: ปรับเทียบ baseline เฉพาะหน้าเทศกาล (เทียบธันวาปีนี้ กับ ธันวาปีที่แล้ว) หรือสร้างเงื่อนไขละเว้น alert ช่วงเทศกาล
🛠️Weekend Sandbox Challenge
เป้าหมาย: สร้าง Python script ตรวจจับ Data Drift ของชุดข้อมูลจำลอง
- สร้างชุดข้อมูล 2 ชุด (Baseline และ Current) ด้วย numpy.random
- ใช้ scipy.stats.ks_2samp ตรวจสอบว่า p-value บ่งบอกถึงความต่างหรือไม่
- เปลี่ยน parameter (mean, std) ของชุด Current ให้ห่างจาก Baseline และรันโค้ดอีกครั้งเพื่อสังเกตผล
🗣️Senior Technical Interview Q&As
Q: คุณจะเลือกใช้ Isolation Forest หรือ Z-Score ในสถานการณ์ไหน?
A: หากข้อมูลเป็นตัวแปรเดียว (Univariate) และรู้แน่ชัดว่าเป็น Normal Distribution การใช้ Z-Score จะรวดเร็วและเบามาก แต่ถ้าข้อมูลมีหลายมิติ (Multivariate) และการกระจายตัวซับซ้อน หรือมี noise เยอะ Isolation Forest จะจับความผิดปกติที่เกิดจากผลรวมของหลายๆ ฟีเจอร์ได้ดีกว่า
Q: ทำไม Concept Drift ถึงตรวจจับยากกว่า Data Drift และแก้ไขอย่างไร?
A: Data Drift ตรวจจากข้อมูลขาเข้า (X) ได้เลยโดยไม่ต้องรอผลลัพธ์ แต่ Concept Drift คือความสัมพันธ์ระหว่าง (X, Y) เปลี่ยน ซึ่งเราต้องรอ Ground Truth (Y จริง) ถึงจะคำนวณ Error ได้ การแก้คือต้องออกแบบระบบให้ได้รับ Ground Truth กลับมาให้เร็วที่สุด (Feedback Loop) และมอนิเตอร์ Model Accuracy แทนแค่ Data Distribution
Deep Dive & Production Architecture
🟢 Basic Level (ปูพื้นฐานภาษาเข้าใจง่าย / Core Concepts)
ทฤษฎีและกลไกการทำงาน (Theory & Mechanism): แนวคิดพื้นฐานของการวางโครงสร้างระบบให้ทำงานได้อย่างถูกต้อง ตั้งแต่การเชื่อมต่อเครือข่าย การกำหนดขอบเขตทรัพยากร ไปจนถึงการสื่อสารระหว่างส่วนประกอบต่างๆ ในระบบคลาวด์
ตัวอย่างโค้ดหรือการตั้งค่า (Code/Config Example): โครงสร้างการตั้งค่าเบื้องต้น
# Basic Structural Configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: basic-system-config
data:
mode: "development"
log_level: "info"Use Case ในชีวิตจริง (Real-world Scenario): ระบบแอปพลิเคชันภายในองค์กร หรือบริการทั่วไปที่มีปริมาณการใช้งานคงที่ ที่เน้นความง่ายในการจัดการและแก้ไขปัญหา
ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การละเลยการตั้งค่าความปลอดภัยพื้นฐาน แนะนำให้ใช้เครื่องมือตรวจสอบอัตโนมัติ (Linter/Scanner) ตั้งแต่ขั้นตอนการพัฒนา
🟡 Intermediate Level (โค้ด/คอนฟิกไวยากรณ์จริง / Real Implementation)
ทฤษฎีและกลไกการทำงาน (Theory & Mechanism): การออกแบบสถาปัตยกรรมระดับกลางที่คำนึงถึงความทนทาน (Resiliency) การขยายตัว (Scalability) และการควบคุมเส้นทางการส่งข้อมูลเครือข่ายอย่างมีประสิทธิภาพ
ตัวอย่างโค้ดหรือการตั้งค่า (Code/Config Example): การกำหนด Network Policy และ Resource Limits
# Intermediate Access Control & Scaling
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: api-gateway-policy
spec:
podSelector:
matchLabels:
role: api
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
project: myprojectUse Case ในชีวิตจริง (Real-world Scenario): แพลตฟอร์มอีคอมเมิร์ซที่มียอดผู้ใช้งานเพิ่มขึ้นแบบฉับพลันในบางช่วงเวลา (Spike Traffic) เช่น ช่วงแคมเปญส่งเสริมการขาย
ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การคอนฟิก Policy ผิดพลาดอาจทำให้ Service ตัดขาดจากระบบ เฝ้าระวังด้วยการทดสอบการเชื่อมต่อ (Connectivity Test) ทุกครั้งที่เปลี่ยนค่า
🔴 Professional Level (Under-the-hood & Performance/FinOps)
ทฤษฎีและกลไกการทำงาน (Theory & Mechanism): การวิเคราะห์เชิงลึกไปถึงการทำงานระดับ Kernel (เช่น eBPF) และการทำ Optimization ทรัพยากรคลาวด์ พร้อมกับการนำแนวคิด FinOps มาใช้ควบคุมค่าใช้จ่ายโดยไม่ลดทอนประสิทธิภาพ
ตัวอย่างโค้ดหรือการตั้งค่า (Code/Config Example): การปรับจูน Resource ควบคู่กับ HPA และ Node Affinity
# Professional FinOps & Performance Tuning
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: high-performance-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: data-processor
minReplicas: 3
maxReplicas: 150
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 80
behavior:
scaleDown:
stabilizationWindowSeconds: 300Use Case ในชีวิตจริง (Real-world Scenario): ระบบ Streaming Data Platform ระดับโลกที่ต้องประมวลผลข้อมูลระดับ Petabytes ต่อวัน พร้อมจัดการ Cost Optimization ขั้นสูง
ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเกิด OOMKilled แบบเงียบๆ หรือปัญหา Cloud Cost Spikes ควรตั้งแจ้งเตือนผ่าน Budget Alerts และทำ Profiling ประสิทธิภาพแอปพลิเคชันอย่างสม่ำเสมอ
🏢 Real-World Enterprise Scenario (เคสระบบการเงิน/Big Tech)
ทฤษฎีและกลไกการทำงาน (Theory & Mechanism): โครงสร้างระบบสำหรับองค์กรขนาดใหญ่ที่เน้น Multi-Region Active-Active, การทำ Disaster Recovery (DR) อัตโนมัติ, และการปฏิบัติตามมาตรฐานความปลอดภัยขั้นสูงสุด (Compliance & Governance)
ตัวอย่างโค้ดหรือการตั้งค่า (Code/Config Example): Infrastructure as Code (IaC) สำหรับ Enterprise Environment
# Enterprise Multi-AZ Infrastructure
module "enterprise_core_network" {
source = "terraform-aws-modules/vpc/aws"
version = "~> 5.0"
name = "prod-banking-core-vpc"
cidr = "10.100.0.0/16"
azs = ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"]
private_subnets = ["10.100.1.0/24", "10.100.2.0/24", "10.100.3.0/24"]
public_subnets = ["10.100.101.0/24", "10.100.102.0/24", "10.100.103.0/24"]
enable_nat_gateway = true
single_nat_gateway = false
one_nat_gateway_per_az = true
enable_vpn_gateway = true
}Use Case ในชีวิตจริง (Real-world Scenario): ระบบ Core Banking ของธนาคารข้ามชาติ หรือระบบ Payment Gateway ที่ต้องมี Uptime 99.999% และห้ามมีข้อมูลสูญหาย (Zero Data Loss)
ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ความล้มเหลวระดับศูนย์ข้อมูล (Data Center Outage) แก้ไขด้วยสถาปัตยกรรม Multi-Region failover อัตโนมัติ และซ้อมแผน Disaster Recovery ทุกไตรมาส