ระบบปฏิบัติการและประมวลผลโมเดล (Machine Learning & MLOps)

ทฤษฎีและกลไกการทำงาน (How it works): การนำโมเดล AI ขึ้นระบบจริง (Production) ไม่ใช่แค่การรันสคริปต์ Jupyter Notebook แต่ต้องมี Pipeline ที่ทำซ้ำได้ (Reproducible): - **Data Pipeline**: ดึงข้อมูลและคลีนข้อมูล - **Feature Pipeline**: แปลงข้อมูลเป็นฟีเจอร์และเก็บลง Feature Store - **Training Pipeline**: ดึงฟีเจอร์มาเทรนโมเดลและเก็บเข้า Registry - **Inference Pipeline**: ดึงโมเดลมาให้บริการ (Serving)

# Conceptual architecture of ML pipeline orchestration
[Raw Data] -> [Feature Pipeline] -> [Feature Store] -> [Training Pipeline] -> [Model Registry] -> [Serving API]
                    

Use Case ในชีวิตจริง (Real-world Scenario): ธนาคารรัน MLOps Pipeline ทุกสิ้นเดือนเพื่อประเมินความเสี่ยงหนี้เสีย ระบบจะดึงประวัติการโอนเงินลูกค้ามาสกัดเป็นฟีเจอร์ เทรนโมเดลใหม่ และสลับเวอร์ชันให้บริการโดยไม่มีใครต้องกดปุ่มรันมือ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): โมเดลทำงานดีตอนทดสอบแต่แย่ตอนรันจริง (Training-Serving Skew) เพราะใช้โค้ดดึงข้อมูลตอนเทรนกับตอนทำนายจริงคนละเวอร์ชัน แก้ไขโดยต้องบังคับให้ระบบเทรนและระบบรันจริง ดึงตัวแปรผ่าน Feature Store ตัวเดียวกันเท่านั้น

ทฤษฎีและกลไกการทำงาน (How it works): **Feature Store** คือคลังเก็บตัวแปรที่คำนวณเสร็จแล้ว โดยจะแยกเป็น 2 ฐานข้อมูล: - **Offline Store (เช่น Iceberg, BigQuery)**: เก็บข้อมูลย้อนหลังมหาศาล เพื่อให้ Data Scientist ดึงไปเทรนโมเดล (Batch) - **Online Store (เช่น Redis)**: ซิงก์เฉพาะค่าล่าสุดจาก Offline มาเก็บไว้ เพื่อให้ API ดึงไปทำนายผล (Inference) ด้วยความเร็วหลักมิลลิวินาที

# Feast Feature View definition configuration
from datetime import timedelta
from feast import Entity, FeatureView, Field, ValueType
from feast.types import Int64, Float32

# Entity defines the primary key matching records
customer = Entity(name="customer_id", value_type=ValueType.INT64)

customer_fv = FeatureView(
    name="customer_analytics_features",
    entities=[customer],
    ttl=timedelta(days=90),
    schema=[
        Field(name="monthly_orders_count", dtype=Int64),
        Field(name="average_transaction_value", dtype=Float32)
    ],
    source=None # Points to data lake source table
)
                    

Use Case ในชีวิตจริง (Real-world Scenario): ระบบตรวจจับบัตรเครดิตโดนแฮก ต้องคำนวณ "ระยะทางระหว่างร้านค้าร้านแรกกับร้านที่สองใน 10 นาที" ถ้าระบบ API ต้องคำนวณสดๆ จะช้าเกินไปจนแฮกเกอร์รูดสำเร็จ ระบบจึงดึงฟีเจอร์ที่คำนวณเตรียมไว้แล้วใน Redis Feature Store ออกมาตัดสินใจได้ใน 10 มิลลิวินาที

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): Online Store ข้อมูลเก่าเกินไปจนทำนายผิดพลาด (Stale Features) แก้ไขโดยตั้งจ๊อบ Streaming (เช่น Flink) หรือรัน Airflow อัปเดตข้อมูลจาก Offline สู่ Online ทุกๆ นาที (Materialization)

