MLOps ในปี 2026: MLflow, Model Registry และคำถามสัมภาษณ์เชิงเทคนิค

คำถามสัมภาษณ์ด้าน MLOps ได้เปลี่ยนจากทักษะเฉพาะทางที่พบไม่บ่อย มาเป็นส่วนสำคัญของการรับสมัครงานสาย Data Science และ Machine Learning Engineering ในปี 2026 ทีมงานไม่ได้ถามเพียงว่าโมเดลถูกฝึกอย่างไรอีกต่อไป แต่ยังเจาะลึกถึงวิธีการติดตาม การกำหนดเวอร์ชัน การนำไปใช้งาน และการเฝ้าติดตามโมเดลเมื่อมีทราฟฟิกจริงเข้ามา บทความนี้จะพาไปทำความเข้าใจคำถามที่มักปรากฏในการสัมภาษณ์ MLOps โดยจัดกลุ่มตามขั้นตอนของวงจรชีวิต พร้อมตัวอย่าง MLflow ที่สะท้อนการตั้งค่าในระบบจริง

คำถามสัมภาษณ์ MLOps เกี่ยวกับวงจรชีวิต Machine Learning

Q1: MLOps คืออะไร และแตกต่างจาก DevOps อย่างไร

MLOps นำหลักการของ DevOps เช่น การทำงานอัตโนมัติ CI/CD และการเฝ้าติดตาม มาปรับใช้กับระบบ machine learning จากนั้นเพิ่มประเด็นอีกสามอย่างที่ซอฟต์แวร์แบบดั้งเดิมไม่มี ได้แก่ การกำหนดเวอร์ชันของข้อมูล การกำหนดเวอร์ชันของโมเดล และการตรวจสอบความถูกต้องอย่างต่อเนื่องเทียบกับการกระจายตัวของข้อมูลจริง ใน DevOps แบบคลาสสิก โค้ดเป็นอาร์ติแฟกต์เพียงอย่างเดียวที่เปลี่ยนแปลง แต่ใน MLOps ทั้งโค้ด ข้อมูล และโมเดลที่ฝึกแล้วต่างมีเวอร์ชันเป็นของตัวเองอย่างอิสระ และองค์ประกอบใดในสามอย่างนี้ก็สามารถทำให้คุณภาพของผลลัพธ์ลดลงอย่างเงียบ ๆ ได้โดยที่โค้ดไม่ได้เปลี่ยนแม้แต่บรรทัดเดียว งานวิจัยที่ถูกอ้างอิงบ่อยอย่าง Hidden Technical Debt in Machine Learning Systems ชี้ให้เห็นว่าโค้ดของโมเดลเป็นเพียงส่วนเล็ก ๆ ของระบบ ML จริง โดยมี data pipeline การเฝ้าติดตาม และการตั้งค่าครอบครองพื้นที่ส่วนใหญ่

Q2: อธิบายขั้นตอนต่าง ๆ ของวงจรชีวิต ML ในระบบ production

คำตอบที่ดีจะระบุห้าขั้นตอนพร้อมอาร์ติแฟกต์ที่แต่ละขั้นตอนสร้างขึ้น ได้แก่ การนำเข้าและตรวจสอบข้อมูล (ชุดข้อมูลที่มีเวอร์ชัน) การทดลอง (การรันที่ถูกติดตามพร้อม metric) การลงทะเบียนโมเดล (โมเดลที่มีเวอร์ชันและพร้อมเลื่อนระดับ) การนำไปใช้งาน (serving endpoint หรือ batch job) และการเฝ้าติดตาม (ข้อมูลเชิงวัดของ drift และประสิทธิภาพที่ป้อนกลับเข้าสู่การฝึกโมเดลใหม่) ผู้สัมภาษณ์จะฟังหา feedback loop กล่าวคือ การเฝ้าติดตามต้องเชื่อมโยงกลับไปยังการทดลอง มิฉะนั้นระบบจะกลายเป็น pipeline ทางเดียวที่เสื่อมสภาพลงเมื่อเวลาผ่านไป

การติดตามการทดลองด้วยตัวอย่างจาก MLflow Tutorial

