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

> คำถามสัมภาษณ์ MLOps ครอบคลุมวงจรชีวิต ML การติดตามการทดลองด้วย MLflow การเลื่อนระดับใน model registry รูปแบบการนำไปใช้งาน การเฝ้าติดตาม drift และ system design สำหรับปี 2026 พร้อมโค้ด Python และคำตอบ

- Published: 2026-06-23
- Updated: 2026-07-06
- Author: Anthony Fillion-Maillet
- Tags: data-science, mlops, mlflow, machine-learning, interview
- Reading time: 9 min

---

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

> **สิ่งที่การสัมภาษณ์ MLOps ทดสอบจริง ๆ**
>
> การสัมภาษณ์ MLOps ประเมินความสามารถสามด้าน ได้แก่ ความสามารถในการทำซ้ำ (การสร้างการทดลองขึ้นมาใหม่จากพารามิเตอร์และอาร์ติแฟกต์ที่ติดตามไว้) ความปลอดภัยในการเลื่อนระดับโมเดล (การย้ายโมเดลจาก staging ไปสู่ production โดยไม่ทำให้บริการปลายทางเสียหาย) และความตระหนักในเชิงปฏิบัติการ (การตรวจจับ drift การย้อนกลับ และตัวกระตุ้นการฝึกโมเดลใหม่) ผู้สมัครที่พูดถึงเพียงความแม่นยำของโมเดลมักจะไปต่อไม่ได้ในคำถามข้อที่สอง

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

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

MLOps นำหลักการของ DevOps เช่น การทำงานอัตโนมัติ CI/CD และการเฝ้าติดตาม มาปรับใช้กับระบบ machine learning จากนั้นเพิ่มประเด็นอีกสามอย่างที่ซอฟต์แวร์แบบดั้งเดิมไม่มี ได้แก่ การกำหนดเวอร์ชันของข้อมูล การกำหนดเวอร์ชันของโมเดล และการตรวจสอบความถูกต้องอย่างต่อเนื่องเทียบกับการกระจายตัวของข้อมูลจริง ใน DevOps แบบคลาสสิก โค้ดเป็นอาร์ติแฟกต์เพียงอย่างเดียวที่เปลี่ยนแปลง แต่ใน MLOps ทั้งโค้ด ข้อมูล และโมเดลที่ฝึกแล้วต่างมีเวอร์ชันเป็นของตัวเองอย่างอิสระ และองค์ประกอบใดในสามอย่างนี้ก็สามารถทำให้คุณภาพของผลลัพธ์ลดลงอย่างเงียบ ๆ ได้โดยที่โค้ดไม่ได้เปลี่ยนแม้แต่บรรทัดเดียว งานวิจัยที่ถูกอ้างอิงบ่อยอย่าง [Hidden Technical Debt in Machine Learning Systems](https://proceedings.neurips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html) ชี้ให้เห็นว่าโค้ดของโมเดลเป็นเพียงส่วนเล็ก ๆ ของระบบ 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 กลับไปยังโค้ด พารามิเตอร์ และสแนปช็อตข้อมูลที่แน่นอนที่สร้างมันขึ้นมา สิ่งนี้เองที่ทำให้การทดลองสามารถทำซ้ำได้แม้ผ่านไปหลายเดือน

```python
# 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](/technologies/data-science/interview-questions/ml-pipelines-validation) มักได้คะแนนสูงกว่า เพราะความสามารถในการทำซ้ำขึ้นอยู่กับ 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 ใหม่แทนที่จะเปลี่ยนแปลงตัวโมเดล

```python
# 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](https://mlflow.org/docs/latest/model-registry.html) ครอบคลุมการกำกับดูแล alias และตัวกระตุ้น webhook อย่างละเอียด

> **Alias เทียบกับ Stage ในหนึ่งประโยค**
>
> Stage ตอบคำถามว่า "โมเดลนี้อยู่ในกลุ่มตายตัวใด" ในขณะที่ alias ตอบว่า "เวอร์ชันใดเป็น champion ในปัจจุบัน" ซึ่งสอดคล้องกับวิธีที่การ rollout แบบ blue-green และ canary กำหนดเส้นทางของทราฟฟิกจริง

## รูปแบบการนำ 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

```bash
# 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 แบบถ่วงน้ำหนัก

```python
# 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](https://www.evidentlyai.com/) เพื่อติดตาม 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](https://feast.dev/) มี offline store สำหรับการฝึกและ online store ที่มี latency ต่ำสำหรับการ serving การออกแบบที่สมบูรณ์ยังต้องระบุ model registry สำหรับการกำหนดเวอร์ชัน tracking server สำหรับ lineage orchestrator สำหรับ pipeline และเลเยอร์การเฝ้าติดตามที่ปิด loop กลับไปยังการฝึกโมเดลใหม่ การอ้างอิงคำตอบกับงานฟีเจอร์จริง เช่น การแลกเปลี่ยนที่กล่าวถึงใน [คู่มือสัมภาษณ์ feature engineering](/blog/data-science/feature-engineering-machine-learning-techniques-interview-2026) นี้ แสดงถึงประสบการณ์ลงมือทำจริงมากกว่าการท่องจำไดอะแกรม

> **กับดัก Training-Serving Skew**
>
> ความล้มเหลวในการออกแบบ MLOps ที่พบบ่อยที่สุดคือการคำนวณฟีเจอร์แบบหนึ่งใน training notebook และอีกแบบหนึ่งในโค้ด serving feature store มีอยู่เพื่อทำให้สิ่งนั้นเป็นไปไม่ได้โดยเฉพาะ ดังนั้นผู้สัมภาษณ์จึงคาดหวังให้มีการเอ่ยถึงมันทันทีที่คำว่า "ฟีเจอร์" ปรากฏในคำตอบด้าน system design

## บทสรุป

- มอง 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 ก่อนที่มันจะถูกยกขึ้นมาเป็นคำถามต่อเนื่อง

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/th/blog/data-science/mlops-mlflow-model-registry-interview-questions-2026