ทฤษฎีและกลไกการทำงาน (How it works): เมื่อเทรนโมเดลหลายร้อยรอบ เราต้องมีเครื่องมือจดบันทึกว่ารันไหนใช้พารามิเตอร์อะไรและได้ความแม่นยำเท่าไหร่ (Experiment Tracking) เมื่อได้โมเดลที่ดีที่สุด จะถูกอัปโหลดขึ้น **Model Registry** (เช่น MLflow) ซึ่งจะทำหน้าที่เหมือน Git แต่เป็นของโมเดล เพื่อประทับตราเวอร์ชัน (v1, v2) และจัดการสถานะ (Staging, Production)

# Python code to log metadata metrics and register model using MLflow
import mlflow

with mlflow.start_run():
    # 1. Log Hyperparameters
    mlflow.log_param("learning_rate", 0.01)
    # 2. Log Metrics
    mlflow.log_metric("accuracy", 0.94)
    # 3. Log model artifacts to the registry repository
    mlflow.sklearn.log_model(model, "churn-model-artifact", registered_model_name="CustomerChurnModel")
                    

Use Case ในชีวิตจริง (Real-world Scenario): โมเดลแนะนำสินค้าเวอร์ชันใหม่ (v3) ทำยอดขายตก ทีม MLOps สามารถคลิกปุ่มบน MLflow เพื่อ Rollback หรือสลับโมเดลตัวเก่า (v2) กลับมาเป็นสถานะ Production ได้ทันทีภายในคลิกเดียว

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ไม่รู้ว่าโมเดลเวอร์ชันนี้ใช้โค้ดชุดไหนเทรน (Lack of Reproducibility) แก้ไขโดยตอนที่รัน `mlflow.start_run()` ต้องส่งค่า Git Commit Hash ของโค้ด ณ เวลานั้นเข้าไปบันทึกคู่กับโมเดลเสมอ

ทฤษฎีและกลไกการทำงาน (How it works): โมเดล AI จะ "โง่ลง" เมื่อเวลาผ่านไป (Model Decay) จาก 2 สาเหตุ: - **Data Drift**: ข้อมูลขาเข้าเปลี่ยนไปจากตอนเทรน (เช่น แคมเปญใหม่ดึงดูดลูกค้าวัยรุ่นเข้ามาเยอะขึ้น) - **Concept Drift**: พฤติกรรมเป้าหมายเปลี่ยนไป (เช่น ลูกค้าไม่ซื้อของออนไลน์หลังหมดช่วงโควิด) หากระบบจับได้ว่ามีการเบี่ยงเบนทางสถิติ (Drift) จะส่งสัญญาณแจ้งเตือน และเรียก Airflow ทริกเกอร์ให้ดึงข้อมูลล็อตใหม่มาสอนโมเดล (Automated Retraining) ทันที

# Concept check script triggering retraining on drift detection alert
def check_drift_and_retrain(reference_dataset, current_dataset):
    # Perform Kolmogorov-Smirnov statistical test for drift detection
    drift_detected = calculate_ks_test(reference_dataset, current_dataset)
    if drift_detected:
        print("Data Drift Detected! Launching retraining workflow pipeline.")
        # trigger_airflow_dag("train_churn_model")
                    

Use Case ในชีวิตจริง (Real-world Scenario): ในช่วงโปรลดราคา 11.11 ระบบแนะนำสินค้าพบว่า Data Drift พุ่งทะลุเกณฑ์ เพราะพฤติกรรมการคลิกของลูกค้าบ้าคลั่งกว่าปกติ ระบบจึงดึงข้อมูลคลิกของเมื่อวานมาเทรนโมเดลใหม่สดๆ และอัปเดตโมเดลรายวันเพื่อให้ทันกระแส

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเทรนโมเดลอัตโนมัติแล้วปล่อยขึ้นโปรดักชันทันทีอาจได้โมเดลที่ห่วยลง แก้ไขโดยต้องมีด่าน A/B Testing หรือ Shadow Mode กั้นไว้ก่อนเสมอ เพื่อเทียบว่าโมเดลใหม่ทำนายได้แม่นยำกว่าโมเดลเก่าจริงหรือไม่ก่อนอนุญาตให้สลับเวอร์ชัน