การติดตามการทดลองเป็นรากฐานที่คำถาม MLOps ส่วนใหญ่ต่อยอดขึ้นมา ดังนั้นคำตอบแบบ MLflow tutorial ที่แสดงการบันทึกจริงจึงมีน้ำหนัก MLflow บันทึกพารามิเตอร์ metric และอาร์ติแฟกต์ในแต่ละการรัน ซึ่งทำให้ผลลัพธ์ใด ๆ สามารถทำซ้ำได้จาก run ID

Q3: MLflow tracking บันทึกการทดลองอย่างไร และเหตุใด run ID จึงสำคัญ

การเรียก mlflow.start_run() แต่ละครั้งจะเปิดการรันที่บันทึก hyperparameter, metric และโมเดลที่ถูกซีเรียลไลซ์ run ID คือ handle ที่ไม่เปลี่ยนแปลงซึ่งผูก metric กลับไปยังโค้ด พารามิเตอร์ และสแนปช็อตข้อมูลที่แน่นอนที่สร้างมันขึ้นมา สิ่งนี้เองที่ทำให้การทดลองสามารถทำซ้ำได้แม้ผ่านไปหลายเดือน

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

อาร์กิวเมนต์ name เข้ามาแทนที่ artifact_path ที่ถูกเลิกใช้ใน MLflow 3.x ซึ่งเป็นการเปลี่ยนแปลงที่ควรกล่าวถึงเพื่อแสดงว่าเข้าใจ API ปัจจุบัน ผู้สมัครที่อ้างอิงถึงการติดตามฟีเจอร์และชุดข้อมูลผ่าน รูปแบบการตรวจสอบ ML pipeline มักได้คะแนนสูงกว่า เพราะความสามารถในการทำซ้ำขึ้นอยู่กับ pipeline ทั้งหมด ไม่ใช่แค่โมเดลเท่านั้น

Model Registry 2026: การกำหนดเวอร์ชันและการเลื่อนระดับ

MLflow Model Registry เปลี่ยนอาร์ติแฟกต์ของการรันให้กลายเป็นออบเจ็กต์ที่มีการกำกับดูแลและพร้อมเลื่อนระดับ การเปลี่ยนแปลงครั้งใหญ่ล่าสุดและเป็นคำถามสัมภาษณ์ที่พบบ่อยในปี 2026 คือการย้ายออกจากการใช้ stage แบบมีชื่อ

Q4: MLflow Model Registry เลื่อนระดับโมเดลอย่างไร และมีอะไรเปลี่ยนแปลงในปี 2026

MLflow เวอร์ชันก่อนหน้าเลื่อนระดับโมเดลผ่าน stage แบบตายตัวที่ชื่อว่า Staging, Production และ Archived แต่ MLflow 3.x เลิกใช้ stage เหล่านั้นและหันมาใช้ alias และ tag แทน เพราะรายการ stage ที่กำหนดตายตัวไม่สามารถแสดง topology การนำไปใช้งานจริงอย่าง champion, challenger หรือ shadow ได้ alias คือตัวชี้ที่เปลี่ยนแปลงได้ซึ่งชี้ไปยังเวอร์ชันหนึ่ง ดังนั้นการเลื่อนระดับจึงกลายเป็นการกำหนด alias ใหม่แทนที่จะเปลี่ยนแปลงตัวโมเดล

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

เนื่องจากผู้ใช้งานโหลด models:/churn-classifier@champion การย้อนกลับจึงเป็นเพียงการกำหนด alias ใหม่ไปยังเวอร์ชันก่อนหน้า โดยไม่ต้อง redeploy เอกสารทางการของ MLflow Model Registry ครอบคลุมการกำกับดูแล alias และตัวกระตุ้น webhook อย่างละเอียด

รูปแบบการนำ Machine Learning ไปใช้งานและการ Serving

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

Q5: เปรียบเทียบการนำ machine learning ไปใช้งานแบบ batch, online และ streaming

| รูปแบบ | Latency | กรณีใช้งานทั่วไป | รูปแบบการ Serving | |---------|---------|------------------|-----------------| | Batch | หลายชั่วโมงถึงรายวัน | การให้คะแนน churn, การรีเฟรชคำแนะนำ | งานตามกำหนดเวลาที่เขียนลงตาราง | | Online (เรียลไทม์) | หลักสิบมิลลิวินาที | การตรวจสอบการฉ้อโกง, การจัดอันดับ ณ เวลาที่ร้องขอ | REST หรือ gRPC endpoint | | Streaming | ต่ำกว่าหนึ่งวินาที ต่อเนื่อง | การตรวจจับความผิดปกติในกระแสเหตุการณ์ | Consumer บน message queue |

คำถามต่อเนื่องมักถามเสมอว่าจะ serve กรณี online อย่างไร โมเดล MLflow บรรจุสภาพแวดล้อมของตัวเองมาด้วย ดังนั้นการ serve จึงเป็นเพียงคำสั่งเดียวที่อ้างอิงไปยัง registry URI

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: การนำไปใช้งานแบบ blue-green และ canary ช่วยลดความเสี่ยงในการ rollout โมเดลอย่างไร

Blue-green จะรักษาสภาพแวดล้อมที่เหมือนกันสองชุดและสลับทราฟฟิกทั้งหมดในคราวเดียวหลังจากโมเดลใหม่ผ่านการตรวจสอบ ซึ่งให้เส้นทางการย้อนกลับได้ทันที ส่วน canary จะกำหนดเส้นทางทราฟฟิกส่วนน้อยไปยังเวอร์ชันใหม่ เฝ้าดู metric แบบเรียลไทม์ แล้วค่อย ๆ เพิ่มสัดส่วน สำหรับโมเดล canary มักปลอดภัยกว่า เพราะปัญหาคุณภาพของโมเดลจะปรากฏก็ต่อเมื่อเจอกับอินพุตจริงเท่านั้น และ canary จำกัดขอบเขตความเสียหายให้อยู่กับผู้ใช้เพียงส่วนน้อย

การทดสอบและ CI/CD สำหรับ Machine Learning Pipeline

Q7: CI/CD ใน ML pipeline ทดสอบอะไรที่ pipeline ซอฟต์แวร์ทั่วไปไม่ได้ทดสอบ

CI pipeline ของซอฟต์แวร์รัน unit test และ integration test บนโค้ด แต่ ML pipeline เพิ่มการทดสอบข้อมูลและโมเดลเข้าไปด้วย ได้แก่ การตรวจสอบ schema ของข้อมูลที่เข้ามา การตรวจสอบการกระจายตัวเพื่อไม่ให้การฝึกดึงฟีเจอร์ที่เสียหายเข้ามาอย่างเงียบ ๆ และ quality gate ของโมเดลที่ทำให้ build ล้มเหลวเมื่อโมเดลผู้ท้าชิงทำคะแนนได้ต่ำกว่า champion ปัจจุบันบนชุด holdout ที่กำหนดไว้ ดังนั้น continuous delivery สำหรับ ML จึงเลื่อนระดับอาร์ติแฟกต์ของโมเดล ไม่ใช่แค่ container image และเกณฑ์การเลื่อนระดับคือเกณฑ์ค่า metric ไม่ใช่เพียงชุดทดสอบที่ผ่านสีเขียวเท่านั้น pipeline ที่เข้มงวดยังตรึงสแนปช็อตข้อมูลและเวอร์ชันของ dependency ไว้ เพื่อให้การรันซ้ำใด ๆ ให้ผลลัพธ์แบบ deterministic ซึ่งเป็นสิ่งที่แยก build ที่ทำซ้ำได้ออกจาก build ที่บังเอิญผ่านในวันนี้

การเฝ้าติดตาม Data Drift และการฝึกโมเดลใหม่

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

Q8: ตรวจจับ data drift อย่างไร และ metric ใดใช้วัดปริมาณของมัน

Data drift หมายถึงการกระจายตัวของอินพุตใน production ได้เคลื่อนออกจากการกระจายตัวของข้อมูลที่ใช้ฝึก Population Stability Index (PSI) เป็นตัววัดที่ใช้กันทั่วไปและไม่ผูกกับเฟรมเวิร์กใด ๆ โดยจะแบ่งการกระจายตัวอ้างอิงออกเป็น bin เปรียบเทียบความถี่ของ production กับ bin เหล่านั้น แล้วรวมผลต่างของ log แบบถ่วงน้ำหนัก

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

นอกเหนือจาก metric ที่เขียนขึ้นเอง ทีม production มักหันไปใช้เครื่องมืออย่าง Evidently เพื่อติดตาม feature drift, target drift และคุณภาพข้อมูลตามกำหนดเวลา คำตอบที่สมบูรณ์จะแยกแยะระหว่าง data drift (อินพุตเปลี่ยน) กับ concept drift (ความสัมพันธ์ระหว่างอินพุตกับเอาต์พุตเปลี่ยน) เพราะอย่างหลังไม่สามารถตรวจจับได้ด้วยการเฝ้าดูอินพุตเพียงอย่างเดียว และต้องอาศัยผลลัพธ์ที่มี label

Q9: อะไรควรเป็นตัวกระตุ้น retraining pipeline

การฝึกโมเดลใหม่ตามเวลาในรอบที่กำหนดตายตัวเป็นทางเลือกที่ง่ายที่สุด แต่สิ้นเปลืองทรัพยากรประมวลผลเมื่อไม่มีอะไรเปลี่ยนแปลง และตอบสนองช้าเมื่อมีบางอย่างเสียหาย ตัวกระตุ้นที่ดีกว่าคือแบบอิงตาม metric ได้แก่ ฝึกใหม่เมื่อ PSI เกินเกณฑ์ เมื่อ metric การประเมินแบบเรียลไทม์ตกต่ำกว่าค่าขั้นต่ำ หรือเมื่อ backtest ตามกำหนดเวลาบนข้อมูลที่เพิ่ง label ใหม่ให้ผลถดถอย งานฝึกใหม่จะลงทะเบียนโมเดลผู้ท้าชิง ซึ่งการ rollout แบบ canary จะนำไปเปรียบเทียบกับ champion ปัจจุบันก่อนที่จะมีการกำหนด alias ใหม่

คำถามสัมภาษณ์ System Design ด้าน MLOps

Q10: ออกแบบแพลตฟอร์มที่ serve โมเดลหลายร้อยตัวด้วยฟีเจอร์ที่สอดคล้องกัน

ศูนย์กลางที่คาดหวังคือ feature store ซึ่งแก้ปัญหา training-serving skew ด้วยการคำนวณฟีเจอร์เพียงครั้งเดียวและส่งค่าที่เหมือนกันให้ทั้งการฝึกและการอนุมาน เครื่องมืออย่าง Feast มี offline store สำหรับการฝึกและ online store ที่มี latency ต่ำสำหรับการ serving การออกแบบที่สมบูรณ์ยังต้องระบุ model registry สำหรับการกำหนดเวอร์ชัน tracking server สำหรับ lineage orchestrator สำหรับ pipeline และเลเยอร์การเฝ้าติดตามที่ปิด loop กลับไปยังการฝึกโมเดลใหม่ การอ้างอิงคำตอบกับงานฟีเจอร์จริง เช่น การแลกเปลี่ยนที่กล่าวถึงใน คู่มือสัมภาษณ์ feature engineering นี้ แสดงถึงประสบการณ์ลงมือทำจริงมากกว่าการท่องจำไดอะแกรม

บทสรุป

• มอง MLOps ว่าเป็น DevOps บวกกับการกำหนดเวอร์ชันของข้อมูลและโมเดล ความสามารถในการทำซ้ำ ความปลอดภัยในการเลื่อนระดับ และการเฝ้าติดตาม คือสามแกนที่ผู้สัมภาษณ์ให้คะแนน
• รู้จักการเปลี่ยน API ของ MLflow 3.x โดย alias และ tag เข้ามาแทน stage Staging และ Production ที่ถูกเลิกใช้ และ log_model ตอนนี้รับ name แทน artifact_path
• จับคู่รูปแบบการนำไปใช้งานกับงบประมาณด้าน latency และเลือก canary มากกว่า blue-green เป็นค่าเริ่มต้นสำหรับการ rollout โมเดล เพราะปัญหาคุณภาพจะปรากฏก็ต่อเมื่อเจอกับอินพุตจริงเท่านั้น
• วัดปริมาณ drift ด้วย metric ที่เป็นรูปธรรมอย่าง PSI และแยกแยะ data drift ออกจาก concept drift เพราะมีเพียงอย่างเดียวเท่านั้นที่มองเห็นได้โดยไม่ต้องมี label
• กระตุ้นการฝึกใหม่ด้วย metric แทนที่จะอิงตามปฏิทิน และส่งโมเดลผู้ท้าชิงที่ได้ผ่าน canary ก่อนที่จะกำหนด alias champion ใหม่
• เอ่ยถึง feature store ในคำตอบ system design ใด ๆ เพื่อปิดช่องว่าง training-serving skew ก่อนที่มันจะถูกยกขึ้นมาเป็นคำถามต่อเนื่อง